Dubbo3 Triple 协议简介与选型思考

• 数据交换格式：定义 RPC 的请求和响应对象在网络传输中的字节流内容，也叫作序列化方式；
• 协议结构：定义包含字段列表和各字段语义以及不同字段的排列方式；
• 协议通过定义规则、格式和语义来约定数据如何在网络间传输。一次成功的 RPC 需要通信的两端都能够按照协议约定进行网络字节流的读写和对象转换。如果两端对使用的协议不能达成一致，就会出现鸡同鸭讲，无法满足远程通信的需求。

RPC 协议的设计需要考虑以下内容：

• 通用性：统一的二进制格式，跨语言、跨平台、多传输层协议支持

• 扩展性：协议增加字段、升级、支持用户扩展和附加业务元数据

• 性能：As fast as it can be

• 穿透性：能够被各种终端设备识别和转发：网关、代理服务器等 通用性和高性能通常无法同时达到，需要协议设计者进行一定的取舍

HTTP/1.1

• HTTP 的语义和可扩展性能很好的满足 RPC 调用需求。
• 通用性，HTTP 协议几乎被网络上的所有设备所支持，具有很好的协议穿透性。

• 典型的 Request – Response 模型，一个链路上一次只能有一个等待的 Request 请求。会产生 HOL。
• Human Readable Headers，使用更通用、更易于人类阅读的头部传输格式，但性能相当差
• 无直接 Server Push 支持，需要使用 Polling Long-Polling 等变通模式

gRPC

上面提到了在 HTTP 及 TCP 协议之上构建 RPC 协议各自的优缺点，相比于 Dubbo 构建于 TCP 传输层之上，Google 选择将 gRPC 直接定义在 HTTP/2 协议之上。gRPC 的优势由 HTTP2 和 Protobuf 继承而来。

• 基于 HTTP2 的协议足够简单，用户学习成本低，天然有 server push / 多路复用 / 流量控制能力
• 基于 Protobuf 的多语言跨平台二进制兼容能力，提供强大的统一跨语言能力
• 基于协议本身的生态比较丰富，K8s / etcd 等组件的天然支持协议，云原生的事实协议标准

• 对服务治理的支持比较基础，更偏向于基础的 RPC 功能，协议层缺少必要的统一定义，对于用户而言直接用起来并不容易。
• 强绑定 protobuf 的序列化方式，需要较高的学习成本和改造成本，对于现有的偏单语言的用户而言，迁移成本不可忽视

• 性能上: Triple 协议采取了 metadata 和 payload 分离的策略，这样就可以避免中间设备，如网关进行 payload 的解析和反序列化，从而降低响应时间。
• 路由支持上，由于 metadata 支持用户添加自定义 header ，用户可以根据 header 更方便的划分集群或者进行路由，这样发布的时候切流灰度或容灾都有了更高的灵活性。
• 安全性上，支持双向 TLS 认证（mTLS）等加密传输能力。
• 易用性上，Triple 除了支持原生 gRPC 所推荐的 Protobuf 序列化外，使用通用的方式支持了 Hessian / JSON 等其他序列化，能让用户更方便的升级到 Triple 协议。对原有的 Dubbo 服务而言，修改或增加 Triple 协议 只需要在声明服务的代码块添加一行协议配置即可，改造成本几乎为 0。

• Service-Version → “tri-service-version” {Dubbo service version}
• Service-Group → “tri-service-group” {Dubbo service group}
• Tracing-ID → “tri-trace-traceid” {tracing id}
• Tracing-RPC-ID → “tri-trace-rpcid” {_span id _}
• Cluster-Info → “tri-unit-info” {cluster infomation}

Triple Streaming

• Streaming 用于什么场景呢？

• Magic - Magic High & Magic Low (16 bits)
  Identifies dubbo protocol with value: 0xdabb
• Req/Res (1 bit)
  Identifies this is a request or response. Request - 1; Response - 0.
• 2 Way (1 bit)
  Only useful when Req/Res is 1 (Request), expect for a return value from server or not. Set to 1 if need a return value from server.
• Event (1 bit)
  Identifies an event message or not, for example, heartbeat event. Set to 1 if this is an event.
• Serialization ID (5 bit)
  Identifies serialization type: the value for fastjson is 6.
• Status (8 bits)
  Only useful when Req/Res is 0 (Response), identifies the status of response
• 20 - OK
• 30 - CLIENT_TIMEOUT
• 31 - SERVER_TIMEOUT
• 40 - BAD_REQUEST
• 50 - BAD_RESPONSE
• 60 - SERVICE_NOT_FOUND
• 70 - SERVICE_ERROR
• 80 - SERVER_ERROR
• 90 - CLIENT_ERROR
• 100 - SERVER_THREADPOOL_EXHAUSTED_ERROR
• Request ID (64 bits)
  Identifies an unique request. Numeric (long).
• Data Length (32)
  Length of the content (the variable part) after serialization, counted by bytes. Numeric (integer).
• Variable Part
  Each part is a byte[] after serialization with specific serialization type, identifies by Serialization ID.

1. If the content is a Request (Req/Res = 1), each part consists of the content, in turn is:
• Dubbo version
• Service name
• Service version
• Method name
• Method parameter types
• Method arguments
• Attachments
2. If the content is a Response (Req/Res = 0), each part consists of the content, in turn is:
• Return value type, identifies what kind of value returns from server side: RESPONSE_NULL_VALUE - 2, RESPONSE_VALUE - 1, RESPONSE_WITH_EXCEPTION - 0.
• Return value, the real value returns from server.

Dubbo version bytes (换行符)Service name bytes  (换行符)...