近年來，隨著微服務架構的流行，分布式訊息引擎在物聯網、分布式事務、實時計算和大規模快取同步等場景中的應用日益增多。本文將分享微眾銀行基於rocketmq構建訊息服務平台的實踐，並通過新增諸多高階特性來解決訊息收發過程中遇到的各種問題，通過此文，您將了解到：
不管是銀行的系統還是其他一些傳統企業的系統，他們在最早的時候都使用到了服務匯流排，即esb或者某種形式存在於soa架構中，目的是把所有的服務都串起來，讓服務之間能夠形成乙個呼叫。但這類服務架構其實是比較重的，所有的服務架構都要經過匯流排，匯流排成為了架構上的瓶頸。很多商業化的esb匯流排大家可能都用過，像oracle、ibm等都有。從服務呼叫的維度來看，銀行的應用架構的演進經歷了以下3個階段。
這個階段的架構具有以下3個特點：
將總行的集中式系統在各個省分行分別都部署一套，每天晚上再以批量處理的方式將各省資料進行集中。
這種架構的方式能夠最快的解決聯機效能問題, 但存在跨省轉賬交易無法實時到賬的問題。
系統發布的實時性是硬傷。
這個階段引入了esb匯流排的理念：
esb匯流排為渠道、核心和外圍系統建立了一座橋梁，提供完全統一的介面標準協議，提公升了系統發布的實時性。但同時，esb成為了最大的單點，要支援大併發高tps低延時，所以ha和效能要求非常高，變更需要相當謹慎。
到了2023年以後，隨著facebook、amazon等開放平台獲得的巨大成功，bat都逐步將自己的介面開放出來，並實施了開放平台生態圈戰略，從而推動了soa服務化的快速發展。
左邊是之前的傳統銀行集中式匯流排架構，右邊是網際網路服務化架構，包含了開放平台、服務註冊和發現，以及服務化產品系統。
通過開放平台對外提供介面暴露，可以發現這種架構在保障傳統銀行系統穩定性的同時也可以滿足網際網路金融需求的快速迭代實施，並且也使用了新興的網際網路分布式技術，來降低開發和運維的成本。
微眾銀行基於apache rocketmq構建了自己的分布式訊息服務架構，我們以rmb（reliable message bus）為接入層，以基於apache rocketmq定製開發的wemq（webank message queue）為訊息服務核心，通過gsl（global service location）進行服務定位，通過sgs（service governance system）進行服務請求和服務響應的服務治理，整個分布式鏈路的追蹤日誌會上報到log中。
接下來，我們來看看我們基於rocketmq改造使用到的常見的訊息服務模式：
consumer可以是乙個或者多個，但是乙個訊息會被多個不同系統的其中乙個consumer收到。
生產者只有乙個，消費者有多個，但是作為ha，只有乙個active，其他都是standby。當active掛掉乙個，standby會迅速接管。
傳送請求-等待響應結果。在傳送方做了乙個執行緒的等待，要等待結果的notify。
在分布式訊息系統的構建過程中，基於業務的需求，我們在rocketmq的訊息系統中新增了多項高階特性，包括多中心多活、灰度發布、熔斷機制、訊息存活期、流量的權重、訊息去重、驚群效應問題的解決、背壓模式、訊息服務治理、mqtt訊息服務等。
dc級別的多活希望解決的問題是，不僅訊息不能丟，還要保證服務不能中斷。這裡有兩個層面的故障，乙個是應用全部宕機，那麼希望被其他idc的應用能夠迅速來接管訊息，另外乙個是訊息中介軟體宕機，那麼希望生產者能夠切換到其他idc的中介軟體進行傳送，並且這個中介軟體的訊息在其他idc有備份，能夠進行消費。微眾已經通過idc斷網演練檢驗同城多活能力。
灰度發布殊望解決的問題是，同乙個消費組內不同的例項有監聽不一樣的topic時，能保證不同topic的訊息被正確的例項消費。
（灰度發布示意圖）
當希望訊息的堆積到一定程度時，可能是消費者出現了故障，我們希望能夠提醒生產者。
熔斷機制示意圖
說到流量的權重，有乙個問題是，topic的q值是在使用過程中手動設定的，當例項的數量超過q的數量，那麼超過部分的例項是收不到訊息的。但是，如果你的例項數量小於q的話，它們之間會由於負載均衡分q。根據負載均衡演算法，分到的q可能是不一致的。比如有的分到2個，有的分到3個。在這種集群消費的情況下，就會出現處理的不對等。比如當大流量到來的時候，分到3個q的那個例項可能會出現一些問題，比如掛掉了。
所以我們希望，不同的例項拿到的訊息量應該是對等的。所以，流量權重希望解決的問題是，隨著例項數的動態增加和減少，能夠動態調整consumequeue的數量，不至於出現流量不均勻的情況。因此，我們做了乙個自動伸縮q的功能。預設topic建成時，q的數量是1，當啟動乙個新的例項的時候，會自動擴充套件乙個，停掉乙個例項的時候會自動縮乙個。從而達到q個數量和例項的數量是一一對等的。這解決了例項和訊息量不對等的問題。
在負載均衡的乙個很短時間內，當新上乙個例項的時候，由於大家分到的q都是相同的，當前乙個分到q的還在繼續拉訊息，下乙個例項由於負載均衡很快做完，也分到q，就會去拿這個q的訊息，這個時候就會出現訊息的重複。此時，通常會通過redis等快取方式進行去重，也可以在broker上做乙個簡單的處理，例如用互斥鎖，在競爭消費的短時間內，對其進行加鎖，搶到鎖的才能進行消費，同時占有鎖的時間有限制，從而解決訊息去重的問題。
訊息服務去重原理圖
訊息的背壓消費模式
背壓模式示意圖
在一些特殊場景下，需要對訊息引擎做一些加強，例如背壓模式。當訊息拉到本地的消費執行緒池時，會出現乙個問題。當要做一些例如db的寫的操作導致出現執行緒卡死，處理能力會下降，服務出現降級，但是訊息還在不停地往本地拉。
這個時候，我們希望達到一種效果，能夠根據後續服務的治理能力決定拉的訊息數量。當然rocketmq的processq也能達到這個效果，但是還不夠精細化。因為在金融場景下，交易一旦出現不一致或者超時，會很麻煩。所以我們希望在實時的交易鏈路上去解決這個問題。於是我們做了乙個類似reactor框架的背壓處理，能夠根據處理能力實時拉取訊息。
當對訊息的有效期有要求時，可以在消費訊息時對存活時間進行判斷，超時則丟棄。
對於存活期非常短和對延時要求比較低的訊息，我們通過記憶體模式（不落盤）進行加速，降低延時。
因為負載均衡演算法在客戶端，客戶端的連線和斷開都會觸發消費組內的所有例項會收到notification做負載均衡。比較理想的情況是，乙個例項的掉線不能影響到其他例項，當監聽的topic比較多時，會出現負載均衡慢的問題，因此我們希望負載均衡收斂到服務端來做，客戶端只需要關注topic，不需要關注consumequeue。
目前，我們團隊已經參與到apache rocketmq的社群建設中，並對自用的訊息服務以社群分支的形式在維護，希望各行業更多的開發者可以一起參與進來，以打造適用範圍更廣、更好用的分布式訊息引擎。
作者介紹
陳廣勝，apache rocketmq資深contributor，曾就職於ibm和華為，現任職於微眾銀行，曾參與過運營商雲和大資料平台的建設，以及銀行的基礎架構建設等。
微眾銀行 讓金融服務普惠大眾
微眾銀行是國內首家民營銀行自上線以來就秉持 讓金融普惠大眾 的理念，致力於覆蓋傳統金融服務未覆蓋的長尾客戶。改革開放 40 年來，民營企業蓬勃發展，成為推動經濟社會發展的重要力量。隨著國家和地方 一系列扶持政策的出台，小微企業資金需求明顯增加，但受各種因素影響，融資難 融資貴 問題仍不容忽視。微眾銀...
微眾銀行 為金融扶貧專案添磚加瓦，形成有效助力
我國制定的 2020 年打贏脫貧攻堅戰目標，如何助力區域協調發展 開展金融脫貧，是中國銀程式設計客棧行業履行社會責任的重要課題程式設計客棧之一。微眾銀行在金融扶貧專案上責無旁貸，致力於高效 全面的扶貧模式。積極創新扶貧模式，提高扶貧效率 普及率 精準度。隨著各銀行精準扶貧 戰役 先後打響，引導資金向...
微眾銀行深耕科技領域 金融科技全面開源
微眾銀行是國內首家民營銀行和網際網路銀行，自上線以來就秉承著開源無限，助力開放創新 生生不息的信念，深耕金融科技領域。webank 微眾銀行 在ai領域，微眾銀行的泛機械人ai技術 新一代聯邦學習技術 fate開源平台 金融ai廣告應用以及ai資管的應用。微眾銀行 微眾銀行深耕科技領域 金融科技全面...