基於 RocketMQ 的 Dubbo-go 通訊新正規化

本文作者：郝洪範 ，Dubbo-go Committer，京東資深研發工程師。

一、MQ Request Reply特性介紹

什麼是 RPC 通訊？

如上圖所示，類似於本地呼叫，A 服務響應呼叫 B 服務的 helloworld 方法需要怎麼做？首先，A 服務的 Client Sub 收到函數呼叫後，會將呼叫方法以及引數序列化。Client Sub 通過 socket 將訊息傳送到伺服器端。伺服器端 B 接收到請求後，會按照協定將 request body 進行反序列化，獲取將要呼叫的函數名以及引數。伺服器端呼叫該函數並獲取到返回結果，Server Stub 將結果進行序列化後通過 socket 傳送到 Client Sub，由 Client Sub 按照協定將訊息反序列化，得到最終結果。

而實際上 RPC 框架會比以上流程更加複雜，還需考慮服務重試、熔斷、 backup、request、路由負載均衡等。

如何利用 MQ 進行 RPC 通訊？原理很簡單，用 MQ 作為通訊管道，模擬全雙工通訊。

如圖所示，使用者端 A 想要呼叫伺服器端 B 的 helloworld 方法需要怎麼做？首先，使用者端會將函數名字以及引數進行序列化，傳送到 MQ Broker。MQ消費者消費到該訊息後，會呼叫本地函數 helloworld，獲取到結果後再將結果傳送到 MQ Broker，MQ Broker  按照某種約定將響應結果傳送到之前請求的 client 上。

以上流程完全為模擬 TCP 通訊流程。RocketMQ 4.6.0分支也開始支援此特性——Request Reply。

上圖為 Request Reply 實現原理。

Producer 建立 RequestFutureTable，producer 發起函數呼叫時，會將函數呼叫傳送到 Broker 同時將該請求記錄傳送到 RequestFutureTable 中。Consumer 收到訊息後，會呼叫本地函數將結果序列化返回給 Broker，同時返回給 Broker 特定的 request reply topic，附帶返回的還有 producer。Broker獲取到這些資訊後，主動將訊息傳送到之前請求的 producer 上，producer 收到訊息後會從RequestFutureTable中核對是否存在此請求，然後整完成整個 RPC 過程。

MQ雖然能用來模擬RPC的全雙工通訊，但需要付出一定代價：

• 使用MQ後，一次 TCP被拆解為四次，耗時增加，RPC 效能降低。
• 訊息從 producer 傳送到 Broker 再傳送到 consumer，增加了訊息傳遞的複雜性。
• MQ 會將訊息落盤，進一步降低 RPC 的吞吐能力。
• RPC 通訊嚴重依賴 MQ 的運維能力，MQ 容易成為效能瓶頸。
• MQ 穩定性的維護成本遠比 RPC 複雜。

綜合考慮，使用 MQ 進行 RPC 通訊不適合對介面耗時非常敏感的場景，但是任何技術都有其合適的應用場景，MQ 進行 RPC 通訊也有其獨特的妙用。

比如可以讓 RPC 執行在類似於訊息匯流排中，便於所有訊息在統一入口進行訊息的落盤審計。利用 MQ 的重試特性，能夠保證所有請求都不會丟失。同時所有請求都運轉在RocketMQ 中，訊息請求的安全性得到進一步提高。

以上特性使得 MQ RPC 通訊特別適合訊息安全性審查嚴格的場景，比如金融和銀行場景，此類場景對介面時延要求不高，但對請求的安全性要求特別高。比如微眾銀行就利用 RocketMQ 的 request reply 特性構建了整個金融產品的 RPC 框架。

二、Dubbo-go介紹

Dubbo-go 是一款高效能的 go 語言微服務 RPC 框架，目標是打造新一代微服務基礎設施，實現 Bridging The Gap Between X And Go，即使得 Dubbo-go 能與任何框架進行通訊。

Dubbo-go 的框架的優勢有以下幾點優勢：

• 開發者可以使用 Dubbo-go 框架輕鬆構建 RPC 服務
• 可以體驗 Dubbo-go 強大的服務治理能力與運維能力。
• Dubbo-go 的生態也在豐富中，比如 pixiu 閘道器已經可以在生產環境中使用。
• Dubbo-go 的社群活躍度非常高，只要提交 issue，馬上會有人進行跟進。

Dubbo-go 由四部分組成，分別是registry（註冊中心）、consumer（使用者端）、provider（伺服器端）、Monitor(Dubbo-go 的控制面)。使用者端發起請求時，會首先從 register 獲取客伺服器端的服務列表，然後通過對應的負載均衡獲取到伺服器端，兩者建立起 socket 進行通訊。

Dubbo-go生態正在不斷快速發展中。目前，Dubbo-go 能與gRPC、Spring Cloud、Dubbo、Java 進行通訊，同時沉澱了 Dubbo-go 閘道器專案等，已經有公司在實際生產中使用。

RocketMQ 社群與Dubbo-go 社群聯合推出了新功能，讓 Dubbo-go 通過 RocketMQ 進行 RPC 通訊來擴充套件 Dubbo-go 的通訊方式。利用 Dubbo-go 豐富的服務治理能力和 RocketMQ 穩定的 RPC 通訊能力，兩者強強聯合，打造 RPC 通訊新正規化。

Dubbo-go 通過 RocketMQ 進行通訊的流程如下：Dubbo-go client 利用 request reply 特性將訊息傳送的 RocketMQ 的 Broker。Dubboserver 消費到 RocketMQ 的訊息後，同樣利用 RocketMQ 的 request reply 特性將訊息返回到 Broker。Broker 將訊息推播到傳送訊息的 Dubbo client 上。整個流程與 MQ 進行 RPC 通訊的一致。

Dubbo-go 服務註冊流程如下：首先 RocketMQ Broker 會向 nameserver 註冊 Broker、topic、queue等資訊。Dubbo-go client 會從 nameserver 中拉取路由資訊，Dubbo-go server 訂閱 topic 資訊。

Dubbo-go 的通訊協定目前能夠支援 Dubbo、Triple 、gRPC、Rest。由於 Dubbo-go 要利用 RocketMQ 進行通訊，我們需要構建新的通訊協定，已經基本設計完畢，能夠讓 RocketMQ 與 Dubbo-go 完美融合。整個序列化協定。

本身 Dubbo-go 能夠支援 Python2、JSON、Protobuf 和 MsgPack，Dubbo-go 利用 RocketMQ 進行通訊同樣能夠支援以上四種序列化協定，但主要使用 Protobuf，另外的三種協定基本作為擴充來使用。

利用 RocketMQ 承載 Dubbo-go 的通訊能力已經開發完畢，正在測試中，很快能與大家見面。