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

1、什么是企業消息系統？

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

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

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

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

消息持久化：RPC的消息只存在于網絡上，而發布到消息傳遞系統中的消息會被持久化，直到它們被成功投遞。

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

消息消費模式

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

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

2、面向消息的中間件

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

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

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

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

3、企業服務總線

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

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

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

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

4、分布式消息系統

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

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

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

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

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

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