建站
咨詢
售后
建站咨詢
新聞中心
本文轉載自微信公眾號「Java極客技術」，作者鴨血粉絲。轉載本文請聯系Java極客技術公眾號。
創(chuàng)新互聯建站專注于企業(yè)網絡營銷推廣、網站重做改版、韶關網站定制設計、自適應品牌網站建設、H5網站設計、成都商城網站開發(fā)、集團公司官網建設、成都外貿網站制作、高端網站制作、響應式網頁設計等建站業(yè)務，價格優(yōu)惠性價比高，為韶關等各大城市提供網站開發(fā)制作服務。
阿粉之前看了一場架構師之路沈劍老師的一場直播，最近又重溫了一下，根據自己的認知總結了一下，分享給大家。
MQ 想必大家或多或少都用過，接入 MQ 之后的整體架構如下：
可以看到使用 MQ 之后，上下游通信就變成圖上的這種方式。
這種跨進程的通信方式，我們還有一種常用的解決方案，使用 Dubbo 等這類 RPC 服務。
理論上使用 RPC 的跨進程通信的場景，使用 MQ 也能解決，當然反過來也能說通。
那為什么不都用 RPC，或者 MQ 來解決那?
這其實都是業(yè)務場景決定的，拋開業(yè)務場景來談架構都是耍流氓!沒有全能的架構，只要適合的架構。
下面我們來看看哪些場景適合 RPC，而哪些場景適合 MQ。
RPC 場景
使用 RPC 的場景一般都是上游服務需要實時依賴下游服務的返回。
我們以一個登錄服務為例，架構圖如下：
用戶發(fā)起的登錄請求首先由對外的 WEB 服務接受，然后 WEB 服務服務調用用戶服務查詢用戶信息，然后比對用戶密碼。
也就是說我們的 WEB 應用需要實時依賴用戶服務返回的用戶信息，如果沒有返回，這次登錄將會失敗。
假如這個場景我們用 MQ 代替， WEB 應用發(fā)送 MQ 消息之后，然后流程就結束了，此時 WEB 應用無法拿到用戶信息。
所以說對于這種需要強依賴下游返回的場景，使用 MQ 將會帶來以下不足：
- 上游無法直接得到下游結果
- 增加一個 MQ 組件，系統更復雜
MQ 場景
上游不關心下游結果的場景舉個例子，在我們第三方支付系統中，每支付成功一筆，都需要計算手續(xù)費。
這個場景我們顯然可以使用 RPC 完成調用，但是實際上，支付系統是不關心的計費系統的結果，兩個系統不存在直接強依賴的關系。
大家可以想象一下，用戶實際上已經收到銀行卡扣款短信了，但是支付系統因為計費系統失敗，導致對外返回是失敗的結果。這對于用戶來講，不能接受啊。我都付錢了，你卻告訴我支付異常。
所以對于這種場景，直接使用 RPC 調用由以下幾點不足：
- 系統整體調用延時增加
- 下游服務異常，影響上游服務。兩者物理以及邏輯依賴嚴重
- 若后面再增加一個下游系統，需要知道支付成功的結果，上游系統需要改動代碼。這種情況對于上游情況來講，就會很煩。明明與上游系統沒有什么關系，卻需要修改代碼。
那一定要用 MQ 解決嗎?
其實不一定，對于我們上面舉的場景，我們其實可以使用異步 RPC 或者線程池異步調用 RPC 就可以解決。
畢竟增加一個 MQ， 系統就變得更加復雜，我們還要單獨運維 MQ，這對于小團隊來講，工作量還是很大的。
但是這種方式，還是解決不了，增加一個下游系統，上游系統還要改動的代碼囧境。
增加 MQ 解耦
這個場景使用 MQ 解耦，帶來幾點優(yōu)點：
- 任務一：上游系統執(zhí)行時間變短
- 任務二：上下游邏輯解耦，物理解耦
- 任務三：最重要一點，增加一個下游服務，其只要訂閱即可，上游服務無需要改動代碼
數據驅動的定時任務場景舉個例子，支付公司每日都需要對賬，主要目的是核實自己系統的應收的錢與支付渠道端是否一致，主要流程分為以下幾步：
定時任務下載渠道對賬文件，下載方式可能為 Http 接口下載，也有可能 SFTP 下載
定時任務解析對賬文件，然后將對賬數據入庫
定時任務將自己本端支付數據與對賬數據核對
上面的定時任務使用 Spring-Schedule 調度，假設各個定時任務下載時間如下所示：
上圖中三個任務，任務二需要依賴任務一完成，而任務三又需要依賴任務二完成。
我們之前使用這種模式，通常會碰到幾個問題：
- 通常 06:00 就能下載到對賬文件，但是有時候渠道端對賬文件延遲，就會導致任務一執(zhí)行失敗，這樣就會后續(xù)兩個定時任務也會執(zhí)行失敗
- 假設任務二數據過多，執(zhí)行時間過長，任務三執(zhí)行時還沒結束，這就導致任務三無法拿到全量數據，導致對賬異常
- 整體任務執(zhí)行時間過長
- 任務一若調整時間，可能導致任務二，任務三都需要調整時間
使用 MQ解耦
使用 MQ 解耦之后架構圖如下：
這種方式，只要任務一的定時任務準時啟動，任務一完成之后發(fā)送 MQ 消息，任務二收到之后就會啟動任務，結束之后再發(fā)送消息給 MQ。任務三流程同任務二
使用這種方式存在優(yōu)點為：
- 下游任務只要收到消息就能立刻執(zhí)行，不需要額外等待，整體任務執(zhí)行時間變短
- 上游任務時間變動，無需修改下游任務時間。我們這個例子，只需要任務一的實際即可
總結
對于上游需要關注下游返回結果的場景，不適合使用 MQ。
適合使用 MQ 的場景有：
上游不關心下游結果的場景
數據驅動的定時任務依賴
本文名稱：RPC用著好好的？為什么還需要使用MQ？
新聞來源：http://m.5511xx.com/article/dpsodhe.html
