Dubbo源码分析系列之-整体架构设计

淡淡的烟草味﹌ 2021-10-15 06:49 441阅读 0赞

> 导语：  
>   在了解一个框架的源码的时候，第一步要了解的就是源码的结构，接下来第二步需要了解的就是源码的架构，下面这张图在Dubbo官网上所展示的Dubbo的架构设计图。接下来就来详细的分析一下这张图。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25paHVpMTIz_size_16_color_FFFFFF_t_70]

#### 整体说明 ####

从左右颜色的角度分析，浅蓝色的表示Consumer也就是服务消费者，浅绿色的表示Provider也就是服务提供者，这个是左右分离的越往两边说明对于服务提供者和服务消费者的调用越强烈，而越往中间则表示都需要进行调用。  
  上面已经看过了从左右颜色的角度上分析，接下来就来分析一下上下结构，从上到下分别分为了十层(从图中可以看出)，最左边有每一层的标注，而在最右边的黑色实线箭头表示的各个层级之间的依赖关系。从整个上下结构来看每一个层级都可以被单独的进行扩展。  
  从整体的颜色分布可以看出蓝色的表示实现类，而绿色的表示接口，这个图中所显示的就是在各个层级中关联的类或者接口。对于每个层级中的详细实现的其他类并没有展示。图中的有实线和虚线。蓝色虚线表示初始化的过程，也就是当Dubbo启动的时候是按照这个过程进行组装，红色实线表示方法的调用过程，也就是在Dubbo运行过程中实施调用的的。紫色的箭头表示类之间的继承关系，可以把子类看作和父类是同一个节点。每条线上的文字表示调用的方法。

#### 上下层分析 ####

从上到下可以分为十层，下面就来分析一下各个层级的作用。

**Service层**  
  表示服务层，也就是说是表示服务的提供者以及服务消费者，在微服务架构中无论是服务提供者还是服务消费者在整个的服务治理体系中都是被看作是一个服务存在。这里通过实现接口或者继承接口的方式进行服务的调用配置，也就是在服务调用的过程中所有继承了某个接口的的服务类就可以向外提供服务。  
**Config配置层**  
  对外配置的接口，这个功能是以ServiceConfig、ReferenceConfig类为中心，可以提供直接的初始化的配置，也可以通过Spring框架来解析对应的配置文件生成配置类。  
**Proxy服务代理层**  
  服务接口代理，主要使用了代理模式，在实现远程服务调用的时候不至于直接操作原始对象，生成服务器端的客户端Stub和服务气短的Skeleton，这个代理层以ServiceProxy为中心，通过ProxyFactory进行扩展。  
**Registry注册中心**  
  封装服务地址以及服务的注册和发现。以服务为中心，拓展接口是RegistryFactory，Registry，RegistryService。当然还提供了RegistryDirectory，RegistryProtocol等实现类。  
**Cluster路由层**  
  封装多个服务提供者的路由以及负载均衡信息，并且桥接了注册中心，以Invoker为中心，扩展接口为Cluster、Directory、Router、LoadBalance  
**Monitor监控**  
  RPC 调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory、Monitor、MonitorService  
**Protocol远程调用层**  
  封装了RPC调用，以Invocation,Result 为中心，扩展的接口为Protocol，Invoker，Exporter等  
**exchange信息交换层**  
  封装请求响应模式，同步与异步之间的转换，以Request、Response为中心，提供了Exchange、ExchangeChannel、ExchangeClient、ExchangeServer等接口以及实现类。  
**Transport网络传输层**  
  对于mina和Netty接口的统一抽象，以Message为中心，扩展接口为Channel，Transporter，Client，Server，Codec。  
**Serialize数据序列化层**  
  提供了一些数据序列化可复用的工具，扩展接口为Serialization，ObjectInput，ObjectOutput,ThreadPool。

#### 各个层级关系说明 ####

*  在RPC中，Protocol是核心层，也就是只有Protocol+Invoker+Exporter就可以完成非透明的RPC调用，然后在Invoker的主过程上Filter拦截点。
 *  在上图中展示的Consumer 和 Provider都是抽象的概念，在Dubbo中大多数场景下都是使用这些名词
 *  Cluster是一个外围的概念，Cluster的目的是为了将多个Invoker封装成一个Invoker,这样的话使用者只需要关注Protocol层面的Invoker，上面提到各个层是可以独立开发的也就是说去掉Cluster或者增加Cluster对于其他层都是不会受到影响。
 *  Proxy层所封装的都是接口的透明化的代理，而其他层都是以Invoker为中心，只有在暴露给用户的时候才用Proxy将Invoker转换为接口，或者将接口转换为Invoker，也就是说去掉了Proxy层RPC是可以进行调用的，只不过就不会是透明调用，而更像是内部调用。
 *  Remoting实现了Dubbo协议，如果选择的是其他的协议，整个的Remoting都不会用到，Remoting内部划分为Transport层和Exchange信息交换层Transport层负责单向消息传递，是对Mina、Netty、Grizzly等的抽象。也可以扩展UDP传输，而Exchange层是在传输层上的分装了Request-Response。
 *  Registry和Monitor都是可以独立存在的。所以使用层级展示在图中。

**从上图可以看到Dubbo实现的RPC就是由Config、Proxy、Registry、Cluster、Monitor、Protocol等实现，其中最为主要的就是Config、Proxy、Protocol三个，分别表示配置、代理、以及协议。**

#### 依赖关系说明 ####

了解过之前的Dubbo框架的人应该知道这个图在相对于之前的调用关系图有了一定的改动。说是改动其实就是将这个架构图画的好看了一些。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25paHVpMTIz_size_16_color_FFFFFF_t_70 1]  
 图中分别展示了Protocol、Cluster、Proxy、Service、Container、Registry、Monitor等模块以及各个模块之前的调用关系，蓝色虚线表示初始化调用、红色虚线表示异步调用、红色实线表示同步调用。整个关系图中并没有看到Remoting，因为这被统一当做了Protocol进行处理。整个关系图按照1~5的顺序标注了调用的步骤，分别展示了蓝色的Consumer和绿色的Provider。

接下来就按照1~5的流程简单的描述一下各自的操作过程，首先当容器启动的时候Dubbo会向注册中心注册Provider的信息，Consumer向注册中心订阅信息。注册中心会以异步的方式向Consumer发送对应的Provider

#### 调用链流程 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25paHVpMTIz_size_16_color_FFFFFF_t_70 2]  
  如图所示浅蓝色的为Consumer也就是服务消费者，而浅绿色的为Provider服务提供者，紫色的实线表示继承关系，蓝色虚线表示初始化操作，红色的实线表示调用关系。中间位置表示整个调用流程中公共调用的地方，也就是编解码操作。

#### 服务提供方暴露服务 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25paHVpMTIz_size_16_color_FFFFFF_t_70 3]

#### 服务消费方调用服务 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25paHVpMTIz_size_16_color_FFFFFF_t_70 4]

## 总结 ##

从Dubbo的官方文档中整理出来自己理解的部分，从整个流程中来看Dubbo是一个比较简单的RPC框架，但是想要将Dubbo用好或者说想要更好的理解微服务利用Dubbo开发出适合自己的微服务调用框架整合Zookeeper以及Dubbo搭建出高可用的微服务集群还是需要更多的技术支持，从最简单的反射到设计模式，从简单的类的调用到整体的架构设计。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25paHVpMTIz_size_16_color_FFFFFF_t_70]: /images/20211015/9e80bd502401496ebae9015963886c1a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25paHVpMTIz_size_16_color_FFFFFF_t_70 1]: /images/20211015/436dda3d0d034f3a8b7cb7e69a29a71d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25paHVpMTIz_size_16_color_FFFFFF_t_70 2]: /images/20211015/5f0bb083914840679bea0b28b5fee2a4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25paHVpMTIz_size_16_color_FFFFFF_t_70 3]: /images/20211015/b007aaa696674a92ac54aa3280de5cf7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25paHVpMTIz_size_16_color_FFFFFF_t_70 4]: /images/20211015/f103d49d95b64858afe77d3928009cb7.png