Dubbo架构理解

Dubbo架构理解

架构整体设计

Dubbo调用关系说明

在这里主要由四部分组成:

• Provider: 暴露服务的服务提供方

Protocol 负责提供者和消费者之间协议交互数据
Service 真实的业务服务信息 可以理解成接口 和 实现
Container Dubbo的运行环境

• Consumer: 调用远程服务的服务消费方

Protocol 负责提供者和消费者之间协议交互数据
Cluster 感知提供者端的列表信息
Proxy 可以理解成 提供者的服务调用代理类，由它接管 Consumer 中的接口调用逻辑

• Registry: 注册中心，用于作为服务发现和路由配置等工作，提供者和消费者都会在这里进行注册
• Monitor: 用于提供者和消费者中的数据统计，比如调用频次，成功失败次数等信息。

启动和执行流程说明:

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

整体的调用链路

业务逻辑层 RPC层(远程过程调用) Remoting (远程数据传输)
整体链路调用的流程:

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

Dubbo源码整体设计

右边的黑色箭头代表层之间的依赖关系，每一层都可以剥离上层被复用，其中，Service 和 Config 层为 API，其它各层均为 SPI。

分层介绍:
Business 业务逻辑层

• service 业务层 包括业务代码 比如 接口 实现类 直接面向开发者

RPC层 远程过程调用层

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

Remoting层 远程数据传输层

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

服务注册与消费源码剖析

注册中心Zookeeper目录结构

例如：只有一个提供者和消费者。 com.lagou.service.HelloService 为我们所提供的服务。

Zookeeper的目录结构如下：

• consumers: 当前服务下面所有的消费者列表(URL)
• providers: 当前服务下面所有的提供者列表(URL)
• configuration: 当前服务下面的配置信息信息，provider或者consumer会通过读取这里的配置信息来获取配置
• routers: 当消费者在进行获取提供者的时，会通过这里配置好的路由来进行适配匹配规则。

• 提供者会在 providers 目录下进行自身的进行注册。
• 消费者会在 consumers 目录下进行自身注册，并且监听 provider 目录，以此通过监听提供者增加或者减少，实现服务发现。
• Monitor模块会对整个服务级别做监听，用来得知整体的服务情况。以此就能更多的对整体情况做监控。

服务的注册过程分析

服务注册(暴露)过程

首先 ServiceConfig 类拿到对外提供服务的实际类 ref（具体的接口实现类），然后通过 ProxyFactory 接口实现类中的 getInvoker 方法使用 ref 生成一个 AbstractProxyInvoker 实例，到这一步就完成具体服务到 Invoker 的转化。接下来就是 Invoker 转换到 Exporter 的过程。

查看 ServiceConfifig 类，重点查看 ProxyFactory 和 Protocol 类型的属性 以及 ref

---

服务注册暴露时序图：

Registry中的类目录结构

• 每个层级代表继承自父级
• 这里面 RegistryService 就是对外提供注册机制的接口。
• 其下面 Registry 也同样是一个接口，是对 RegistryService 的集成，并且继承了 Node 接口，说明注册中心也是基于URL去做的。
• AbstractRegistry 是对注册中心的封装，其主要会对本地注册地址的封装，主要功能在于远程注册中心不可用的时候，可以采用本地的注册中心来使用。
• FailbackRegistry 从名字中可以看出来，失败自动恢复，后台记录失败请求，定时重发功能。
• 最深的一层则更多是真实的第三方渠道实现。

URL规则详解 和 服务本地缓存

URL规则详解

服务本地缓存

dubbo调用者需要通过注册中心（例如：ZK）注册信息，获取提供者，但是如果频繁往从ZK获取信息，肯定会存在单点故障问题，所以dubbo提供了将提供者信息缓存在本地的方法。
Dubbo在订阅注册中心的回调处理逻辑当中会保存服务提供者信息到本地缓存文件当中（同步/异步两种方式），以URL纬度进行全量保存。
Dubbo在服务引用过程中会创建registry对象并加载本地缓存文件，会优先订阅注册中心，订阅注册中心失败后会访问本地缓存文件内容获取服务提供信息。

构建流程：

1. 初始化AbstractRegistry构造函数，并且从系统中读取已有的配置信息。

1. 方法notify(url.getBackupUrls()) ->notify(url, listener, filterEmpty(url, urls)) -> saveProperties(url)，通过寻找，这个属性的设置值只有在一个地方: saveProperties ，这里也有基于版本号的的更改

1. doSaveProperties(long version)，最终缓存的保存方法。

Dubbo 消费过程分析

首先 ReferenceConfig 类的 init 方法调用 createProxy() ,期间 使用 Protocol 调用 refer 方法生 成 Invoker 实例(如上图中的红色部分)，这是服务消费的关键。接下来使用ProxyFactory把 Invoker 转换为客户端需要的接口

Dubbo扩展SPI源码剖析

getExtensionLoader 加载过程

注：

• cachedAdaptiveClass: 当前Extension类型对应的AdaptiveExtension类型(只能一个)
• cachedWrapperClasses: 当前Extension类型对应的所有Wrapper实现类型(无顺序)
• cachedActivates: 当前Extension实现自动激活实现缓存(map,无序)
• cachedNames: 扩展点实现类对应的名称（如配置多个名称则值为第一个）
• **getExtension获取扩展点的方法 **
• injectExtension注入其他扩展点的实体，用于扩展点和其他的扩展点相互打通(set的方式注入)

Adaptive功能实现原理

Adaptive的主要功能是对所有的扩展点进行封装为一个类，通过URL传入参数的时动态选择需要使用的扩展点。其底层的实现原理就是动态代理。

createAdaptiveExtensionClass()方法生成具体的Adaptive代理对象，通过AdaptiveClassCodeGenerator下的generate()方法做将具体的接口实现类重新做字符串拼接插入需要提前调用的方法和URL参数判断，最后通过org.apache.dubbo.common.compiler.Compiler 将字符串编译成class文件。

private Class<?> createAdaptiveExtensionClass() {
   
    
    String code = new AdaptiveClassCodeGenerator(type, cachedDefaultName).generate();
    ClassLoader classLoader = findClassLoader();
    org.apache.dubbo.common.compiler.Compiler compiler = 	
        ExtensionLoader.getExtensionLoader(org.apache.dubbo.common.compiler.Compiler.class)
        .getAdaptiveExtension();
    return compiler.compile(code, classLoader);
}

**

集群容错源码剖析

集群容错的组件包含 Cluster、 Cluster Invoker、Directory、Router 和 LoadBalance 等。

集群工作过程可分为两个阶段：

• 第一个阶段是在服务消费者初始化期间，集群 Cluster 实现类为服务消 费者创建 Cluster Invoker 实例，即上图中的 merge 操作。
• 第二个阶段是在服务消费者进行远程调用时。以FailoverClusterInvoker为例：
  1. 该类型ClusterInvoker首先会调用Directory的list方法列举Invoker列表（可将Invoker简单理解为服务提供者）。Directory的用途是保存Invoker列表，可简单类比为List。其实现类RegistryDirectory是一个动态服务目录，可感知注册中心配置的变化，它所持有的Invoker列表会随着注册中心内容的变化而变化。
  2. 每次变化后，RegistryDirectory会动态增删Invoker，并调用Router的route方法进行路由，过滤掉不符合路由规则的Invoker。
  3. 当FailoverClusterInvoker拿到Directory返回的Invoker列表后，它会通过LoadBalance从Invoker列表中选择一个Invoker。
  4. 最后FailoverClusterInvoker会将参数传给LoadBalance选择出的Invoker实例的invoker方法，进行真正的远程调用。

Dubbo 主要提供了这样几种容错方式：

1. Failover Cluster - 失败自动切换 失败时会重试其它服务器
2. Failfast Cluster - 快速失败 请求失败后快速返回异常结果 不重试
3. Failsafe Cluster - 失败安全 出现异常 直接忽略 会对请求做负载均衡
4. Failback Cluster - 失败自动恢复 请求失败后 会自动记录请求到失败队列中
5. Forking Cluster - 并行调用多个服务提供者 其中有一个返回 则立即返回结果

信息缓存接口Directory

Directory是Dubbo中的一个接口，主要用于缓存当前可以被调用的提供者列表信息。我们在消费者进 行调用时都会通过这个接口来获取所有的提供者列表，再进行后续处理。

public interface Directory<T> extends Node {
   
    
	//获取服务类型
    Class<T> getInterface();
    //获取本次调用可以使用的提供者信息
    List<Invoker<T>> list(Invocation invocation) throws RpcException;
    //获取所有提供者信息
    List<Invoker<T>> getAllInvokers();

    URL getConsumerUrl();
}

RouterChain#route 方法。这里所做的就是依次遍历所有的路由，然后分别执行并返回。这 也就是整体的路由规则的实现。

路由规则实现原理

RouterChain 中的 Router下的子类 ConditionRouter 为例
这两个属性比较关键，这两个属性也是判断的关键。

init方法做路由规则的初始化，也对上面的whenCondition与thenCondition做了初始化，其中paseRule方法是解析路由规则的方法并返回Map其值MatchPair存储了匹配条件和不匹配条件的Set集合

MatchPair

route方法则是筛选出符合条件的invoke并进行返回（List）

Cluster组件

Cluster 主要用于代理真正的Invoker执行时做处理，提供了多种容错方案。

这里以默认的FailoverCluster为例


通过 AbstractClusterInvoker#invoke 调用 FailoverClusterInvoker#doInvoke

负载均衡实现原理

Cluster 中经过负载选择真正 Invoker 的代码

以RandomLoadBalance为例，doSelect负责处理具体的负载均衡操作。

Invoker执行逻辑

Invoker是真实执行请求的组件。

以DubboInvoker调用为例

ExchangeClient为主要数据传输的客户端，其继承了HeaderExchangeChannel接口

doInvoke方法中根据isOneway判断是否执行异步请求

ExchangeClient 接口下的 **request **方法为真实发送消息的方法