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

?Labs 導讀

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

1 面向消息的中間件

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

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

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

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

圖1 RPC調(diào)用

圖2 MOM調(diào)用

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

2 消息中間件作用

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

2.1 應用解耦/事件驅動

事件驅動架構(Event Driven Architecture)是一種側重于以生產(chǎn)、消費為基礎的分布式異步架構模式?；谑录寗蛹軜嬆Ｊ降膽弥校到y(tǒng)與系統(tǒng)之間可以通過消息傳遞的形式驅動業(yè)務，以流式的模型處理。其具有高并發(fā)、易擴展、松耦合等特點。

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

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

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

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

2.2 異步通信

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

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

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

圖4 異步通信

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

2.3 流量削峰

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

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

2.4 最終一致性

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

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

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

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

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

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

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

3 消息中間件副作用

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

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

4 消息中間件組成

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

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

5 消息中間件協(xié)議

5.1 JMS

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

? JMS由以下元素組成：

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

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

5.2 AMQP

AMQP(Advanced Message Queuing Protocol)，一個提供統(tǒng)一消息服務的應用層標準高級消息隊列協(xié)議，是應用層協(xié)議的一個開放標準，為面向消息的中間件設計?；诖藚f(xié)議的客戶端與消息中間件可傳遞消息，并不受客戶端/中間件不同產(chǎn)品，不同開發(fā)語言等條件的限制。

AMQP目前已經(jīng)推出協(xié)議1.0版本，實現(xiàn)此協(xié)議的比較知名的產(chǎn)品有 StormMQ、RabbitMQ、Apache Qpid等。RabbitMQ實現(xiàn)的AMQP版本是0.9.1，可通過plugin的方式支持1.0版本。

? 以下內(nèi)容摘自官網(wǎng)：

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，消息隊列遙測傳輸協(xié)議），是一種基于發(fā)布/訂閱(publish/subscribe)模式的“輕量級”通訊協(xié)議，該協(xié)議構建于TCP/IP協(xié)議上，由IBM在1999年發(fā)布。

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

? RabbitMQ通過插件可以支持該協(xié)議。

圖6 MQTT應用場景

5.4 STOMP協(xié)議

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

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

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

5.5 XMPP

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

5.6 自定義協(xié)議

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

5.7 各協(xié)議簡單對比

圖7

6 總結

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

參考文獻

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

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