能用 MQ 就不要用 RPC？

你好，我是老鄭。一個後端開發 10 餘年的北漂。

最近在網上看到一種觀點：“能用 MQ 就不用 RPC”。

我不這麼認爲。

今天聊聊 RPC 和 MQ 的選擇問題。對你應該有幫助。

一、RPC 與 MQ 

• RPC（Remote Procedure Call）：面向結果的同步通信機制，調用方需等待服務提供方返回結果。適用於強依賴實時結果的場景，比如用戶登錄驗證。

• MQ（Message Queue）：面向過程的異步通信工具，消息生產方不關注消費方結果。適用於解耦和處理異步任務的場景，比如訂單支付後的異步處理。

二、業務場景決定技術選型

場景

1. RPC 的核心場景：強依賴實時結果

• 案例：用戶登錄驗證

• 實時性要求高：用戶輸入賬號密碼後，必須立即返回登錄結果。

• 故障隔離：登錄服務故障不會影響其他服務。

• 場景描述：用戶登錄時，WEB 服務需要實時獲取用戶數據驗證身份。

• 選擇 RPC 的原因：

• 實時性要求高：用戶輸入賬號密碼後，必須立即返回登錄結果。

• 故障隔離：登錄服務故障不會影響其他服務。

上圖：

RPC 的三大優勢：

• 實時性：毫秒級響應

• 雙向交互：調用方直接獲取結果

• 故障隔離：單點故障不影響全局

2.  MQ 的殺手鐧：解耦與削峯填谷

• 案例：電商訂單支付後的異步處理

• 解耦：支付服務與下游業務無直接依賴，新增業務無需修改核心服務。

• 削峯填谷：支付高峯時，MQ 緩衝流量，避免系統過載。

• 場景描述：用戶支付成功後，需要觸發庫存扣減、積分計算、營銷活動等多個下游業務。

• 選擇 MQ 的原因：

• 解耦：支付服務與下游業務無直接依賴，新增業務無需修改核心服務。

• 削峯填谷：支付高峯時，MQ 緩衝流量，避免系統過載。

上圖：

MQ 的五大價值：

• 物理解耦：上下游無直接連接

• 邏輯解耦：新增業務無需修改生產者

• 流量緩衝：突發流量不壓垮系統

• 異步處理：縮短主鏈路響應時間

• 定時驅動：任務依賴鏈自動觸發

深度對比表

三、技術選型決策樹

三步決策法：

1. 是否需要實時結果？

• 是 → 選擇 RPC（如支付狀態查詢）

• 否 → 進入下一步

3. 是否存在多下游依賴？

• 是 → 選擇 MQ（如訂單支付後通知庫存、營銷系統）

• 否 → 進入下一步

5. 是否需要削峯填谷？

• 是 → 選擇 MQ（如秒殺場景）

• 否 → 選擇 RPC（如簡單服務調用）

上圖：

反模式警示

• 錯誤用 MQ 實現登錄驗證：導致流程斷裂，用戶體驗極差。

• 錯誤用 RPC 串聯多個下游服務：鏈路過長，延遲爆炸，系統脆弱。

四、架構沒有銀彈，只有權衡

最佳實踐

• 強結果依賴：選擇 RPC（如核心交易鏈路）

• 事件驅動場景：選擇 MQ（如數據同步、通知）

• 混合架構：RPC + MQ 組合使用（如支付成功後同步返回訂單號 + MQ 異步計算佣金）

核心結論：MQ 解耦上下游，RPC 打通實時路；業務場景定邊界，架構選型需思量。

讀完這篇文章，相信你心裏有了答案。

技術選型的本質是業務訴求與技術成本的博弈。

MQ 解耦的代價是系統複雜度，RPC 實時的代價是耦合風險。

優秀的架構師，能在解耦與效率間找到黃金分割點。

架構設計不是選邊站，而是根據業務需求和系統特點，選擇最適合的技術方案。

在實際項目中，我們往往需要結合 RPC 和 MQ 的優勢，構建混合架構，以滿足複雜多變的業務場景和性能要求。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/qIYXDoIqILMJlRewHDkeaA