本文整理於 2023 年雲棲大會林清山帶來的主題演講《Apache RocketMQ 雲原生統一消息引擎》
Apache RocketMQ 簡介
消息隊列演進趨勢
操作系統、數據庫、中間件是基礎軟件的三駕馬車，而消息隊列屬於最經典的中間件之一，已經有 30 多年的歷史。他的發展主要經歷了以下幾個階段：
第一個階段，2000 年之前。80 年代誕生了第一款消息隊列是 The Information Bus，第一次提出發佈訂閱模式來解決軟件之間的通信問題；到了 90 年代，則是國際商業軟件巨頭的時代，IBM、Oracle、Microsoft 紛紛推出了自己的 MQ，其中最具代表性的是 IBM MQ，價格昂貴，面向高端企業，主要是大型金融、電信等企業；這類商業 MQ 一般採用高端硬件，軟硬件一體機交付，MQ 本身的軟件架構是單機架構。
第二階段，2000-2007 年。進入 00 年代後，初代開源消息隊列崛起，誕生了 JMS、AMQP 兩大標準，與之對應的兩個實現分別爲 ActiveMQ、RabbitMQ，他們引領了初期的開源消息隊列技術。開源極大的促進了消息隊列的流行、降低了使用門檻，技術普惠化，逐漸成爲了企業級架構的標配。相比於今天而言，這類 MQ 主要還是面向傳統企業級應用，面向小流量場景，橫向擴展能力比較弱。
第三階段，2007~2017 年。PC 互聯網、移動互聯網爆發式發展。由於傳統的消息隊列無法承受億級用戶的訪問流量和海量數據傳輸，誕生了互聯網消息中間件，核心能力是全面採用分佈式架構、具備很強的橫向擴展能力，開源典型代表有 Kafka、RocketMQ，閉源的還有淘寶 Notify。Kafka 的誕生還將消息中間件從消息領域延伸到了流領域，從分佈式應用的異步解耦場景延伸到大數據領域的流存儲和流計算場景。
第四階段，2014~至今。雲計算、IoT、大數據引領了新的浪潮。
Apache RocketMQ 發展歷程
伴隨着消息隊列行業的發展，Apache RocketMQ 自身也發展了十年，可分爲“誕生於互聯網”與“成長於雲計算”兩大階段。
第一個階段是 RocketMQ 的從 0 到 1，在阿里內部規模化落地。2012 年，爲了支撐超大規模電商互聯網架構，阿里中間件研發了 RocketMQ，並在產品誕生初期開源，2017 年 RocketMQ 統一了阿里消息技術體系。
第二個階段是雲計算，2016 年 RocketMQ 上雲，這也是業界首個提供公共雲 SaaS 形態的開源消息隊列。2016 年，阿里把 RocketMQ 捐贈給 Apache，17 年孵化畢業，成爲國內首個 TLP 的互聯網中間件。在雲計算和開源雙輪驅動下，RocketMQ 在阿里外部完成全面規模化，幫助千行百業完成數字化轉型，產品能力也得到進一步的飛躍。2022 年 5.0 正式發佈，Apache RocketMQ 正式邁進雲原生時代。
Apache RocketMQ 5.x 統一消息引擎
Apache RocketMQ 5.X 業務全景
爲了滿足雲時代多樣化的用戶需求，RocketMQ 5.0 從原來的互聯網業務消息中間件，擴展到"消息、事件、流"超融合處理平臺，解鎖更全面的能力。
在消息領域，全面擁抱雲原生技術，更好的彈性架構和高可用能力。
在事件領域，支持 CloudEvent 規範，以事件爲中心的產品新界面，助力客戶建設跨業務、跨組織的數字化商業生態
在流領域，流存儲增強批量特性，大幅度提高數據吞吐量；新增邏輯隊列能力，解耦邏輯資源和物理資源，在流場景也具備無縫伸縮能力；新增流數據庫 RSQLDB，提供實時事件流處理、流分析能力。
RocketMQ 基於端雲一體化架構實現了完整的物聯網消息隊列的能力，從原來的連接應用擴展到連接物聯網設備。同時 RocketMQ 5.0 也繼續保持極簡架構的原則，能夠以最低的資源消耗、運維成本搭建服務，適合邊緣計算。
消息和流的統一
爲什麼說 Apache RocketMQ 是統一的消息引擎，主要有以下幾方面的統一：
第一個統一是 Apache RocketMQ 統一了消息和流的場景。通過這個對比圖來看，消息和流的區別。常說的消息場景、隊列場景側重於業務集成，在這個場景裏 RocketMQ 的主要作用是連接業務應用，解耦業務架構的上下游系統，比如交易系統的解耦。這類場景，更多的是在線業務，由用戶觸發某個業務流程，比如購買。
爲了保障用戶體驗，消息系統要優先保障低延遲。這個場景裏和同步通信 RPC 對應，消息系統承擔都是異步通信職責。在消息消費層面，更多的是基於消息數據執行對應的業務邏輯，觸發下一個業務流程。每條消息的處理都是不相關的，無狀態的。側重於業務數字化場景，可類比於數據庫的 OLTP，單次操作數據量少，用於在線交易。
再來看流場景的話，它主要是側重於數據集成，連接各種數據組件，進行數據分發，解耦數據架構的上下游系統。比如日誌解決方案，採集日誌數據，進行 ETL 將日誌數據分發到搜索引擎、流計算、數據倉庫等。除了日誌之外，數據庫 Binlog 分發、頁面點擊流也是常見的數據源。在這種場景裏裏面，由於是離線業務，它對低延遲的需求較弱，更加側重於大批量吞吐型負載。另外在消息消費階段，不再是單條消息處理，更多的是批量轉儲，或者批量進行流計算。側重於數字業務化場景，可類比於數據庫的 OLAP，單次操作數據量大，用於離線分析場景。
具體來說，RocketMQ 如何實現消息和流的統一呢？
主要體現在領域模型的統一，包含 Producer、Consumer、Topic、Topic 邏輯分區 MessageQueue。在統一的領域模型下采用不同的訪問模式來滿足消息和流的不同場景。
在消息場景，客戶端只感知 Topic，往 Topic 發送消息，基於訂閱關係消費 Topic 的消息，觸發對應的業務邏輯，返回消費成功或者失敗，消費失敗還會有重試。
而在流的場景，對於消息數據的訪問模式有所不同。由於是用在數據集成的場景，對於大規模的數據集成，不可避免的要涉及到數據的分片，基於數據分片來連接上下游數據系統。在消息的讀寫方式上，不再是指定 Topic 讀寫，而是指定 Topic 分片，也就是隊列進行讀寫操作。作爲流存儲系統，下游的消費通常會是一些流計算引擎，用於有狀態計算。爲了支撐流計算引擎的容錯處理，它需要支持 checkpoint 機制，類似於爲流計算引擎提供 redolog，能夠按照隊列位點重放消息，重新恢復流計算的狀態。他也會要求分片內有序，同一個 key 的數據會 hash 到同一個分片，用於實現 keyby 的操作。
這個就是流存儲訪問模式跟消息訪問模式的區別。在消息場景裏，用戶只需要關注到 topic 資源，無需瞭解隊列、位點等概念。
在流場景裏面，還有一個很重要的變化，就是數據類型的變化。做個簡單對比，業務集成場景，消息的數據承載的是業務事件，比如說訂單操作、物流操作，它特點就是數據規模較小，但是它每一條數據的價值都特別高，它的訪問模式是偏向於在線的，單條事務的短平快訪問模式。
而在流的場景裏面呢，它更多的是一些非交易型的數據。比如說用戶日誌，系統的監控、IoT 的一些傳感器數據、網站的點擊流等等。他的特點是數據規模有數量級的提升，但單條數據的價值比較低的，然後它的訪問模式偏向於離線批量傳輸。所以在流的場景裏面，RocketMQ 存儲要面向高吞吐做更多的優化。
在 RocketMQ 5.0 裏面， 引入了端到端的批量消息。從客戶端開始，在發送階段，消息在客戶端攢批到一定數量，直接 1 個 RPC 請求裏面直接發到 broker 端。broker 存儲階段，直接把整批消息存儲，用批量索引的技術，一批消息只會構建一個索引，大幅度提升索引構建速度。在消費階段，也是按照整批數據讀取到消費端，先進行解包操作，最後執行消費邏輯。這樣整個 Broker 的消息 TPS 可以從原來的 10 萬級提升至百萬級。
端和雲的統一
第二個統一是端和雲的統一，端指物聯網設備端、移動端，雲指雲端服務和應用。我們先來了解一下物聯網的場景是什麼，以及消息在物聯網裏面有什麼作用。物聯網肯定是最近幾年最火的技術趨勢之一，有大量的研究機構、行業報告都提出了物聯網快速發展的態勢。
- 物聯網設備規模爆發式增長，會在 2025 年達到 200 多億臺。
- 物聯網的數據規模，來自物聯網的數據增速接近 28%，並且未來有 90% 以上的實時數據來自物聯網場景。這也就意味着未來的實時流數據處理數據類型會有大量物聯網數據。
- 重要的趨勢是邊緣計算，未來會有 75% 的數據在傳統數據中心或者雲環境之外來處理，這裏的邊緣指的是商店、工廠、火車等等這些離數據源更近的地方。
通過這個圖能看出消息在物聯網場景發揮的作用：
第一個作用是連接，承擔通信的職責，支持設備和設備的通信，設備和雲端應用的通信，比如傳感器數據上報、雲端指令下發等等這些功能，支撐 IoT 的應用架構，連接雲邊端。
第二個作用是數據處理，物聯網設備源源不斷的產生數據流，有大量需要實時流處理的場景，比如設備維護，高溫預警等等。基於 MQ 的事件流存儲和流計算能力，可以構建物聯網場景的數據架構。
在一個完整的物聯網解決方案中，會同時涉及到端和雲的協同，端用於採集數據、執行設備指令，雲用於存儲數據、分析數據，執行復雜業務邏輯。所以在 RocketMQ 5.0 裏發佈了 MQTT 子產品，實現端雲一體化。它有 3 個核心特點：
- 採用標準的物聯網協議 MQTT，該協議面向物聯網弱網環境、低算力的特點設計，協議十分精簡。同時有很豐富的特性，支持多種訂閱模式，多種消息的 QoS，比如有最多一次，最少一次，當且僅當一次。它的領域模型設計也是 消息、 主題、發佈訂閱等等這些概念，和 RocketMQ 特別匹配，這爲打造一個雲端一體的 RocketMQ 產品形態奠定了基礎。
- 採用端雲一體化的架構，因爲領域模型接近、並且以 RocketMQ 作爲存儲層，每條消息只存一份，這份消息既能被物聯網設備消費，也能被雲端應用消費。另外 RocketMQ 本身是天然的流存儲，流計算引擎可以無縫對 IoT 數據進行實時分析。消息可以來自各個接入場景（如服務端的 RocketMQ，設備端的 MQTT），但只會寫一份存到 commitlog 裏面，然後分發出多個需求場景的隊列索引，比如服務端場景（RocketMQ）可以按照一級 Topic 隊列進行傳統的服務端消費，設備端場景可以按照 MQTT 多級 Topic 以及通配符訂閱進行消費消息。這樣就可以基於同一套存儲引擎，同時支持服務端應用集成和 IoT 場景的消息收發，達到端雲一體化。
- 將原來 RocketMQ 的萬級隊列能力提升到百萬級隊列能力。例如 Kafka 這樣的消息隊列每個 Topic 是獨立文件，但是隨着 Topic 增多消息文件數量也增多，順序寫就退化成了隨機寫，性能明顯下降。RocketMQ 在 Kafka 的基礎上進行了改進，使用了一個 Commitlog 文件來保存所有的消息內容，再使用 CQ 索引文件來表示每個 Topic 裏面的消息隊列，因爲 CQ 索引數據比較小，文件增多對 IO 影響要小很多，所以在隊列數量上可以達到十萬級。但是這個終端設備隊列的場景下，十萬級的隊列數量還是太小了，希望進一步提升一個數量級，達到百萬級隊列數量，所以，引入了 Rocksdb 引擎來進行 CQ 索引分發，實現了百萬級隊列。
消息和事件的統一
還有第三個統一是消息和事件的統一。
在這之前， 我們先了解一下什麼是事件驅動。事件驅動本質上是一種軟件設計模式，它能夠最大化降低不同模塊以及不同系統之間的耦合度。
下面是一個典型的事件驅動架構圖，首先是事件生產者發送事件到 EventBroker，然後 EventBroker 會把事件路由到對應的消費者進行事件處理。事件處理能夠靈活擴展，隨時增減事件消費者，事件生產者對此透明。
事件驅動架構其實是個很經典的設計模式，因爲早在幾十年前，就出現過多種事件驅動的技術。比如桌面客戶端編程框架，點擊按鈕就可以觸發 onclick 事件，開發者編寫業務邏輯響應事件；在編程語言上，也經常會採用事件驅動的代碼模式，比如 callback、handler 這類的函數；進入分佈式系統的時代，系統之間的通信協同也會採用事件驅動的方式。
從這個圖我們可以發現事件驅動架構其實和基於消息的應用解耦差別不大，他們本質上要解決的都是解耦的問題。無論是消息的發佈訂閱，還是事件的生產消費都是爲了進行代碼解耦、系統解耦。消息隊列更偏技術實現，大部分的 EventBroker 都是基於消息隊列實現的，而事件驅動更偏向於架構理念。
事件驅動跟消息驅動最大的區別就是，事件是一種特殊的消息，只有消息滿足了某些特徵，才能把它叫做事件。
打個比方，來看上面這個圖。消息就像是一個抽象類，有多種子類，最主要的就是 Command 和 Event 兩種。以信號燈爲例，向信號燈發送打開的消息，這就是一種 Command，信號燈接受這個 Command 並開燈。開燈後，信號燈對外發出信號燈變成綠色的消息，這個就是一種 Event。
對於 Event 來說，有四個主要的特徵：
- 它是一個不可變的，事件就是表示已經發生了的事情，已經成爲事實。
- 事件有時間概念，並且對同一個實體來說事件的發送是有序的。如信號燈按順序發送了綠、黃、紅等事件。
- 事件是無預期的，這個就是 EDA 架構之所以能夠實現最大化解耦的特點，事件的產生者對於誰是事件消費者，怎麼消費這個事件是不關心的。
- 由於事件驅動是徹底解耦的，並且對於下游怎麼去消費事件沒有預期，所以事件是具象化的，應該包括儘可能詳盡的信息，讓下游消費者各取所需。這就是消息和事件的區別。
走向 Serverless
Serverless 大勢
Serverless 被認爲是下一代的雲原生代表技術；雲原生的本質則是通過一套技術體系和方法論，幫助客戶更好的用雲，充分釋放雲計算紅利，讓使用雲計算的客戶能夠實現更高效、更低成本的數字化轉型。關於雲原生的技術， 聽的比較多有微服務、容器化等。微服務側重於應用架構理念的革新，用微服務來實現業務高內聚、低耦合，從而提高研發效率、協作效率、業務敏捷度；而容器化則涉及應用運維層面，用容器化來屏蔽基礎設施的差異，提高可移植性，藉助 K8s 平臺，還能提高應用的運維效率、資源利用率。
而 Serverless 在雲原生所代表的含義則是，基礎技術下沉，雲服務界面上移的趨勢，本質上還是讓客戶把更多的精力聚焦在業務研發上，無需關心底層技術和物理資源。
如下面這個圖，在雲計算之前，用戶需要自建 IDC、購買物理機、自行虛擬化、搭建中間件，然後才能進行業務研發，有大量的時間、精力、資源都花在和業務無關的項目上。進入雲計算之後，越來越多的基礎設施由雲廠商來提供，從最早的 IaaS，直接使用雲廠商的計算、存儲、網絡資源；再到 PaaS，無需自建數據庫和中間件，直接使用託管基礎軟件服務；再到現在雲計算演進到 Serverless 的階段，客戶完全把大部分精力聚焦在業務代碼的開發上。
對雲服務廠商來說，Serverless 的雲產品也從最早的少數產品如對象存儲、函數計算等，發展到現在的 all on Serverless，具備了完備的 Serverless 產品體系，如 Serverless 消息隊列、微服務、數據庫、搜索、大數據產品等。
全面 Serverless 的應用場景
進入 Serverless 時代，全面使用 Serverless 的客戶會爲消息隊列帶來哪些場景變化呢？
- 如在應用側，越來越多的應用不在部署在自行購買的 ECS 上面，直接託管在 Serverless 容器、應用引擎、函數計算上，雲服務會根據其業務流量或者系統負載自動進行彈性伸縮，對應的消息服務也要能根據消息流量自行彈性伸縮；
- 在車聯網消息解決方案場景裏，汽車每天都有早晚高峯，上下行的消息流量也出現明顯的波峯波谷，車聯網客戶無需爲波峯流量預先購買消息資源，而是根據實際消息量，用多少付多少錢；
- 在移動 App 推送場景，也會面臨更多維度的資源指標，比如需要維持大量的連接數、偶爾的峯值消息推送、極小的消息存儲空間，客戶無需預先購買計算、存儲、網絡綁定的消息實例，而是分別面向連接數、消息流量、存儲空間分別付費。
- 除了核心的彈性能力之外，消息隊列的核心架構場景“事件驅動”在 Serverless 時代成爲最重要的架構模式，事件驅動架構有助於開發更加敏捷、可擴展、韌性的 Serverless 應用，事件驅動天然匹配 Serverless 研發範式。因此 Serverless 全雲開發模式中，客戶希望消息隊列的服務界面也需要上移，具備“事件總線”的能力。客戶不僅需要開箱即用的 Serverless 雲服務，也需要開箱即用的事件驅動集成服務，無需像以前一樣編寫集成的膠水代碼，研發效率進一步提升，走向 lowcode、nocode。比如雲產品事件集成，OSS 文件上傳事件發送到事件總線，用戶訂閱這個事件，並基於函數計算進行文件加工處理響應事件，驅動 Serverless 算力。
面向 Serverless 的趨勢，RocketMQ 5.0 從產品形態到技術架構都做了巨大的演進。
面向 Serverless 應用的新 SDK
當應用大量使用 Serverless 技術之後，應用的實例數將會隨着流量的變化動態彈性伸縮，相比於過去的場景，實例數變化將十分頻繁，這就對消息收發的負載均衡提出比較大的挑戰。
先來看生產鏈路的負載均衡，生產者通過服務發現機制，知道了 Topic 的數據分片以及對應的 Broker 地址。他的服務發現機制是比較簡單的，在默認情況下采用 RoundRobin 的方式輪詢發送到各個 Topic 隊列，保證了 Broker 集羣的流量均衡。生產者是徹底無狀態的，所以無論如何彈性伸縮，都沒有太多影響。
再來看下消費者的負載均衡，相對來說它會比生產者更復雜，舊模式是隊列級負載均衡，消費者知道 Topic 的隊列總數，也知道同一個 ConsumerGroup 下的實例數，就可以按照統一的分配算法，類似一致性 hash 的方式，讓每個消費者實例綁定對應的隊列，只消費綁定隊列的消息，每個隊列的消息也只會被一個消費者實例消費。這種模式最大的缺點就是負載不均衡，消費者實例要綁定隊列、有臨時狀態。當應用實例數變化頻繁的時候，這種負載不均衡會導致應用的 Serverless 擴容無效，擴容的新階段無法分擔消息的流量。如圖 Topic 有 2 個分區，擴容第三個節點會出現空跑；如果把 Topic 擴容成 3 個分區，隨後消費者實例又縮容回 2 個，那麼就會出現其中一個消費者實例承擔三分之二的流量，出現過載。
所以在 RocketMQ5.0 裏面， 引入了消息粒度的負載均衡機制，無需綁定隊列，消息在消費者集羣隨機分發，這樣就可以保障消費者集羣的負載均衡。更重要的是這種模式更加符合全鏈路 Serverless 化的場景，Broker 的機器數、Topic 的隊列數和消費者實例數完全解耦，可以獨立擴縮容。
Serverless 事件驅動的挑戰
在上一個章節， 提到消息和事件的統一，事件是一種包含業務語義的消息。下面結合一個典型事件驅動的案例來看看。
如下圖是一個基於消息隊列 RocketMQ 實現的一個交易系統，採用事件驅動的架構，圍繞“訂單”事件完成交易業務。事件生產者是交易中心，消費者是交易的下游系統。比如發送訂單創建事件，購物車響應事件，刪除之前的加購商品；發生訂單付款事件，會員系統響應事件，給客戶增加積分，物流系統響應事件，執行後續的發貨履約環節。整個交易系統是由“事件驅動”的微服務構建而成。
基於經典消息隊列的事件驅動方案在一個組織內部、部門內部是一個不錯的選擇。但是在 Serverless 時代面臨很多全新的挑戰。
- 越來越多的商業數字化解決方案是由多個不同組織協作完成的，比如 SaaS 平臺（釘釘）和它的合作伙伴，釘釘平臺發佈各種事件，包括視頻會議、日程、通訊錄、審批流、釘盤等事件，下游合作伙伴消費這些事件，研發行業應用。在這類新型數字化解決方案中，往往事件的生產者和消費者屬於不同的公司，開發者無法進行密集的交流，低成本的瞭解“事件”定義、格式、使用方法。目前的模式過於依賴開發者之間的交流，以及公司的內部文檔沉澱。
- 不同的公司往往會使用不同的技術體系，比如使用不同的消息隊列，事件生產者使用 RocketMQ，事件消費者使用 RabbitMQ；比如使用不同的消息傳輸協議，HTTP 或 AMQP。
- 事件的消費者多樣化，哪怕是同一個業務的事件，事件消費者可能只需要其中的某種子類型；哪怕是同一個事件，事件消費者也可能只能訪問其中的部分字段。
- 缺少開箱即用的事件集成能力，客戶全面用雲後，需要響應各種雲產品事件，比如響應 OSS 上傳事件，使用函數計算對文件進行處理，這種預先集成的特性，經典的消息隊列不具備。
Serverless 的事件驅動技術需要更加徹底的解耦，只關注“事件”本身，解耦技術實現細節，如傳輸協議、SDK、生產消費模式。
Serverless 事件驅動的設計
爲了實現 Serverless 的事件驅動， 在消息隊列的基礎上面，將“事件驅動”場景的服務界面上移，圍繞“事件”的領域模型進行重新設計。
最左邊是事件源，由於事件需要具備跨平臺生產消費的能力，所以採用 CNCF 的 CloudEvents 來作爲事件的格式。這個是業界事件的事實標準，它標準簡化了事件聲明，提升事件在跨服務、跨平臺的互操作性。
由於事件是有可能被跨組織消費的，所以需要一個統一的事件中心，讓這些不同的事件源都註冊到這個事件中心。對消費者來說就好比是一個事件商店，能夠選擇自己感興趣的事件訂閱。
在事件消費者開始編寫消費邏輯的時候，開發者還需要對這個事件的格式有更清楚的瞭解，需要知道這個事件有哪些內容，有哪些字段，分別是什麼含義，才能編寫正確的消費業務邏輯。所以，事件總線還提供了 schema 中心，有這個 schema 中心後，消費者對於事件的格式也就一目瞭然，不用跟事件源的發起者進行溝通了，整個效率也得到了大幅度的提升。
再往後面看，就到了事件消費的環節，因爲事件的消費者種類很多，不同消費者關注不同的事件類型，事件總線需要提供豐富的過濾規則。即便多個消費者對同一個事件感興趣，但是可能只需要事件的部分內容，事件總線還提供了事件轉換的能力。這就是 RocketMQ5.0 對事件驅動的能力抽象。
Serverless 事件驅動的新形態
基於上面的全新設計，以 RocketMQ 作爲事件存儲的內核，實現了全新的事件總線 EventBridge。
在產品界面上，面向事件驅動的業務進行一層抽象，核心領域對象從消息變成 CloudEvents。基於統一事件標準來構建事件驅動的數字生態。
事件源是多樣化的，可以是雲產品事件、數據流事件、也可以是 SaaS 平臺事件，應用自定義事件、通用的 WebHook。當然，它的事件目標也是多樣化的，通過事件規則引擎把事件路由到不同的消費者，典型的消費者包括函數計算、消息系統（用於解耦生產者、消費者使用不同的消息隊列技術）、存儲系統、流計算引擎、通用的 webhook，甚至可以是消息通知如語音\短信\郵件。事件驅動架構更適合建設混合雲、多雲的數字化系統。
通過 EventBridge 實現徹底的事件驅動架構，真正做到只關心“事件”本身，生產者和消費者實現更加徹底的解耦，包括組織解耦、技術體系解耦。
面向 Serverless 消息內核的重構
前面提到的主要是面向 Serverless 應用場景，如一些 Serverless 化的應用，Serverless 化的事件驅動架構，RocketMQ 在產品形態、使用界面上做出的改變。現在我們從技術架構演進的角度來看 RocketMQ 如何實現一個 Serverless 化的消息雲服務。在 Serverless 場景下，客戶需要的是聲明式的邏輯資源，不同邏輯資源可以解綁，分別彈性、按量服務。
面向 Serverless 的場景，RocketMQ 演進到三層存算分離的架構。
- 第一層是 RocketMQ proxy，它主要承載的是多協議，多領域場景的覆蓋。這裏面的領域場景有 RocketMQ 場景，經典的服務端應用集成；還有 MQTT，面向物聯網的應用；還有 EventBridge 面向事件驅動型的應用。Proxy 可以認爲是計算資源的主要載體，它是一個徹底的無狀態的網關。它可以面向客戶不同的連接數，不同的消息 TPS 以及不同的消息的讀寫的比例的變化，進行一個計算、網絡資源的獨立彈性。這樣纔可以匹配到客戶在 Serverless 場景下，對多種資源解耦彈性的需求。
- 第二層是 RocketMQ 的存儲引擎，它主要專注於消息多副本實現、多副本如何進行高可用切換。同時它也要負責本地存儲跟雲存儲的統一抽象。由於消息的存儲主要在雲盤和對象存儲上面，大部分的消息數據存儲在對象存儲，store 自身的狀態被弱化了，彈性效率也得以提升。RocketMQ store 可以根據客戶的消息流量特點，如消息吞吐量、TPS、消息大小、批量因素等和存儲資源 IOPS、帶寬、存儲空間進行彈性匹配，實現消息存儲和計算的解耦。
- 第三層是雲存儲層這一塊，大部分的消息存儲在對象存儲上，這是公共雲基礎設施級的存儲池化。通過將冷數據卸載到了對象存儲，然後縮短了 RocketMQ Store 的生命週期，同時也具備一個低成本的無限消息存儲空間。
現在 RocketMQ5.0 已經具備彈性架構，採用雲服務形態的 RocketMQ 能夠進一步和雲的基礎設施深度結合，充分釋放雲計算紅利。
在計算層面，RocketMQ 5.0 通過容器服務充分利用 ECS 彈性能力，採取彈性資源池 + HPA 相關技術支持計算能力快速彈性，同時 ACK 自帶的跨可用區部署能力爲雲產品提供了充足的高可用保障。
在網絡層面，RocketMQ 5.0 可接入了多種雲原生網絡能力，滿足用戶對多樣性網絡的需求，公網隨開隨用，支持多種私網網絡形態，基於 CEN 構建了全球互通的消息網絡，實現異地多活。
在存儲方面，基於盤古 DFS、對象存儲的多級存儲架構，提供低成本的無限存儲能力，冷熱數據鏈路分離，提供更高的 SLA。
事件驅動賦能 Serverless 技術棧
最後，基於 Apache RocketMQ 打造的消息產品體系，以事件驅動+集成兩大場景，賦能全面 Serverless 技術棧。
以上是一個典型的 Serverless 產品體系，一些頭部雲廠商已經實現了核心產品的全面 Serverless 化，無論是計算、存儲，還是大數據分析都具備了 Serverless 服務能力，基於這些能力客戶能夠打造端到端的 Serverless 應用，聚焦核心業務，把降本增效做到極致。
演講嘉賓：
林清山（花名：隆基），Apache RocketMQ 聯合創始人，阿里雲資深技術專家，阿里雲消息產品線負責人。國際消息領域專家，致力於消息、實時計算、事件驅動等方向的研究與探索，推進 RocketMQ 雲原生架構、超融合架構的演進。
本文爲阿里雲原創內容，未經允許不得轉載。