Dubbo框架整体设计

最新推荐文章于 2025-10-04 23:56:29 发布

原创最新推荐文章于 2025-10-04 23:56:29 发布 · 420 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#rpc #zookeeper #分布式

dubbo 专栏收录该内容

10 篇文章

订阅专栏

本文详细解析了Dubbo服务调用过程，包括Provider、Consumer、Registry和Monitor的角色，以及从接口调用到数据传输的完整链路。通过源码结构剖析，展示了各层次组件的工作原理，适合深入理解Dubbo架构。

dubbo调用关系

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

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

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

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

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

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

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

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

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

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

整体调用链路

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

图中：

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

整体链路调用的流程：

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