從“消息隊列”到“服務(wù)總線”和“流處理平臺”

什么是隊列

隊列是一種先進(jìn)先出的數(shù)據(jù)結(jié)構(gòu)，特殊之處在于它只允許在隊列的前端（front）進(jìn)行刪除操作，而在隊列的后端（rear）進(jìn)行插入操作。

什么是消息隊列

消息隊列就是一個隊列結(jié)構(gòu)的中間件，也就是說消息放入這個中間件之后就可以直接返回，并不需要系統(tǒng)立即處理，而另外會有一個程序讀取這些數(shù)據(jù)，并按順序進(jìn)行逐次處理。

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

消息隊列的核心功能就是消息傳遞。但由于其異步性和消息存儲的特定，使消息隊列具備如下優(yōu)勢：

解耦

消息隊列在處理過程中間插入了一個隱含的、基于數(shù)據(jù)的接口層，兩邊的處理過程都要實(shí)現(xiàn)這一接口。這允許你獨(dú)立的擴(kuò)展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束。

冗余

有時在處理數(shù)據(jù)的時候處理過程會失敗。除非數(shù)據(jù)被持久化，否則將永遠(yuǎn)丟失。消息隊列把數(shù)據(jù)進(jìn)行持久化直到它們已經(jīng)被完全處理，通過這一方式規(guī)避了數(shù)據(jù)丟失風(fēng)險。在被許多消息隊列所采用的"插入-獲取-刪除"范式中，在把一個消息從隊列中刪除之前，需要你的處理過程明確的指出該消息已經(jīng)被處理完畢，確保你的數(shù)據(jù)被安全的保存直到你使用完畢。

擴(kuò)展性

因為消息隊列解耦了你的處理過程，所以增大消息入隊和處理的頻率是很容易的；只要另外增加處理過程即可。不需要改變代碼、不需要調(diào)節(jié)參數(shù)。擴(kuò)展就像調(diào)大電力按鈕一樣簡單。

靈活性 & 峰值處理能力

在訪問量劇增的情況下，你的應(yīng)用仍然需要繼續(xù)發(fā)揮作用，但是這樣的突發(fā)流量并不常見；如果為以能處理這類峰值訪問為標(biāo)準(zhǔn)來投入資源隨時待命無疑是巨大的浪費(fèi)。使用消息隊列能夠使關(guān)鍵組件頂住增長的訪問壓力，而不是因為超出負(fù)荷的請求而完全崩潰。

可恢復(fù)性

當(dāng)體系的一部分組件失效，不會影響到整個系統(tǒng)。消息隊列降低了進(jìn)程間的耦合度，所以即使一個處理消息的進(jìn)程掛掉，加入隊列中的消息仍然可以在系統(tǒng)恢復(fù)后被處理。而這種允許重試或者延后處理請求的能力通常是造就一個略感不便的用戶和一個沮喪透頂?shù)挠脩糁g的區(qū)別。

送達(dá)保證

消息隊列提供的冗余機(jī)制保證了消息能被實(shí)際的處理，只要一個進(jìn)程讀取了該隊列即可。

排序保證

在許多情況下，數(shù)據(jù)處理的順序都很重要。消息隊列本來就是排序的，并且能保證數(shù)據(jù)會按照特定的順序來處理。

緩沖

在任何重要的系統(tǒng)中，都會有需要不同的處理時間的元素。例如,加載一張圖片比應(yīng)用過濾器花費(fèi)更少的時間。消息隊列通過一個緩沖層來幫助任務(wù)最高效率的執(zhí)行--寫入隊列的處理會盡可能的快速，而不受從隊列讀的預(yù)備處理的約束。該緩沖有助于控制和優(yōu)化數(shù)據(jù)流經(jīng)過系統(tǒng)的速度。

理解數(shù)據(jù)流

在一個分布式系統(tǒng)里，要得到一個關(guān)于用戶操作會用多長時間及其原因的總體印象，是個巨大的挑戰(zhàn)。消息系列通過消息被處理的頻率，來方便的輔助確定那些表現(xiàn)不佳的處理過程或領(lǐng)域，這些地方的數(shù)據(jù)流都不夠優(yōu)化。

異步通信

很多時候，你不想也不需要立即處理消息。消息隊列提供了異步處理機(jī)制，允許你把一個消息放入隊列，但并不立即處理它。你想向隊列中放入多少消息就放多少，然后在你樂意的時候再去處理它們。

消息模型——如何發(fā)布和獲取消息

JMS（Java Message Service,Java消息服務(wù)）API 是一個消息服務(wù)的標(biāo)準(zhǔn)/規(guī)范，允許應(yīng)用程序組件基于 JavaEE 平臺創(chuàng)建、發(fā)送、接收和讀取消息。在 JMS 標(biāo)準(zhǔn)中，有兩種消息模型：P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。

Point-to-Point(PTP)模型

在 P2P 模型中，每個消息只有一個消費(fèi)者（即一旦被消費(fèi)，消息就不再在消息隊列中），隊列保留著消息，直到它們被消費(fèi)或超時。發(fā)送者和接收者之間在時間上沒有依賴性，也就是說當(dāng)發(fā)送者發(fā)送了消息之后，不管接收者有沒有正在運(yùn)行，它不會影響到消息被發(fā)送到隊列。接收者在成功接收消息之后需向隊列應(yīng)答成功如果你希望發(fā)送的每個消息都應(yīng)該被成功處理的話，那么你需要P2P模型

Publisher/Subscriber (Pub/Sub) 模型

在 Pub/Sub 模型中包含如下概念：主題（Topic）、發(fā)布者（Publisher）、訂閱者（Subscriber）?？蛻舳藢⑾l(fā)送到主題。多個發(fā)布者將消息發(fā)送到 Topic，系統(tǒng)將這些消息傳遞給多個訂閱者。

每個消息可以有多個消費(fèi)者。發(fā)布者和訂閱者之間有時間上的依賴性。針對某個主題(Topic)的訂閱者，它必須創(chuàng)建一個訂閱之后，才能消費(fèi)發(fā)布者的消息，而且，為了消費(fèi)消息，訂閱者必須保持運(yùn)行的狀態(tài)。當(dāng)然，為了緩和這種嚴(yán)格的時間相關(guān)性，JMS 允許訂閱者創(chuàng)建一個可持久化的訂閱。這樣，即使訂閱者沒有被激活（運(yùn)行），它也能接收到發(fā)布者的消息。如果你希望發(fā)送的消息可以不被做任何處理、或者被一個消費(fèi)者處理、或者可以被多個消費(fèi)者處理的話，那么可以采用 Pub/Sub 模型。

何時使用消息隊列

消息隊列是軟件系統(tǒng)作信息傳遞和系統(tǒng)集成的主要手段，同時相對于使用消息隊列發(fā)送消息而言，還有另外一種更加普遍使用的集成技術(shù)，就是API。兩者都具有廣泛的應(yīng)用，所以在實(shí)際架構(gòu)設(shè)計中，經(jīng)常要考慮的問題是什么時候使用API，什么時候使用消息隊列。下表列出兩者主要的區(qū)別：

如何判斷什么時候該使用API，什么時候該使用消息呢？舉個例子：

假設(shè)一個零售商開放他的產(chǎn)品清單。通過開放這個產(chǎn)品清單，合作廠商可以快速定位到自己的產(chǎn)品。產(chǎn)品清單中的數(shù)據(jù)是只讀的，所以用戶可以重復(fù)的請求訪問。這種場景下，REST API 使用簡單并且同步，更適合這個場景。

另一個場景，假設(shè)一個醫(yī)院要在治療病人之后更新病人的病歷。病歷信息對于醫(yī)院和病人來講都是非常關(guān)鍵的信息，為了保證信息在傳輸過程中不會丟失，此時采用消息更加合適。

最后一個場景。假設(shè)一個零售商搭建一個應(yīng)用允許合作廠商訪問他的產(chǎn)品清單并下訂單。這種情況下，可以同時使用 API 和消息。在查詢產(chǎn)品清單時，可以使用 API。而在下訂單時，為了避免消息丟失和處理峰值流量，可以使用消息隊列。

服務(wù)總線

消息總線可以理解成全局的消息通道。所以相對消息隊列而言，他的不同之處在于全局性和共享性。所以，消息總線會包含三部分：通用數(shù)據(jù)模型、通用指令集和消息隊列。跟隨 SOA（Service Oriented Architecture，面向服務(wù)架構(gòu)）的概念，信息系統(tǒng)的總線通常叫服務(wù)總線，企業(yè)層的總線稱之為企業(yè)服務(wù)總線(ESB)。企業(yè)服務(wù)總線可以看作是一種模式，在這種模式下定義了一個集中式的消息中間件實(shí)現(xiàn)各種后端系統(tǒng)的集成（包括數(shù)據(jù)模型轉(zhuǎn)換、連接、路由和編排），從而實(shí)現(xiàn)些集成服務(wù)可以在構(gòu)建新應(yīng)用時復(fù)用。

在 SOA 中，IT 架構(gòu)被分成組件層、Web 服務(wù)層、業(yè)務(wù)流程層等。組件層包括各種應(yīng)用系統(tǒng)，它們通常是技術(shù)相關(guān)的具體實(shí)現(xiàn)，各種具體的分布式組件技術(shù)(CORBA、COM/DCOM、J2EE)都可以用于實(shí)現(xiàn)組件層的應(yīng)用組件。通常復(fù)雜的 IT 環(huán)境中的組件層都同時使用了多種分布式組件技術(shù)，而不同實(shí)現(xiàn)技術(shù)之間的互聯(lián)性障礙給應(yīng)用集成帶來了極大的困難，進(jìn)而形成了一個個信息孤島。SOA 引入了 Web 服務(wù)層來解決此種情況下的應(yīng)用集成問題。Web 服務(wù)是獨(dú)立于各種分布式組件技術(shù)的，它使用標(biāo)準(zhǔn)的基于 XML 的服務(wù)描述語言(Web Service Description Language，WSDL)來定義和封裝離散的業(yè)務(wù)功能，各種支持Web服務(wù)的分布式組件技術(shù)能夠?qū)⑵渖系臉I(yè)務(wù)組件發(fā)布成 Web 服務(wù)并產(chǎn)生相應(yīng)的 WSDL 文檔，并且只需要依據(jù) WSDL 描述的信息就能夠調(diào)用 Web 服務(wù)，即 WSDL 所描述的業(yè)務(wù)功能。在 SOA 中，需要進(jìn)入系統(tǒng)集成環(huán)節(jié)的業(yè)務(wù)組件都被映射為 Web 服務(wù)，形成了 Web 服務(wù)層。業(yè)務(wù)流程層則處于 Web 服務(wù)層之上，通過對 Web 服務(wù)的流程編排來實(shí)現(xiàn)商業(yè)流程。業(yè)務(wù)流程層通過 Web 服務(wù)層能夠調(diào)用到基于各種分布式組件技術(shù)實(shí)現(xiàn)的業(yè)務(wù)組件，實(shí)現(xiàn)了復(fù)雜 IT 系統(tǒng)環(huán)境的應(yīng)用集成。

作為 SOA 基礎(chǔ)架構(gòu)的關(guān)鍵部分，ESB 的功能主要體現(xiàn)在通信、服務(wù)交互、應(yīng)用集成、服務(wù)質(zhì)量、安全性以及管理和監(jiān)控等方面。在通信方面，ESB 能夠支持消息路由/尋址，支持多種通信技術(shù)、通信協(xié)議(如 JMS、HTTP)，支持發(fā)布/訂閱的通信模式，能夠處理請求/響應(yīng)、同步以及異步的消息傳遞方式，并且要求以可靠的方式傳遞消息。

常見的 ESB 產(chǎn)品包括：IBM 的 WebSphere ESB，Microsoft 基于 BizTalk 的 ESB 產(chǎn)品，JBOSS SOA Platform 等。

需要強(qiáng)調(diào)的是，消息總線或企業(yè)服務(wù)總線的目的是為了系統(tǒng)集成和服務(wù)共享。因此，當(dāng)使用消息總線的時候，所有的服務(wù)或者應(yīng)用必須共享相同的數(shù)據(jù)類型，指令集以及相同的通信協(xié)議，并且在消息總線中，會最大量消息轉(zhuǎn)換和編排的工作。而相對而言，消息隊列的目的是信息傳輸，因此并不限制是否類型一致。

流處理平臺——Kafka

市面上的消息隊列產(chǎn)品有很多，比如 ActiveMQ、RabbitMQ 、Kafka 、RocketMQ ，還有 ZeroMQ ，連 redis 這樣的 NoSQL 數(shù)據(jù)庫也支持 MQ 功能。但其中影響力最大的應(yīng)該還是 Kafka。而從 Kafka 給自己的定義可以看出， Kafka 不只是消息隊列，而是分布式的流處理平臺。

什么是流處理平臺呢？流處理是一種重要的大數(shù)據(jù)處理手段，其主要特點(diǎn)是其處理的數(shù)據(jù)是源源不斷且實(shí)時到來的。分布式流處理是一種面向動態(tài)數(shù)據(jù)的細(xì)粒度處理模式，基于分布式內(nèi)存，對不斷產(chǎn)生的動態(tài)數(shù)據(jù)進(jìn)行處理。其對數(shù)據(jù)處理的快速，高效，低延遲等特性，在大數(shù)據(jù)處理中發(fā)揮越來越重要的作用。流處理技術(shù)有很多技術(shù)選型，更多信息可以參考“Apache 的流處理技術(shù)概述”。僅從 Kafka 的角度看流處理平臺和消息隊列的區(qū)別，Kafka 作為流處理平臺具有以下三種特性:

可以讓你發(fā)布和訂閱流式的記錄。這一方面與消息隊列或者消息總線類似。

可以儲存流式的記錄，并且有較好的容錯性。

可以在流式記錄產(chǎn)生時就進(jìn)行處理。

但與基于隊列和交換的 RabbitMQ 不同，Kafka 的存儲層是使用分區(qū)的事務(wù)日志實(shí)現(xiàn)的。Kafka 還提供用于實(shí)時處理流的 Streams API 和可輕松與各種數(shù)據(jù)源集成的Connector API。Kafka 沒有“執(zhí)行隊列”的概念。相反，Kafka 將記錄的集合存儲在稱為主題（Topic）的類別中。對于每個主題，Kafka 維護(hù)消息的分區(qū)日志。每個分區(qū)都是一個有序的，不可變的記錄序列，在該記錄中連續(xù)附加消息。因此Kafka 的實(shí)現(xiàn)十分適合“Publisher/Subscriber (Pub/Sub) 模型”，但不適合“Point-to-Point(PTP)模型”。因此 Kafka 的定位并非消息隊列或消息總線，而是流處理平臺。

因此，流處理平臺和消息隊列或消息總線最大的區(qū)別就是在消息隊列功能基礎(chǔ)上，流處理平臺更加關(guān)注對流數(shù)據(jù)分析的支持。