原文位址：http://zhuanlan.51cto.com/art/201704/536407.htm
一、緣起
一切脫離業務的架構設計與新技術引入都是耍流氓。
引入一個技術之前，首先應該解答的問題是，這個技術解決什麼問題。
就像微服務分層架構之前，應該首先回答，為什麼要引入微服務，微服務究竟解決什麼問題(詳見《網際網路架構為什麼要做微服務?》)。
最近分享了幾篇MQ相關的文章：
- 《MQ如何實作延時消息》
- 《MQ如何實作消息必達》
- 《MQ如何實作幂等性》
不少網友詢問，究竟什麼時候使用MQ，MQ究竟适合什麼場景，故有了此文。
二、MQ是幹嘛的
消息總線(Message Queue)，後文稱MQ，是一種跨程序的通信機制，用于上下遊傳遞消息。
在網際網路架構中，MQ是一種非常常見的上下遊“邏輯解耦+實體解耦”的消息通信服務。
使用了MQ之後，消息發送上遊隻需要依賴MQ，邏輯上和實體上都不用依賴其他服務。
三、什麼時候不使用消息總線
既然MQ是網際網路分層架構中的解耦利器，那所有通訊都使用MQ豈不是很好?這是一個嚴重的誤區，調用與被調用的關系，是無法被MQ取代的。
MQ的不足是：
- 系統更複雜，多了一個MQ元件
- 消息傳遞路徑更長，延時會增加
- 消息可靠性和重複性互為沖突，消息不丢不重難以同時保證
- 上遊無法知道下遊的執行結果，這一點是很緻命的
舉個栗子：使用者登入場景，登入頁面調用passport服務，passport服務的執行結果直接影響登入結果，此處的“登入頁面”與“passport服務”就必須使用調用關系，而不能使用MQ通信。
無論如何，記住這個結論：調用方實時依賴執行結果的業務場景，請使用調用，而不是MQ。
四、什麼時候使用MQ
【典型場景一：資料驅動的任務依賴】
什麼是任務依賴，舉個栗子，網際網路公司經常在淩晨進行一些資料統計任務，這些任務之間有一定的依賴關系，比如：
- task3需要使用task2的輸出作為輸入
- task2需要使用task1的輸出作為輸入
這樣的話，tast1, task2, task3之間就有任務依賴關系，必須task1先執行，再task2執行，載task3執行。
對于這類需求，常見的實作方式是，使用cron人工排執行時間表：
- task1，0:00執行，經驗執行時間為50分鐘
- task2，1:00執行(為task1預留10分鐘buffer)，經驗執行時間也是50分鐘
- task3，2:00執行(為task2預留10分鐘buffer)
這種方法的壞處是：
- 如果有一個任務執行時間超過了預留buffer的時間，将會得到錯誤的結果，因為後置任務不清楚前置任務是否執行成功，此時要手動重跑任務，還有可能要調整排班表
- 總任務的執行時間很長，總是要預留很多buffer，如果前置任務提前完成，後置任務不會提前開始
- 如果一個任務被多個任務依賴，這個任務将會稱為關鍵路徑，排班表很難展現依賴關系，容易出錯
- 如果有一個任務的執行時間要調整，将會有多個任務的執行時間要調整
無論如何，采用“cron排班表”的方法，各任務耦合，誰用過誰痛誰知道(采用此法的請評論留言)
優化方案是，采用MQ解耦：
- task1準時開始，結束後發一個“task1 done”的消息
- task2訂閱“task1 done”的消息，收到消息後第一時間啟動執行，結束後發一個“task2 done”的消息
- task3同理
采用MQ的優點是：
- 不需要預留buffer，上遊任務執行完，下遊任務總會在第一時間被執行
- 依賴多個任務，被多個任務依賴都很好處理，隻需要訂閱相關消息即可
- 有任務執行時間變化，下遊任務都不需要調整執行時間
需要特别說明的是，MQ隻用來傳遞上遊任務執行完成的消息，并不用于傳遞真正的輸入輸出資料。
【典型場景二：上遊不關心執行結果】
上遊需要關注執行結果時要用“調用”，上遊不關注執行結果時，就可以使用MQ了。
舉個栗子，58同城的很多下遊需要關注“使用者釋出文章”這個事件，比如招聘使用者釋出文章後，招聘業務要獎勵58豆，房産使用者釋出文章後，房産業務要送2個置頂，二手使用者釋出文章後，二手業務要修改使用者統計資料。
對于這類需求，常見的實作方式是，使用調用關系：
文章釋出服務執行完成之後，調用下遊招聘業務、房産業務、二手業務，來完成消息的通知，但事實上，這個通知是否正常正确的執行，文章釋出服務根本不關注。
- 文章釋出流程的執行時間增加了
- 下遊服務當機，可能導緻文章釋出服務受影響，上下遊邏輯+實體依賴嚴重
- 每當增加一個需要知道“文章釋出成功”資訊的下遊，修改代碼的是文章釋出服務，這一點是最惡心的，屬于架構設計中典型的依賴倒轉，誰用過誰痛誰知道(采用此法的請評論留言)
- 文章釋出成功後，向MQ發一個消息
- 哪個下遊關注“文章釋出成功”的消息，主動去MQ訂閱
- 上遊執行時間短
- 上下遊邏輯+實體解耦，除了與MQ有實體連接配接，子產品之間都不互相依賴
- 新增一個下遊消息關注方，上遊不需要修改任何代碼
典型場景三：上遊關注執行結果，但執行時間很長
有時候上遊需要關注執行結果，但執行結果時間很長(典型的是調用離線處理，或者跨公網調用)，也經常使用回調網關+MQ來解耦。
舉個栗子，微信支付，跨公網調用微信的接口，執行時間會比較長，但調用方又非常關注執行結果，此時一般怎麼玩呢?
一般采用“回調網關+MQ”方案來解耦：
- 調用方直接跨公網調用微信接口
- 微信傳回調用成功，此時并不代表傳回成功
- 微信執行完成後，回調統一網關
- 網關将傳回結果通知MQ
- 請求方收到結果通知
這裡需要注意的是，不應該由回調網關來調用上遊來通知結果，如果是這樣的話，每次新增調用方，回調網關都需要修改代碼，仍然會反向依賴，使用回調網關+MQ的方案，新增任何對微信支付的調用，都不需要修改代碼啦。
五、總結
MQ是一個網際網路架構中常見的解耦利器。
什麼時候不使用MQ?
- 上遊實時關注執行結果
什麼時候使用MQ?
- 資料驅動的任務依賴
- 上遊不關心多下遊執行結果
- 異步傳回執行時間長
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】