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

-     什么是隊(duì)列？     -

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

-     什么是消息隊(duì)列？     -

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

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

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

1. 解耦

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

2. 冗余

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

3. 擴(kuò)展性

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

4. 靈活性 & 峰值處理能力

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

5. 可恢復(fù)性

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

6. 送達(dá)保證

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

7.排序保證

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

8.緩沖

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

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

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

10. 異步通信

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

-     消息模板：如何發(fā)布和獲取消息     -

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

Publisher/Subscriber (Pub/Sub) 模型

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

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

-     何時(shí)使用消息隊(duì)列     -

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

如何判斷什么時(shí)候該使用API，什么時(shí)候該使用消息呢？舉個(gè)例子：

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

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

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

-     服務(wù)總線     -

消息總線可以理解成全局的消息通道。所以相對消息隊(duì)列而言，他的不同之處在于全局性和共享性。所以，消息總線會包含三部分：通用數(shù)據(jù)模型、通用指令集和消息隊(duì)列。跟隨SOA（Service Oriented Architecture，面向服務(wù)架構(gòu)）的概念，信息系統(tǒng)的總線通常叫服務(wù)總線，企業(yè)層的總線稱之為企業(yè)服務(wù)總線(ESB)。

企業(yè)服務(wù)總線可以看作是一種模式，在這種模式下定義了一個(gè)集中式的消息中間件實(shí)現(xiàn)各種后端系統(tǒng)的集成（包括數(shù)據(jù)模型轉(zhuǎn)換、連接、路由和編排），從而實(shí)現(xiàn)些集成服務(wù)可以在構(gòu)建新應(yīng)用時(shí)復(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ù)，而不同實(shí)現(xiàn)技術(shù)之間的互聯(lián)性障礙給應(yīng)用集成帶來了極大的困難，進(jìn)而形成了一個(gè)個(gè)信息孤島。

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)使用消息總線的時(shí)候，所有的服務(wù)或者應(yīng)用必須共享相同的數(shù)據(jù)類型，指令集以及相同的通信協(xié)議，并且在消息總線中，會最大量消息轉(zhuǎn)換和編排的工作。而相對而言，消息隊(duì)列的目的是信息傳輸，因此并不限制是否類型一致。

-     流處理平臺——Kafka     -

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

什么是流處理平臺呢？流處理是一種重要的大數(shù)據(jù)處理手段，其主要特點(diǎn)是其處理的數(shù)據(jù)是源源不斷且實(shí)時(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的角度看流處理平臺和消息隊(duì)列的區(qū)別，Kafka作為流處理平臺具有以下三種特性:

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

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

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

但與基于隊(duì)列和交換的RabbitMQ不同，Kafka的存儲層是使用分區(qū)的事務(wù)日志實(shí)現(xiàn)的。Kafka還提供用于實(shí)時(shí)處理流的Streams API和可輕松與各種數(shù)據(jù)源集成的Connector API。Kafka沒有“執(zhí)行隊(duì)列”的概念。相反，Kafka將記錄的集合存儲在稱為主題（Topic）的類別中。

對于每個(gè)主題，Kafka維護(hù)消息的分區(qū)日志。每個(gè)分區(qū)都是一個(gè)有序的，不可變的記錄序列，在該記錄中連續(xù)附加消息。因此Kafka的實(shí)現(xiàn)十分適合“Publisher/Subscriber (Pub/Sub) 模型”，但不適合“Point-to-Point(PTP)模型”。因此Kafka的定位并非消息隊(duì)列或消息總線，而是流處理平臺。

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

作者：陳喆gavin

來源：

https://blog.csdn.net/gavinchen1985/article/details/113957742

-   關(guān)注“架構(gòu)之美”   -