作者 | 周禮（不銘） 阿里巴巴集團消息中間件架構師

導讀：本文整理自作者于 2020 年云原生微服務大會上的分享《云原生時代的消息中間件演進》，主要探討了傳統的消息中間件如何持續進化為云原生的消息服務。

關注阿里巴巴云原生公眾號，后臺回復 818 即可獲取直播回看地址和大會 PPT 合集。

引言

本文以一張云進化歷史圖開場，來談談云原生時代消息中間件的演進路線，但本文絕對不是“開局一張圖，內容全靠編”。

從虛擬化技術誕生以來，IaaS / PaaS / SaaS 概念陸續被提了出來，各種容器技術層出不窮。到 2015 年，Cloud Native 概念應運而生，一時間，各種云廠商，云服務以及云應用都加上了“云原生”前綴。

我們也一直在思考，傳統的消息中間件需要做些什么才能加上云原生這個修飾詞，這也是本文探討的主題：傳統的消息中間件如何持續進化為云原生的消息服務。

云原生消息服務

1. 什么是云原生

首先來談談什么是云原生，云原生是一個天然適用于云計算的架構理念，實踐云原生技術理念的應用可以最大化享受云計算的技術紅利，包括彈性伸縮、按量付費、無廠商綁定、高 SLA 等。

應用在實踐云原生技術理念時一般會遵循四個要素：

• 采取 DevOps 領域的最佳實踐來管理研發和運維流程；
• 通過 CICD 工具鏈做到應用的快速迭代和持續交付；
• 采取微服務架構；
• 采取容器及相關技術進行應用的托管。

消息服務作為應用的通信基礎設施，是微服務架構應用的核心依賴，也是實踐云原生的核心設計理念的關鍵技術，通過消息服務能夠讓用戶很容易架構出分布式的、高性能的、彈性的、魯棒的應用程序。消息服務在云原生的重要性也導致其極可能成為應用實踐云原生的阻塞點，所以消息服務的云原生化是至關重要的。

2. 什么是云原生消息服務

先說結論，我們認為云原生消息服務是云原生的通信基礎設施。2015 年成立的 CNCF 基金會大范圍推廣了云原生的技術理念，并提供了一套完整的實踐技術工具集，幫助開發者落地云原生理念。這套工具集收錄于 CNCF 云原生全景圖，其中消息中間件處于應用定義和開發層的 Streaming 和 Messaging 類目。

消息中間件在云原生的應用場景，主要是為微服務和 EDA 架構提供核心的解耦、異步和削峰的能力，在云原生全景圖定義的其它層次領域，消息服務還發揮著數據通道、事件驅動、集成與被集成等重要作用。

另外云原生倡導面向性能設計，基于消息隊列的異步調用能夠顯著降低前端業務的響應時間，提高吞吐量；基于消息隊列還能實現削峰填谷，把慢服務分離到后置鏈路，提升整個業務鏈路的性能。

3. 云原生消息服務演進方向

云原生時代對云服務有著更高的要求，傳統的消息服務在云原生這個大背景下如何持續進化為云原生的消息服務，我們認為方向有這么幾個：

1）高 SLA

云原生應用將對消息這種云原生 BaaS 服務有更高的 SLA 要求，應用將假設其依賴的云原生服務具備跟云一樣的可用性，從而不需要去建設備份鏈路來提高應用的可用性，降低架構的復雜度。只有做到與云一樣的可用性，云在服務就在，才能稱為真正的云原生服務。

2）低成本

在過去，每家公司自建消息中間件集群，或是自研的、或是開源的，需要投入巨大的研發、運維成本。云原生時代的消息服務借助 Serverless 等彈性技術，無需預先 Book 服務器資源，無需容量規劃，采取按量付費這種更經濟的模式將大幅度降低成本。

3）易用性

在云原生時代，消息服務第一步將進化成為一種所見即所得、開箱即用的服務，易用性極大的提高。接下來，消息服務將以網格的形式觸達更復雜的部署環境，小到 IoT 設備，大到自建 IDC，都能以跟公有云同樣易用的方式接入消息服務，且能輕易地滿足云邊端一體化、跨 IDC、跨云等互通需求，真正成為應用層的通信基礎設施。

4）多樣性

云原生消息服務將致力于建設大而全的消息生態，來涵蓋豐富的業務場景，提供各式各樣的解決方案，從而滿足不同用戶的多樣性需求。阿里云消息隊列目前建設了多個子產品線來支撐豐富的業務需求，比如消息隊列 RocketMQ，Kafka，微消息隊列等。

5）標準化

容器鏡像這項云原生的核心技術輕易地實現了不可變基礎設施，不可變的鏡像消除了 IaaS 層的差異，讓云原生應用可以在不同的云廠商之間隨意遷移。但實際上，很多云服務提供的接入形式并不是標準的，所以依賴這些非標準化云服務的應用形成了事實上的廠商鎖定，這些應用在運行時是無法完成真正的按需遷移，所以只能稱為某朵云上的原生應用，無法稱為真正的云原生應用。因此，消息服務需要做到標準化，消除用戶關于廠商鎖定的擔憂，目前阿里云消息隊列采納了很多社區標準，支持了多種開源的 API 協議，同時也在打造自己標準化接口。

總結一下，傳統的消息隊列將從高 SLA、低成本、易用性、多樣性和標準化幾個方向持續進化為云原生的消息服務。

云原生消息三化

談到云原生，離不開 Kubernetes、Serverless 以及 Service Mesh，接下來為大家分享下我們如何利用 K8s 社區的生態紅利，如何實踐 Serverless 和 Service Mesh 技術理念。

1. 云原生消息 Kubernetes 化

Kubernetes 項目當下絕對是大紅大紫，在容器編排和應用托管領域絕對的事實標準，整個社區也是生機盎然。所以，必須將我們的消息服務升級為 K8s 環境開箱即用的服務。

云原生消息 Kubernetes 化是指通過自定義 CRD 資源將有狀態的消息集群托管至 Kubernetes 集群中，充分利用

K8s 提供的部署、升級、自愈等能力提高運維效率，同時盡可能享受 K8s 的社區生態紅利。

我們在 RocketMQ 開源社區也提供了 CRD 描述文件以及相應的 Operator 實現，通過這套實現，可以快速部署 RocketMQ 集群至 K8s 環境；利用 K8s 的能力低成本運維 RocketMQ 集群；也可以使用云原生的 Prometheus 觀察集群指標。

RocketMQ 完成 Kubernetes 化后，就變成了 Kubernetes 環境原生可訪問的一個消息服務，將給開發者帶來極大的便利性。

同時，在商業化環境，我們也正在依賴 Kubeone 將消息隊列系列產品完成 Kubernetes 化。

2. 云原生消息 Serverless 化

Serverless 最核心的理念是“按需”，云原生消息 Serverless 化主要是從兩個維度落地按需的概念：

• 一方面根據業務規模自動化擴縮容實例規格、隊列數等邏輯資源；
• 另一方面，根據服務端負載自動化擴縮容計算、存儲等物理資源。

1）邏輯資源按需擴縮容

在用戶側，更關心的是消息實例提供的邏輯資源是否充足，比如購買的實例 TPS 規格是否足夠，隊列數量是否能滿足擴展性需求。比如一個商業化的 MQ 實例中，可以根據用戶的流量對實例規格進行自動的升降配，從 2W TPS 至 10W TPS 按需調整；也可以根據用戶分布式消費者的數量規模，對邏輯隊列數量進行動態調整；用戶完全不需要進行容量評估。

2）物理資源按需擴縮容

在云服務開發者側，我們更關心的是如何通過 Serverless 降低運維成本，避免手動的機器購買、VIP 申請、磁盤申請以及集群擴縮容等。在 Kubernetes 化完成后，可以很輕易地根據集群 Load 等指標自動擴容 MQ 物理資源；在集群縮容的處理上，會比較麻煩，因為每個 MQ 節點其實是有狀態的，圖中的某個 PV 代表了一個 CommitLog，我們在內部通過在 ASI 上支持 PV 漂移，在 RocketMQ 存儲層支持多 CommitLog 掛載來完成自動化縮容。

3. 云原生消息 Mesh 化

Service Mesh 出發點是解決微服務架構的網絡問題，將服務之間的通信問題從業務進程中進行剝離，讓業務方更加專注于自身的業務邏輯。 云原生消息 Mesh 化將消息的富客戶端能力下沉至 Sidecar，將消息的服務發現、負載均衡、流量監控等職責與業務邏輯隔離，在運行時完成透明組裝，同時提供細粒度的消息灰度和治理能力。

目前阿里云消息隊列 RocketMQ 是國內第二個成功進入 Service Mesh 官方社區的中間件產品，在進行 Envoy 適配的過程中推動了 Envoy 社區加速對 on-demand CDS 的支持，創新性地使用 Pop 消費模式來適配 Mesh 的無狀態網絡模型。

更詳細的 Mesh 化介紹參考文章：Apache RocketMQ 的 Service Mesh 開源之旅

云原生消息生態

在云原生消息服務演進方向小節中提到，云原生消息服務需要大而全的消息生態來覆蓋業務方豐富的業務場景，本小節介紹我們在生態建設方面做的一些努力。

1. 云原生消息產品矩陣

阿里云消息產品矩陣包含消息隊列 RocketMQ、Kafka、AMQP、微消息隊列 MQTT、消息通知服務 MNS 以及即將發布的 EventBridge，涵蓋互聯網、大數據、移動互聯網、物聯網等領域的業務場景，為云原生客戶提供一站式消息解決方案。

• 消息隊列 RocketMQ ：阿里巴巴自主研發及 雙11 交易核心鏈路消息產品，阿里云主打品牌，主要面向業務消息處理，打造金融級高可靠消息服務；
• 消息隊列 Kafka ： 聚焦大數據生態鏈，100% 融合 Kafka 開源社區，大數據應用領域中不可或缺的消息產品；
• 微消息隊列 MQTT ：基于 MQTT 標準協議自研，拓展消息產品的領域與邊界，延伸到移動互聯網以及物聯網，實現端與云的連接；
• 消息隊列 AMQP ：100% 兼容 AMQP 事實標準協議，全面融合 RabbitMQ 開源社區生態；
• 消息服務 MNS ：聚焦云產品生態集成 & 消息通知服務（HTTP Endpoint、Function Compute、事件通知、移動推送等）；
• 事件總線 EventBridge ：作為我們下一代的消息產品形態，原生支持 CloudEvents 標準，提供中心化事件服務能力，加速云原生生態集成，EDA 首選。

2. 云原生消息生態

在生態建設方面，我們在商業化和開源兩個生態都取得了不錯得成功。

在阿里云消息商業化生態中，消息隊列產品線已經支持 11 BU，30+ 云產品或者解決方案，有些對用戶是可見的，有些是不可見的，真正做到了云原生通信基礎設施的定位。

在開源方面，開源 RocketMQ 已經完成了云原生技術棧的集成，包括 Knative 中的事件源，Prometheus 的 Exporter，K8s 的 Operator 等；也支持了微服務框架 Dubbo、SpringCloud 以及函數計算框架 OpenWhisk；同時開發了很多 Connector 作為 Sink 或者 Source 去連接了 ELK、Flume、Flink、Hadoop 等大數據和數據分析領域的優秀開源產品。

3. 云原生消息標準

最開始我們就提到標準化是云原生消息中間件的進化方向之一，我們從兩個維度打磨產品的標準化建設。

1）社區標準

在消息領域，無論是接口還是協議，社區一直有很多事實上的“標準”，比如 Kafka 提供的 API 和協議，JMS API，CloudEvents 規范，MQTT 中的協議和模型，AMQP 的協議和模型等，阿里云消息隊列產品線對這些事實標準都提供了相應的接入方式，用戶可以低成本完成遷移上云。

2）自建標準

事實上的“標準”如果太多，其實就沒有標準，開源方面一直在推動自建標準 OpenMessaging，OMS 將提供六大核心特性：多領域、流、平臺無關、標準的 Benchmark，面向云，線路層可插拔。目前，國內有很多云提供商都接入了 OMS 標準。

云原生消息核心競爭力

作為云原生的消息，核心競爭力在哪，特別是開源生態愈發蓬勃，用戶可選的解決方案非常多，如何讓用戶選擇我們云原生的消息服務，我們認為核心競爭力主要有這么幾個。

1. 領先的消息服務能力

阿里云的消息服務，在多個方面都具備絕對領先的服務能力。

1）接入&遷移

整個產品線支撐了多協議、多 API、多語言、多終端以及多生態的接入，做到了“0”接入成本，開源或自建用戶都可以無縫上云；同時全球消息路由也支持跨地域的消息同步，異構的消息遷移同步等。

2）多租戶

阿里云消息服務支持命名空間隔離、標準的訪問控制；支持實例限流、資源隔離、多租戶的海量堆積。

3）消息類型

在業務消息領域，阿里云消息有多年的業務沉淀，消息類型上支持：普通消息、事務消息、定時消息、順序消息、重試消息以及死信消息等。

4）消費 & 治理

在消費和治理領域，云消息服務支持 Pub / Sub 模式，廣播/集群消費模式，消費過程中支持 Tag 過濾、SQL 過濾。在運維時，提供了消息軌跡、消息查詢以及消息回放等治理能力。

5）服務能力

阿里云消息的服務能力是經過多年錘煉的：

• 高可用：核心交易鏈路 12 年，雙十一 10 年歷程，在云上承諾的可用性 SLA 為 99.95%，可靠性 8 個 9；
• 高性能：雙11 消息收發 TPS 峰值過億，日消息收發總量 3 萬億；擁有全球最大的業務消息集群之一；
• 低延遲：在 雙11 萬億級數據洪峰下，消息發送 99.996% 在毫秒級響應；消息發布平均響應時間不超過 3 毫秒。

2. 統一的消息內核

阿里云消息隊列的另一核心競爭力為統一的消息內核，整個消息云產品簇都建設在統一的 RocketMQ 內核之上，所有的云產品提供一致的底層能力。

RocketMQ 內核主要包含以下幾個模塊：

1）富客戶端

RocketMQ 提供一個輕量級的富客戶端，暴露 Push、Pull 以及 Pop 三種消費模式，同時內置了重試、熔斷等高可用功能，產品簇的眾多客戶端都是通過對內核的富客戶端進行二次開發的。

2）注冊中心

也就是 RocketMQ 開發者熟知的 NameServer，以簡單可靠的方式提供集群管理、元數據管理、Topic 路由和發現等功能，節點無狀態，最終一致的語義確保 NameServer 具有超高的可用性。

3）計算節點

Broker 中的計算部分包含一個高性能的傳輸層，以及一個可擴展的 RPC 框架，以支持各個產品的豐富的業務需求。

4）存儲引擎

Broker 中的核心為存儲引擎，經過多年錘煉的存儲引擎包含幾個核心特點：

• 低延遲讀寫互斥：通過在 PageCache 層完成消息的讀寫互斥，來大幅度保障寫鏈路的低延遲；
• 日志與索引分離：整個存儲層將消息以 Append-Only 的方式集中式存儲在 CommitLog 中，同時以索引派發這種可擴展的方法來支持事務、定時、查詢以及百萬隊列等高級特性；
• 一致性多副本：提供多套一致性多副本實現來滿足不同的部署場景和需求，比如 Master-Slave 架構、基于 Raft 的 Dleger 和正在自研的秒級 RTO 多副本協議；
• 多模存儲：在未來存儲的方式肯定是多樣化的，存儲引擎抽象來統一的存儲接口，并提供了本地塊設備、云存儲以及盤古原生存儲等實現。
• 多級存儲：越來越的用戶對消息生命周期有了更高的要求，在過去，消息作為應用開發的中間狀態，往往只會被存儲數天，通過 Deep Storage，將以低成本的方式大幅延長消息的生命周期，將消息轉化為用戶的數據資產，以挖掘更多的諸如消息分析、消息計算需求。

3. 全方面的穩定性建設

穩定性永遠是前面的 1，業務發展和創新是后面的 0。
—— 叔同

穩定性的重要性是不言而喻的，穩定性是用戶做技術和產品選型的時候考察第一要素，阿里云消息隊列在穩定性方面做了全面的建設。

阿里云消息隊列主要從以下幾個維度進行穩定性建設：

1）架構開發

整個系統是面向失敗設計的，除了最核心的組件，所有的外部依賴都是弱依賴；在產品迭代階段，建立了完善的 Code Review、單元測試、集成測試、性能測試以及容災測試流程。

2）變更管理

風險往往來自于變更，我們對變更的要求是可灰度、可監控、可回滾以及可降級的。

3）穩定性防護

限流、降級、容量評估、應急方案、大促保障、故障演練、預案演練、定期風險梳理等都是我們的穩定性防護手段。

4）體系化巡檢

分為黑盒巡檢和白盒巡檢，黑盒巡檢會站在用戶視角對產品功能進行全方面掃描，包含了 50+ 檢測項；白盒巡檢會自動化檢測 JVM 運行時指標、內核系統指標、集群統計指標等，并在指標異常時及時預警。

5）故障應急

我們建設了一套完整的故障應急流程，從監控報警->故障發生->快速止血->排查根因->故障復盤，整個鏈路都是順暢的。

云原生消息展望

在消息產品矩陣小節中提到，EventBridge 是作為我們下一代的消息產品形態，該產品也即將迎來公測，本章節主要介紹 EventBridge 的產品定位。

1. 消息與事件

消息和事件是兩種不同形態的抽象，也意味著滿足不同的場景：

1）消息

消息是比事件更通用的抽象，常用于微服務調用之間的異步解耦，微服務調用之間往往需要等到服務能力不對等時才會去通過消息對服務調用進行異步化改造；消息的內容往往綁定了較強的業務屬性，消息的發送方對消息處理邏輯是有明確的預期的。

2）事件

事件相對于消息更加具像化，代表了事情的發送、條件和狀態的變化；事件源來自不同的組織和環境，所以事件總線天然需要跨組織；事件源對事件將被如何響應沒有任何預期的，所以采用事件的應用架構是更徹底的解耦，采用事件的應用架構將更加具備可擴展性和靈活性。

2. EventBridge：中心化事件總線

EventBridge 作為我們即將發布的新產品，其核心能力之一便是提供中心化的事件總線能力。

EventBridge 將提供云產品之間、云應用之間、云產品與云應用之間，以及它們與 SaaS 提供商之間的集成與被集成能力。

在中心化事件總線中有幾個重要的概念：

• 事件源：事件源可以是阿里云服務，比如對象存儲、ECS、數據庫等，也可以是用戶的應用程序或者第三方 SaaS，這些事件源將提供豐富的業務事件、云產品運維事件、事件流等；
• 資源管理：EventBridge 內部將提供總線管理、規則管理以及 Schema 管理，提供全托管的事件服務；
• 事件處理：EventBridge 將提供事件傳輸、事件過濾、事件路由、事件查詢、回放、重試、追蹤等核心的事件處理能力；
• 事件目標：事件最終投遞的目標服務包羅萬象，既可以觸發一個 Serverless 的 Function，也可以投遞至消息隊列其它產品，運維事件還可以通過短信、郵件以及日志服務觸達運維人員。

3. EventBridge：EDA 服務框架

EventBridge 另一個核心能力是 EDA 服務框架。微服務有兩種驅動方式：請求驅動和事件驅動。在請求驅動模式下，服務之間調用是同步調用，這種模式優點是延遲低，但是服務之間的耦合是比較重的，相比之下事件驅動有幾個優點：

• 異步化：所有的調用通過事件異步化驅動，服務之間沒有顯示的依賴關系；
• 松耦合：通過事件總線解除所有服務之間的耦合關系；
• 可擴展：可擴展能力非常強，基于總線和事件 Schema 完成業務的擴展非常簡單；
• 零改造：請求驅動的微服務，在遇到服務之間能力不對等時，往往需要進行基于消息異步化改造，避免慢調用、超時等異常情況在整個分布式集群觸發雪崩效應。基于事件驅動的微服務天然具備力異步、削峰等能力，所以在業務規模擴大時不會帶來額外的改造成本。

上圖是設想的一個采用 EDA 的應用架構圖：

• 基于 EventBridge 可以實踐流行的 CQRS 和 Event Souring 范式；
• 可以從 IoT 端設備上接入 Event Streaming；
• 基于事件驅動的微服務程序也可以通過 API 網關暴露傳統的 Request 請求方式，供前端訪問；
• EventBridge 還可以連接第三方 SaaS 提供商，云提供商，不同組織的觀察者，與分布式的事件微服務集成；
• 事件驅動和請求驅動是相輔相成的關系，通過統一 Event APIs 和 REST APIs 打通事件驅動的微服務與請求驅動的微服務，來進行架構上的融合與統一。

4. EDA 成熟度模型

我們通過 Gartner 報告總結的 EDA 成熟度模型，展望以下 EDA 架構的未來：

• Incidental：偶發性地使用事件通知機制來進行一些狀態的捕獲，沒有明確的事件處理策略；
• Brokered：提供托管的事件代理服務，組織中部分應用開始采用基于消息或者事件的異步化架構；
• Centralized：以戰略的形式提出中心化的 EDA 解決方案，有專門的組織團隊提供 EDA 實現，EDA 架構開始廣泛被采用；
• Advanced：EDA 架構開始觸達更多的業務領域，比如流計算，數據分析，AI，以及 API 市場等，跨組織的事件生態開始形成并進行擴張；
• Pervasive：事件變得無處不在，龐大的事件生態形成，組織間的隔離被事件徹底打通，企業的關鍵業務都將采取 EDA 架構；事件驅動與請求驅動兩個生態完成融合。

阿里云消息團隊在 EDA 領域的探索目前是處于第三個階段，未來還有很長的路要走。

“阿里巴巴云原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的公眾號。”

總結

以上是生活随笔為你收集整理的阿里云rocketmq_云原生时代消息中间件的演进路线的全部內容，希望文章能夠幫你解決所遇到的問題。

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