[[356992]]

本文轉載自微信公眾號「Java極客技術」，作者鴨血粉絲。轉載本文請聯系Java極客技術公眾號。   

阿粉之前看了一場架構師之路沈劍老師的一場直播，最近又重溫了一下，根據自己的認知總結了一下，分享給大家。

MQ 想必大家或多或少都用過，接入 MQ 之后的整體架構如下：

 

可以看到使用 MQ 之后，上下游通信就變成圖上的這種方式。

這種跨進程的通信方式，我們還有一種常用的解決方案，使用 Dubbo 等這類 RPC 服務。

理論上使用 RPC 的跨進程通信的場景，使用 MQ 也能解決，當然反過來也能說通。

那為什么不都用 RPC，或者 MQ 來解決那?

這其實都是業務場景決定的，拋開業務場景來談架構都是耍流氓!沒有全能的架構，只要適合的架構。

下面我們來看看哪些場景適合 RPC，而哪些場景適合 MQ。

RPC 場景

使用 RPC 的場景一般都是上游服務需要實時依賴下游服務的返回。

我們以一個登錄服務為例，架構圖如下：

 

用戶發起的登錄請求首先由對外的 WEB 服務接受，然后 WEB 服務服務調用用戶服務查詢用戶信息，然后比對用戶密碼。

也就是說我們的 WEB 應用需要實時依賴用戶服務返回的用戶信息，如果沒有返回，這次登錄將會失敗。

假如這個場景我們用 MQ 代替， WEB 應用發送 MQ 消息之后，然后流程就結束了，此時 WEB 應用無法拿到用戶信息。

所以說對于這種需要強依賴下游返回的場景，使用 MQ 將會帶來以下不足：

• 上游無法直接得到下游結果
• 增加一個 MQ 組件，系統更復雜

MQ 場景

上游不關心下游結果的場景舉個例子，在我們第三方支付系統中，每支付成功一筆，都需要計算手續費。

 

這個場景我們顯然可以使用 RPC 完成調用，但是實際上，支付系統是不關心的計費系統的結果，兩個系統不存在直接強依賴的關系。

大家可以想象一下，用戶實際上已經收到銀行卡扣款短信了，但是支付系統因為計費系統失敗，導致對外返回是失敗的結果。這對于用戶來講，不能接受啊。我都付錢了，你卻告訴我支付異常。

所以對于這種場景，直接使用 RPC 調用由以下幾點不足：

• 系統整體調用延時增加
• 下游服務異常，影響上游服務。兩者物理以及邏輯依賴嚴重
• 若后面再增加一個下游系統，需要知道支付成功的結果，上游系統需要改動代碼。這種情況對于上游情況來講，就會很煩。明明與上游系統沒有什么關系，卻需要修改代碼。

那一定要用 MQ 解決嗎?

其實不一定，對于我們上面舉的場景，我們其實可以使用異步 RPC 或者線程池異步調用 RPC 就可以解決。

畢竟增加一個 MQ， 系統就變得更加復雜，我們還要單獨運維 MQ，這對于小團隊來講，工作量還是很大的。

但是這種方式，還是解決不了，增加一個下游系統，上游系統還要改動的代碼囧境。

增加 MQ 解耦

這個場景使用 MQ 解耦，帶來幾點優點：

• 任務一：上游系統執行時間變短
• 任務二：上下游邏輯解耦，物理解耦
• 任務三：最重要一點，增加一個下游服務，其只要訂閱即可，上游服務無需要改動代碼

數據驅動的定時任務場景舉個例子，支付公司每日都需要對賬，主要目的是核實自己系統的應收的錢與支付渠道端是否一致，主要流程分為以下幾步：

定時任務下載渠道對賬文件，下載方式可能為 Http 接口下載，也有可能 SFTP 下載

定時任務解析對賬文件，然后將對賬數據入庫

定時任務將自己本端支付數據與對賬數據核對

上面的定時任務使用 Spring-Schedule 調度，假設各個定時任務下載時間如下所示：

 

上圖中三個任務，任務二需要依賴任務一完成，而任務三又需要依賴任務二完成。

我們之前使用這種模式，通常會碰到幾個問題：

• 通常 06:00 就能下載到對賬文件，但是有時候渠道端對賬文件延遲，就會導致任務一執行失敗，這樣就會后續兩個定時任務也會執行失敗
• 假設任務二數據過多，執行時間過長，任務三執行時還沒結束，這就導致任務三無法拿到全量數據，導致對賬異常
• 整體任務執行時間過長
• 任務一若調整時間，可能導致任務二，任務三都需要調整時間

使用 MQ解耦

使用 MQ 解耦之后架構圖如下：

 

這種方式，只要任務一的定時任務準時啟動，任務一完成之后發送 MQ 消息，任務二收到之后就會啟動任務，結束之后再發送消息給 MQ。任務三流程同任務二

使用這種方式存在優點為：

• 下游任務只要收到消息就能立刻執行，不需要額外等待，整體任務執行時間變短
• 上游任務時間變動，無需修改下游任務時間。我們這個例子，只需要任務一的實際即可

總結

對于上游需要關注下游返回結果的場景，不適合使用 MQ。

適合使用 MQ 的場景有：

上游不關心下游結果的場景

 

數據驅動的定時任務依賴