作者 | 葛賢亮，單位：中國移動智慧家庭運營中心

?Labs 導讀

近年來，互聯網技術發展迅猛，各行各業的信息量急劇膨脹。隨著云計算和算力網絡時代的到來，消息中間件在國內許多行業的關鍵應用中越來越受到重視。在高并發分布式場景下，合理地利用消息中間件往往能起到突破性能瓶頸與化繁為簡的效果。

1 面向消息的中間件

在現代架構設計領域內，基于目的和實現機制，中間件可分為兩類：

• 基于遠程過程調用(Remote Procedure Call, RPC)的中間件，允許一個應用程序中的過程調用遠程應用程序中的過程，就好像它們是本地調用一樣。
• 面向消息的中間件(Message-Oriented Middleware，MOM)，使分布式應用程序可以通過發送和接收消息來進行通信和交換數據。

這兩類模型都可以使一個本地組件通過網絡協議訪問（影響）另一個遠程組件。區別在于RPC中間件調用遠程組件時是同步操作，必須等待調用過程返回才能往下執行。而MOM中間件則通過高效可靠的消息傳遞機制進行異步數據傳輸。

同步與異步的差別導致了RPC模型中，本地組件（調用方）與遠程組件（被調用方）必須同時處于運行狀態，如果遠程組件當前處于升級或故障狀態，則RPC調用會失敗，此時需要本地組件實現數據緩存及重試機制以確保最終調用成功（也可以根據產品需求特性直接向用戶返回失敗提示）。而在MOM模型中，幾乎所有的消息中間件都實現了消息持久化功能，在本地組件發送消息至遠程組件時，消息首先會被打包發送至通信服務器（Broker），通信服務器收到消息后會將消息進行持久化，之后通過底層網絡將消息發送至遠程組件，遠程組件從消息隊列接口中讀取消息。

圖1 RPC調用

圖2 MOM調用

如上所述，基于MOM的系統實現了一種持久異步通信模式，允許組件進行更松散的耦合，可在分布式場景下擴展服務（進程）間的通信，并支持異構系統與多開發及時下流行的微服務架構相輔相成，使業務系統具有良好的動態負載伸縮能力。

2 消息中間件作用

實際應用場景中，消息中間件作為事件驅動架構模式的一種實現，通過提供消息隊列模型和消息傳遞機制，也可以在分布式環境下提供應用解耦、異步通信、流量削峰、彈性伸縮、冗余存儲、數據同步、最終一致性等功能。

2.1 應用解耦/事件驅動

事件驅動架構(Event Driven Architecture)是一種側重于以生產、消費為基礎的分布式異步架構模式。基于事件驅動架構模式的應用中，系統與系統之間可以通過消息傳遞的形式驅動業務，以流式的模型處理。其具有高并發、易擴展、松耦合等特點。

相較于通過RPC直接調用（同步/異步），采用消息傳輸方式使生產者與消費者依靠消息建立邏輯上的聯系，生產者與消費者可歸屬于不同的系統。對于非核心流程，能夠將其拆分至不同的消費者中，且支持后續的動態擴展。消費者對消息的消費與否也不會影響生產者中的核心流程。

?示例：如在用戶注冊流程中，當注冊成功后，系統需要發送郵件通知與短信通知。發送短信與發送郵件的調用邏輯都是寫在注冊方法中。用戶注冊模塊與短信模塊、郵件模塊強耦合。如果后續又有發送微信公眾號通知等需求時，只能去修改用戶注冊流程，與更多的模塊產生依賴關系。

圖3 應用解耦-用戶注冊-消息隊列

但其實，在用戶注冊流程中，核心流程是用戶信息寫入，發送短信、發送郵件等操作都是由用戶注冊成功后觸發而來，若采用事件驅動風格（消息/事件通知），用戶模塊作為生產者在用戶注冊成功后產生“注冊成功”事件消息，其他模塊作為消費者訂閱該事件消息，則可以實現用戶模塊與其他模塊（短信、郵件）的解耦。由于生產者不關心事件的后續處理結果，消費者模塊可根據實際情況選擇不同的調度策略，如并發處理、異步處理或按照閑時、忙時等狀態處理。

2.2 異步通信

將非核心流程異步化，可以減少系統響應時間，提升吞吐量，從而提升用戶體驗。例如：短信通知、APP推送等。

在消息中間件場景中，用戶通過前端頁面點擊注冊按鈕，平臺接收到請求后，在用戶模塊中執行用戶注冊流程，注冊成功后，發送“注冊成功”事件消息至消息服務器(Broker)，短信模塊接收到事件消息后發送短信至用戶手機。

以上流程中，我們忽略掉部分細節，取主要步驟做以下假設，前端頁面到用戶模塊需耗時100毫秒，來回共200毫秒，用戶模塊執行注冊流程需要耗時50毫秒，短信模塊執行需要耗時100毫秒。此時短信發送流程由事件消息觸發，不會堵塞用戶注冊主流程，對于用戶來說，用戶注冊流程僅耗時250毫秒。而如果采用傳統調用方式，則需要耗時350毫秒。

圖4 異步通信

當然RPC方式也可以實現異步模式，如本地組件A同步調用遠程組件B，遠程組件B收到請求后，將處理過程放置在異步線程池中處理，當前線程則快速返回結果。這種方式下，一是要求遠程組件B必須在線（否則會因超時返回調用失敗），二是遠程組件B中異步線程池執行時可能因進程重啟導致任務丟失（任務僅在內存隊列中，未進行持久化）。消息中間件的異步特性與消息持久化機制則不存在這兩個問題（此處指廣義上不存在，若消息中間件服務器故障也會出現生產者發送消息失敗的情況）。

2.3 流量削峰

在一些秒殺等互聯網電商場景中，當上游系統的吞吐能力高于下游系統時，在流量洪峰時可能會沖垮下游系統。采用線程池方案時，雖然可以對用戶進行快速返回，但任務都被堆積在線程池隊列中，造成內存占用過大的及進程重啟導致任務丟失問題。而消息中間件可以在峰值時堆積消息，而在峰值過去后下游系統慢慢消費消息解決流量洪峰的問題。

?示例：用戶在支付系統成功結帳后，訂單系統會經過短信系統向用戶推送扣費通知。短信系統可能因為短板效應，速度卡在網關上（每秒幾百次請求），跟前端的并發量不是一個數量級。因而，就形成支付系統和短信系統的處理能力出現差別化。此時可以把消息隊列當成可靠的消息暫存地，進行一定程度的消息堆積，下游系統可以根據自己的節奏獲取并處理消息。

2.4 最終一致性

一致性的概念來源于本地事務的ACID特性與分布式事務中的CAP理論，是指數據符合期望，相互關聯的數據之間不會產生矛盾。

CAP、ACID中討論的一致性稱為“強一致性”(Strong Consistency)，有時也稱為“線性一致性”（Linearizability，通常是在討論共識算法的場景中），而把犧牲了C的AP系統又要盡可能獲得正確的結果的行為稱為追求“弱一致性”。在弱一致性里，人們又總結出了一種稍微強一點的特例，被稱為“最終一致性”(Eventual Consistency)，它是指：如果數據在一段時間之內沒有被另外的操作所更改，那它最終將會達到與強一致性過程相同的結果。

最終一致性不是消息隊列的必備特性，但確實可以依靠消息隊列來實現最終一致性。反之，如果需要強一致性，關注業務邏輯的處理結果，則使用RPC顯得更為合適。

使用消息中間件實現最終一致性可以有兩種方案：

方案一：本地消息表+補償機制。本地消息表用來確保任務不會丟失，補償機制通過不斷重試實現失敗消息最終被消費成功。該方案需要注意消息重復與冪等設計。

方案二：使用RocketMQ自帶消息事務的消息中間件（消息事務并非銀彈，也同樣存在著其他分布式事務具有的缺陷）。

圖5 最終一致性-MQ 消息事務(RocketMQ)

3 消息中間件副作用

消息中間件帶來諸多好處的同時，也會引入很多的弊端：

• 系統可用性降低：系統可用性在某種程度上降低，比如要考慮消息丟失、消息中間件宕機等問題。
• 系統復雜性提高：引入消息中間件之后，業務需要考慮消息被重復消費、消息丟失、消息傳遞順序等問題。
• 一致性問題：消息隊列的異步機制確實可以提高系統響應速度，但消費者沒有正確消費可能會引入一致性問題。

4 消息中間件組成

雖然各個消息中間件實現機制不一樣，但基本都會包含以下幾種角色：

• Broker：消息服務器，提供消息核心服務，負責存儲/轉發消息（轉發模式分為 push 和 pull）；
• Producer：消息生產者，業務的發起方，負責生產消息傳輸給 broker；
• Consumer：消息消費者，業務的處理方，負責從broker獲取消息并進行業務邏輯處理；
• Topic：主題，發布訂閱模式下的消息統一匯集地，不同生產者向topic發送消息，由MQ服務器分發到不同的訂閱者，實現消息的廣播；
• Queue：消息隊列，PTP（點對點）模式下，特定生產者向特定queue發送消息，消費者訂閱特定的queue完成指定消息的接收；
• Message：消息體，根據不同通信協議定義的固定格式進行編碼的數據包，來封裝業務數據，實現消息的傳輸。

5 消息中間件協議

5.1 JMS

JMS即Java消息服務(Java Message Service)應用程序接口，是一個Java平臺中關于面向消息中間件(MOM)的API，用于在兩個應用程序之間，或分布式系統中發送消息，進行異步通信。它類似于 JDBC(Java Database Connectivity)。

? JMS由以下元素組成：

• JMS提供者：連接面向消息中間件，JMS接口的實現。提供者可以是Java平臺的JMS實現，也可以是非Java平臺的面向消息中間件的適配器；
• JMS客戶：生產或消費基于消息的Java的應用程序或對象；
• JMS生產者：創建并發送消息的JMS客戶；
• JMS消費者：接收消息的JMS客戶；
• JMS消息：包括可以在JMS客戶之間傳遞的數據的對象；
• JMS隊列：一個容納那些被發送的等待閱讀的消息的區域。與隊列名字所暗示的意思不同，消息的接受順序并不一定要與消息的發送順序相同。一旦一個消息被閱讀，該消息將被從隊列中移走；
• JMS主題：一種支持發送消息給多個訂閱者的機制。

嚴格意義上來說，消息領域中的JMS更多的是一個規范而不是一個協議。ActiveMQ是該協議的典型實現。

5.2 AMQP

AMQP(Advanced Message Queuing Protocol)，一個提供統一消息服務的應用層標準高級消息隊列協議，是應用層協議的一個開放標準，為面向消息的中間件設計。基于此協議的客戶端與消息中間件可傳遞消息，并不受客戶端/中間件不同產品，不同開發語言等條件的限制。

AMQP目前已經推出協議1.0版本，實現此協議的比較知名的產品有 StormMQ、RabbitMQ、Apache Qpid等。RabbitMQ實現的AMQP版本是0.9.1，可通過plugin的方式支持1.0版本。

? 以下內容摘自官網：

RabbitMQ implements version 0-9-1 of the AMQP specification in the core, with a number of extensions to the specification.

RabbitMQ implements AMQP 1.0 via a plugin. However, AMQP 1.0 is a completely different protocol than AMQP 0-9-1 and hence not a suitable replacement for the latter. RabbitMQ will therefore continue to support AMQP 0-9-1 indefinitely.

--來源：https://www.rabbitmq.com/specification.html

5.3 MQTT

MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸協議），是一種基于發布/訂閱(publish/subscribe)模式的“輕量級”通訊協議，該協議構建于TCP/IP協議上，由IBM在1999年發布。

MQTT最大優點在于，可以以極少的代碼和有限的帶寬，為連接遠程設備提供實時可靠的消息服務。作為一種低開銷、低帶寬占用的即時通訊協議，使其在物聯網、小型設備、移動應用等方面有較廣泛的應用。

? RabbitMQ通過插件可以支持該協議。

圖6 MQTT應用場景

5.4 STOMP協議

STOMP(Streaming Text Orientated Message Protocol)是流文本定向消息協議，是一種為MOM（Message Oriented Middleware，面向消息的中間件）設計的簡單文本協議。STOMP提供一個可互操作的連接格式，允許客戶端與任意STOMP消息代理(Broker)進行交互。

STOMP協議的前身是TTMP協議（一個簡單的基于文本的協議），專為消息中間件設計。

STOMP是一個非常簡單和容易實現的協議，其設計靈感源自于HTTP的簡單性。盡管STOMP協議在服務器端的實現可能有一定的難度，但客戶端的實現卻很容易。例如，可以使用Telnet登錄到任何的STOMP代理，并與STOMP代理進行交互。

5.5 XMPP

XMPP（可擴展消息處理現場協議，Extensible Messaging and Presence Protocol）是基于可擴展標記語言(XML)的協議，多用于即時消息(IM)以及在線現場探測。適用于服務器之間的準即時操作。核心是基于XML流傳輸，這個協議可能最終允許因特網用戶向因特網上的其他任何人發送即時消息，即使其操作系統和瀏覽器不同。特點：通用公開、兼容性強、可擴展、安全性高，但XML編碼格式占用帶寬大，是一種歷史悠久的協議。

5.6 自定義協議

有些特殊框架（如：Redis、Kafka、ZeroMq 等）根據自身需要未嚴格遵循MQ規范，而是基于TCP/IP自行封裝了一套協議，通過網絡socket接口進行傳輸，實現了MQ的功能。

5.7 各協議簡單對比

圖7

6 總結

當前，消息中間件技術已經成為構建分布式互聯網應用的基礎設施。越來越多的系統使用消息中間件解決異步、解耦、削峰等難題。消息中間件不是一項新技術，但新的實現方案層出不窮，引入消息中間件時還需要根據自身的業務特性與需求選擇適合的方案。

參考文獻

[1] 面向消息的中間件 (Message-Oriented Middleware, MOM)：https://docs.oracle.com/cd/E19148-01/820-0533/6nc927vst/index.html.

[2] 鳳凰架構：http://icyfenix.cn/.?