协议与编解码

Difficulty: Advanced
Status: Stable
Last reviewed: 2026年8月

Dubbo 协议层把 RPC 语义放在 Exchange 之上，把字节格式放在 Codec 之下。这样协议实现可以复用请求响应、Future、超时和连接管理，而编码器只处理线格式和对象转换。

先给答案：Dubbo 协议层把 RPC 语义放在 Exchange 之上，把字节格式放在 Codec 之下

Dubbo 协议层把 RPC 语义放在 Exchange 之上，把字节格式放在 Codec 之下。这样协议实现可以复用请求响应、Future、超时和连接管理，而编码器只处理线格式和对象转换。正文沿“协议栈 -> 服务端与客户端 -> 请求响应分派”展开：先确认入口和状态归属，再跟踪控制流或数据流的推进，最后落到对外可观察的结果。

主要失效边界集中在“半包/粘包、大消息反序列化、延迟连接首次慢”这些场景。它们破坏的是容量、顺序、并发或生命周期前提；排查时应先确认状态是否仍由正确对象持有，再核对推进条件和清理路径。

协议栈

Invoker
  -> Protocol
  -> ExchangeClient.request / ExchangeServer
  -> HeaderExchangeHandler
  -> Transport Channel
  -> Codec2.encode/decode
  -> bytes

服务端与客户端

DubboProtocol#export 在 dubbo-rpc/dubbo-rpc-dubbo/src/main/java/org/apache/dubbo/rpc/protocol/dubbo/DubboProtocol.java:346 保存导出器并准备服务端；openServer 中 Exchangers.bind 位于 DubboProtocol.java:426。客户端引用入口 refer 在 :445，协议绑定引用在 :451，连接创建在 :590 或 :591，分别支持延迟连接和立即连接。

Exchangers.bind 位于 dubbo-remoting/dubbo-remoting-api/src/main/java/org/apache/dubbo/remoting/exchange/Exchangers.java:53，最终交给扩展的 Exchanger#bind；connect 在 :93 走同一抽象。这是 Exchange 与底层 Transport 的适配边界。

请求响应分派

DubboProtocol 在 DubboProtocol.java:115 创建 requestHandler，reply 在 :118 根据消息找到 Exporter 并调用服务 Invoker。HeaderExchangeHandler#received 位于 dubbo-remoting/dubbo-remoting-api/src/main/java/org/apache/dubbo/remoting/exchange/support/header/HeaderExchangeHandler.java:196，请求数据在 :207 分派给业务处理器，响应在 :65 交给 DefaultFuture 完成等待中的调用。

编解码与延迟解码

DubboCodec 在 dubbo-rpc/dubbo-rpc-dubbo/src/main/java/org/apache/dubbo/rpc/protocol/dubbo/DubboCodec.java 负责请求/响应头和主体。请求和结果对象在 DubboCodec.java:129、:200 触发 DecodeableRpcResult#decode 与 DecodeableRpcInvocation#decode，把较重的反序列化延后到明确需要的阶段。

关键取舍

为什么分离 Exchange 与 Codec

替代方案：每个协议实现自己处理 Future、响应关联、连接和字节编解码。为什么不行：协议数量增长后会复制大量请求响应状态机，且难以保证超时与异常语义一致。证据：Exchangers 只负责选择 Exchange 扩展，DubboCodec 只负责消息格式，HeaderExchangeHandler 独立完成响应关联。

源码坐标索引

DubboProtocol#export — dubbo-rpc/dubbo-rpc-dubbo/src/main/java/org/apache/dubbo/rpc/protocol/dubbo/DubboProtocol.java:346
DubboProtocol#refer — dubbo-rpc/dubbo-rpc-dubbo/src/main/java/org/apache/dubbo/rpc/protocol/dubbo/DubboProtocol.java:445
DubboProtocol#protocolBindingRefer — dubbo-rpc/dubbo-rpc-dubbo/src/main/java/org/apache/dubbo/rpc/protocol/dubbo/DubboProtocol.java:451
DubboProtocol#requestHandler — dubbo-rpc/dubbo-rpc-dubbo/src/main/java/org/apache/dubbo/rpc/protocol/dubbo/DubboProtocol.java:115
Exchangers#bind — dubbo-remoting/dubbo-remoting-api/src/main/java/org/apache/dubbo/remoting/exchange/Exchangers.java:53
Exchangers#connect — dubbo-remoting/dubbo-remoting-api/src/main/java/org/apache/dubbo/remoting/exchange/Exchangers.java:93
HeaderExchangeHandler#received — dubbo-remoting/dubbo-remoting-api/src/main/java/org/apache/dubbo/remoting/exchange/support/header/HeaderExchangeHandler.java:196
DubboCodec#decode -> DecodeableRpcResult#decode() — dubbo-rpc/dubbo-rpc-dubbo/src/main/java/org/apache/dubbo/rpc/protocol/dubbo/DubboCodec.java:129
DubboCodec#decode -> DecodeableRpcInvocation#decode() — dubbo-rpc/dubbo-rpc-dubbo/src/main/java/org/apache/dubbo/rpc/protocol/dubbo/DubboCodec.java:200
DecodeableRpcResult#decode — dubbo-rpc/dubbo-rpc-dubbo/src/main/java/org/apache/dubbo/rpc/protocol/dubbo/DecodeableRpcResult.java:127
DecodeableRpcInvocation#decode — dubbo-rpc/dubbo-rpc-dubbo/src/main/java/org/apache/dubbo/rpc/protocol/dubbo/DecodeableRpcInvocation.java:103

边界与踩坑

场景	现象	原因	规避
半包/粘包	解码得到不完整对象	TCP 没有消息边界	使用长度字段和累计缓冲，不能按一次 read 解一条消息
大消息反序列化	CPU、内存突增	主线程同步解码	限制 payload、选择合适序列化、观察解码线程
延迟连接首次慢	第一次调用超时	`LazyConnectExchangeClient` 把连接推迟到请求时	关键链路预热或设置合理超时

可迁移知识

网络系统可把“业务语义、请求响应、传输、线格式”分成四层。每层只拥有自己的状态，协议升级和传输替换的影响面会显著降低。

面试锚点

Exchange 和 Protocol 的职责区别是什么？

Dubbo 请求如何从字节变成服务方法调用？

为什么需要延迟解码和延迟连接？