文章深度解讀了某商業(yè)銀行做消息隊列選型時考慮的因素，包括關鍵需求、選型要點、選型原則等，同時給出了選型建議、產(chǎn)品對比以及典型場景和二次封裝的建議。本文作者在自己豐富實踐經(jīng)驗基礎上抽象出一些方法論，供讀者在做消息隊列技術選型時參考。

本文主要內(nèi)容包括以下方面：

1 概述

2 為什么引入消息隊列

•   何為消息隊列

•   消息隊列的優(yōu)勢

•   消息隊列的不足 

3 消息隊列選型

•    關鍵需求

•   其他需要考慮的因素

•   選型要點及原則

•   選型建議

•   候選產(chǎn)品比較

•   選擇RocketMQ的原因

 4 二次封裝建議

 5 典型場景

•     支付場景

•    第三方延時調(diào)用場景

6 經(jīng)驗總結(jié)和建議

作為金融企業(yè)對公眾提供服務一定要保證其可用性，盡量做到更多個9（一般SLA中描述的高可用性99.99%，中的9越多代表全年服務可用時間越長服務更可靠，停機時間越短），隨著軟件系統(tǒng)的復雜度越來越高，故障是不可避免的。這就需要企業(yè)實現(xiàn)整體的彈性架構（Resilient Architecture），為應對故障而設計。

然而，常見的RPC、RMI企業(yè)集成技術，因為是同步請求，常因為執(zhí)行方失敗、超時等因素而影響最終用戶體驗，而且很多故障是無法徹底消除的。而且RPC和RMI調(diào)用需要服務的消費方和服務的提供方同時在線，并且雙方需要通過某種機制確認彼此的調(diào)用關系，因為存在這些弊端，就導致了面向消息的中間件（MOM）的產(chǎn)生，通過在企業(yè)架構中引入消息中間件，確保在故障發(fā)生時，受此影響的系統(tǒng)部分在一個很小的范圍內(nèi)。

消息中間件就是在分布式系統(tǒng)中間引入一個透明的中間層，隔離服務的提供方和消費方。

2.1 何為消息隊列

消息隊列（Message Queue，MQ）是一種不同應用程序之間(跨進程)的通信方法，用于上下游應用程序之間傳遞消息。我們拆分來看：

• 消息：應用程序通過寫入和檢索出入列隊的數(shù)據(jù)（消息）來通信。

• 隊列：除去了接收和發(fā)送應用程序同時執(zhí)行的要求。

這樣就實現(xiàn)了上游與下游之間的解耦，上游向MQ發(fā)送消息，下游從MQ接收消息，上游下游互不依賴，它們只依賴MQ。因為有隊列的存在，MQ可在上下游之間進行緩沖，把上游信息先緩存起來，下游根據(jù)自己的能力從MQ中拉取信息，起到削峰的作用。

2.2 消息隊列的優(yōu)勢

1   解耦

1）什么是耦合

高內(nèi)聚低耦合，是軟件工程中的概念，這里的低耦合是指各個組件之間，盡可能相互獨立。通俗一點的理解就是，增加模塊間調(diào)用透明化，最高的透明度就是不用知道彼此的存在，因此減少接口的復雜性、規(guī)范調(diào)用的方式及傳遞的信息，降低產(chǎn)品各模塊的依賴，提高重用程度。

2）如何解耦

在企業(yè)整體架構中解耦，主要設計兩個方面：一是簡化減少交互，二是增加一個中間層實現(xiàn)兩方的隔離，MQ就是其中的中間層（如下圖所示）。引入MQ后生產(chǎn)者和消費者不必知道彼此的存在也不必同時在線，主要交互流程如下：

• 生產(chǎn)者負責：生產(chǎn)消息并通過SDK或API調(diào)用發(fā)送給MQ（同步發(fā)送或者異步發(fā)送）；

• MQ負責：接收消息，并持久化消息到消息存儲（同步或異步存儲消息）；

• 生產(chǎn)者接收來自MQ的響應（消息發(fā)送狀態(tài)或異常）；

• 消費者訂閱消息后，接收來自MQ的消息；

• 消費者執(zhí)行消息對應的后續(xù)業(yè)務操作；

• 對消費結(jié)果進行確認（消費成功、失敗、異常等）。

• 削峰填谷

2 削峰填谷

由于系統(tǒng)閑忙分布不均，QPS常相差幾十倍甚至更高，特別是在遇到營銷活動時，瞬間流量很可能超過后端系統(tǒng)的承載能力，這就要考慮通過消息中間件來緩沖，MQ客戶端實例根據(jù)自己的處理能力從MQ服務器拉取消息，以此來減輕或消除后端系統(tǒng)的瓶頸。

（圖片來源：https://github.com/alibaba/Sentinel/wiki/Sentinel-為-RocketMQ-保駕護航）

3 異構集成

由于各種原因，我們在企業(yè)信息化建設過程中，都會面臨軟件產(chǎn)品來自不同的廠家只解決某特定領域的問題，這些產(chǎn)品因為封閉的架構無法對外提供服務或缺少核心開發(fā)而無法做大的改造，這就造成了彼此之間很難集成。通過引入MQ可以部分解決該問題，只需要在某個環(huán)節(jié)生產(chǎn)一條消息，或者根據(jù)消息做出具體的響應，只需與MQ對接，不必與其他系統(tǒng)做一對一的對接。

4 異步隔離

為了提供金融服務的整體彈性，需要隔離內(nèi)部、外部系統(tǒng)間的依賴。如支付通知分為兩種，一種是同步通知，這時API調(diào)用會因為網(wǎng)絡故障而超時，因為服務提供方處理能力限制而得不到及時響應等多種因素影響，另一種是異步通知，在一定時效范圍內(nèi)最終通知到即可，從而提供提高最終用戶的體驗和交易成功率，提高業(yè)務的整體生產(chǎn)率。

2.3 消息隊列的不足

凡有收益必有代價，MQ也有其不足：

• 在支持靈活性的同時，增加了系統(tǒng)的整體復雜度。

• 因為異步調(diào)用的延時大于RPC同步調(diào)用是，所以會出現(xiàn)短暫的不一致性

• 無法做到事務的強一致，需要分布式事務方案來處理

• 服務的消費方要做冪等設計，來規(guī)避重復調(diào)用的問題

所以在軟件的正常功能開發(fā)中，并不需要去刻意的尋找消息隊列的使用場景，而是當出現(xiàn)性能瓶頸時，去查看業(yè)務邏輯是否存在可以異步處理的耗時操作，如果存在的話便可以引入消息隊列來解決。否則盲目的使用消息隊列可能會增加維護和開發(fā)的成本卻無法得到可觀的性能提升，那就得不償失了。

但凡選擇就會受到主觀和客觀兩個因素的影響。我們?nèi)绾伪M量客觀的進行架構和框架選型，而避免先有結(jié)果而后找理由的文字游戲，下面我分享下我們做MQ選型的過程（這里不是說主觀就是不好的，但作為工程師凡事做結(jié)構化和量化還是有必要的）。

3.1 關鍵需求

•  集群支持：為了保證消息中間件的可靠性，需要提供完備的生產(chǎn)者、消費者、消息中間件集群方案；

• 持久化的支持：為了避免消息丟失，需要支持消息保存到磁盤文件或其它格式存儲；

• 消息重試的支持：消息處理失敗后的支持失敗轉(zhuǎn)存或重試，并提供消息至少投第一次或消息最多投遞一次的配置；

• 分布式事務的支持：為了保證業(yè)務的完整性，選擇的中間件需要支持分布式；

• 消息的按序消費：在有些場景下，需要消息的消費能夠按照發(fā)送的同樣順序進行處理從而保證順序執(zhí)行；

• 消息的延時支持：在2C業(yè)務處理或三方數(shù)據(jù)源對接中，會遇到消息延時投遞要求，需要支持延投遞；

• 消息堆積和回溯功能：在消息中間件持久化保存大量消息時不會對性能有大的影響，支持消息查詢、重發(fā)，或者按照時間點來重新消費消息，以應對某一段時間消息的重新消費場景。

3.2 其他需要考慮的因素

• 產(chǎn)品與當前技術棧是否匹配，團隊人員熟悉源代碼更便于對消息中間件的原理理解和后續(xù)功能擴展；

•  產(chǎn)品的使用廣度特別是金融同業(yè)客戶：同業(yè)因為業(yè)務同質(zhì)化校對，場景需求相近，使用的人越多，說明關鍵場景支持較好，問題在之前暴露的越充分，當我們在使用時碰問題的時候，就比較容易找到對應的解決方案或解決人員；

• 產(chǎn)品的高可用性：作為一個金融企業(yè)，需要服務的持續(xù)可用，作為提高企業(yè)彈性的基礎消息平臺，集群和高可用是一個必不可少的要求；

• 產(chǎn)品的穩(wěn)定性：產(chǎn)品可以持續(xù)、穩(wěn)定的提供服務，不需要經(jīng)常因為資源泄露或性能衰減等問題而重新啟動。

• 產(chǎn)品的活躍度：通過github統(tǒng)計數(shù)據(jù)能看出來這個產(chǎn)品是否經(jīng)常有人維護，經(jīng)常有人開發(fā)一些新的功能，經(jīng)常fix一些bug。

3.3 選型要點及原則

• 搜尋滿足關鍵需求的框架到候選清單；

• 從功能和非功能性需求等幾個方面對候選框架進行篩選；

• 在選型過程中要做好量化記錄，避免先有傾向性的結(jié)果，后有篩選，這樣選型就變成了一場數(shù)字游戲；

• 有時要換個角度思考，常用來做比較的可能就是最好的，如很多MQ框架都與Kafka做比較，那么Kafka有可能就是最通用的框架，如果做選型就要對其是否滿足自己的需求做重點分析；

• 遵循第三眼美女原則，讓理性引導感性；

  適合的就是最好的，不要但純追求高性能和功能全面。

3.4 選型建議

     為未來最少三年或五到十年來選擇，因為TedNeward在JAVA 消息服務的序言中總結(jié)了技術熟悉的過程4個階段（門外漢、探索者、熟手、大師）。選型到全范圍推廣結(jié)束一年左右的時間就過去了，到大家熟悉和精通又一年過去了，誰都不想在剛熟悉還沒用好，當前的產(chǎn)品就不滿足要求了，又要重新來過。

區(qū)分關注點，確保只針對核心關注點進行選擇。給出選擇的deadline，并按時進入到項目實戰(zhàn)準備，再多的理論分析，都不如真正使用過后的感受深入，產(chǎn)品需要成長、團隊成員同樣需要成長，既然路在遠方就趕緊起程。

3.5 候選產(chǎn)品比較

1 產(chǎn)品特性比較

2 測試建議

     功能測試：建議搭建POC環(huán)境進行驗證，除驗證相關功能性指標有沒有，還要驗證好不好用。所以在測試時要基于MQ提供的功能構建使用場景進行業(yè)務功能實現(xiàn)的驗證。

性能測試：其實性能測試涉及的各方面因素比較多，如：基于什么樣的環(huán)境，做了哪些配置，采用什么樣的壓測腳本和報文來做壓力測試？比較指標：除TPS（發(fā)送者TPS、消費者最終處理業(yè)務的TPS）、延時、支持多少同時在線鏈接（生產(chǎn)者數(shù)據(jù)量、消費者數(shù)據(jù)量）、Topic配置（Topic數(shù)量以及每個Topic隊列數(shù)量與生產(chǎn)者、消費者數(shù)據(jù)量的關系）、服務器的性能指標（cpu、內(nèi)存、磁盤io、網(wǎng)絡io）如何等也是需要考量的。

疲勞測試：在一定壓力下持續(xù)運行24小時、一周或更長時間。要重點關注穩(wěn)定性、服務器的各項指標、是否有緩慢增長的趨勢等。

重啟或故障演練：分別對注冊中心NameServer、Broker、Producer、Consumer的實例進行部分重啟（或直接kill）或全部重啟（或直接kill）、磁盤故障、網(wǎng)絡故障等，查看應用的影響，如：在RocketMQ服務是否可以恢復，生產(chǎn)者消費者是否可以恢復服務，消息是否有丟失，消息是否有重復等。

3.6 選擇RocketMQ的原因

• ActiveMQ的優(yōu)勢在于支持協(xié)議多樣、文檔資料豐富，缺點是性能、順序投遞支持有限；

• Kafka的優(yōu)勢在于高吞吐率，缺點是分布式事務、消費失敗重試、延時/定時消息支持有限；

• RabbitMQ的優(yōu)勢在于與SpringBoot集成好，缺點是分布式事務、延時/定時消息支持有限；

• RockeMQ的優(yōu)勢在于高吞吐率、順序消息、延時消息、消息堆積、消息回溯等支持較好，缺點是支持協(xié)議有限，多語言客戶端支持有限。

我們最終選擇RocketMQ的主要原因如下：

• 金融服務有場景對順序消息有嚴格要求；

• 金融服務有場景對延時消息需求；

• 為了保證最終一致性需要支持分布式事務；

• 為了保證一致性消息對賬需要MQ中間件支持消息查詢；

• RocketMQ在高一致性（持久化、消息重試）做的比較好；

• 行內(nèi)使用的JAVA技術棧，暫不需要多協(xié)議和多語言支持；

• RocketMQ的用戶有國內(nèi)知名的互聯(lián)網(wǎng)金融公司、有微眾銀行、民生銀行這樣的互聯(lián)銀行和直銷銀行代表、有企業(yè)軟件服務商，從3.1選型需求匹配和主要用戶可以看出RocketMQ對金融場景適配比較好行業(yè)認可度高，隨著金融用戶的使用未來更多的需求將會被滿足。

封裝主要是對業(yè)務、技術和數(shù)據(jù)進行抽象和封裝，封裝具有如下優(yōu)點：

• 透明，通過引入二次封裝SDK膠水層，隱藏具體實現(xiàn)細節(jié)

• 重用，提高基礎代碼的重用性同時增加的代碼的可維護性和可靠性

• 安全，通過規(guī)范操作提高安全性

將規(guī)范封裝到基礎代碼中以便在企業(yè)內(nèi)部統(tǒng)一交互標準，具體的規(guī)范包括：

• topic命名規(guī)范

• producter命名規(guī)范

• Consumer命名規(guī)范

• 基于MessageId、key或業(yè)務ID的冪等通用方案封裝

通過賦義編碼規(guī)范可以通過名稱定位到所屬項目、模塊等業(yè)務場景，以便在出現(xiàn)未知問題時可以快速協(xié)調(diào)人員進行處理，當然對topic、生產(chǎn)者、消費者等原數(shù)據(jù)管理也是必要的，畢竟命名規(guī)范能保留的信息有限。通過命名規(guī)范還可以避免沖突，比如topic的沖突會或誤會導致消息無法正常消費或者業(yè)務流轉(zhuǎn)等問題，消費者GroupID沖突會導致消息丟失等問題。

通過封裝和定制化增強管理功能如批量信息查詢、批量信息重發(fā)、消息對賬等。

RocketMQ是提高整體服務彈性的重要基礎中間件，在個類金融交易中承擔著重要的角色。

4.1 支付場景

下面以活期賬戶轉(zhuǎn)出服務場景為例來講解。

• 出于安全考慮我們每筆用戶活期賬戶轉(zhuǎn)出都要發(fā)送一條短信通知，這時通過RPC調(diào)用即可實現(xiàn)，如下圖所示：

• 隨著業(yè)務發(fā)展及出于安全和反欺詐考慮，建設了反欺詐服務，需要在每筆轉(zhuǎn)出時發(fā)送支出場景的埋點數(shù)據(jù)，這個時候有兩種方案，一種是繼續(xù)使用RPC調(diào)用，如下圖所示，這時轉(zhuǎn)出操作響應時間可能是處理耗時A 短信調(diào)用時間B 反欺詐服務調(diào)用時間C（也有可能是通過異步RPC調(diào)用：響應時間轉(zhuǎn)出操作時間 Max（B，C）），除了耗時之外，系統(tǒng)的故障點也多了，如果反欺詐服務或者短信服務宕機了，那么很大可能活期賬戶轉(zhuǎn)出服務會隨之宕掉（如果使用了熔斷和隔離，可以很大程度規(guī)避跨系統(tǒng)間的調(diào)用異常影響）。

• 第二種解決方案是未雨綢繆，既然現(xiàn)在有第二個服務需要了解事件，那么以后是不是還會有第三個、第N個呢？如下圖所示。這時活期賬戶轉(zhuǎn)出服務的穩(wěn)定性會進一步降低，復雜度急劇上升，在處理登錄邏輯的同時需要考慮N個系統(tǒng)的關聯(lián)需求。

• 如果從領域模型上看這些是活期賬戶轉(zhuǎn)出服務應該做的嗎？顯然不是，轉(zhuǎn)出應該只關注與本身的賬戶操作，其它服務應該依賴轉(zhuǎn)出的事件來做后續(xù)的相關業(yè)務邏輯，在這樣的場景中適合用消息中間件來解耦。如下圖所示。

這樣各服務回歸到本來應該的樣子，賬戶轉(zhuǎn)出服務不用關注于其它系統(tǒng)對它的依賴，只需要產(chǎn)生賬戶轉(zhuǎn)出事件的消息，有需要的服務各自去訂閱這個消息就好了，相互不受影響。

4.2 第三方延時調(diào)用場景

在與銀行外部系統(tǒng)對接的時候，會有需要在發(fā)送服務請求N秒后，去獲得響應結(jié)果的異步請求。在使用RocketMQ的延時消息前，都是通過將數(shù)據(jù)落地到數(shù)據(jù)庫或Redis緩存中，然后通過定時輪詢?nèi)蝿諄聿僮?。這樣做有以下缺點：

• 非通用方案，每個系統(tǒng)都需要單獨維護一個輪詢?nèi)蝿眨?/span>

• 數(shù)據(jù)量大了以后輪詢會影響數(shù)據(jù)庫性能；

• 輪詢時間不宜設置過低，常以分鐘為單位輪詢，時效性差，如果時間過短對數(shù)據(jù)庫壓力也會增加；

• 針對輪詢失敗的重試機制需要各自實現(xiàn)。

使用RocketMQ后有以下優(yōu)點：

• 通用延時方案，生產(chǎn)延時消息和消息消費隔離；

• 支持高并發(fā)，具備較好的橫向擴展能力；

• 時效性大幅提升，可以精確到秒級。

不過，當前版本還不支設置時間精度，只能按照特定的messageDelayLevel來設置，這就要在搭建RocketMQ時提前最好延時級別的規(guī)劃或者對RocketMQ延時源碼進行擴展以支持指定時間精度。

• Topic隊列數(shù)設置不合理導致負載不均衡，影響RocketMQ的Broker的穩(wěn)定。

• 消息堆積導致投遞延時時間變長。

• 因為消費者的集群ID設置不規(guī)范，導致A消費者消費了B的消息。

• 因為Topic設置的不合理導致一個Broker節(jié)點的宕機導致消息消投遞和消費異常。

• Topic、消費者GroupID相關命名不規(guī)范，導致運行一段時間后RocketMQ的Topic混亂無法清理回收資源。

當故障是不可避免的，就需要在應用程序設計的時候考慮通過一系列機制具備自我管理、自我恢復、自我配置等自治功能，隨著云原生架構的流行，面對負載的加重和不斷發(fā)生的各類故障，MQ不會是彈性系統(tǒng)設計的唯一選擇，但也許是一個不錯的選擇，值得一試。

聲明：文章謹代表作者觀點，與所在平臺無關。