微服務中消息匯流排架構設計應用

導語：

當一個O2O電商系統到達一定規模之後，就需要考慮系統的可擴展性、松耦合和組件化。一般採用的都是基於時下比較流行SpringCloud和Dubbo的分散式的微服務的架構模式，雖然模塊間能夠獨立部署了，但是模塊間的還是強依賴關係，每次改動都需要重新發版上線，產品迭代速度又快，就造成了每次上線心裡都唱忐忑。

基於上面這個背景，系統需要做重構，需要解耦，因此我增加了消息匯流排模塊，使用非同步消息隊列和標準組件來實現了模塊間的強耦合和快速的開發迭代。

現有匯流排設計的問題

一般的消息匯流排是直接使用MQ來連接上下游的模塊。以O2O電商系統為例，一個訂單支付完成以後需要發送通知下游的積分模塊給用戶送積分，優惠券模塊給用戶送優惠券，微信模塊給用戶推送微信消息，簡訊模塊給用戶發送簡訊等。上下游直接通過MQ伺服器建立起了消息生產和消費的關係。

1.下游消費端必須增加MQ消息消費處理代碼，代碼會比較複雜，開發者必須掌握MQ消費端開發。

2.當下游有多個消費端時，消費端每個模塊需要生成一個消息對列，增加了MQ伺服器的壓力。

3.當下游多個消費端執行需要有先後關係時，比如優惠券發完了才能推送微信消息，這樣就大大增加了系統設計的複雜程度。

優化設計

針對以上幾個問題對消息匯流排系統進行了優化設計，看下圖：

通過這種實現實現了一個下幾個特點：

1.模塊間實現了松耦合的機制，各業務模塊間只跟消息匯流排系統集成，簡化開發。

2.消息確保必達，消息到達任何一端都要進行確認，出現網路問題或其他異常能夠重試。

3.保證消息處理的冪等，不能因為重複消息導致重複執行相同的操作。

三個基本概念

事件消息：如下單事件、註冊事件等，事件有唯一的編號，保證任何系統收到。消費操作，如送積分、送優惠券、微信消息推送、簡訊發送、PUSH推送等等。執行日誌，記錄每個消費操作執行的結果，失敗可以通過定時任務重試。

快速擴展集成

為什麼增加獨立的消息生產模塊？

因為前端業務模塊比較多的時候，只能對消息的內容本身形成一個標準，很容易出現問題，增加一個消息生產模塊對外提供標準的API介面，前端業務調用按照說明添加參數即可，開發人員也不需要掌握MQ的客戶端開發的相關技術。

為什麼增加獨立的消息消費模塊？

因為業務需求變化較快，後端消費模塊會經常增加新的模塊或停用已有的模塊，提供標準的消費介面供消費模塊直接實現，能夠快速的實現。

保證消息不丟失

消息產生模塊如何保證消息不丟失？保證必須產生前端模塊發起消息生產的調用，由消息生產組件再發送消息到MQ，這個時候(2)如果未返回成功或網路超時就重複發送，消息生產模塊與MQ之間的調用也是這樣，(4)未正常返回或者網路超時(2)是返回未成功，需要重新發送消息。如果(4)返回成功就說明MQ持久化完成了(這裡消息採用持久化方式)，到此階段消息發送完成。

消息消費模塊如何保證消息不丟失？監聽MQ隊列消息，如果有消息來就存儲到db中，並ack給MQ，確定消息收到了，然後根據數據中配置的模塊調用後端的模塊非同步調用後端模塊，每一個操作調用都記錄到db中，對於因為網路或者異常未執行成功的，由定時任務定期檢查db中執行的狀態，未成功的調用的消費操作繼續調用執行，直到消費成功。

冪等性設計

在消息生成模塊，因為消息未發送成功重試造成消息的重複，如果消息消費和後端業務不做冪等性設計就會業務數據產生影響，如用戶下單完成可能送多次積分或者優惠券。為了避免相同一個事件消息的重複的消費，就需要每條消息都有一個唯一的MSGID，在消息消費模塊保存到db時對消息進行唯一性的驗證，保證事件消息不重複。同樣，後端的業務模塊在實現消費介面時同樣要做冪等處理，保證相同的事件消息不重複執行，如果已執行返回成功。

延時消息實現

電商系統中一般在下單多長時間內不支付訂單會自動取消，這是一個典型的延時消息，因為我採用的MQ是ArtemisMQ本身天然攜帶延時消息的功能，所以在這個系統中我採用的是ArtemisMQ的延時消息，到指定時間自動讓消息生效，在消息消費模塊執行。對於已經成功支付的訂單，在支付成功時增加一個刪除延時消息的消費操作，減少系統的調用，刪除時使用的就是消息的MSGID。

如何流量削峰

因為ArtemisMQ本身已經實現了消息的緩衝，在消息消費端通過設定固定的線程數，就能實現消息消費的固定的消費速度，保證消息消費不會受到性能的衝擊。

技術架構實現

使用SpringCloud+Dubbo來實現整個架構的搭建，SpringCloud用於外部rest服務的實現，Dubbo用於內部介面的調用的實現。提供消費匯流排介面模塊，提供公共的介面類和實體類供消費生產模塊和消息消費模塊使用。下圖為模塊依賴關係圖。

消息生成模塊採用Dubbo實現，前端業務模塊通過Dubbo介面調用消息生成介面即可，根據要求傳遞對應的參數即可完成。消費操作的實現採用Dubbo的RPC來實現，使用的是Dubbo的可以動態生成消費者的特點，消息消費模塊接收到消息後會從資料庫中讀取關聯的消費操作列表，然後循環調用每個消費操作，每一次操作執行都要記錄操作日誌並記錄結果。

通過以上幾點消息匯流排架構基本上設計並實現完成了！你有什麼好的建議和意見嗎？

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！