1 Dubbo 整体架构设计
dubbo-remoting 模块提供多种客户端和服务端通信功能。最底层部分即为 Remoting 层:
包括 Exchange、Transport和Serialize 三层。本文主要描述 Exchange 和 Transport 两层。
Dubbo直接集成已有的第三方网络库,如Netty、Mina、Grizzly 等 NIO 框架:
dubbo-remoting-zookeeper使用 Apache Curator 实现与 zk 的交互。
2 dubbo-remoting-api
是其他 dubbo-remoting-*
模块的顶层抽象,其他 dubbo-remoting 子模块都是依赖第三方 NIO 库,来实现 dubbo-remoting-api 模块。
2.1 buffer 包
定义Buffer相关接口、抽象类及实现类。在各 NIO 框架中都有自己的缓冲区实现。但这里的 buffer 包在更高层面,抽象各个 NIO 框架的缓冲区,同时也提供一些基础实现。
2.2 exchange包
抽象 Request、Response,并为其添加很多特性。整个远程调用的核心部分。
2.3 transport包
抽象网络传输层,但只负责抽象单向消息传输,即:
- 请求消息由 Client 端发出,Server 端接收
- 响应消息由 Server 端发出,Client端接收
很多网络库可实现网络传输,如Netty,transport包是在网络库上层的一层抽象。
2 传输层核心接口
“端点(Endpoint)”:一个 ip
和 port
唯一确定,两端点间会创建 TCP
连接,双向传输数据。
Dubbo 将 Endpoint 之间的 TCP 连接抽象为(Channel)通道:
- 发起请求的 Endpoint 抽象为Client
- 接收请求的 Endpoint 抽象为Server
2.1 Endpoint 接口
- getXXX() 用于获得 Endpoint 本身的一些属性,如Endpoint 的本地地址、关联的 URL 信息及底层 Channel 关联的 ChannelHandler
- send() 负责数据发送
- close() 及 startClose() 用于关闭底层 Channel
- isClosed() 方法用于检测底层 Channel 是否已关闭
3 Channel
对 Endpoint 双方连接的抽象,就像传输管道。消息发送端往 Channel 写入消息,接收端从 Channel 读取消息。
3.1 接口定义
继承 Endpoint 接口,也具备开关状态以及发送数据能力。可在 Channel 上附加 KV 属性:
4 ChannelHandler
注册在 Channel 上的消息处理器
4.1 定义
@SPI
注解表明该接口是一个扩展点。
有一类特殊的 ChannelHandler 专门负责实现编解码功能,实现:
- 字节数据与有意义的消息之间的转换
- 或消息之间的相互转换
该接口也是个扩展接口,encode()、decode() 被 @Adaptive 注解修饰,也就会生成适配器类,其中会根据 URL 中的 codec 值确定具体的扩展实现类。
DecodeResult 枚举是在处理 TCP 传输时粘包和拆包使用的,如当前能读取到的数据不足以构成一个消息时,就使用 NEED_MORE_INPUT
。
5 Client、RemotingServer
分别抽象客户端、服务端,都继承 Channel、Resetable 等接口,即都具备读写数据的能力。
都继承了 Endpoint,只是在语义上区分请求和响应职责,都具备发送数据能力。
Client V.S Server
- Client 只能关联一个 Channel
- Server 可接收多个 Client 发起的 Channel 连接,所以在 RemotingServer 接口中定义查询 Channel 的相关方法
6 Transporter
Dubbo 在 Client、Server 之上又封装一层Transporter 接口:
@SPI
注解扩展接口,默认使用“netty”扩展名。
@Adaptive
注解表示动态生成适配器类:
- 先后根据“server”“transporter”的值,确定
RemotingServer
的扩展实现类 - 先后根据“client”“transporter”的值,确定 Client 接口的扩展实现
几乎对每个支持的 NIO 库,都有接口实现:
7.1 为何单独抽象Transporter层,不直接让上层使用 Netty?
利用依赖倒置原则,Netty、Mina、Grizzly 等 NIO 库对外接口和使用方式不同,若在上层直接依赖 Netty 或Grizzly,就依赖具体 NIO 库,而非依赖一个有传输能力的抽象,后续要切换实现,就需修改依赖和接入的相关代码。
而有了 Transporter 层,就可通过 Dubbo SPI,修改使用的具体 Transporter 扩展实现,切换到不同 Client 和 RemotingServer 实现,切换底层 NIO 库,而无须修改代码。当有更先进的 NIO 库出现,也只需开发相应的 dubbo-remoting-*
实现模块提供 Transporter、Client、RemotingServer 等核心接口的实现,即可接入,完全符合开放封闭原则。
7 Transporters
不是一个接口,而是门面类,封装:
- Transporter 对象的创建(通过 Dubbo SPI)
- 及 ChannelHandler 的处理
在创建 Client、RemotingServer 时,可指定多个 ChannelHandler 绑定到 Channel,来处理其中传输的数据。Transporters.connect()、bind() 方法都会将多个 ChannelHandler 封装成一个 ChannelHandlerDispatcher 对象。
ChannelHandlerDispatcher 也是 ChannelHandler 接口实现类之一,维护一个 CopyOnWriteArraySet 集,它所有的 ChannelHandler 接口实现都会调用其中每个 ChannelHandler 元素的相应方法。ChannelHandlerDispatcher 还提供增删该 ChannelHandler 集合的相关方法。
8 总结
- Endpoint 接口抽象“端点”概念,这是所有抽象接口的基础
- 上层使用方会通过 Transporters 门面类,获取到 Transporter 的具体扩展实现,然后通过 Transporter 拿到相应 Client、RemotingServer 实现,就能建立(或接收)Channel 与远端进行交互
- 无论 Client、RemotingServer,都会使用 ChannelHandler 处理 Channel 中传输的数据,其中负责编解码的 ChannelHandler 被抽象出为 Codec2 接口。
Transporter 层整体结构图
参考