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的具体调用链路。

整体调用链路

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

图中 ：

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

整体链路调用的流程：

1. 消费者通过Interface进行方法调用，统一交由消费者的Proxy处理（Proxy通过ProxyFactory来进行代理对象的创建）

2. Proxy调用Filter模块，做一个统一的过滤请求。（这里的过滤一般是服务容错、调用本地缓存等）

3. 进入到最主要的invoker调用逻辑：

4. 1. 通过Directory读取配置信息， 最终通过list方法获取所有的invoker
   2. 通过Cluster模块，根据选择的具体路由规则来选择invoker列表
   3. 通过loadBalance模块，选择负载均衡策略，选择一个具体的invoker来处理请求
   4. 如果执行出错，且Consumer阶段配置了重试机制，则会重新尝试执行

5. 继续经过filter，进行执行功能的前后封装 invoker 选择具体的执行协议。（注意这里的filter要区别于上面步骤2中的filter，这里做的事情与上面完全不同，这里操作有：context、deprecated、count、limit、monitor等）

6. 请求进入client，进行codec（编码）、serialization（序列化），然后发送数据给provider

7. 请求到达Provider中的Server， 这里进行方便吗和反序列化的接收数据

8. 使用Exporter选择执行器（执行协议）

9. 交给Filter进行一个提供者端的过滤， 到达invoker

10. 1. 这里我们可以将6、7、8的执行过程与前面 4、5的执行过程做一个对比，前面4、5的执行过程时通过filter包装对象 – > invoker选择执行协议 —> client编码和序列化数据 ； 这里6、7、8的执行过程是 server反序列化接收到的数据 --> Export选择执行协议 —> filter 包装数据。 我们可以看到前面4、5的过程是服务消费端加工数据和传输的过程， 后面6、7、8是服务提供端接收数据和翻译数据的过程。

11. 通过invoker调用接口的具体实现，然后返回

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

dubbo源码整体设计

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

如下图所示：

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

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

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

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

下面我们看一下dubbo各个层级的状况：

• config 配置层：对外配置接口，以 ServiceConfig, ReferenceConfig 为中心，可以直接初始化配置类，也可以通过 spring 解析配置生成配置类
• proxy 服务代理层：服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton, 以 ServiceProxy 为中心，扩展接口为 ProxyFactory
• registry 注册中心层：封装服务地址的注册与发现，以服务 URL 为中心，扩展接口为 RegistryFactory, Registry, RegistryService
• cluster 路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心，扩展接口为 Cluster, Directory, Router, LoadBalance
• monitor 监控层：RPC 调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory, Monitor, MonitorService
• protocol 远程调用层：封装 RPC 调用，以 Invocation, Result 为中心，扩展接口为 Protocol, Invoker, Exporter
• exchange 信息交换层：封装请求响应模式，同步转异步，以 Request, Response 为中心，扩展接口为 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer
• transport 网络传输层：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel, Transporter, Client, Server, Codec
• serialize 数据序列化层：可复用的一些工具，扩展接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool

这些层次可能现在看起来并没有任何概念，当我们后续章节深入阅读了dubbo的源码后，会能够经常看见这些熟悉的层次模块

参考资料

https://dubbo.apache.org/zh/docsv2.7/dev/design/

https://blog.csdn.net/zhoushimiao1990/article/details/117033648