我的架构梦：（二十五）Dubbo源码分析之整体架构设计

一、源码下载和编译

1、dubbo的项目在github中的地址为: https://github.com/apache/dubbo

2、进入需要进行下载的地址，执行 git clone https://github.com/apache/dubbo.git

3、为了防止master中代码不稳定，进入dubbo项目 cd dubbo 可以切入到最近的release分支 git checkout 2.7.6-release

4、进行本地编译，进入dubbo项目 cd dubbo , 进行编译操作 mvn clean install -DskipTests

5、使用IDE引入项目。

二、整体架构设计

1、Dubbo调用关系说明

整个架构由四部分组成：

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

2、启动和执行流程说明

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

3、整体的调用链路

图例说明：淡绿色代表了服务生产者的范围；淡蓝色代表了服务消费者的范围；红色箭头代表了调用的方向。

整体链路调用的流程：

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

3、Dubbo源码整体设计

图例说明:

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

Dubbo源码整体设计与调用链路十分相似。只不过这里可以看到接口的一些具体实现以及左侧也有更为详细的层次划分，我们在后面的源码解析时也会着重介绍其中比较重要的模块实现。

分层介绍:

• 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 数据序列化层 负责管理整个框架中的数据传输的序列化和反序列化