作者 | 郭浩（項(xiàng)升）? 阿里巴巴經(jīng)濟(jì)體 RPC 框架負(fù)責(zé)人

導(dǎo)讀：Dubbo 社區(qū)策劃了【Dubbo 云原生之路】系列文章，和大家一起回顧 Apache Dubbo 產(chǎn)品和社區(qū)的發(fā)展，并展望未來(lái)發(fā)展。系列文章主要涵蓋 Dubbo 技術(shù)解讀、社區(qū)運(yùn)營(yíng)、應(yīng)用案例解析三大部分。本文為系列第 4 篇。

前言

協(xié)議是 RPC 的基礎(chǔ)。數(shù)據(jù)在連接上以什么格式傳輸，服務(wù)端如何確定收到請(qǐng)求的大小，同一個(gè)連接上能不能同時(shí)存在多個(gè)請(qǐng)求，請(qǐng)求如果出錯(cuò)了應(yīng)該怎么響應(yīng)……這些都是需要協(xié)議解決的問(wèn)題。

從定義上講，協(xié)議通過(guò)定義規(guī)則、格式和語(yǔ)義來(lái)約定數(shù)據(jù)如何在網(wǎng)絡(luò)間傳輸。RPC 需要通信的兩端都能夠識(shí)別同一種協(xié)議。數(shù)據(jù)在網(wǎng)絡(luò)上以比特流的方式傳輸，如果本端的協(xié)議對(duì)端不識(shí)別，對(duì)端就無(wú)法從請(qǐng)求中獲取到有用信息，就會(huì)出現(xiàn)雞同鴨講的情況，無(wú)法實(shí)現(xiàn)上層的業(yè)務(wù)需求。

一個(gè)簡(jiǎn)單的協(xié)議需要定義數(shù)據(jù)交換格式，協(xié)議格式和請(qǐng)求方式。

數(shù)據(jù)交換格式在 RPC 中也叫做序列化格式。常用的序列化有 JSON / Protobuf / Hessian 等，評(píng)價(jià)序列化優(yōu)劣一般從三個(gè)維度：

• 序列化后的字節(jié)數(shù)組大小
• 序列化和反序列化速度
• 序列化后的可讀性

協(xié)議在選取序列化方式時(shí)，按照具體的需求在這三個(gè)維度中互相取舍。序列化后的數(shù)組越小，越節(jié)省網(wǎng)絡(luò)流量，但序列化過(guò)程可能更消耗時(shí)間。JSON\XML 這類(lèi)基于文本的序列化方式往往更容易被開(kāi)發(fā)者接受，因?yàn)橄啾扔谝贿B傳的字節(jié)數(shù)組，文本更容易被理解，在各層設(shè)備中都能比較容易的識(shí)別，但可讀性提高的后果是性能大幅降低。

協(xié)議格式是和 RPC 框架緊密相關(guān)的，按照功能劃分有兩種：

• 一種是緊湊型協(xié)議，只提供用于調(diào)用的簡(jiǎn)單元數(shù)據(jù)和數(shù)據(jù)內(nèi)容；
• 另外一種是復(fù)合型協(xié)議，會(huì)攜帶框架層的元數(shù)據(jù)用來(lái)提供功能上的增強(qiáng)，這類(lèi)協(xié)議的一個(gè)代表就是 RSocket。

請(qǐng)求方式和協(xié)議格式息息相關(guān)，常見(jiàn)的請(qǐng)求格式有同步 Request/Response 和異步 Request/Response，區(qū)別是客戶端發(fā)出一個(gè)請(qǐng)求后，是否需要同步等待響應(yīng)返回。如果不需要等待響應(yīng)，一個(gè)鏈接上就可以同時(shí)存在多個(gè)未完成的請(qǐng)求，這也被叫做多路復(fù)用。另外的請(qǐng)求模型有 Streaming ，在一次完整的業(yè)務(wù)調(diào)用中存在多次 RPC，每次都傳輸一部分?jǐn)?shù)據(jù)，適合流數(shù)據(jù)傳輸。

有了這三個(gè)基本約定，就能實(shí)現(xiàn)一個(gè)簡(jiǎn)單的 RPC 協(xié)議了。

Dubbo3 的一個(gè)核心內(nèi)容就是定義下一代 RPC 協(xié)議。除了基礎(chǔ)的通信功能，新協(xié)議還應(yīng)該具有以下特性：

• 統(tǒng)一的跨語(yǔ)言二進(jìn)制格式
• 支持 Streaming 和應(yīng)用層全雙工調(diào)用模型
• 易于擴(kuò)展
• 能夠被各層設(shè)備識(shí)別

這里我們對(duì)比一些常用的協(xié)議，來(lái)探索新協(xié)議的形態(tài)。

HTTP/1.1

HTTP/1.1 應(yīng)該是應(yīng)用最廣泛的協(xié)議，簡(jiǎn)單清晰的語(yǔ)法，跨語(yǔ)言以及對(duì)原生移動(dòng)端的支持都讓其成為了事實(shí)上最被廣泛接受的 RPC 方案。

然而從 RPC 協(xié)議的訴求上講， HTTP1.1 主要有以下幾個(gè)問(wèn)題

• 隊(duì)頭阻塞(HOL)導(dǎo)致其在單連接的性能低下，盡管支持了 pipeline 但仍無(wú)法避免響應(yīng)按序返回；

• 基于文本的協(xié)議每次請(qǐng)求都會(huì)重復(fù)攜帶很多繁雜無(wú)用的頭部信息，浪費(fèi)帶寬影響性能；

• 純粹的 Request/Response 請(qǐng)求模型，無(wú)法實(shí)現(xiàn) Server Push，只能依靠客戶端輪詢，同樣 Streaming 的全雙工也是不安全的。

RESP

RESP?是 Redis 使用的通信協(xié)議，其簡(jiǎn)潔易于理解的格式也助力了 Redis 各語(yǔ)言客戶端的快速發(fā)展。但是這種類(lèi)似 HTTP/1.1 的協(xié)議也存在著同樣的性能問(wèn)題。

• 序列化表達(dá)能力弱，通常還需要借助其他序列化方式輔助，然而協(xié)議中又不支持設(shè)置特定序列化方式，只能依靠客戶端約定；

• 同樣存在隊(duì)頭阻塞問(wèn)題，pipeline 無(wú)法從根本上解決單連接性能問(wèn)題；

• Pub/Sub 在單連接情況下也有數(shù)量瓶頸。

Dubbo2.0

Dubbo2.0 協(xié)議直接定義在 TCP 傳輸層協(xié)議上，為協(xié)議功能定義提供了最大的靈活性，但同時(shí)也正是因?yàn)檫@樣明顯的靈活性優(yōu)勢(shì)，RPC 協(xié)議普遍都是定制化的私有協(xié)議。

Dubbo 協(xié)議體 Body 中有一個(gè)可擴(kuò)展的 attachments 部分，這給 RPC 方法之外額外傳遞附加屬性提供了可能，是一個(gè)很好的設(shè)計(jì)。但是類(lèi)似的 Header 部分，卻缺少類(lèi)似的可擴(kuò)展 attachments，這點(diǎn)可參考 HTTP 定義的 Ascii Header 設(shè)計(jì)，將 Body Attachments 和 Header Attachments 做職責(zé)劃分。

• Body 協(xié)議體中的一些 RPC 請(qǐng)求定位符如 Service Name、Method Name、Version 等，可以提到 Header 中，和具體的序列化協(xié)議解耦，以更好的被網(wǎng)絡(luò)基礎(chǔ)設(shè)施識(shí)別或用于流量管控；

• 擴(kuò)展性不夠好，欠缺協(xié)議升級(jí)方面的設(shè)計(jì)，如 Header 頭中沒(méi)有預(yù)留的狀態(tài)標(biāo)識(shí)位，或者像 HTTP 有專(zhuān)為協(xié)議升級(jí)或協(xié)商設(shè)計(jì)的特殊 packet；

• 在 Java 版本的代碼實(shí)現(xiàn)上，不夠精簡(jiǎn)和通用。如在鏈路傳輸中，存在一些語(yǔ)言綁定的內(nèi)容；消息體中存在冗余內(nèi)容，如 Service Name 在 Body 和 Attachments 中都存在。

HTTP/2.0

HTTP/2.0 保留了 HTTP/1 的所有語(yǔ)義，在保持兼容的同時(shí)，在通信模型和傳輸效率上做了很大的改進(jìn)，主要也是為了解決 HTTP/1 中的問(wèn)題。

• 支持單條鏈路上的 Multiplexing，相比于 Request - Response 獨(dú)占鏈路，基于 Frame 實(shí)現(xiàn)更高效利用鏈路，StreamId 提供了上下文狀態(tài)，client 可以根據(jù) StreamId 支持亂序 Response 返回；

• 頭部壓縮 HPACK，基于靜態(tài)表和動(dòng)態(tài)表實(shí)現(xiàn)了 Header 緩存，減少傳輸數(shù)據(jù)量；

• Request - Stream 語(yǔ)義，原生支持 Server Push 和 Stream 數(shù)據(jù)傳輸；

• Binary Frame，二進(jìn)制分幀，可以單獨(dú)處理 Header 和 Data。

HTTP/2.0 雖然克服了以上問(wèn)題，但也存在著一些爭(zhēng)議點(diǎn)，比如在 TCP 的上層進(jìn)行流量控制的必要性，以及對(duì) HTTP 語(yǔ)義通過(guò) HPACK 兼容是否過(guò)于繁瑣復(fù)雜。

gRPC

相比較于一些框架將應(yīng)用層協(xié)議構(gòu)建在裸 TCP 上，gRPC 選擇了 HTTP/2.0 作為傳輸層協(xié)議。通過(guò)對(duì) Header 內(nèi)容和 Payload 格式的限定實(shí)現(xiàn)上層協(xié)議功能。

下面是 gRPC 的一些設(shè)計(jì)理念：

• Coverage & Simplicity，協(xié)議設(shè)計(jì)和框架實(shí)現(xiàn)要足夠通用和簡(jiǎn)單，能運(yùn)行在任何設(shè)備之上，甚至一些資源首先的如 IoT、Mobile 等設(shè)備；

• Interoperability & Reach，要構(gòu)建在更通用的協(xié)議之上，協(xié)議本身要能被網(wǎng)絡(luò)上幾乎所有的基礎(chǔ)設(shè)施所支持；

• General Purpose & Performant，要在場(chǎng)景和性能間做好平衡，首先協(xié)議本身要是適用于各種場(chǎng)景的，同時(shí)也要盡量有高的性能；

• Payload Agnostic，協(xié)議上傳輸?shù)呢?fù)載要保持語(yǔ)言和平臺(tái)中立；

• Streaming，要支持 Request - Response、Request - Stream、Bi-Steam 等通信模型；

• Flow Control，協(xié)議自身具備流量感知和限制的能力；

• Metadata Exchange，在 RPC 服務(wù)定義之外，提供額外附加數(shù)據(jù)傳輸?shù)哪芰Α?/p>

在這樣的設(shè)計(jì)理念指導(dǎo)下，gRPC 最終被設(shè)計(jì)為一個(gè)跨語(yǔ)言、跨平臺(tái)、通用的協(xié)議。功能上基本已經(jīng)完全具備或可以輕易擴(kuò)展出需要的新功能。然而我們知道，軟件工程沒(méi)有銀彈，相比較于裸 TCP 專(zhuān)有協(xié)議，極限性能上 gRPC 肯定是要差一些。但是對(duì)大部分應(yīng)用來(lái)說(shuō)，相比較于 HTTP/1.1 的協(xié)議，gRPC/HTTP2 已經(jīng)在性能上取得了很大的進(jìn)步，同時(shí)又兼顧了可讀性。

序列化上，gRPC 被設(shè)計(jì)成保持 payload 中立，但實(shí)際的跨語(yǔ)言場(chǎng)景需要一個(gè)強(qiáng)規(guī)范的接口定義語(yǔ)言來(lái)保證序列化結(jié)果的一致。在 gRPC 的官方實(shí)現(xiàn)中，protobuf 和 json 分別用來(lái)支持性能場(chǎng)景和開(kāi)發(fā)效率場(chǎng)景。從序列化方式的選擇到協(xié)議的各維度比較，基于 gRPC 擴(kuò)展出新的協(xié)議是最優(yōu)的選擇。

Dubbo3.0

Dubbo3.0 的協(xié)議基于 gRPC ，在應(yīng)用層、異常處理、協(xié)議層負(fù)載均衡支持和 Reactive 支持上提供了擴(kuò)展。主要有三個(gè)目標(biāo)：

• 在分布式大規(guī)模集群場(chǎng)景下，提供更完善的負(fù)載均衡，以獲取更高性能和保證穩(wěn)定性；

• 支持 tracing/monitoring 等分布式標(biāo)準(zhǔn)擴(kuò)展，支持微服務(wù)標(biāo)準(zhǔn)化以及平滑遷移；

• Reactive 語(yǔ)義在協(xié)議層增強(qiáng)，能夠提供分布式 back-pressure 能力和更完善的 Streaming 支持。

除了協(xié)議層的支持，Dubbo3.0 新協(xié)議還包括易用性方面的支持，包括同時(shí)支持 IDL compiler 和 Annotation Compiler。客戶端將更完善地支持原生異步回調(diào)、Future 異步和同步調(diào)用，服務(wù)端將使用非反射調(diào)用，這十分顯著地提升了客戶端和服務(wù)端性能。從用戶遷移的角度，Dubbo 框架將提供平滑的協(xié)議升級(jí)支持，力求盡可能少的改造代碼或配置就能帶來(lái)成倍的性能提升。

系列文章：

• Dubbo 云原生之路：ASF 畢業(yè)一周年、3.0 可期
• Dubbo 邁出云原生重要一步 - 應(yīng)用級(jí)服務(wù)發(fā)現(xiàn)解析

總結(jié)

本文介紹了 RPC 協(xié)議的基礎(chǔ)概念，比較了常用的一些協(xié)議，并在這些協(xié)議的優(yōu)劣對(duì)比后提出了 Dubbo3.0 協(xié)議。Dubbo3.0 協(xié)議將在易用性、跨平臺(tái)、跨語(yǔ)言、高性能等方面取得更大的領(lǐng)先。預(yù)計(jì)在 2021 年 3 月，Dubbo3.0 協(xié)議將完整支持，請(qǐng)大家拭目以待。

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開(kāi)發(fā)者的公眾號(hào)。”

總結(jié)

以上是生活随笔為你收集整理的Dubbo 3.0 前瞻之：常用协议对比及 RPC 协议新形态探索的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。