分布式-dubbo

Dear 丶 2022-09-04 03:45 193阅读 0赞

# 一、dubbo概述 #

## 1.1 什么是dubbo ##

Apache Dubbo 是一款微服务开发框架，它提供了 RPC通信 与 微服务治理 两大关键能力。这意味着，使用 Dubbo 开发的微服务，将具备相互之间的远程发现与通信能力， 同时利用 Dubbo 提供的丰富服务治理能力，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。同时 Dubbo 是高度可扩展的，用户几乎可以在任意功能点去定制自己的实现，以改变框架的默认行为来满足自己的业务需求。

## 1.2 dubbo的流程图 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tpbmcxMzEyNw_size_16_color_FFFFFF_t_70][]

上面这张图是很经典的dubbo流程图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tpbmcxMzEyNw_size_16_color_FFFFFF_t_70 1][]

调用流程:

1.  服务提供者在服务容器启动时，向注册中心注册自己提供的服务
2.  服务消费者在启动时，向注册中心注册自身和订阅自己所需的服务
3.  注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心会基于长连接推送变更数据给消费者
4.  服务消费者从提供者地址列表中，基于软负载均衡算法选一台提供者进行调用，如果调用失败，则重新选择一台服务提供者和消费者
5.  在内存中的调用次数和调用时间，定时每分钟发送给监控中心

# 二、Dubbo的配置项 #

## 2.1 dubbo:application ##

对应 org.apache.dubbo.config.ApplicationConfig, 代表当前应用的信息

1.  name: 当前应用程序的名称，在dubbo-admin中我们也可以看到，这个代表这个应用名称。我们在真正时是时也会根据这个参数来进行聚合应用请求。
2.  owner: 当前应用程序的负责人，可以通过这个负责人找到其相关的应用列表，用于快速定位到责任人。
3.  qosEnable : 是否启动QoS ，默认true
4.  qosPort : 启动QoS绑定的端口 默认22222
5.  qosAcceptForeignIp: 是否允许远程访问 默认是false

## 2.2 dubbo:registry ##

对应org.apache.dubbo.config.RegistryConfig, 代表该模块所使用的注册中心。一个模块中的服务可以将其注册到多个注册中心上，也可以注册到一个上。后面再service和reference也会引入这个注册中心。

1.  id : 当当前服务中provider或者consumer中存在多个注册中心时，则使用需要增加该配置。在一些公司，会通过业务线的不同选择不同的注册中心，所以一般都会配置该值。
2.  address : 当前注册中心的访问地址。
3.  protocol : 当前注册中心所使用的协议是什么。也可以直接在 address 中写入，比如使用zookeeper，就可以写成 zookeeper://xx.xx.xx.xx:2181
4.  timeout : 当与注册中心不再同一个机房时，大多会把该参数延长。

## 2.3 dubbo:protocol ##

对应org.apache.dubbo.config.ProtocolConfig, 指定服务在进行数据传输所使用的协议。

1.  id : 在大公司，可能因为各个部门技术栈不同，所以可能会选择使用不同的协议进行交互。这里在多个协议使用时，需要指定。
2.  name : 指定协议名称。默认使用 dubbo 。

## 2.4 dubbo:service ##

对应org.apache.dubbo.config.ServiceConfig, 用于指定当前需要对外暴露的服务信息。

1.  interface : 指定当前需要进行对外暴露的接口是什么。
2.  ref : 具体实现对象的引用，一般我们在生产级别都是使用Spring去进行Bean托管的，所以这里面一般也指的是Spring中的BeanId。
3.  version : 对外暴露的版本号。不同的版本号，消费者在消费的时候只会根据固定的版本号进行消费。
4.  mock: 用于在方法调用出现错误时，当做服务降级来统一对外返回结果。
5.  timeout: 用于指定当前方法或者接口中所有方法的超时时间。我们一般都会根据提供者的时长来具体规定。比如我们在进行第三方服务依赖时可能会对接口的时长做放宽，防止第三方服务不稳定导致服务受损。
6.  check: 用于在启动时，检查生产者是否有该服务。我们一般都会将这个值设置为false，不让其进行检查。因为如果出现模块之间循环引用的话，那么则可能会出现相互依赖，都进行check的话，那么这两个服务永远也启动不起来。
7.  retries: 用于指定当前服务在执行时出现错误或者超时时的重试机制。注意提供者是否有幂等，否则可能出现数据一致性问题。
8.  cluster: 属于集群容村配置，用于指定请求失败后的处理策略，包含了failfast(失败立即报错,通常用于非幂等性的写操作，默认)、failsafe(出现异常时直接忽略。通常用于写入审计日志等操作)、failback(后台记录失败请求，定时重发。通常用于消息通知操作)、forking(并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 `forks="2"` 来设置最大并行数。)。

## 2.5 dubbo:reference ##

对应org.apache.dubbo.config.ReferenceConfig, 消费者的配置，这里只做简单说明，后面会具体讲解。

1.  id : 指定该Bean在注册到Spring中的id。
2.  interface: 服务接口名
3.  version : 指定当前服务版本，与服务提供者的版本一致。
4.  registry : 指定所具体使用的注册中心地址。这里面也就是使用上面在 dubbo:registry 中所声明的id。
5.  mock: 用于在方法调用出现错误时，当做服务降级来统一对外返回结果，后面我们也会对这个方法做更多的介绍。
6.  timeout: 用于指定当前方法或者接口中所有方法的超时时间。我们一般都会根据提供者的时长来具体规定。比如我们在进行第三方服务依赖时可能会对接口的时长做放宽，防止第三方服务不稳定导致服务受损。
7.  check: 用于在启动时，检查生产者是否有该服务。我们一般都会将这个值设置为false，不让其进行检查。因为如果出现模块之间循环引用的话，那么则可能会出现相互依赖，都进行check的话，那么这两个服务永远也启动不起来。
8.  retries: 用于指定当前服务在执行时出现错误或者超时时的重试机制。注意提供者是否有幂等，否则可能出现数据一致性问题。
9.  cluster: 属于集群容村配置，用于指定请求失败后的处理策略，包含了failfast(失败立即报错,通常用于非幂等性的写操作，默认)、failsafe(出现异常时直接忽略。通常用于写入审计日志等操作)、failback(后台记录失败请求，定时重发。通常用于消息通知操作)、forking(并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 `forks="2"` 来设置最大并行数。)。

## 2.6 dubbo:method ##

对应org.apache.dubbo.config.MethodConfig, 用于在制定的 dubbo:service 或者dubbo:reference 中的更具体一个层级，指定具体方法级别在进行RPC操作时候的配置，可以理解为对这上面层级中的配置针对于具体方法的特殊处理。

1.  name : 指定方法名称，用于对这个方法名称的RPC调用进行特殊配置。
2.  async: 是否异步 默认false

# 三、dubbo高级特性 #

## 3.1 SPI ##

Java中如果想要使用SPI功能，先提供标准服务接口，然后再提供相关接口实现和调用者。这样就可以通过SPI机制中约定好的信息进行查询相应的接口实现。JDK的SPI遵循如下约定：

*  当服务提供者提供了接口的一种具体实现后，在META-INF/services目录下创建一个以“接口全限定名”为命名的文件，内容为实现类的全限定名；
 *  接口实现类所在的jar包放在主程序的classpath中；
 *  主程序通过java.util.ServiceLoader动态装载实现模块，它通过扫描META-INF/services目录下的配置文件找到实现类的全限定名；，把类加载到JVM；
 *  SPI的实现类必须携带一个无参构造方法

但是JDK 标准的 SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源，如果有扩展点加载失败，则所有扩展点无法使用。所以dubbo在spi基础上自己实现了一套SPI机制，但大致流程一致，同时提供了对扩展点包装的功能(Adaptive)，并且还支持通过set的方式对其他的扩展点进行注入。

dubbo中大量的使用了SPI来作为扩展点，通过实现同一接口的前提下，可以进行定制自己的实现类。比如比较常见的协议，Filter，负载均衡策略，都可以通过SPI的方式进行定制化，自己扩展。Dubbo中已经存在的所有已经实现好的扩展点。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tpbmcxMzEyNw_size_16_color_FFFFFF_t_70 2][]

Dubbo中的Adaptive功能，主要解决的问题是如何动态的选择具体的扩展点。通过  
getAdaptiveExtension 统一对指定接口对应的所有扩展点进行封装，通过URL的方式对扩展点来进行动态选择。 (dubbo中所有的注册信息都是通过URL的形式进行处理的。)这里同样采用相同的方式进行实现。下面以实现Filter为例讲解（Dubbo的Filter机制，是专门为服务提供方和服务消费方调用过程进行拦截设计的，每次远程方法执行，该拦截都会被执行。这样就为开发者提供了非常方便的扩展性，比如为dubbo接口实现ip白名单功能、监控功能 、日志记录等。），步骤如下：

1.  实现 org.apache.dubbo.rpc.Filter 接口
2.  使用 org.apache.dubbo.common.extension.Activate 接口进行对类进行注册 通过group 可以指定生产端 消费端 如:@Activate(group = \{CommonConstants.CONSUMER)
3.  Filter逻辑代码实现
4.  在 META-INF.dubbo 中新建 org.apache.dubbo.rpc.Filter 文件，并将当前类的全名写入
5.  在使用该Filter的服务生产端或者消费端 进行依赖引入。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tpbmcxMzEyNw_size_16_color_FFFFFF_t_70 3][]

## 3.2 负载均衡 ##

在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为 `random` 随机调用，也可以自行扩展负载均衡策略。dubbo提供的负载均衡策略如下：

*  Random **随机**，按权重设置随机概率。
 *  RoundRobin **轮询**，按公约后的权重设置轮询比率。
 *  LeastActive **最少活跃调用数**，相同活跃数的随机，活跃数指调用前后计数差。
 *  ConsistentHash **一致性 Hash**，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

使用负载均衡可以客户端或者服务端配置接口或者方法：

#服务端服务级别
    <dubbo:service interface="..." loadbalance="roundrobin" />
    #客户端服务级别
    <dubbo:reference interface="..." loadbalance="roundrobin" />

## 3.3 异步调用 ##

Dubbo不只提供了堵塞式的的同步调用，同时提供了异步调用的方式。这种方式主要应用于提供者接口响应耗时明显，消费者端可以利用调用接口的时间去做一些其他的接口调用,利用 Future 模式来异步等待和获取结果即可。这种方式可以大大的提升消费者端的利用率。 目前这种方式可以通过XML的方式进行引入，主要通过修改dubbo:reference的async属性。方法在同步调用时的返回值是空，我们可以通过 RpcContext.getContext().getFuture() 来进行获取Future对象来进行后续的结果等待操作。

>     <dubbo:reference id="helloService" interface="com.XXX.service.HelloService">
>       <dubbo:method name="sayHello" async="true" />
>     </dubbo:reference>

## 3.4 线程模型-dubbo线程池 ##

![dubbo-protocol][]

dubbo在使用时，都是通过创建真实的业务线程池进行操作的。遇到事件处理逻辑较慢，或者需要发起新的 IO 请求，比如需要查询数据库，则必须派发到线程池，否则 IO 线程阻塞，将导致不能接收其它请求。

使用方式：

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

Dispatcher：

*  `all` 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。
 *  `direct` 所有消息都不派发到线程池，全部在 IO 线程上直接执行。
 *  `message` 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
 *  `execution` 只有请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
 *  `connection` 在 IO 线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。

ThreadPool：

*  `fixed` 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)
 *  `cached` 缓存线程池，空闲一分钟自动删除，需要时重建。
 *  `limited` 可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。
 *  `eager` 优先创建`Worker`线程池。在任务数量大于`corePoolSize`但是小于`maximumPoolSize`时，优先创建`Worker`来处理任务。当任务数量大于`maximumPoolSize`时，将任务放入阻塞队列中。阻塞队列充满时抛出`RejectedExecutionException`。(相比于`cached`:`cached`在任务数量超过`maximumPoolSize`时直接抛出异常而不是将任务放入阻塞队列)

## 3.5 服务动态降级 ##

服务降级，当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务有策略的降低服务级别，以释放服务器资源，保证核心任务的正常运行。而为什么要使用服务降级，这是防止分布式服务发生雪崩效应，什么是雪崩？就是蝴蝶效应，当一个请求发生超时，一直等待着服务响应，那么在高并发情况下，很多请求都是因为这样一直等着响应，直到服务资源耗尽产生宕机，而宕机之后会导致分布式其他服务调用该宕机的服务也会出现资源耗尽宕机，这样下去将导致整个分布式服务都瘫痪，这就是雪崩。

dubbo有两种方式实现服务降级，一个是控制管理台，一个是配置。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tpbmcxMzEyNw_size_16_color_FFFFFF_t_70 4][]

屏蔽和容错：

*  mock=force:return+null 表示消费方对该服务的方法调用都直接返回 null 值，不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
 *  mock=fail:return+null 表示消费方对该服务的方法调用在失败后，再返回 null 值，不抛异常。用来容忍不重要服务不稳定时对调用方的影响。

#配置的方式实现容错
    <dubbo:reference id="xxService" check="false" interface="com.xx.XxService"
    timeout="3000" mock="return null" />
    <dubbo:reference id="xxService2" check="false" interface="com.xx.XxService2"
    timeout="3000" mock="return 1234" />
    
    #注解方式
    @Reference(mock="return null") @Reference(mock="return 简单值")，也支持@Reference(mock="force:return null")

# 四、dubbo源码剖析 #

## 4.1 架构整体设计 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tpbmcxMzEyNw_size_16_color_FFFFFF_t_70 5][]

在开篇我们简单介绍过这几个组件，这里详细说明一下：

1.Provider: 暴露服务的服务提供方  
Protocol 负责提供者和消费者之间协议交互数据  
Service 真实的业务服务信息 可以理解成接口 和 实现  
Container Dubbo的运行环境  
2.Consumer: 调用远程服务的服务消费方  
Protocol 负责提供者和消费者之间协议交互数据  
Cluster 感知提供者端的列表信息  
Proxy 可以理解成 提供者的服务调用代理类 由它接管 Consumer中的接口调用逻辑  
3.Registry: 注册中心，用于作为服务发现和路由配置等工作，提供者和消费者都会在这里进行注册  
4.Monitor: 用于提供者和消费者中的数据统计，比如调用频次，成功失败次数等信息。

启动和执行流程说明:

1.  提供者端启动容器负责把Service信息加载，并通过Protocol 注册到注册中心
2.  消费者端启动，通过监听提供者列表来感知提供者信息，并在提供者发生改变时，通过注册中心及时通知消费端
3.  通过Proxy模块消费方发起请求
4.  利用Cluster模块来选择真实的要发送给的提供者信息
5.  交由Consumer中的Protocol 把信息发送给提供者
6.  提供者同样需要通过Protocol 模块来处理消费者的信息
7.  最后由真正的服务提供者Service 来进行处理

## 4.2 整体的调用链路 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tpbmcxMzEyNw_size_16_color_FFFFFF_t_70 6][]

整体链路调用的流程:

1.  消费者通过Interface进行方法调用，统一交由消费者端的Proxy，过ProxyFactory 来进行代理对象的创建（使用到了jdk和javassist的动态代理技术）
2.  交给Filter这个模块做一个统一的过滤请求
3.  接下来会进入最主要的Invoker调用逻辑：第一步通过Directory 去配置中新读取信息，最终通过list方法获取所有的Invoker；第二步通过Cluster模块，根据选择的具体路由规则来选取Invoker列；第三部通过LoadBalance模块，根据负载均衡策略选择一个具体的Invoker 来处理我们的请求，如果执行中出现错误并且Consumer阶段配置了重试机制，则会重新尝试执行
4.  继续经过Filter 进行执行功能的前后封装 Invoker 选择具体的执行协议
5.  客户端 进行编码和序列化 然后发送数据
6.  到达Consumer中的 Server 在这里进行 反编码 和 反序列化的接收数据
7.  使用Exporter选择执行器
8.  交给Filter 进行一个提供者端的过滤 到达 Invoker 执行器
9.  通过Invoker 调用接口的具体实现 然后返回

## 4.3 Dubbo源码整体设计 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tpbmcxMzEyNw_size_16_color_FFFFFF_t_70 7][]

图例说明：

*  图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口。
 *  图中从下至上分为十层，各层均为单向依赖，右边的黑色箭头代表层之间的依赖关系，每一层都可以剥离上层被复用，其中，Service 和 Config 层为 API，其它各层均为 SPI。
 *  图中绿色小块的为扩展接口，蓝色小块为实现类，图中只显示用于关联各层的实现类。
 *  图中蓝色虚线为初始化过程，即启动时组装链，红色实线为方法调用过程，即运行时调时链，紫色三角箭头为继承，可以把子类看作父类的同一个节点，线上的文字为调用的方法。

分层介绍:

### 4.3.1 Business 业务逻辑层 ###

service业务层包括我们的业务代码，比如接口、实现类。

### 4.3.2 RPC层 远程过程调用层 ###

主要分为：

*  config 配置层 对外提供配置 以ServiceConfig ReferenceConfig 为核心 可以直接初始化配置类 也可以解析配置文件生成
 *  proxy 服务代理层 无论是生产者 还是消费者 框架都会产生一个代理类 整个过程对上层透明 就是业务层对远程调用无感
 *  registry 注册中心层 封装服务地址的注册与发现 以服务的URL为中心
 *  cluster 路由层 (集群容错层) 提供了多个提供者的路由和负载均衡 并且它桥接注册中心 以Invoker为核心
 *  monitor 监控层 RPC调用相关的信息 如 调用次数 成功失败的情况 调用时间等 在这一层完成
 *  protocol 远程调用层 封装RPC调用 无论是服务的暴露 还是 服务的引用 都是在Protocol中作为主功能入口 负责Invoker的整个生命周期 Dubbo中所有的模型都向Invoker靠拢

### 4.3.3 Remoting层 远程数据传输层 ###

主要分为：

*  exchange 信息交换层 封装请求和响应的模式 如把请求由同步 转换成异步
 *  transport 网络传输层 统一网络传输的接口 比如 netty 和 mina 统一为一个网络传输接口
 *  serialize 数据序列化层 负责管理整个框架中的数据传输的序列化 和反序列化

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tpbmcxMzEyNw_size_16_color_FFFFFF_t_70]: /images/20220829/6dda1fb2b99849d483d6cc99988c046a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tpbmcxMzEyNw_size_16_color_FFFFFF_t_70 1]: /images/20220829/0d2e6728f41244229ef190caccc1c0d8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tpbmcxMzEyNw_size_16_color_FFFFFF_t_70 2]: /images/20220829/bb23eb53fb1c4655a428243154aec1f5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tpbmcxMzEyNw_size_16_color_FFFFFF_t_70 3]: /images/20220829/f7e20f858fd04a6398ed082c27f9496d.png
[dubbo-protocol]: /images/20220829/977d93ac8c2f4e56abae13d1a47d35bc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tpbmcxMzEyNw_size_16_color_FFFFFF_t_70 4]: /images/20220829/604ae8ff9c394433b7fee7024dd61bf4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tpbmcxMzEyNw_size_16_color_FFFFFF_t_70 5]: /images/20220829/f683c2c71cad4e8494ff9ca205230b52.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tpbmcxMzEyNw_size_16_color_FFFFFF_t_70 6]: /images/20220829/1523bc55091a4b0da214724bbfedb3ae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tpbmcxMzEyNw_size_16_color_FFFFFF_t_70 7]: /images/20220829/0e1f3142183c4626b0bfd02486ca9a0e.png