Dubbo3 Triple 協(xié)議簡介與選型思考

• 數(shù)據(jù)交換格式：定義 RPC 的請求和響應(yīng)對象在網(wǎng)絡(luò)傳輸中的字節(jié)流內(nèi)容，也叫作序列化方式；
• 協(xié)議結(jié)構(gòu)：定義包含字段列表和各字段語義以及不同字段的排列方式；
• 協(xié)議通過定義規(guī)則、格式和語義來約定數(shù)據(jù)如何在網(wǎng)絡(luò)間傳輸。一次成功的 RPC 需要通信的兩端都能夠按照協(xié)議約定進行網(wǎng)絡(luò)字節(jié)流的讀寫和對象轉(zhuǎn)換。如果兩端對使用的協(xié)議不能達(dá)成一致，就會出現(xiàn)雞同鴨講，無法滿足遠(yuǎn)程通信的需求。

RPC 協(xié)議的設(shè)計需要考慮以下內(nèi)容：

• 通用性：統(tǒng)一的二進制格式，跨語言、跨平臺、多傳輸層協(xié)議支持

• 擴展性：協(xié)議增加字段、升級、支持用戶擴展和附加業(yè)務(wù)元數(shù)據(jù)

• 性能：As fast as it can be

• 穿透性：能夠被各種終端設(shè)備識別和轉(zhuǎn)發(fā)：網(wǎng)關(guān)、代理服務(wù)器等 通用性和高性能通常無法同時達(dá)到，需要協(xié)議設(shè)計者進行一定的取舍

HTTP/1.1

• HTTP 的語義和可擴展性能很好的滿足 RPC 調(diào)用需求。
• 通用性，HTTP 協(xié)議幾乎被網(wǎng)絡(luò)上的所有設(shè)備所支持，具有很好的協(xié)議穿透性。

• 典型的 Request – Response 模型，一個鏈路上一次只能有一個等待的 Request 請求。會產(chǎn)生 HOL。
• Human Readable Headers，使用更通用、更易于人類閱讀的頭部傳輸格式，但性能相當(dāng)差
• 無直接 Server Push 支持，需要使用 Polling Long-Polling 等變通模式

gRPC

上面提到了在 HTTP 及 TCP 協(xié)議之上構(gòu)建 RPC 協(xié)議各自的優(yōu)缺點，相比于 Dubbo 構(gòu)建于 TCP 傳輸層之上，Google 選擇將 gRPC 直接定義在 HTTP/2 協(xié)議之上。gRPC 的優(yōu)勢由 HTTP2 和 Protobuf 繼承而來。

• 基于 HTTP2 的協(xié)議足夠簡單，用戶學(xué)習(xí)成本低，天然有 server push / 多路復(fù)用 / 流量控制能力
• 基于 Protobuf 的多語言跨平臺二進制兼容能力，提供強大的統(tǒng)一跨語言能力
• 基于協(xié)議本身的生態(tài)比較豐富，K8s / etcd 等組件的天然支持協(xié)議，云原生的事實協(xié)議標(biāo)準(zhǔn)

• 對服務(wù)治理的支持比較基礎(chǔ)，更偏向于基礎(chǔ)的 RPC 功能，協(xié)議層缺少必要的統(tǒng)一定義，對于用戶而言直接用起來并不容易。
• 強綁定 protobuf 的序列化方式，需要較高的學(xué)習(xí)成本和改造成本，對于現(xiàn)有的偏單語言的用戶而言，遷移成本不可忽視

• 性能上: Triple 協(xié)議采取了 metadata 和 payload 分離的策略，這樣就可以避免中間設(shè)備，如網(wǎng)關(guān)進行 payload 的解析和反序列化，從而降低響應(yīng)時間。
• 路由支持上，由于 metadata 支持用戶添加自定義 header ，用戶可以根據(jù) header 更方便的劃分集群或者進行路由，這樣發(fā)布的時候切流灰度或容災(zāi)都有了更高的靈活性。
• 安全性上，支持雙向 TLS 認(rèn)證（mTLS）等加密傳輸能力。
• 易用性上，Triple 除了支持原生 gRPC 所推薦的 Protobuf 序列化外，使用通用的方式支持了 Hessian / JSON 等其他序列化，能讓用戶更方便的升級到 Triple 協(xié)議。對原有的 Dubbo 服務(wù)而言，修改或增加 Triple 協(xié)議 只需要在聲明服務(wù)的代碼塊添加一行協(xié)議配置即可，改造成本幾乎為 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  (換行符)...