[[409473]]

本文轉(zhuǎn)載自微信公眾號「HHFCodeRv」，作者h(yuǎn)aohongfan。轉(zhuǎn)載本文請聯(lián)系HHFCodeRv公眾號。

hi, 大家好，我是 haohongfan。

最近瀏覽 帖子[1] 的時候看到一個有意思的吐槽。

大概意思是架構(gòu)師沒有選用 RPC 框架來做服務(wù)間調(diào)用，而選擇用 MQ 來代替。是不是很意外?

當(dāng)然不出意外的，評論區(qū)炸了!

現(xiàn)在提出一些疑問：

• 這個架構(gòu)師的做法對嗎 ?
• MQ 是否能做 RPC 調(diào)用 ?

RPC 框架的職責(zé)

回答上面問題之前，稍微捋一下 RPC 框架。目前市面上比較流行的 RPC 框架其實并不多。

• Java: SpringCloud，Dubbo 等
• Go: Dubbogo，go-micro，rpcx，go-zero 等
• 其他：Thrift，gRPC 等

當(dāng)然還有其他的一些框架，這里就不再羅列。雖說 RPC 多如牛毛，但是大家干的事情基本都差不多，都是穩(wěn)定，高效、準(zhǔn)確的進(jìn)行服務(wù)間遠(yuǎn)程調(diào)用。

說起 RPC 應(yīng)該大部分人下意識會聯(lián)想到 gRPC，不過 gRPC 只提供的了服務(wù)間通信的能力，但卻沒有開源對應(yīng)的服務(wù)治理的能力，需要進(jìn)行二次開發(fā)。Thrift 也是同樣的問題。

下面以 Dubbogo 為例，大概介紹下 Dubbogo 實現(xiàn)的功能。

Dubbo-go 還有下面這些特點：

• 傳輸支持 http2
• 雙向流模式 rpc
• 應(yīng)用級服務(wù)發(fā)現(xiàn)

跟 Dubbo(Java) 版本對齊，互相之間能穩(wěn)定通信，同時也打通與其他微服務(wù)框架的通信，如：SpringCloud、gRPC

綜上，Dubbo-go 為了保證數(shù)據(jù)準(zhǔn)確、高效、穩(wěn)定傳輸，做了各種各樣的架構(gòu)設(shè)計。隨著 dubbo 3.0 的發(fā)布，在易用性、超大規(guī)模微服務(wù)實踐、云原生基礎(chǔ)設(shè)施適配等幾大方向上進(jìn)行了全面升級。

MQ 代替 RPC ?

接著說 MQ 是否能替代 RPC。先看看 MQ 被寫進(jìn)八股文里面的幾大特性：

• 服務(wù)間解耦
• 最終一致性
• 流量削峰
• 異步消費(fèi)

MQ 是微服務(wù)框架中必不可少的一環(huán)，上面的特性是我們?nèi)粘ｉ_發(fā)中最常用的。這些特性確實能讓系統(tǒng)的穩(wěn)定性得到增強(qiáng)，同時也讓系統(tǒng)的構(gòu)建出現(xiàn)更多的可能性。

但是是否能讓 MQ 來代替 RPC，做服務(wù)間的調(diào)用?回答這個問題之前，我們再來看看 RPC 是如何工作的。

大概流程(資料節(jié)選 dubbogo website[2])

• 類似本地調(diào)用，Client 調(diào)用遠(yuǎn)程服務(wù)
• Client stub 收到調(diào)用，把調(diào)用方法、參數(shù)序列化
• Client 通過 socket 把消息發(fā)送到服務(wù)端
• Server stub 收到消息后，將消息對象反序列化
• Server stub 根據(jù)解碼結(jié)果調(diào)用本地的服務(wù)，并將結(jié)果返回給 Server stub
• Server stub 將返回結(jié)果序列化，通過 sockets 將消息發(fā)送到客戶端
• Client stub 接收到結(jié)果消息，對返回消息反序列化
• 客戶端得到最終結(jié)果

簡單概括下 RPC 調(diào)用就是 Client 通過 TCP 調(diào)用 Server 的一個函數(shù)，得到一個返回結(jié)果。

再簡單點，是不是可以拆分下面兩個過程：

1. Client 發(fā)起一個調(diào)用到 Server
2. Server 返回一個結(jié)果到 Client

那么是不是可以用 MQ 模擬這個過程。

當(dāng)然這個流程并不是我瞎寫的，這是 RabbitMQ 的官方教程 Remote procedure call (RPC)[3]，有興趣的可以看文末的參考鏈接。

RabbitMQ tutorial 這篇文章基本就是 MQ 代替 RPC 的理論支持，所以文章開篇帖子提到的 Java 架構(gòu)師的方案也不算無的放矢，也不算是錯的。

MQ 代替 RPC 的真實情況

正常情況有點規(guī)模互聯(lián)網(wǎng)公司內(nèi)部都是會有一套 RPC 框架的，要么是基于開源版本的二次開發(fā)版本，要么完全自研的，使用過或者維護(hù)公司框架的都會被各種問題折磨到死，比如：限流、熔斷、重試、服務(wù)注冊發(fā)現(xiàn)、網(wǎng)絡(luò)問題，SDK 升級等。

如果能用 MQ 代替 RPC 做服務(wù)間調(diào)用，那是不是只用維護(hù)一套 MQ 基礎(chǔ)組件就可以了，既減少了人力的配置，又能將問題歸納。

理想很豐滿，真相往往卻很殘酷。

如果你下意識去搜一下：用 MQ 代替 RPC 進(jìn)行服務(wù)間通信，你會發(fā)現(xiàn)網(wǎng)上只有寥寥幾個 Demo 而已，并沒有太多真實實踐。

沒有太多實踐 并不代表沒有人在項目中實戰(zhàn)過，比如那個 Java 架構(gòu)師。曾經(jīng)專門向朋友請教過這個設(shè)計，話說某大廠曾經(jīng)在某個項目做了 MQ 代替 RPC 的實踐，但是三個月不到這個項目就被斃了。所以你看不到這個設(shè)計方案的缺點：因為很多人不能把失敗的案例放出來而已。

簡單說下這個方案的缺點吧：

• 本來 一次 TCP 通信就搞定的事情，用 MQ 后會被拆分成 四次 TCP，耗時增加不少。
• 目前 MQ 大部分消費(fèi)端是 Pull 模型，有一定的耗時成本
• 服務(wù)間調(diào)用完全依賴于 MQ 的穩(wěn)定性。從目前使用 MQ 經(jīng)驗來看，MQ 穩(wěn)定性的維護(hù)成本比 RPC 復(fù)雜太多了。如果做異步調(diào)用還能容忍出錯、延時，做同步調(diào)用的話，這些都是不能忽略的問題
• 如果用 MQ 代替 RPC，那些 RPC 框架做的服務(wù)治理的事情，MQ 都需要實現(xiàn)一遍，工作量并沒有減少
• 。。。

現(xiàn)在說一下統(tǒng)一結(jié)論：

用 MQ 代替 RPC 只是一種理論，但是高可用無法保障，而且對業(yè)務(wù)開發(fā)來說就更加黑盒了，出現(xiàn)問題就只能干瞪眼了，不建議業(yè)務(wù)開發(fā)實踐。