![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/1c8ebd61b9ab4076b69afdd937b51e1d.png)

作者 | 郭浩（項升）  阿里巴巴經濟體 RPC 框架負責人

> **導讀**：Dubbo 社群策劃了【Dubbo 雲原生之路】系列文章，和大家一起回顧 Apache Dubbo 產品和社群的發展，並展望未來發展。系列文章主要涵蓋 Dubbo 技術解讀、社群運營、應用案例解析三大部分。本文為系列第 4 篇。

# 前言

協議是 RPC 的基礎。資料在連線上以什麼格式傳輸，服務端如何確定收到請求的大小，同一個連線上能不能同時存在多個請求，請求如果出錯了應該怎麼響應……這些都是需要協議解決的問題。

從定義上講，協議透過定義規則、格式和語義來約定資料如何在網路間傳輸。RPC 需要通訊的兩端都能夠識別同一種協議。資料在網路上以位元流的方式傳輸，如果本端的協議對端不識別，對端就無法從請求中獲取到有用資訊，就會出現雞同鴨講的情況，無法實現上層的業務需求。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/0dfe4cfcb34a4e9b8014e3aa4e1ef915.png)

一個簡單的協議需要定義資料交換格式，協議格式和請求方式。

資料交換格式在 RPC 中也叫做序列化格式。常用的序列化有 JSON / Protobuf / Hessian 等，評價序列化優劣一般從三個維度：

- 序列化後的位元組陣列大小
- 序列化和反序列化速度
- 序列化後的可讀性

協議在選取序列化方式時，按照具體的需求在這三個維度中互相取捨。序列化後的陣列越小，越節省網路流量，但序列化過程可能更消耗時間。JSON\XML 這類基於文字的序列化方式往往更容易被開發者接受，因為相比於一連傳的位元組陣列，文字更容易被理解，在各層裝置中都能比較容易的識別，但可讀性提高的後果是效能大幅降低。

協議格式是和 RPC 框架緊密相關的，按照功能劃分有兩種：

- 一種是緊湊型協議，只提供用於呼叫的簡單後設資料和資料內容；
- 另外一種是複合型協議，會攜帶框架層的後設資料用來提供功能上的增強，這類協議的一個代表就是 RSocket。

請求方式和協議格式息息相關，常見的請求格式有同步 Request/Response 和非同步 Request/Response，區別是客戶端發出一個請求後，是否需要同步等待響應返回。如果不需要等待響應，一個連結上就可以同時存在多個未完成的請求，這也被叫做多路複用。另外的請求模型有 Streaming ，在一次完整的業務呼叫中存在多次 RPC，每次都傳輸一部分資料，適合流資料傳輸。

有了這三個基本約定，就能實現一個簡單的 RPC 協議了。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/8374406b335846ee99d3b597209404a0.png)

Dubbo3 的一個核心內容就是定義下一代 RPC 協議。除了基礎的通訊功能，新協議還應該具有以下特性：

- 統一的跨語言二進位制格式
- 支援 Streaming 和應用層全雙工呼叫模型
- 易於擴充套件
- 能夠被各層裝置識別

這裡我們對比一些常用的協議，來探索新協議的形態。

# HTTP/1.1

HTTP/1.1 應該是應用最廣泛的協議，簡單清晰的語法，跨語言以及對原生移動端的支援都讓其成為了事實上最被廣泛接受的 RPC 方案。

然而從 RPC 協議的訴求上講， HTTP1.1 主要有以下幾個問題

- 隊頭阻塞(HOL)導致其在單連線的效能低下，儘管支援了 pipeline 但仍無法避免響應按序返回；

- 基於文字的協議每次請求都會重複攜帶很多繁雜無用的頭部資訊，浪費頻寬影響效能；

- 純粹的 Request/Response 請求模型，無法實現 Server Push，只能依靠客戶端輪詢，同樣 Streaming 的全雙工也是不安全的。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/79fd0b600dba40668caff278cea9e59b.png)

# RESP

RESP 是 Redis 使用的通訊協議，其簡潔易於理解的格式也助力了 Redis 各語言客戶端的快速發展。但是這種類似 HTTP/1.1 的協議也存在著同樣的效能問題。

- 序列化表達能力弱，通常還需要藉助其他序列化方式輔助，然而協議中又不支援設定特定序列化方式，只能依靠客戶端約定；

- 同樣存在隊頭阻塞問題，pipeline 無法從根本上解決單連線效能問題；

- Pub/Sub 在單連線情況下也有數量瓶頸。

# Dubbo2.0

Dubbo2.0 協議直接定義在 TCP 傳輸層協議上，為協議功能定義提供了最大的靈活性，但同時也正是因為這樣明顯的靈活性優勢，RPC 協議普遍都是定製化的私有協議。

Dubbo 協議體 Body 中有一個可擴充套件的 attachments 部分，這給 RPC 方法之外額外傳遞附加屬性提供了可能，是一個很好的設計。但是類似的 Header 部分，卻缺少類似的可擴充套件 attachments，這點可參考 HTTP 定義的 Ascii Header 設計，將 Body Attachments 和 Header Attachments 做職責劃分。

- Body 協議體中的一些 RPC 請求定位符如 Service Name、Method Name、Version 等，可以提到 Header 中，和具體的序列化協議解耦，以更好的被網路基礎設施識別或用於流量管控；

- 擴充套件性不夠好，欠缺協議升級方面的設計，如 Header 頭中沒有預留的狀態標識位，或者像 HTTP 有專為協議升級或協商設計的特殊 packet；

- 在 Java 版本的程式碼實現上，不夠精簡和通用。如在鏈路傳輸中，存在一些語言繫結的內容；訊息體中存在冗餘內容，如 Service Name 在 Body 和 Attachments 中都存在。

# HTTP/2.0

HTTP/2.0 保留了 HTTP/1 的所有語義，在保持相容的同時，在通訊模型和傳輸效率上做了很大的改進，主要也是為了解決 HTTP/1 中的問題。

- 支援單條鏈路上的 Multiplexing，相比於 Request - Response 獨佔鏈路，基於 Frame 實現更高效利用鏈路，StreamId 提供了上下文狀態，client 可以根據 StreamId 支援亂序 Response 返回；

- 頭部壓縮 HPACK，基於靜態表和動態表實現了 Header 快取，減少傳輸資料量；

- Request - Stream 語義，原生支援 Server Push 和 Stream 資料傳輸；

- Binary Frame，二進位制分幀，可以單獨處理 Header 和 Data。

HTTP/2.0 雖然克服了以上問題，但也存在著一些爭議點，比如在 TCP 的上層進行流量控制的必要性，以及對 HTTP 語義透過 HPACK 相容是否過於繁瑣複雜。

# gRPC

相比較於一些框架將應用層協議構建在裸 TCP 上，gRPC 選擇了 HTTP/2.0 作為傳輸層協議。透過對 Header 內容和 Payload 格式的限定實現上層協議功能。

下面是 gRPC 的一些設計理念：

- Coverage & Simplicity，協議設計和框架實現要足夠通用和簡單，能執行在任何裝置之上，甚至一些資源首先的如 IoT、Mobile 等裝置；

- Interoperability & Reach，要構建在更通用的協議之上，協議本身要能被網路上幾乎所有的基礎設施所支援；

- General Purpose & Performant，要在場景和效能間做好平衡，首先協議本身要是適用於各種場景的，同時也要儘量有高的效能；

- Payload Agnostic，協議上傳輸的負載要保持語言和平臺中立；

- Streaming，要支援 Request - Response、Request - Stream、Bi-Steam 等通訊模型；

- Flow Control，協議自身具備流量感知和限制的能力；

- Metadata Exchange，在 RPC 服務定義之外，提供額外附加資料傳輸的能力。

在這樣的設計理念指導下，gRPC 最終被設計為一個跨語言、跨平臺、通用的協議。功能上基本已經完全具備或可以輕易擴充套件出需要的新功能。然而我們知道，軟體工程沒有銀彈，相比較於裸 TCP 專有協議，極限效能上 gRPC 肯定是要差一些。但是對大部分應用來說，相比較於 HTTP/1.1 的協議，gRPC/HTTP2 已經在效能上取得了很大的進步，同時又兼顧了可讀性。

序列化上，gRPC 被設計成保持 payload 中立，但實際的跨語言場景需要一個強規範的介面定義語言來保證序列化結果的一致。在 gRPC 的官方實現中，protobuf 和 json 分別用來支援效能場景和開發效率場景。從序列化方式的選擇到協議的各維度比較，基於 gRPC 擴充套件出新的協議是最優的選擇。

# Dubbo3.0

Dubbo3.0 的協議基於 gRPC ，在應用層、異常處理、協議層負載均衡支援和 Reactive 支援上提供了擴充套件。主要有三個目標：

- 在分散式大規模叢集場景下，提供更完善的負載均衡，以獲取更高效能和保證穩定性；

- 支援 tracing/monitoring 等分散式標準擴充套件，支援微服務標準化以及平滑遷移；

- Reactive 語義在協議層增強，能夠提供分散式 back-pressure 能力和更完善的 Streaming 支援。

除了協議層的支援，Dubbo3.0 新協議還包括易用性方面的支援，包括同時支援 IDL compiler 和 Annotation Compiler。客戶端將更完善地支援原生非同步回撥、Future 非同步和同步呼叫，服務端將使用非反射呼叫，這十分顯著地提升了客戶端和服務端效能。從使用者遷移的角度，Dubbo 框架將提供平滑的協議升級支援，力求儘可能少的改造程式碼或配置就能帶來成倍的效能提升。

系列文章：

- [Dubbo 雲原生之路：ASF 畢業一週年、3.0 可期](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247494485&idx=1&sn=3c5c813461d936e55684ecd80bfab464&chksm=fae6e09acd91698c50347614445577eb9e0990e163fab928b12d09dfed5bab15cbe9de52b971&scene=21#wechat_redirect)
- [Dubbo 邁出雲原生重要一步 - 應用級服務發現解析](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247491122&idx=1&sn=6c5529e6321a68ff107a5c7894eab599&chksm=fae515fdcd929cebe9928703a06c12435d5362d3f12f420d1f3f53c1d847710209cd1db4937c&scene=21#wechat_redirect)

# 總結

本文介紹了 RPC 協議的基礎概念，比較了常用的一些協議，並在這些協議的優劣對比後提出了 Dubbo3.0 協議。Dubbo3.0 協議將在易用性、跨平臺、跨語言、高效能等方面取得更大的領先。預計在 2021 年 3 月，Dubbo3.0 協議將完整支援，請大家拭目以待。

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247494967&idx=1&sn=7dd2e30ba6f1d58d289372b8503fe423&chksm=fae6e6f8cd916feeb1686f8da8fec422dd8b39683c1c022e1f8593c8ae2337438f3ce84dc77d&token=1660215492&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

Dubbo 3.0 前瞻之：常用協議對比及 RPC 協議新形態探索

相關文章