Dubbo3 提供了 Triple(Dubbo3)、Dubbo2 協議，這是 Dubbo 框架的原生協議。除此之外，Dubbo3 也對眾多第三方協議進行了集成，並將它們納入 Dubbo 的編程與服務治理體系， 包括 gRPC、Thrift、JsonRPC、Hessian2、REST 等。以下重點介紹 Triple 與 Dubbo2 協議。
下一代 RPC 協議 - Triple
Triple 協議是 Dubbo3 推出的主力協議。Triple 意為第三代，通過 Dubbo1.0/ Dubbo2.0 兩代協議的演進，以及雲原生帶來的技術標准化浪潮，Dubbo3 新協議 Triple 應運而生。
RPC 協議簡介
協議是 RPC 的核心，它規范了數據在網絡中的傳輸內容和格式。除必須的請求、響應數據外，通常還會包含額外控制數據，如單次請求的序列化方式、超時時間、壓縮方式和鑒權信息等。
協議的內容包含三部分：
- 數據交換格式：定義 RPC 的請求和響應對象在網絡傳輸中的字節流內容，也叫作序列化方式；
- 協議結構：定義包含字段列表和各字段語義以及不同字段的排列方式；
- 協議通過定義規則、格式和語義來約定數據如何在網絡間傳輸。一次成功的 RPC 需要通信的兩端都能夠按照協議約定進行網絡字節流的讀寫和對象轉換。如果兩端對使用的協議不能達成一致，就會出現雞同鴨講，無法滿足遠程通信的需求。
RPC 協議的設計需要考慮以下內容：
- 通用性：統一的二進制格式，跨語言、跨平台、多傳輸層協議支持
- 擴展性：協議增加字段、升級、支持用戶擴展和附加業務元數據
- 性能：As fast as it can be
- 穿透性：能夠被各種終端設備識別和轉發：網關、代理服務器等 通用性和高性能通常無法同時達到，需要協議設計者進行一定的取舍
HTTP/1.1
比於直接構建於 TCP 傳輸層的私有 RPC 協議，構建於 HTTP 之上的遠程調用解決方案會有更好的通用性，如WebServices 或 REST 架構，使用 HTTP + JSON 可以說是一個事實標准的解決方案。
選擇構建在 HTTP 之上，有兩個最大的優勢：
- 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 選型的思考
最終我們選擇了兼容 gRPC ，以 HTTP2 作為傳輸層構建新的協議，也就是 Triple。容器化應用程序和微服務的興起促進了針對負載內容優化技術的發展。客戶端中使用的傳統通信協議（ RESTFUL或其他基於 HTTP 的自定義協議）難以滿足應用在性能、可維護性、擴展性、安全性等方便的需求。一個跨語言、模塊化的協議會逐漸成為新的應用開發協議標准。自從 2017 年 gRPC 協議成為 CNCF 的項目后，包括 K8s、etcd 等越來越多的基礎設施和業務都開始使用 gRPC 的生態，作為雲原生的微服務化框架， Dubbo 的新協議也完美兼容了 gRPC。並且，對於 gRPC 協議中一些不完善的部分， Triple 也將進行增強和補充。那么，Triple 協議是否解決了上面我們提到的一系列問題呢？
- 性能上: Triple 協議采取了 metadata 和 payload 分離的策略，這樣就可以避免中間設備，如網關進行 payload 的解析和反序列化，從而降低響應時間。
- 路由支持上，由於 metadata 支持用戶添加自定義 header ，用戶可以根據 header 更方便的划分集群或者進行路由，這樣發布的時候切流灰度或容災都有了更高的靈活性。
- 安全性上，支持雙向 TLS 認證（mTLS）等加密傳輸能力。
- 易用性上，Triple 除了支持原生 gRPC 所推薦的 Protobuf 序列化外，使用通用的方式支持了 Hessian / JSON 等其他序列化，能讓用戶更方便的升級到 Triple 協議。對原有的 Dubbo 服務而言，修改或增加 Triple 協議 只需要在聲明服務的代碼塊添加一行協議配置即可，改造成本幾乎為 0。
現狀
1、完整兼容 gRPC、客戶端/服務端可以與原生 gRPC 客戶端打通
2、目前已經經過大規模生產實踐驗證，達到生產級別
特點與優勢
1、具備跨語言互通的能力，傳統的多語言多 SDK 模式和 Mesh 化跨語言模式都需要一種更通用易擴展的數據傳輸格式。
2、提供更完善的請求模型，除了 Request/Response 模型，還應該支持 Streaming 和 Bidirectional。
3、易擴展、穿透性高，包括但不限於 Tracing / Monitoring 等支持，也應該能被各層設備識別，網關設施等可以識別數據報文，對 Service Mesh 部署友好，降低用戶理解難度。
4、多種序列化方式支持、平滑升級。
5、支持 Java 用戶無感知升級，不需要定義繁瑣的 IDL 文件，僅需要簡單的修改協議名便可以輕松升級到 Triple 協議。
Triple 協議簡介
基於 gRPC 協議進行進一步擴展
- 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}
其中 Service-Version 跟 Service-Group 分別標識了 Dubbo 服務的 version 跟 group 信息，因為 grpc 的 path 申明了 service name 跟 method name，相比於 Dubbo 協議，缺少了 version 跟 group 信息；Tracing-ID、Tracing-RPC-ID 用於全鏈路追蹤能力，分別表示 tracing id 跟 span id 信息；Cluster-Info 表示集群信息，可以使用其構建一些如集群划分等路由相關的靈活的服務治理能力。
Triple Streaming
Triple 協議相比傳統的 unary 方式，多了目前提供的 Streaming RPC 的能力
- Streaming 用於什么場景呢？
在一些大文件傳輸、直播等應用場景中， consumer 或 provider 需要跟對端進行大量數據的傳輸，由於這些情況下的數據量是非常大的，因此是沒有辦法可以在一個 RPC 的數據包中進行傳輸，因此對於這些數據包我們需要對數據包進行分片之后，通過多次 RPC 調用進行傳輸，如果我們對這些已經拆分了的 RPC 數據包進行並行傳輸，那么到對端后相關的數據包是無序的，需要對接收到的數據進行排序拼接，相關的邏輯會非常復雜。但如果我們對拆分了的 RPC 數據包進行串行傳輸，那么對應的網絡傳輸 RTT 與數據處理的時延會是非常大的。
為了解決以上的問題，並且為了大量數據的傳輸以流水線方式在 consumer 與 provider 之間傳輸，因此 Streaming RPC 的模型應運而生。
通過 Triple 協議的 Streaming RPC 方式，會在 consumer 跟 provider 之間建立多條用戶態的長連接，Stream。同一個 TCP 連接之上能同時存在多個 Stream，其中每條 Stream 都有 StreamId 進行標識，對於一條 Stream 上的數據包會以順序方式讀寫。
總結
在 API 領域，最重要的趨勢是標准化技術的崛起。Triple 協議是 Dubbo3 推出的主力協議。它采用分層設計，其數據交換格式基於 Protobuf (Protocol Buffers) 協議開發，具備優秀的序列化/反序列化效率，當然還支持多種序列化方式，也支持眾多開發語言。在傳輸層協議，Triple 選擇了 HTTP/2，相較於 HTTP/1.1，其傳輸效率有了很大提升。此外 HTTP/2 作為一個成熟的開放標准，具備豐富的安全、流控等能力，同時擁有良好的互操作性。Triple 不僅可以用於 Server 端服務調用，也可以支持瀏覽器、移動 App 和 IoT 設備與后端服務的交互，同時 Triple協議無縫支持 Dubbo3 的全部服務治理能力。
在 Cloud Native 的潮流下，跨平台、跨廠商、跨環境的系統間互操作性的需求必然會催生基於開放標准的 RPC 技術，而 gRPC 順應了歷史趨勢，得到了越來越廣泛地應用。在微服務領域，Triple 協議的提出與落地，是 Dubbo3 邁向雲原生微服務的一大步。
附錄：Dubbo2 Protocol SPEC
Protocol SPEC!
- 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 PartEach part is a byte[] after serialization with specific serialization type, identifies by Serialization ID.
Every part is a byte[] after serialization with specific serialization type, identifies by Serialization ID
- 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
- 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.
注意： 對於 (Variable Part) 變長部分，當前版本的 dubbo 框架使用 json 序列化時，在每部分內容間額外增加了換行符作為分隔，請選手在 Variable Part 的每個 part 后額外增加換行符， 如：
Dubbo version bytes (換行符)
Service name bytes (換行符)
...