ApsaraMQ Serverless 能力再升級，事件驅動架構賦能 AI 應用

本文整理於 2024 年雲棲大會阿里雲智慧集團高階技術專家金吉祥（牟羽）帶來的主題演講《ApsaraMQ Serverless 能力再升級，事件驅動架構賦能 AI 應用》

雲訊息佇列 ApsaraMQ 全系列產品 Serverless 化，支援按量付費、自適應彈性、跨可用區容災，幫助客戶降低使用和維護成本，專注業務創新。那 ApsaraMQ 是如何一步一步完成 Serverless 能力升級的？在智慧化時代，我們的事件驅動架構又是如何擁抱 AI、賦能 AI 的？

本次分享將從以下四個方面展開：

首先，回顧 ApsaraMQ Serverless 化的完整歷程，即 ApsaraMQ 從阿里內部誕生、開源，到捐贈給 Apache 進行孵化，再到完成 Serverless 化升級的不斷突破、與時俱進的過程。
然後，重點介紹 ApsaraMQ 的存算分離架構，這是全面 Serverless 化程序中不可或缺的前提。
接下來，會從技術層面重點解讀近一年 ApsaraMQ Serverless 能力的演進升級，包括彈效能力的升級、基於 RDMA 進一步降低儲存和計算層之間的 CPU 開銷，以及對無感擴縮容的最佳化。
最後，介紹我們在面向 AI 原生應用的事件驅動架構上的探索，以及基於阿里雲事件匯流排定向更新向量資料庫，為 AI 應用融入實時最新資料的最佳實踐。

ApsaraMQ Serverless 化歷程

首先，我們來看 ApsaraMQ Serverless 化的整個發展歷程。

2012 年，RocketMQ 在阿里巴巴內部誕生，並將程式碼在 Github 上開源；
2016 年，雲訊息佇列 RocketMQ 版開啟商業化的同時，阿里雲將 RocketMQ 捐贈給了 Apache，進入孵化期；
2017 年，RocketMQ 以較短的時間孵化成為 Apache TLP，並快速迭代新功能特性，順利釋出 4.0 版本，支援了順序、事務、定時等特殊型別的訊息；
2018 年，隨著大資料、網際網路技術的發展，資料量爆發式增長，雲訊息佇列 Kafka 版商業化釋出；
2019 年，雲訊息佇列 RabbitMQ 版、雲訊息佇列 MQTT 版兩款產品商業化釋出，補齊了 ApsaraMQ 在 AMQP、MQTT 協議適配上的缺失；
2021 年，經過一段時間的孵化，ApsaraMQ 家族中的另一款產品事件匯流排 EventBridge 開始公測，開始融合事件、訊息、流處理；
2023 年，ApsaraMQ 全系列產品依託存算分離架構，完成 Serverless 化升級，打造事件、訊息、流一體的融合型訊息處理平臺；
今年，我們專注提升核心技術能力，包括秒級彈性、無感發布、計算儲存層之間的 RDMA 等，實現 Serverless 能力的進一步升級，並結合當下客戶需求，透過事件驅動架構賦能 AI 原生應用。

存算分離架構全景

第二部分，我們來看 ApsaraMQ 存算分離架構的全景，這是 Serverless 化升級不可或缺的前序準備。

ApsaraMQ 存算分離架構全景：雲原生時代的選擇

ApsaraMQ 的存算分離架構，是雲原生時代的選擇。

從下往上看，這套架構是完全構建在雲原生基礎之上的，整個架構 K8s 化，充分利用 IaaS 層的資源彈效能力，同時也基於 OpenTelemetry 的標準實現了metrics、tracing 和 logging 的標準化。
再往上一層是基於阿里雲飛天盤古構建的儲存層，儲存節點身份對等，Leaderless 化，副本數量靈活選擇，可以在降低儲存成本和保證訊息可靠性之間實現較好的平衡。
再往上一層是在本次架構升級中獨立抽出來的計算層，即無狀態訊息代理層，負責訪問控制、模型抽象、協議適配、訊息治理等。比較關鍵的點是，它是無狀態的，可獨立於儲存層進行彈性。
在使用者接入層，我們基於雲原生的通訊標準 gRPC 開發了一個全新的輕量級 SDK，與之前的富客戶端形成了很好的互補。

“Proxy” 需要代理什麼？

接下來我們重點看下這套架構裡的核心點，即獨立抽出來的 Proxy。

它是一層代理，那到底需要代理什麼呢？

在之前的架構中，客戶端與 Broker/NameServer 是直連模式，我們需要在中間插入一個代理層，由原先的二層變成三層。然後，將原先客戶端側部分業務邏輯下移，Broker、Namesrv 的部分業務邏輯上移，至中間的代理層，並始終堅持一個原則：往代理層遷移的能力必須是無狀態的。

從這張圖中，我們將原先客戶端裡面比較重的負載均衡、流量治理（小黑屋機制）以及 Push/Pull 的消費模型下移至了 Proxy，將原先 Broker 和 Namesrv 側的訪問控制（ACL）、客戶端治理、訊息路由等無狀態能力上移至了 Proxy。然後在 Proxy 上進行模組化設計，抽象出訪問控制、多協議適配、通用業務能力、流量治理以及通用的可觀測性。

ApsaraMQ 存算分離的技術架構

接下來看 ApsaraMQ 存算分離的技術架構，在原先的架構基礎上剝離出了無狀態Proxy 元件，承接客戶端側所有的請求和流量；將無狀態 Broker，即訊息儲存引擎和共享儲存層進行剝離，讓儲存引擎的職責更加聚焦和收斂的同時，充分發揮共享儲存層的冷熱資料分離、跨可用區容災的核心優勢。

這個架構中無狀態 Proxy 承擔的職責包括：

1. 多協議適配： 能夠識別多種協議的請求，包括 remoting、gRPC 以及 Http 等協議，然後統一翻譯成 Proxy 到 Broker、Namesrv 的 remoting 協議。

2. 流量治理、分發： Proxy 具備按照不同維度去識別客戶端流量的能力，然後根據分發規則將客戶端的流量導到後端正確的 Broker 叢集上。

3. 通用業務能力擴充套件： 包含但不限於訪問控制、訊息的 Tracing 以及可觀測性等。

4. Topic 路由代理： Proxy 還代理了 Namesrv 的 TopicRoute 功能，客戶端可以向 Proxy 問詢某個 topic 的詳細路由資訊。

5. 消費模型升級： 使用 Pop 模式來避免單客戶端消費卡住導致訊息堆積的歷史問題。

無狀態 Broker，即訊息儲存引擎的職責更加的聚焦和收斂，包括：

1. 核心儲存能力的迭代： 專注訊息儲存能力的演進，包括訊息快取、索引的構建、消費狀態的維護以及高可用的切換等。

2. 儲存模型的抽象： 負責冷熱儲存的模型統一抽象。

共享儲存為無狀態 Broker 交付了核心的訊息讀寫的能力，包括：

1. 熱儲存 EBS： 熱儲存 EBS，提供高效能、高可用儲存能力。

2. 冷儲存 OSS： 將冷資料解除安裝到物件儲存 OSS，獲取無限低成本儲存空間。

3. 跨可用區容災： 基於 OSS 的同城冗餘、Regional EBS 的核心能力構建跨可用區容災，交付一寫多讀的訊息儲存能力。

基於雲端儲存的存算分離架構，兼顧訊息可靠性和成本

存算分離架構中的儲存層是完全構建在阿里雲飛天盤古儲存體系之上的。基於這套架構，我們能夠靈活控制訊息的副本數量，在保證訊息可靠性和降低儲存成本之間做到一個比較好的平衡。

左圖是存算分離儲存架構中上傳和讀取的流程。可以看到，我們是在 CommitLog 非同步構建 consumeQueue 和 Index 的過程中額外新增了按照 topic 拆分上傳到物件儲存的過程；在讀取過程中智慧識別讀取訊息的儲存 Level，然後進行定向化讀取。

基於雲端儲存的架構，我們提供了 ApsaraMQ 的核心能力，包括：

1. 超長時間定時訊息： 超過一定時間的定時訊息所在的時間輪會儲存至物件儲存上，快到期時時間輪再拉回到本地進行秒級精準定時。

2. 叢集縮容自動接管： 訊息資料實時同步到物件儲存，物件儲存的資料能夠動態掛載到任意 Broker，實現徹底存算分離，Broker 的無狀態化。

3. 按需設定 TTL 成本最佳化： 支援按需設定訊息 TTL，不同重要程度的訊息可設定不同的 TTL，滿足訊息儲存時長需求的同時兼顧成本控制。

4. 冷熱訊息分離、分段預取： 熱資料的讀取命中本地儲存，速度快；冷資料的讀取命中遠端儲存，速率恆定且不會影響熱資料的讀取。

5. 動態調控雲端儲存的比例： 動態調控 EBS 和 OSS 的比例，大比例的 EBS 能夠具備更高的穩定性，應對 OSS 負載過高的背壓，提升 EBS 作為 OSS 的前置容災的能力；小比例的 EBS 則是可以最大化降低訊息單位儲存成本，讓整體的儲存成本趨同於 OSS 儲存成本。

Serverless 能力再升級

有了存算分離架構的鋪墊，ApsaraMQ 全系列產品 Serverless 化就更加順暢了。接下來展開介紹 ApsaraMQ Serverless 能力的升級。

訊息場景下的 Serverless 化

在訊息場景下通常會有兩個角色：訊息服務的使用方和提供方。

在傳統架構中通常是這樣的流程：使用方會給提供方提需求：我要大促了，你保障下；提供方說給你部署 10 臺夠不夠，使用方說好的；結果真到大促那一刻，真實流量比預估的要大很多倍，整個訊息服務被擊穿，硬生生掛了半小時。

在 Serverless 化改造前，仍需提前規劃容量；但相比傳統架構的提升點是，依託 IaaS 層的快速擴容能力，能夠極大縮短擴容時間；再演進到當前的 Serverless 架構，我們期望訊息服務提供方是能夠非常淡定地應對大促。

Serverless 現在已經成為了一個趨勢和雲的發展方向。ApsaraMQ 全線產品實現彈性靈活的 Serverless 架構，既彰顯了技術架構的先進性，也提升了客戶的安全感。業務部門減少了容量評估的溝通成本，用多少付多少，更省成本；運維部門免去了容量規劃，實現自動彈性擴縮，降低運維人員投入的同時，大大提升了資源的利用率。

Serverless 方案的 Why / What / How

Serverless 化預期達到的收益是：省心——秒級彈性，免容量規劃；省錢——用多少付多少；省力——少運維、免運維。

要解決的痛點是：使用者使用容量模型比較難做精準預估；運維側手動擴容，是一個非常耗時耗力的過程。

核心目標是：

彈性要快： 特別是針對一些脈衝型的秒殺業務，需要具備秒級萬 TPS 的彈效能力。
縮容無感： 應對 MQ 客戶端與服務側 TCP 長連線的特性，縮容、服務端釋出時要無感。
成本要低： 極致的效能最佳化，才能進一步降低使用者側的單位 TPS 成本。

透過如下幾個關鍵路徑構建 ApsaraMQ Serverless 核心能力：

多租、安全隔離、業務流量隔離： 是構建 Serverless 核心能力的基礎。
物理預彈&邏輯彈性： 物理預彈和邏輯彈性結合的極致彈性方案，透過映象加速、後設資料批次建立、主動路由更新等核心技術加速物理彈性，結合邏輯彈性最終交付秒級萬 TPS 的極致彈效能力。
RDMA： 在儲存和計算層之間引入 RDMA 技術，充分利用 RDMA 的零複製、核心旁路、CPU 解除安裝等特性進一步降低計算層與儲存層之間的通訊開銷。
優雅上下線： 依託 gRPC 協議的 GOAWAY 以及 Remoting 協議的擴充套件實現 TCP 長連線的優雅上下線。
控制資源水位： 透過智慧化的叢集流量排程以及平滑 Topic 遷移方案，進一步控制單個叢集的資源水位在一個合理的值。

這套 Serverless 方案可以同時滿足如下幾種場景：

第一種是平穩型：流量上升到一定水位後會平穩執行。
第二種是穩中有“進”型：流量平穩執行的同時，偶爾會有一些小脈衝。
第三種是週期性“脈衝型”：流量會週期性地變化。

計算、儲存與網路：充分利用雲的彈效能力

我們前面也有提到，這套架構是完全構建在雲原生基礎設施之上的，我們在計算、儲存、網路上都充分利用了雲的彈效能力，具體來看：

在計算側，透過 K8s 充分利用 ECS 的彈效能力，透過彈性資源池、HPA 等核心技術支援計算層的快速彈性，並透過跨可用區部署提升可用性。
在儲存側，充分利用飛天盤古儲存的彈效能力，支援自定義訊息的儲存時長，冷熱資料分離，額外保障冷讀的 SLA。
在網路側，公網隨開隨用，安全和方便兼具，支援多種私網形態接入，並基於 CEN 構建全球互通的訊息網路。

在這之上，結合 SRE 平臺的智慧叢集流量排程、叢集水位監控、物理預彈性等核心能力，最終交付了一套完整的 ApsaraMQ Serverless 化物理彈效能力。

秒級萬 TPS 的極致彈效能力保障

依託於上面的基礎物理資源的彈效能力，來看下我們是如何保障秒級萬 TPS 的極致彈效能力的？

從兩個維度來看使用者視角的彈性：

從限流維度看： 在無損彈性上限以內的 TPS，都不會觸發限流；超過無損彈性 TPS 上限後，會有秒級別的限流，透過邏輯彈性調整例項級別的限流閾值後，即可實現最終的 TPS 彈性。
從付費角度看： 在預留規格內按規格進行預付費；超過預留規格的上限 TPS，超過部分按量付費，即用多少付多少。

為了滿足使用者視角的秒級彈效能力，我們透過物理彈性和邏輯彈性相結合的方式來進行保障：

物理彈性是預彈的機制，彈性時間在分鐘級，使用者側無任何感知，由服務側來 Cover 成本。
邏輯彈性是實時生效的，彈性時間在秒級，同時在觸發無損彈性 TPS 上限時，使用者側是會有秒級別的限流感知的，另一方面，使用者是需要為彈出來的那部分流量進行按量付費的。

兩者的關係是：物理彈性是邏輯彈性的支撐，邏輯彈性依賴物理彈性。從彈性流程上看，當使用者的流量觸發無損彈性上限時，優先判斷物理資源是否充足，充足的話就進行秒級邏輯彈性，不充足的話就等待物理資源擴容後再進行邏輯彈性。當然這裡會有個預彈的機制，儘量保障邏輯彈性時物理資源都是充足的。

從物理彈性加速來看，透過以下幾個方面進行加速：

計算、儲存層按需彈性： 計算層更關注 CPU、客戶端連線數等核心指標；儲存層更關注記憶體、磁碟 IO 等效能指標。
映象下載加速： 透過 PlaceHolder + 映象快取元件加速新節點的擴容。
新增後設資料批次建立的機制： 新增儲存節點建立 5000 級別的 Topic 下降至 3 秒。
新增主動路由更新機制： 降低儲存節點物理擴容後承接讀寫流量的延遲。

我們的系統設計精密，旨在確保使用者體驗到極致的彈效能力，特別是實現每秒萬次事務處理（TPS）的秒級彈性擴充套件。這一能力的保障策略圍繞兩個核心維度展開，並深度融合物理與邏輯彈性機制，確保在高吞吐需求下的無縫響應與成本效率。

ApsaraMQ on RDMA：降低計算與儲存層之間通訊開銷

RDMA（全稱遠端記憶體直接訪問）是一種高效能的網路通訊技術，相比 TCP/IP 的網路模式，具有零複製、核心旁路、CPU 解除安裝等核心優勢。ApsaraMQ Serverless 化架構具備存算分離的特點，非常適合在計算層和儲存層之間引入 RDMA 技術，進一步降低內部元件之間的資料通訊開銷。

具體來看，計算層 Proxy 在接收到客戶端各種協議的訊息收發請求以後，透過內建的 Remoting Client 和儲存層 Broker 進行資料交換。在原先的 TCP/IP 網路模式中，這些資料是需要從作業系統的使用者態複製到核心態後，再經由網路卡和對端進行互動。依託 RDMA 核心旁路特性，透過實現 RdmaEventLoop 的介面卡，訊息直接由使用者態到 RDMA 網路卡和對端進行互動。

從最終 BenchMark 的測試效果來看，引入 RDMA 技術後，儲存層 Broker 的 CPU 資源消耗下降了 26.7%，計算層 Proxy 的 CPU 資源消耗下降了 10.1%，計算到儲存的傳送 RT 下降了 23.8%。

優雅上下線：ApsaraMQ Serverless 彈性如絲般順滑

在 Serverless 場景下，物理資源的水平彈性擴縮是一個常態化的過程，同時結合 MQ 客戶端和計算層 Proxy TCP 長連線的特點，在 Proxy 上下線過程中是比較容易出現連線斷開的感知，比如客戶端剛發出一個接收訊息的請求，連線就被服務側強行關閉了，是非常容易造成單次請求超時的異常的。

因此，我們透過 gRPC 協議 Http2 的 Go Away 機制以及 Remoting 協議層的擴充套件，結合 SLB 連線優雅終端的能力來實現 ApsaraMQ 在擴容態、縮容態、以及釋出態的無感。

右圖展示了縮容態下單臺 Proxy 優雅下線的過程：

當收到 Proxy-0 需要下線的指令後，SLB 會將 Proxy-0 摘除，保障新的連線不再建立到 Proxy-0 上，同時 Proxy-0 進入 Draining 狀態，舊連線進行會話保持。
Proxy-0 上收到新的請求後，返回的 Response Code 都更新為 Go Away；同時客戶單收到 Go Away 的 Response 後，斷開原先的連線，向 SLB 發起新建連線的請求。
SLB 收到新建連線的請求，會導流至 Proxy-1。
等待一段時間後 Proxy-0 上的連線會自然消亡，最終達到無感下線的目的。

事件驅動架構賦能 AI 應用

接下來，將闡述面向 AI 原生應用的事件驅動架構如何擁抱 AI，賦能 AI 應用蓬勃發展。

面向 AI 應用的實時處理，具備實時 Embedding 至向量資料庫、更新私有資料儲存的能力，全面提升 AI 應用實時性、個性化和準確度。
面向 AI 應用的非同步解耦，解耦 AI 推理鏈路的快慢服務，加快應用響應速度。
面向 AI 應用的訊息負載，ApsaraMQ 支援主動 Pop 消費模式，允許動態設定每一條訊息的個性化消費時長. 同時也支援優先順序佇列，滿足下游多個大模型服務的優先順序排程。
面向 AI 應用的訊息彈性，ApsaraMQ 提供全模式的 Serverless 彈效能力，支援純按量和預留+彈性、定時彈性等多種流量配置模型；

最後，讓我們來看下阿里雲事件匯流排 EventBridge 是如何實現資料實時向量化，提升 AI 應用的實時性和準確度的？

阿里雲事件匯流排的 Event Streaming 事件流處理框架，具備監聽多樣化資料來源，然後經過多次 Transform 之後再投遞給下游資料目標的原子能力；依託這個框架，我們是很容易去實現資料的實時向量化的，從 RocketMQ、Kafka、OSS 等多個源監聽到實時資料流入之後，經過文字化、切片、向量化等操作，最終存入向量資料庫，作為 AI 應用實時問答的多維度資料檢索的依據，最終提升了 AI 應用的實時性和準確度。

點選此處，觀看本場直播回放。