RPC 通信協(xié)議

Dubbo3提供了Triple(Dubbo3)、Dubbo2協(xié)議，這是Dubbo框架的原生協(xié)議。除此之外，Dubbo3也對眾多第三方協(xié)議進行了集成，并將它們納入Dubbo的編程與服務(wù)治理體系， 包括:gRPC、Thrift、JsonRPC、Hessian2、REST等。以下重點介紹 Triple 與 Dubbo2 協(xié)議。

Triple 協(xié)議

Triple協(xié)議是Dubbo3 推出的主力協(xié)議。Triple意為第三代，通過Dubbo1.0/Dubbo2.0兩代協(xié)議的演進，以及云原生帶來的技術(shù)標(biāo)準(zhǔn)化浪潮，Dubbo3新協(xié)議Triple應(yīng)運而生。

RPC協(xié)議的選擇

• 通信協(xié)議是RPC的核心，它規(guī)范了數(shù)據(jù)在網(wǎng)絡(luò)中的傳輸內(nèi)容和格式。
• 除必須的請求、響應(yīng)數(shù)據(jù)外，通常還會包含額外控制數(shù)據(jù)，如:單次請求的序列化方式、超時時間、壓縮方式和鑒權(quán)信息等。

協(xié)議的內(nèi)容包含三部分

• 數(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é)議不能達成一致，就會出現(xiàn)雞同鴨講，無法滿足遠程通信的需求。

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

• 通用性： 統(tǒng)一的二進制格式，跨語言、跨平臺、多傳輸層協(xié)議支持
• 擴展性： 協(xié)議增加字段、升級、支持用戶擴展和附加業(yè)務(wù)元數(shù)據(jù)
• 穿透性：能夠被各種中端設(shè)備識別和轉(zhuǎn)發(fā)：網(wǎng)關(guān)、代理服務(wù)器等 通用性和高性能通常無法同時達到，需要協(xié)議設(shè)計者進行一定的取舍。
• 性能：As fast as it can be

HTTP/1.1

直接構(gòu)建于TCP傳輸層的私有RPC協(xié)議，構(gòu)建于HTTP之上的遠程調(diào)用解決方案會有更好的通用性，如：WebService或REST架構(gòu)，使用HTTP + JSON 可以說是一個事實標(biāo)準(zhǔn)的解決方案。

選擇構(gòu)建在 HTTP 之上，有兩個最大的優(yōu)勢：

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

選擇構(gòu)建在 HTTP 之上，但也存在比較明顯的問題：

• 典型的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

兼容gRPC ，以HTTP2作為傳輸層構(gòu)建新的協(xié)議，也就是Triple。

容器化應(yīng)用程序和微服務(wù)的興起促進了針對負載內(nèi)容優(yōu)化技術(shù)的發(fā)展。 客戶端中使用的傳統(tǒng)通信協(xié)議（ RESTFUL或其他基于 HTTP 的自定義協(xié)議）難以滿足應(yīng)用在性能、可維護性、擴展性、安全性等方便的需求。

GRPC協(xié)議的興起

一個跨語言、模塊化的協(xié)議會逐漸成為新的應(yīng)用開發(fā)協(xié)議標(biāo)準(zhǔn)。自從 2017 年 gRPC 協(xié)議成為 CNCF 的項目后，包括 k8s、etcd 等越來越多的基礎(chǔ)設(shè)施和業(yè)務(wù)都開始使用 gRPC 的生態(tài)，作為云原生的微服務(wù)化框架， Dubbo 的新協(xié)議也完美兼容了 gRPC。并且，對于 gRPC 協(xié)議中一些不完善的部分， Triple 也將進行增強和補充。

Triple協(xié)議是否解決問題

• 性能上: Triple 協(xié)議采取了 metadata 和 payload 分離的策略，這樣就可以避免中間設(shè)備，如網(wǎng)關(guān)進行 payload 的解析和反序列化，從而降低響應(yīng)時間。

• 路由支持上，由于 metadata 支持用戶添加自定義 header ，用戶可以根據(jù) header 更方便的劃分集群或者進行路由，這樣發(fā)布的時候切流灰度或容災(zāi)都有了更高的靈活性。

• 安全性上，支持雙向TLS認證（mTLS）等加密傳輸能力。

• 易用性上，Triple 除了支持原生 gRPC 所推薦的 Protobuf 序列化外，使用通用的方式支持了 Hessian / JSON 等其他序列化，能讓用戶更方便的升級到 Triple 協(xié)議。對原有的 Dubbo 服務(wù)而言，修改或增加 Triple 協(xié)議 只需要在聲明服務(wù)的代碼塊添加一行協(xié)議配置即可，改造成本幾乎為 0。

Triple協(xié)議

Triple 協(xié)議通信方式

現(xiàn)狀

1. 完整兼容grpc、客戶端/服務(wù)端可以與原生grpc客戶端打通

2. 目前已經(jīng)經(jīng)過大規(guī)模生產(chǎn)實踐驗證，達到生產(chǎn)級別

特點與優(yōu)勢

1. 具備跨語言互通的能力，傳統(tǒng)的多語言多 SDK 模式和 Mesh 化跨語言模式都需要一種更通用易擴展的數(shù)據(jù)傳輸格式。

2. 提供更完善的請求模型，除了 Request/Response 模型，還應(yīng)該支持 Streaming 和 Bidirectional。

3. 易擴展、穿透性高，包括但不限于 Tracing / Monitoring 等支持，也應(yīng)該能被各層設(shè)備識別，網(wǎng)關(guān)設(shè)施等可以識別數(shù)據(jù)報文，對 Service Mesh 部署友好，降低用戶理解難度。

4. 多種序列化方式支持、平滑升級

5. 支持 Java 用戶無感知升級，不需要定義繁瑣的 IDL 文件，僅需要簡單的修改協(xié)議名便可以輕松升級到 Triple 協(xié)議

Triple 協(xié)議內(nèi)容介紹

基于 grpc 協(xié)議進行進一步擴展

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 分別標(biāo)識了 Dubbo 服務(wù)的 version 跟 group 信息，因為grpc的 path 申明了 service name 跟 method name，相比于 Dubbo 協(xié)議，缺少了version 跟 group 信息；Tracing-ID、Tracing-RPC-ID 用于全鏈路追蹤能力，分別表示 tracing id 跟 span id 信息；Cluster-Info 表示集群信息，可以使用其構(gòu)建一些如集群劃分等路由相關(guān)的靈活的服務(wù)治理能力。

Triple Streaming

Triple協(xié)議相比傳統(tǒng)的unary方式，多了目前提供的Streaming RPC的能力

Streaming 用于什么場景呢？
在一些大文件傳輸、直播等應(yīng)用場景中， consumer或provider需要跟對端進行大量數(shù)據(jù)的傳輸，由于這些情況下的數(shù)據(jù)量是非常大的，因此是沒有辦法可以在一個RPC的數(shù)據(jù)包中進行傳輸，因此對于這些數(shù)據(jù)包我們需要對數(shù)據(jù)包進行分片之后，通過多次RPC調(diào)用進行傳輸，如果我們對這些已經(jīng)拆分了的RPC數(shù)據(jù)包進行并行傳輸，那么到對端后相關(guān)的數(shù)據(jù)包是無序的，需要對接收到的數(shù)據(jù)進行排序拼接，相關(guān)的邏輯會非常復(fù)雜。但如果我們對拆分了的RPC數(shù)據(jù)包進行串行傳輸，那么對應(yīng)的網(wǎng)絡(luò)傳輸RTT與數(shù)據(jù)處理的時延會是非常大的。

為了解決以上的問題，并且為了大量數(shù)據(jù)的傳輸以流水線方式在consumer與provider之間傳輸，因此Streaming RPC的模型應(yīng)運而生。

通過Triple協(xié)議的Streaming RPC方式，會在consumer跟provider之間建立多條用戶態(tài)的長連接，Stream。同一個TCP連接之上能同時存在多個Stream，其中每條Stream都有StreamId進行標(biāo)識，對于一條Stream上的數(shù)據(jù)包會以順序方式讀寫。

總結(jié)

在API領(lǐng)域，最重要的趨勢是標(biāo)準(zhǔn)化技術(shù)的崛起。Triple 協(xié)議是 Dubbo3 推出的主力協(xié)議。它采用分層設(shè)計，其數(shù)據(jù)交換格式基于Protobuf (Protocol Buffers) 協(xié)議開發(fā)，具備優(yōu)秀的序列化/反序列化效率，當(dāng)然還支持多種序列化方式，也支持眾多開發(fā)語言。在傳輸層協(xié)議，Triple 選擇了 HTTP/2，相較于 HTTP/1.1，其傳輸效率有了很大提升。此外HTTP/2作為一個成熟的開放標(biāo)準(zhǔn)，具備豐富的安全、流控等能力，同時擁有良好的互操作性。Triple 不僅可以用于Server端服務(wù)調(diào)用，也可以支持瀏覽器、移動App和IoT設(shè)備與后端服務(wù)的交互，同時 Triple協(xié)議無縫支持 Dubbo3 的全部服務(wù)治理能力。

在Cloud Native的潮流下，跨平臺、跨廠商、跨環(huán)境的系統(tǒng)間互操作性的需求必然會催生基于開放標(biāo)準(zhǔn)的RPC技術(shù)，而gRPC順應(yīng)了歷史趨勢，得到了越來越廣泛地應(yīng)用。在微服務(wù)領(lǐng)域，Triple協(xié)議的提出與落地，是 Dubbo3 邁向云原生微服務(wù)的一大步。