dubbo使用（dubbo使用注解方式注入）

本篇文章给大家谈谈dubbo使用，以及dubbo使用注解方式注入对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Dubbo的基本使用
• 2、dubbo泛化调用使用及原理解析
• 3、dubbo 中使用 ThreadLocal 隐患

Dubbo的基本使用

官网地址：

如果在消费端和服务端都配置了负载均衡策略，以消费端为准。

在服务提供者和服务消费者上都可以配置服务超时时间，这两者是不一样的。

消费者调用一个服务，分为三步：

1.消费者发送请求（饥旁网络传输）

2.服务端执行服务

3.服务端返回响应（网络传输）

如果在服务端和消费端各配置了一个timeout，那就比较复杂了，假设

1.服务执行为5s

2.消费端timeout=3s

3.服务端timeout=6s

那么消费端掉用服务时，消费端会收到超时异常（因为消费端超时了），服务端一切正常（服务端没有超时）。

官网地址：

集群容错表示：服务消费者在掉用某个服务时，这个服务有多个服务提供烂埋橡者，在经过负载均衡后选择其中一个服务提供者之后进液顷行调用，但调用报错后，Dubbo所采取的后续处理策略。

官网地址：

服务降级表示：服务消费者在调用某个服务提供者时，如果该服务提供者报错了，所采取的措施。

集群容错和服务降级的区别在于：

1.集群容错时整个集群范围内的容错

2.服务降级时单个服务提供者的自身容错

官网地址：

本地存根：名字很抽象，但实际上不难理解，本地存根就是一段逻辑，这段逻辑是在服务消费端执行的，这段逻辑一般都是由服务提供者提供，服务提供者可以利用这种机制在服务消费者远程调用服务提供者之前或之后再做一些其他事情，比如结果缓存，请求参数验证等等。

官网地址：

本地伪装就是Mock，Dubbo中的Mock的功能相对于本地存根更简单一点，Mock其实就是Dubbo中的服务容错的解决方案。

官网地址：

如果当前服务支持参数回调，意思就是对于某个服务接口中的某个方法，如果想支持消费者在调用这个方式时能设置回调逻辑，那么该方法就是需要提供一个入参用来表示回调逻辑

因为Dubbo协议是基于长连接，所以消费者在两次调用同一个方法想指定不同的回调逻辑，那么就需要在调用时在指定一定key进行区分。

官网地址：

理解起来比较容易，主要要理解CompletableFuture，如果不理解，就直接把它理解为Future

其他异步调用方式：

官网地址：

泛化调用可以用来做服务测试。

在Dubbo中，如果某个服务想要支持泛化调用，就可以将该服务的generic属性设置为true，那对于服务消费者来说，就可以不用依赖该服务的接口，直接利用GenericService接口来进行服务调用

官网地址：

实现了GenericService接口就是泛化服务

官网地址：

github地址：

官网地址：

注意动态配置修改的是服务参数，并不能修改服务的协议,IP,PORT,VERSION,GROUP,因为这5个信息是服务的标识信息，是服务的身份证号，是不能修改的。

官网地址：

dubbo泛化调用使用及原理解析

通常我们想调用别人的dubbo服务时，我们需要在项目中引入对应的jar包。而泛化调用的作用是，我们无需依赖相关jar包，也能调用到该服务。

这个特性一般使用在网关类项目中，在业务开发中基本不会使用。

假设我现在要调用下面的接口服务

在xml文件做以下配置

然后注入使用

在两种调用方式中，我们都需要使用被调用接口的字符串参数生成GenericService，通过GenericService的$invoke间接调用目标接口的接口。

$invoke的三个参数分别为，方法名，方法参数类型数组，方法参数数组。

可以看到泛化调厅并用的一个复杂性弊伏唤在于$invoke的第三个参数的组装，下面介绍几种复杂入参的调用方式

首先丰富提供者接口

与入参相似，虽然$invoke的返回定义为Object，实际上针对不同类型有不同的返回。

泛化调用和直接调用在消费者者端，在 使用上的区别 是，我们调用服务时使用的接口为GenericService，方法为$invoker。在 底层的区别 是，消费者端发出的rpc报文发生了变化。

在使用上，不管哪种配置方式，我们都需要配置generic=true

设置generic=true后，RefereceConfig的interfaceClass会被强制设置为GenericService

这也使得我们的RefereanceBean返回的是GenericService类型的代理。

生成的代理是GenericService的代理只是我们使用方式上的变化，更为核心的是，底层发送的rpc报文发生了什么变化。

Dubbo的rpc报文分为header和body两部分。我们这边只需要关注body部分。构造逻辑如下

那么我们通过直接调用与泛化调用ByeService的bye方法在报文上有啥区别呢？

我一开始以为报文中的path是GenericeService，其实并没有，path就是我们调用的目标方法。

path来源？？？todo

而报文中的方法名，方法参数类型以及具体参数，还是按照GenericeService的$invoke方法入参传递的。

这么个二合一的报文，发送到提供者那边，它估计也会很懵逼，我应该怎么执行？

所以针对泛化调用报文还会把generic=true放在attchment中传递过去

具体逻辑在GenericImplFilter中。

GenericImplFilter中有很多其他逻辑，比如泛化调用使用的序列化协议，正常接口走泛化调用的模式，我们只需要设置attachment的那部分。

知道消费者端报文发生了什么变化，那么接下来就去看提供者端如何处理这个改造后的报文。

总结一下ReferenceConfig中interfaceClass和interfaceName的区别？(这道面试题好像不错)

interfaceClass用于指定生成代理的接口

interfaceName用于指定发送rpc报文中的path(告诉服务端我要调用那个服务)

消费者泛化调用的rpc报文传递到提供者还不能直接使用，虽然path是对的，但是实际的方法名，参数类型，参数要从rpc报文的参数中提取出来。

GenericFilter就是用来做这件事情。

在提供者这边，针对泛化调用的逻辑全部封装到了GenericFilter，解耦的非常好。

注意第4个条件，一开始很疑惑，后来发现rpc报文中的path是目标接口的，这边invoker.getInterface()返回的肯定就是实际接口了

这边有个疑问，为什么这边还要再次反序列化一次，netty不是有decoder么？？

嗯，你别忘了，针对一个POJO你传过来是一个Map，从Map转换为POJO需要这边进一步处理。

这边需要注意一下！！针对接口的泛化调用，抛出的异常都会经过GenericException包装一下。

从功能上来看，泛化调用提供了在没有接口依赖情况下进行的解决方案，丰富框架的使用场景。

从设计上来看，泛化调用的功能还是通租凯过扩展的方式实现的，侵入性不强，值得学习借鉴。

[img]

dubbo 中使用 ThreadLocal 隐患

在 Dubbo 中使用 ThreadLocal ，如果采用默认的设置，每次 Dubbo 调用结束，Dubbo 处理响应线程并不会被销毁， 而是归还到迅没线程池中。而从 ThreadLocal 源码可裤唯以看出，每次我们设置的值其实会存在位于 Thread 中 ThreadLocalMap 变量中。

这就导致，下次如果 Dubbo 处理响应恰好继续使用到这个线程，该线程就能调用到上次响应中设置在 ThreadLocal 设置的值。这就引起内存泄露，可能还会导致业务上异常。其实并不止在 Dubbo 中，该案例还会发生在 web项目中，只要相关使用线程池的，都有可能发生。

dubbo 默认采用单一长连接加线程池方式处理调用。

默认采取 Dispatcher=all 的分发策略，所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。

线程池在缺省配置为固定大小线程池，启动时建立线程，不关闭，一直持有。胡昌培

使用 Threadlocal，我们需要注意几点：

调整线程池大小配置是

dubbo.protocol.threads = 5000

调整线程池类型配置是

dubbo.protocol.threadpool = cached

调整事件处理方式配置是

dubbo.protocol.dispatcher = message

或者

dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" /

关于dubbo使用和dubbo使用注解方式注入的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。