作者介紹：林清山（花名：隆基）

操作系統、數據庫、中間件是基礎軟件的三駕馬車，而消息隊列屬于最經典的中間件之一，已經有30多年的歷史。其發展主要經歷了以下幾個階段：

第一個階段，2000年之前。 80年代誕生了第一款消息隊列是 The Information Bus，第一次提出發布訂閱模式來解決軟件之間的通信問題；到了90年代，則是國際商業軟件巨頭的時代，IBM、Oracle、Microsoft紛紛推出了自己的 MQ，其中最具代表性的是IBM MQ，價格昂貴，面向高端企業，如大型金融、電信等企業；這類商業MQ一般采用高端硬件，軟硬件一體機交付，MQ本身的架構是單機架構。

第二階段，2000~2007年。 進入00年代后，初代開源消息隊列崛起，誕生了JMS、AMQP兩大標準，與之對應的兩個實現分別為 ActiveMQ、RabbitMQ，開源極大的促進了消息隊列的流行度，降低了使用門檻，逐漸成為了企業級架構的標配。相比于今天而言，這類MQ主要還是面向傳統企業級應用，面向小流量場景，橫向擴展能力比較弱。

第三階段，2007~2018年。 PC互聯網、移動互聯網爆發式發展。由于傳統的消息隊列無法承受億級用戶的訪問流量和海量數據傳輸，誕生了互聯網消息中間件，核心能力是全面采用分布式架構、具備很強的橫向擴展能力，開源典型代表有 Kafka、RocketMQ，還有淘寶的 Notify。Kafka 的誕生還將消息中間件從Messaging領域延伸到了 Streaming 領域，從分布式應用的異步解耦場景延伸到大數據領域的流存儲和流計算場景。

第四階段，2014~至今。 IoT、云計算、云原生引領了新的技術趨勢。面向IoT的場景，消息隊列開始從云內服務端應用通信，延伸到邊緣機房和物聯網終端設備，支持MQTT等物聯網標準協議也成了各大消息隊列的標配。

隨著云計算的普及，云原生的理念深入人心，各種云原生代表技術層出不窮，包括容器、微服務、Serverless、Service Mesh、事件驅動等。云原生的核心問題是如何重新設計應用，才能充分釋放云計算的技術紅利，實現業務成功最短路徑。

消息隊列本身作為云計算的PaaS服務之一，要進一步發揮“解耦”的能力，幫助業務構建現代化應用，這里最關鍵的一個能力演進是Eventing的演進。通過將消息升華為“事件”，提供面向標準 CloudEvent 的編排過濾、發布訂閱等能力構建更大范圍的解耦，包括云服務事件和業務應用的解耦、跨組織SaaS業務事件的解耦、遺留應用和現代化應用的解耦等，同時事件驅動也是天然符合云計算 Serverless 函數計算的范式，是應用 Serverless 化演進的催化劑。

云原生對于消息中間件而言，還有另一層含義就是消息隊列自身架構的云原生化演進，如何充分發揮云的彈性計算、存儲、網絡，讓自己獲得更強的技術指標和 Serverless 彈性能力。

消息中間件在技術上有哪些進展與突破？

阿里云 MQ 是基于 RocketMQ 打造的一站式消息服務，以 RocketMQ 作為統一內核，實現業界標準、主流的消息協議，包括MQTT、Kafka、RabbitMQ、AMQP、CloudEvent、HTTP等，滿足客戶多樣化場景訴求。為了提高易用性，我們分別對不同的協議進行了產品化，以獨立產品的模式提供消息服務（如阿里云RabbitMQ、阿里云Kafka），開箱即用、免運維、完備的可觀測體系，幫助開源客戶無縫遷云。

在經歷數萬企業客戶多樣化場景的持續打磨，數年的超大規模云計算的生產實踐，我們的內核RocketMQ逐漸往一體化架構和云原生架構演進。

1. 一體化架構

微服務、大數據、實時計算、IoT、事件驅動等技術潮流，不斷的擴展消息的業務邊界，業界有不同的消息隊列滿足不同的業務場景，比如RabbitMQ側重滿足微服務場景，Kafka則是側重于滿足大數據、事件流場景，EMQ則是滿足了IoT垂直領域場景。而隨著數字化轉型的深入，客戶的業務往往同時涉及交叉場景，比如來自物聯網設備的消息、或者微服務系統產生的業務消息要進行實時計算，如果是引入多套系統，會帶來額外的機器、運維、學習等成本。

在過去“分”往往是技術實現的妥協，而現在“合”才是用戶的真正需求。 RocketMQ 5.0基于統一Commitlog擴展多元化索引，包括時間索引、百萬隊列索引、事務索引、KV索引、批量索引、邏輯隊列等技術。在場景上同時支撐了RabbitMQ、Kafka、MQTT、邊緣輕量計算等產品能力，真正實現了“消息、事件、流”，“云邊端”一體化架構。

2.?云原生架構

云原生架構是指云上原生的架構，云計算是云原生的“源動力”，脫離了云計算談云原生如同紙上談兵。RocketMQ 過去幾年正是立足于阿里云超大規模的云計算生產實踐，幫助數萬企業完成數字化轉型的經驗中吸取養分，從而完成互聯網消息中間件到云原生消息中間件的進化。這也是 RocketMQ 和其他消息中間件最大的區別，他是實踐出來的云原生架構，下面我們盤點一下 RocketMQ 在云原生架構的關鍵技術演進。

RocketMQ 是 2011 年誕生于淘寶核心電商系統，一開始是定位于服務集團業務，面向單一超大規模互聯網企業設計。原來的架構并不能很好的滿足云計算的場景，有不少的痛點，比如重型 SDK，客戶端邏輯復雜、多語言 SDK 開發成本高、商業特性迭代慢；彈性能力差，計算存儲耦合、客戶端和物理隊列數耦合、隊列數無法擴展到百萬級、千萬級；而其他主流的開源消息項目也同樣未進行云原生架構的轉型，比如 RabbitMQ 單隊列能力無法橫向擴展、Kafka 彈性擴容會面臨大量的數據拷貝均衡等，都不適用于在公共云為大規模客戶提供彈性服務。

為此，RocketMQ 5.0 面向云計算的場景進行重新設計，期望從架構層面解決根本性問題，對客戶端、Broker到存儲引擎全面升級：

客戶端輕量化。 RocketMQ 5.0 SDK 把大量邏輯下沉到服務端，代碼行數精簡三分之二，開發維護多語言 SDK 的成本大幅度降低；輕量的 SDK 更容易被 Service Mesh、Dapr等云原生代表技術集成。

可分可合的存算分離架構。 用戶根據不同的場景訴求,既可以同一進程啟動存儲和計算的功能，也可以將兩者分開部署。分開部署后的計算節點可以做到“無狀態”，一個接入點可代理所有流量，在云上結合新硬件內核旁路技術，可以降低分離部署帶來的性能及延遲問題。而選擇“存儲計算一體化”架構，則具備“就近計算”的優勢，性能更優。在云上多租、多VPC復雜網絡、多協議接入方式的場景下，采用存儲計算分離模式能夠避免后端存儲服務直接暴露給客戶端，便于實現流量的管控、隔離、調度、權限管理、協議轉換等。

但是有利必有弊，存算分離也同時帶來了鏈路變長、延遲增大、機器成本上升等問題，運維也沒得到簡化，除了要運維有狀態存儲節點外，還要多運維無狀態計算節點。其實在大多數簡單消息收發場景，數據鏈路基本上就是寫Log、讀Log，無復雜計算邏輯（計算邏輯和數據庫相比太簡單），這個時候優選存儲計算一體化架構，簡單夠用、性能高、延遲低。 特別是在大數據傳輸場景下，存算一體能夠極大降低機器及流量成本，這個從 Kafka 的架構演進也可以得到印證。總的來說不要為了存算分離而分離，還是要回歸客戶、業務場景的本質訴求。

彈性存儲引擎。 面向 IoT 海量設備、云上大規模小客戶場景，我們引入 LSM 的 KV 索引，實現單機海量隊列的能力，隊列數量可以無限擴展；為了進一步釋放云存儲的能力，我們實現分級存儲，消息存儲時長從3天提高到月、年級別，存儲空間可以無限擴展，同時還分離了冷熱數據，冷數據存儲成本降低了80%。

Serverless化。 在老架構里面，客戶感知物理隊列，物理隊列綁定固定存儲節點，強狀態。Broker、客戶端、物理隊列的擴縮容互相耦合，負載均衡粒度是隊列級，對Serverless的技術演進很不友好。為了實現極致彈性 Serverless，RocketMQ 5.0 對邏輯資源和物理資源做進一步的解耦。

在 Messaging/無序消息的場景，客戶指定 Topic 進行消息無序收發，新架構對客戶端屏蔽隊列概念，只暴露邏輯資源 Topic。負載均衡粒度從隊列級到消息級，實現了客戶端的無狀態化，客戶端、服務端彈性伸縮解耦。

在 Streaming/順序消息的場景，客戶端需要指定 Topic 下的某個隊列（也稱分區）進行消息順序收發。在新架構里，對客戶端屏蔽物理隊列，引入邏輯隊列概念，一個邏輯隊列通過橫向分片和縱向分段，分散在不同的物理存儲節點。橫向分片解決了高可用問題，同一個邏輯隊列的多個分片多點隨機可寫，基于 Happen before 的原理保序，秒級 Failover，無需主備切換；縱向分段，解決邏輯隊列的擴容問題，通過多級隊列映射，實現 0 數據遷移的秒級擴容，邏輯資源和物理資源的彈性伸縮解耦。

如何看待消息領域生態玩家?

在云原生、IoT、大數據的趨勢引導下，消息成為現代化應用架構的剛需，使用場景更加廣泛，可應用于微服務的異步解耦、事件驅動、物聯網設備數據上下行、大數據流存儲、輕量流計算等場景。客戶需求旺盛、市場活躍，吸引了不少廠商加入角逐。

從好的角度來看，廠商的充分競爭，會進一步激活創新，培養更多用戶，共同做大消息的市場，用戶看起來也有更多的選擇；

從壞的角度來看，未來部分競爭失利的消息隊列會進入停滯期、下線期，用戶的應用就會面臨遷移大改造和穩定性風險，所以建議用戶在滿足自身業務需求的情況下，盡可能選擇標準接口、協議的方式接入，或者直接使用業界事實標準的消息隊列。

消息中間件未來的發展趨勢是什么？

隨著 IoT、5G 網絡的持續發展，數據量增速28%,預計到2025年物聯網設備將達到 400 億臺，進入萬物互聯的時代。物聯網時代的消息存儲量和計算量會爆發式增長，消息系統將面臨巨大的成本壓力。未來消息系統，需要深挖新硬件的紅利，比如持久內存、DPU等技術，采用軟硬結合的方式深度優化，將消息的存儲計算成本進一步降低。

IoT時代還有另外一個很重要的趨勢是邊緣計算，Gartner 預計到 2025 年，75%的數據將在傳統數據中心或云環境之外進行處理,消息系統需要進一步輕量化、降低資源消耗以適應邊緣計算環境。這也意味著，消息中間件的一體化架構，要具備良好的插件化設計，能夠根據場景的特點實現多形態輸出。比如公共云的形態可以和公共云的基礎設施深度集成，充分利用云盤、對象存儲增強存儲能力，集成日志服務、應用監控等服務提升可觀測能力；而邊緣計算的形態則是以最小的資源代價輸出核心存儲、輕量計算的能力，簡單夠用即可。

近幾年云計算高速發展，得益于全球范圍內大量企業在進行數字化轉型，通過業務在線化、業務數據化、數據智能化來提升企業競爭力。數據化轉型也伴隨著商業思維的轉型，越來越多的企業采用“事件驅動”的模式來構建商業邏輯和數字化系統。

Gartner預測，未來超過60%的新型數字化商業的解決方案會采用“事件驅動”模式，從業務角度看，“事件驅動”的模式能夠幫助企業實時響應客戶，抓住更多的商業機會，創造增量價值；從技術角度看，“事件驅動”的架構，能夠以動態、靈活、解耦的方式來鏈接跨組織、跨環境的異構系統，天然適合用于構建大型的跨組織數字化商業生態。

為了應對這個趨勢，Messaing 往 Eventing 演進，出現了 EventBridge （EventBroker）的產品形態。在 EventBridge 里，“事件”這個概念成為一等公民，事件的發布者和訂閱者不耦合任何一種具體的消息隊列SDK和實現。EventBroker 圍繞標準的 CloudEvent 規范構建更加泛化的發布訂閱模式，能夠鏈接一切跨組織、跨環境的異構事件源和事件處理目標。

目前以“事件驅動”構建的數字化商業生態才剛起步，未來 EventBridge 將圍繞事件這一抽象層次實現更強大的能力，比如事件的全鏈路可觀測、事件分析計算、低代碼開發等特性，幫助企業全面落地云時代的“事件驅動”架構。

作者介紹：

?林清山（花名：隆基），阿里云資深技術專家，阿里云消息產品線負責人。國際消息領域專家，致力于消息、實時計算、事件驅動等方向的研究與探索，推進 RocketMQ 云原生架構、超融合架構的演進。?

總結

以上是生活随笔為你收集整理的技术盘点：消息中间件的过去、现在和未来的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。