到底什麼時候該使用MQ(講的很透徹)?

一、緣起

一切脫離業務的架構設計與新技術引入都是耍流氓。

引入一個技術之前,首先應該解答的問題是,這個技術解決什麼問題。

就像微服務分層架構之前,應該首先回答,為什麼要引入微服務,微服務究竟解決什麼問題(詳見《互聯網架構為什麼要做微服務?》)。

最近分享了幾篇MQ相關的文章:

《MQ如何實現延時消息》

《MQ如何實現消息必達》

《MQ如何實現冪等性》

不少網友詢問,究竟什麼時候使用MQ,MQ究竟適合什麼場景,故有了此文。

二、MQ是幹嘛的

消息總線(Message Queue),後文稱MQ,是一種跨進程的通信機制,用於上下游傳遞消息。

到底什麼時候該使用MQ(講的很透徹)?


在互聯網架構中,MQ是一種非常常見的上下游“邏輯解耦+物理解耦”的消息通信服務。

使用了MQ之後,消息發送上游只需要依賴MQ,邏輯上和物理上都不用依賴其他服務。

三、什麼時候不使用消息總線

到底什麼時候該使用MQ(講的很透徹)?


既然MQ是互聯網分層架構中的解耦利器,那所有通訊都使用MQ豈不是很好?這是一個嚴重的誤區,調用與被調用的關係,是無法被MQ取代的。

MQ的不足是:

1)系統更復雜,多了一個MQ組件

2)消息傳遞路徑更長,延時會增加

3)消息可靠性和重複性互為矛盾,消息不丟不重難以同時保證

4)上游無法知道下游的執行結果,這一點是很致命的

舉個栗子:用戶登錄場景,登錄頁面調用passport服務,passport服務的執行結果直接影響登錄結果,此處的“登錄頁面”與“passport服務”就必須使用調用關係,而不能使用MQ通信。

無論如何,記住這個結論調用方實時依賴執行結果的業務場景,請使用調用,而不是MQ

四、什麼時候使用MQ

【典型場景一:數據驅動的任務依賴】

什麼是任務依賴,舉個栗子,互聯網公司經常在凌晨進行一些數據統計任務,這些任務之間有一定的依賴關係,比如:

1)task3需要使用task2的輸出作為輸入

2)task2需要使用task1的輸出作為輸入

這樣的話,tast1, task2, task3之間就有任務依賴關係,必須task1先執行,再task2執行,載task3執行。

到底什麼時候該使用MQ(講的很透徹)?


對於這類需求,常見的實現方式是,使用cron人工排執行時間表:

1)task1,0:00執行,經驗執行時間為50分鐘

2)task2,1:00執行(為task1預留10分鐘buffer),經驗執行時間也是50分鐘

3)task3,2:00執行(為task2預留10分鐘buffer)

這種方法的壞處是:

1)如果有一個任務執行時間超過了預留buffer的時間,將會得到錯誤的結果,因為後置任務不清楚前置任務是否執行成功,此時要手動重跑任務,還有可能要調整排班表

2)總任務的執行時間很長,總是要預留很多buffer,如果前置任務提前完成,後置任務不會提前開始

3)如果一個任務被多個任務依賴,這個任務將會稱為關鍵路徑,排班表很難體現依賴關係,容易出錯

4)如果有一個任務的執行時間要調整,將會有多個任務的執行時間要調整

無論如何,採用“cron排班表”的方法,各任務耦合,誰用過誰痛誰知道(採用此法的請評論留言)

到底什麼時候該使用MQ(講的很透徹)?


優化方案是,採用MQ解耦:

1)task1準時開始,結束後發一個“task1 done”的消息

2)task2訂閱“task1 done”的消息,收到消息後第一時間啟動執行,結束後發一個“task2 done”的消息

3)task3同理

採用MQ的優點是:

1)不需要預留buffer,上游任務執行完,下游任務總會在第一時間被執行

2)依賴多個任務,被多個任務依賴都很好處理,只需要訂閱相關消息即可

3)有任務執行時間變化,下游任務都不需要調整執行時間

需要特別說明的是,MQ只用來傳遞上游任務執行完成的消息,並不用於傳遞真正的輸入輸出數據。

【典型場景二:上游不關心執行結果】

上游需要關注執行結果時要用“調用”,上游不關注執行結果時,就可以使用MQ了。

舉個栗子,58同城的很多下游需要關注“用戶發佈帖子”這個事件,比如招聘用戶發佈帖子後,招聘業務要獎勵58豆,房產用戶發佈帖子後,房產業務要送2個置頂,二手用戶發佈帖子後,二手業務要修改用戶統計數據。

到底什麼時候該使用MQ(講的很透徹)?


對於這類需求,常見的實現方式是,使用調用關係:

帖子發佈服務執行完成之後,調用下游招聘業務、房產業務、二手業務,來完成消息的通知,但事實上,這個通知是否正常正確的執行,帖子發佈服務根本不關注。

這種方法的壞處是:

1)帖子發佈流程的執行時間增加了

2)下游服務當機,可能導致帖子發佈服務受影響,上下游邏輯+物理依賴嚴重

3)每當增加一個需要知道“帖子發佈成功”信息的下游,修改代碼的是帖子發佈服務,這一點是最噁心的,屬於架構設計中典型的依賴倒轉,誰用過誰痛誰知道(採用此法的請評論留言)

到底什麼時候該使用MQ(講的很透徹)?


優化方案是,採用MQ解耦:

1)帖子發佈成功後,向MQ發一個消息

2)哪個下游關注“帖子發佈成功”的消息,主動去MQ訂閱

採用MQ的優點是:

1)上游執行時間短

2)上下游邏輯+物理解耦,除了與MQ有物理連接,模塊之間都不相互依賴

3)新增一個下游消息關注方,上游不需要修改任何代碼

典型場景三:上游關注執行結果,但執行時間很長

有時候上游需要關注執行結果,但執行結果時間很長(典型的是調用離線處理,或者跨公網調用),也經常使用回調網關+MQ來解耦。

舉個栗子,微信支付,跨公網調用微信的接口,執行時間會比較長,但調用方又非常關注執行結果,此時一般怎麼玩呢?

到底什麼時候該使用MQ(講的很透徹)?


一般採用“回調網關+MQ”方案來解耦:

2)微信返回調用成功,此時並不代表返回成功

4)網關將返回結果通知MQ

5)請求方收到結果通知

這裡需要注意的是,不應該由回調網關來調用上游來通知結果,如果是這樣的話,每次新增調用方,回調網關都需要修改代碼,仍然會反向依賴,使用回調網關+MQ的方案,新增任何對微信支付的調用,都不需要修改代碼啦。

五、總結

MQ是一個互聯網架構中常見的解耦利器。

-------------------------------------------------------------------------------


分享到:


相關文章: