dubbo整体框架设计

1、dubbo调用关系说明

前面我们已经介绍过dubbo的调用关系说明，这里我们对其做一些补充

dubbo的调用关系主要由四部分组成：

一、Provider： 暴露服务的服务提供方

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

二、Consumer：调用远程服务的服务消费方

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

三、Registry：注册中心，用于作为服务发现和路由配置等工作，提供者和消费者都会在这里进行注册

四、Monitor：用于提供者和消费者的数据统计，如调用频次、成功失败次数等

 

dubbo的启动和执行流程说明：

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

明白了dubbo的启动和执行流程，我们来看一下dubbo的具体调用链路。

2、整体调用链路

下面是dubbo的整体调用链路图：

图中 ：

• 淡绿色代表了 服务生产者的范围 ； 淡蓝色代表了服务消费者的范围 ； 红色箭头代表了调用的方向
• 图中主要分为三个层面： 业务逻辑层（我们编写的业务代码）； RPC层（远程调用过程） ； Remoting（远程数据传输）

整体链路调用的流程：

1. 消费者通过Interface进行方法调用，统一交由消费者的Proxy处理（Proxy通过ProxyFactory来进行代理对象的创建）
2. Proxy调用Filter模块，做一个统一的过滤请求。（这里的过滤一般是服务容错、调用本地缓存等）
3. 进入到最主要的invoker调用逻辑：
   1. 通过Directory读取配置信息， 最终通过list方法获取所有的invoker
   2. 通过Cluster模块，根据选择的具体路由规则来选择invoker列表
   3. 通过loadBalance模块，选择负载均衡策略，选择一个具体的invoker来处理请求
   4. 如果执行出错，且Consumer阶段配置了重试机制，则会重新尝试执行
4. 继续经过filter，进行执行功能的前后封装 invoker 选择具体的执行协议。（注意这里的filter要区别于上面步骤2中的filter，这里做的事情与上面完全不同，这里操作有：context、deprecated、count、limit、monitor等）
5. 请求进入client，进行codec（编码）、serialization（序列化），然后发送数据给provider
6. 请求到达Provider中的Server， 这里进行方便吗和反序列化的接收数据
7. 使用Exporter选择执行器（执行协议）
8. 交给Filter进行一个提供者端的过滤， 到达invoker
   1. 这里我们可以将6、7、8的执行过程与前面 4、5的执行过程做一个对比，前面4、5的执行过程时通过filter包装对象 -- > invoker选择执行协议 ---> client编码和序列化数据 ； 这里6、7、8的执行过程是 server反序列化接收到的数据 --> Export选择执行协议 ---> filter 包装数据。 我们可以看到前面4、5的过程是服务消费端加工数据和传输的过程， 后面6、7、8是服务提供端接收数据和翻译数据的过程。
9. 通过invoker调用接口的具体实现，然后返回

到这里我们了解了dubbo的整体调用链路的具体过程，下面我们看看dubbo根据这一调用链路设计的源码结构：

3、dubbo源码整体设计

下面是dubbo的源码整体设计，乍一看可能比较混乱，下面我们一点点的拆分出来看

如下图所示：

• 图中左边的淡蓝色部分是服务消费端的源码设计，右边的淡绿色部分为服务提供者的源码设计， 中间用红色方框括起来的部分是二者的公共部分。
• 我们再看图的最左边部分，整个服务从大的层面分我们可以分为三层： business（具体实现业务层）、RPC（远程服务调用层）、Remoting（远程数据传输成）
• 图中最左边，又将数据分成10小层，而图中的最右边代表着各层之间的依赖关系，从图中我们可以看出各层之间是单向依赖的，每一层都可以剥离上一层被单独调用。
• 图中蓝色虚线代表初始化的过程，即启动时组装链；红色实线为方法的调用过程，即运行时调用链； 紫色三箭头为继承，可以把子类看作父类的同一个节点，线上的文字为调用方法。

现在对于图中的结构我们已经做了大致的了解，下面我们根据上面dubbo的整体调用链路来看看在这张图里，dubbo的调用过程：

按照上面了解到的dubbo的整体调用链路， 在这里的调用过程是： start ---> interface --- > proxy -- >filter ---> invoker  --> filter ---> client ----> codec--->serilization  ----> server  ---> export  ---> filter  ---> invoker

图中我用红色箭头做了标记，整体过程的每个阶段在图中我们都能找到，只不过这里将很多过程更加细化了。

下面我们看一下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数据序列化层，负责管理整个框架中的数据传输的序列化和反序列化

这一篇我们介绍了dubbo的整体框架设计，后面我们会开始介绍dubbo的各个组件的源码实现。