消息係統的演進：從MOM、ESB到下一代雲原生的分布式消息係統

1、什麽(me) 是企業(ye) 消息係統？

企業(ye) 消息係統(Enterprise Messaging System)是提供實現各種消息協議的軟件，如AMQP、MSMQ等。這些協議支持在企業(ye) 內(nei) 部的分布式係統和應用程序之間發送和接收消息。企業(ye) 消息係統是為(wei) 了解決(jue) 遠程過程調用（RPC）的一些問題而設計的。在RPC架構中，當一個(ge) 進程想要與(yu) 遠程服務交互時，它首先需要通過服務發現確定服務的位置，然後使用適當的參數遠程調用所需的方法。應用程序進行遠程調用時，必須等待該調用返回後才能繼續處理。

RPC的同步特性使得基於(yu) 這種架構的應用程序本身就會(hui) 變慢。另外，遠程服務可能會(hui) 在一段時間內(nei) 不可用，這就需要應用開發者使用防禦性編程來識別服務是否可用，並做出相應的反應。

企業(ye) 消息係統則通過引入中間服務，解耦了消息發送者和接收者。通過提供一個(ge) 標準化和可靠的組件來完成解耦，該組件作為(wei) 處理數據的持久緩衝(chong) 區，消息的發送者和接收者不必同時在線。
企業(ye) 消息係統有一些關(guan) 鍵特性

異步通信：消息係統允許服務和應用程序以非阻塞的方式相互通信。

消息持久化：RPC的消息隻存在於(yu) 網絡上，而發布到消息傳(chuan) 遞係統中的消息會(hui) 被持久化，直到它們(men) 被成功投遞。

消息確認：消息係統必須保留消息，直到所有的接收者都收到信息。因此需要一種機製，使消費者能夠確認消息的成功投遞。這樣，消息係統就可以清除所有成功投遞的消息。

消息消費模式

發布訂閱模式——支持向一個(ge) 特定的消息主題生產(chan) 消息，多個(ge) 訂閱者可能對接收來自特定消息主題的消息感興(xing) 趣。

    消息隊列模式——用於(yu) 消息生產(chan) 者和消息消費者之間點到點通信。消息生產(chan) 者將消息發送到由某個(ge) 名字標識的特定消費者。這個(ge) 名字實際上對於(yu) 消費服務中的一個(ge) 隊列（Queue），在消息傳(chuan) 遞給消費者之前它被存儲(chu) 在這個(ge) 隊列中。
消息係統已經存在了幾十年，並得到了廣泛的應用。讓我們(men) 回顧一下消息係統的演進。

2、麵向消息的中間件

第一類消息係統通常被稱為(wei) 麵向消息的中間件(Message Oriented Middleware，MOM)，它的設計目的是在運行於(yu) 不同網絡、操作係統等的分布式係統之間提供進程間通信和應用集成。最著名的MOM實現之一是1993年發布的IBM WebSphere MQ。

最早的實現被設計為(wei) 部署在一台機器上，這意味著係統的可擴展性受限於(yu) 主機的物理硬件，這台單一的服務器負責處理所有的客戶請求和存儲(chu) 所有的消息。這些單服務器MOM係統可以服務的並發生產(chan) 者和消費者的數量受到網卡帶寬的限製，存儲(chu) 容量受到機器上物理磁盤的限製。

通過為(wei) MOM係統中增加集群功能，可以解決(jue) 可擴展性問題。這使得多個(ge) 單服務實例可以分擔消息的處理，並提供一些負載平衡。盡管MOM是集群部署，但實際上每個(ge) 服務實例負責為(wei) 所有主題的一個(ge) 子集提供服務和消息存儲(chu) 。在出現主題"熱點"的情況下，分配給該特定主題的實例仍然會(hui) 成為(wei) 瓶頸。

這種局限性要求用戶必須注意的消息分布，調整主題的分別，使主題與(yu) 底層物理硬件相匹配，確保負載在集群中均勻分布。更好的做法是，能夠將一個(ge) 主題分布在多台機器上，這正是分布式消息係統所做的事情。

3、企業(ye) 服務總線

企業(ye) 服務總線(Enterprise Service Bus, ESB)出現於(yu) 本世紀初，當時XML是使用基於(yu) SOAP的SOA架構應用的首選消息格式。ESB的核心概念是 "消息總線"，它是所有應用程序和服務之間的通信通道。這種集中式的架構與(yu) 麵向消息的中間件（MOM）所采用的點對點的集成方式形成了直接對比。

每個(ge) 應用向 ESB "注冊(ce) "自己，並指定一套規則，用於(yu) 識別它感興(xing) 趣的消息，而 ESB 將處理所有必要的邏輯，以便從(cong) 總線上動態地路由符合這些規則的消息。同樣，每個(ge) 服務不再需要事先知道消息的預定目標，隻需將消息發布到 "總線 "上，讓它對消息進行路由。每個(ge) 應用或服務通過ESB發送和接收所有消息，而不必指定它們(men) 想要發布和消費的特定主題名稱。

ESB在 "流處理 "上邁出了第一步，強調在消息係統內(nei) 部處理消息的能力。大多數ESB提供消息轉換服務，通過XSLT或XQuery，處理發送和接收者之間的消息格式轉換。這是對消息係統的一種全新的思考方式，在這之前，消息係統幾乎隻被用作一種傳(chuan) 輸通道。現在ESB都支持更先進的計算功能，包括業(ye) 務流程編排、事件關(guan) 聯和模式匹配等複雜事件處理。

ESB在今天仍然非常流行，但它們(men) 是集中式係統，被設計成部署在單台主機上。ESB和MOM一樣，同樣存在著可擴展性的問題。

4、分布式消息係統

隨著Hadoop的普及，分布式計算模式開始被廣泛采用。分布式計算最大的一個(ge) 優(you) 勢就是，隻需在係統中增加新的機器，就可以橫向擴展係統。新的係統架構將計算和存儲(chu) 分離，並且分布在多台機器上，不再受單機物理硬件的限製。

消息係統已經向分布式計算模式過渡。當前最流行的 Kafka，以及最近崛起的 Pulsar都采用了分布式計算模式，以滿足互聯網、大型企業(ye) 對可擴展性和性能的需求。

在分布式消息係統中，一個(ge) 主題被分布在多台機器上，以便在消息層提供水平可擴展的存儲(chu) 。將數據分布存儲(chu) 還提供了一些優(you) 勢，包括數據的冗餘(yu) 和高可用性，增加了消息的存儲(chu) 容量，增加了消息吞吐量，以及消除了係統內(nei) 的單點故障。

分布式消息係統和集群式單節點係統在架構上的關(guan) 鍵區別，是存儲(chu) 層的設計方式。在以前的單節點係統中，主題的消息數據都被存儲(chu) 在一台機器上，這將主題的大小限製在該機器上磁盤容量大小。在分布式消息係統中，數據分布在集群內(nei) 的多台機器上。

分布式消息係統的另一個(ge) 好處是，可以有多個(ge) broker為(wei) 給定的主題提供消息服務，通過將負載分散在多台機器上，提高了消息的生產(chan) 和消費吞吐量。

我們(men) 以新近崛起的Pulsar為(wei) 例，它就是典型的分布式消息係統架構。Pulsar使用了存儲(chu) 和計算分離的雲(yun) 原生架構，數據從(cong) Broker 搬離，存在共享存儲(chu) 內(nei) 部。上層是無狀態 Broker，複製消息分發和服務；下層是持久化的存儲(chu) 層 Bookie 集群。Pulsar存儲(chu) 是分片的，這種構架可以避免擴容時受限製，實現數據的獨立擴展和快速恢複。Pulsar解決(jue) 了Kafka在設計上的一些並不能很好地適應於(yu) 雲(yun) 原生環境的缺陷，比如消息服務和消息存儲(chu) 的緊耦合、IO並不隔離、基於(yu) 物理分區的存儲(chu) 模型等。Pulsar還內(nei) 置了一個(ge) 輕量級計算引擎，為(wei) 用戶提供了一個(ge) 部署簡單、運維方便的 FaaS（Function as a service）平台。