引言
本文以一張雲進化曆史圖開場，來談談雲原生時代消息中間件的演進路線，但本文絕對不是“開局一張圖，内容全靠編”。
從虛拟化技術誕生以來，IaaS/PaaS/SaaS概念陸續被提了出來，各種容器技術層出不窮。到2015年，Cloud Native概念應運而生，一時間，各種雲廠商，雲服務以及雲應用都加上了“雲原生”字首。
我們也一直在思考，傳統的消息中間件需要做些什麼才能加上雲原生這個修飾詞，這也是本文探讨的主題：傳統的消息中間件如何持續進化為雲原生的消息服務。
雲原生消息服務
什麼是雲原生
首先來談談什麼是雲原生，雲原生是一個天然适用于雲計算的架構理念，實踐雲原生技術理念的應用可以最大化享受雲計算的技術紅利，包括彈性伸縮、按量付費、無廠商綁定、高SLA等。
應用在實踐雲原生技術理念時一般會遵循四個要素：
- 采取DevOps領域的最佳實踐來管理研發和運維流程。
- 通過CICD工具鍊做到應用的快速疊代和持續傳遞。
- 采取微服務架構。
- 采取容器及相關技術進行應用的托管。
消息服務作為應用的通信基礎設施，是微服務架構應用的核心依賴，也是實踐雲原生的核心設計理念的關鍵技術，通過消息服務能夠讓使用者很容易架構出分布式的、高性能的、彈性的、魯棒的應用程式。消息服務在雲原生的重要性也導緻其極可能成為應用實踐雲原生的阻塞點，是以消息服務的雲原生化是至關重要的。
什麼是雲原生消息服務
先說結論，我們認為雲原生消息服務是雲原生的通信基礎設施。2015年成立的CNCF基金會大範圍推廣了雲原生的技術理念，并提供了一套完整的實踐技術工具集，幫助開發者落地雲原生理念。這套工具集收錄于CNCF雲原生全景圖，其中消息中間件處于應用定義和開發層的Streaming和Messaging類目。
消息中間件在雲原生的應用場景，主要是為微服務和EDA架構提供核心的解耦、異步和削峰的能力，在雲原生全景圖定義的其它層次領域，消息服務還發揮着資料通道、事件驅動、內建與被內建等重要作用。
另外雲原生倡導面向性能設計，基于消息隊列的異步調用能夠顯著降低前端業務的響應時間，提高吞吐量；基于消息隊列還能實作削峰填谷，把慢服務分離到後置鍊路，提升整個業務鍊路的性能。
雲原生消息服務演進方向
雲原生時代對雲服務有着更高的要求，傳統的消息服務在雲原生這個大背景下如何持續進化為雲原生的消息服務，我們認為方向有這麼幾個：
高SLA
雲原生應用将對消息這種雲原生BaaS服務有更高的SLA要求，應用将假設其依賴的雲原生服務具備跟雲一樣的可用性，進而不需要去建裝置份鍊路來提高應用的可用性，降低架構的複雜度。隻有做到與雲一樣的可用性，雲在服務就在，才能稱為真正的雲原生服務。
低成本
在過去，每家公司自建消息中間件叢集，或是自研的、或是開源的，需要投入巨大的研發、運維成本。雲原生時代的消息服務借助Serverless等彈性技術，無需預先Book伺服器資源，無需容量規劃，采取按量付費這種更經濟的模式将大幅度降低成本。
易用性
在雲原生時代，消息服務第一步将進化成為一種所見即所得、開箱即用的服務，易用性極大的提高。接下來，消息服務将以網格的形式觸達更複雜的部署環境，小到IoT裝置，大到自建IDC，都能以跟公有雲同樣易用的方式接入消息服務，且能輕易地滿足雲邊端一體化、跨IDC、跨雲等互通需求，真正成為應用層的通信基礎設施。
多樣性
雲原生消息服務将緻力于建設大而全的消息生态，來涵蓋豐富的業務場景，提供各式各樣的解決方案，進而滿足不同使用者的多樣性需求。阿裡雲消息隊列目前建設了多個子産品線來支撐豐富的業務需求，比如消息隊列RocketMQ，Kafka，微消息隊列等。
标準化
容器鏡像這項雲原生的核心技術輕易地實作了不可變基礎設施，不可變的鏡像消除了IaaS層的差異，讓雲原生應用可以在不同的雲廠商之間随意遷移。但實際上，很多雲服務提供的接入形式并不是标準的，是以依賴這些非标準化雲服務的應用形成了事實上的廠商鎖定，這些應用在運作時是無法完成真正的按需遷移，是以隻能稱為某朵雲上的原生應用，無法稱為真正的雲原生應用。是以，消息服務需要做到标準化，消除使用者關于廠商鎖定的擔憂，目前阿裡雲消息隊列采納了很多社群标準，支援了多種開源的API協定，同時也在打造自己标準化接口。
總結一下，傳統的消息隊列将從高SLA、低成本、易用性、多樣性和标準化幾個方向持續進化為雲原生的消息服務。
雲原生消息三化
談到雲原生，離不開Kubernetes、Serverless以及Service Mesh，接下來為大家分享下我們如何利用K8S社群的生态紅利，如何實踐Serverless和Service Mesh技術理念。
雲原生消息Kubernetes化
Kubernetes項目當下絕對是大紅大紫，在容器編排和應用托管領域絕對的事實标準，整個社群也是生機盎然。是以，必須将我們的消息服務更新為K8S環境開箱即用的服務。
雲原生消息Kubernetes化是指通過自定義CRD資源将有狀态的消息叢集托管至Kubernetes叢集中，充分利用
K8S提供的部署、更新、自愈等能力提高運維效率，同時盡可能享受K8S的社群生态紅利。
我們在RocketMQ開源社群也提供了CRD描述檔案以及相應的Operator實作，通過這套實作，可以快速部署RocketMQ叢集至K8S環境；利用K8S的能力低成本運維RocketMQ叢集；也可以使用雲原生的Prometheus觀察叢集名額。
RocketMQ完成Kubernetes化後，就變成了Kubernetes環境原生可通路的一個消息服務，将給開發者帶來極大的便利性。
同時，在商業化環境，我們也正在依賴Kubeone将消息隊列系列産品完成Kubernetes化。
雲原生消息Serverless化
Serverless最核心的理念是“按需”，雲原生消息Serverless化主要是從兩個次元落地按需的概念。一方面根據業務規模自動化擴縮容執行個體規格、隊列數等邏輯資源；另一方面，根據服務端負載自動化擴縮容計算、存儲等實體資源。
邏輯資源按需擴縮容：
在使用者側，更關心的是消息執行個體提供的邏輯資源是否充足，比如購買的執行個體TPS規格是否足夠，隊列數量是否能滿足擴充性需求。比如一個商業化的MQ執行個體中，可以根據使用者的流量對執行個體規格進行自動的升降配，從2W TPS至10W TPS按需調整；也可以根據使用者分布式消費者的數量規模，對邏輯隊列數量進行動态調整；使用者完全不需要進行容量評估。
實體資源按需擴縮容：
在雲服務開發者側，我們更關心的是如何通過Serverless降低運維成本，避免手動的機器購買、VIP申請、磁盤申請以及叢集擴縮容等。在Kubernetes化完成後，可以很輕易地根據叢集Load等名額自動擴容MQ 實體資源；在叢集縮容的處理上，會比較麻煩，因為每個MQ 節點其實是有狀态的，圖中的某個PV 代表了一個CommitLog，我們在内部通過在ASI上支援PV漂移，在RocketMQ存儲層支援多CommitLog挂載來完成自動化縮容。
雲原生消息Mesh化
Service Mesh出發點是解決微服務架構的網絡問題，将服務之間的通信問題從業務程序中進行剝離，讓業務方更加專注于自身的業務邏輯。 雲原生消息Mesh化将消息的富用戶端能力下沉至Sidecar，将消息的服務發現、負載均衡、流量監控等職責與業務邏輯隔離，在運作時完成透明組裝，同時提供細粒度的消息灰階和治理能力。
目前阿裡雲消息隊列 RocketMQ 是國内第二個成功進入 Service Mesh 官方社群的中間件産品，在進行Envoy适配的過程中推動了Envoy社群加速對on-demand CDS的支援，創新性地使用Pop消費模式來适配Mesh的無狀态網絡模型。
更詳細的Mesh化介紹參考文章：
Apache RocketMQ 的 Service Mesh 開源之旅。
雲原生消息生态
在雲原生消息服務演進方向小節中提到，雲原生消息服務需要大而全的消息生态來覆寫業務方豐富的業務場景，本小節介紹我們在生态建設方面做的一些努力。
雲原生消息産品矩陣
阿裡雲消息産品矩陣包含消息隊列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首選。
在生态建設方面，我們在商業化和開源兩個生态都取得了不錯得成功。
在阿裡雲消息商業化生态中，消息隊列産品線已經支援 11 BU，30+雲産品或者解決方案，有些對使用者是可見的，有些是不可見的，真正做到了雲原生通信基礎設施的定位。
在開源方面，開源RocketMQ已經完成了雲原生技術棧的內建，包括Knative中的事件源，Prometheus的Exporter，K8S的Operator等；也支援了微服務架構Dubbo、SpringCloud以及函數計算架構OpenWhisk；同時開發了很多Connector作為Sink或者Source去連接配接了ELK、Flume、Flink、Hadoop等大資料和資料分析領域的優秀開源産品。
雲原生消息标準
最開始我們就提到标準化是雲原生消息中間件的進化方向之一，我們從兩個次元打磨産品的标準化建設。
社群标準 ：
在消息領域，無論是接口還是協定，社群一直有很多事實上的“标準”，比如Kafka提供的API和協定，JMS API，CloudEvents規範，MQTT中的協定和模型，AMQP的協定和模型等，阿裡雲消息隊列産品線對這些事實标準都提供了相應的接入方式，使用者可以低成本完成遷移上雲。
自建标準 ：
事實上的“标準”如果太多，其實就沒有标準，開源方面一直在推動自建标準
OpenMessaging，OMS将提供六大核心特性：多領域、流、平台無關、标準的Benchmark，面向雲，線路層可插拔。目前，國内有很多雲提供商都接入了OMS标準。
雲原生消息核心競争力
作為雲原生的消息，核心競争力在哪，特别是開源生态愈發蓬勃，使用者可選的解決方案非常多，如何讓使用者選擇我們雲原生的消息服務，我們認為核心競争力主要有這麼幾個。
領先的消息服務能力
阿裡雲的消息服務，在多個方面都具備絕對領先的服務能力。
接入&遷移
整個産品線支撐了多協定、多API、多語言、多終端以及多生态的接入，做到了“0”接入成本，開源或自建使用者都可以無縫上雲；同時全球消息路由也支援跨地域的消息同步，異構的消息遷移同步等。
多租戶
阿裡雲消息服務支援命名空間隔離、标準的通路控制；支援執行個體限流、資源隔離、多租戶的海量堆積。
消息類型
在業務消息領域，阿裡雲消息有多年的業務沉澱，消息類型上支援：普通消息、事務消息、定時消息、順序消息、重試消息以及死信消息等。
消費&治理
在消費和治理領域，雲消息服務支援Pub/Sub模式，廣播/叢集消費模式，消費過程中支援Tag過濾、SQL過濾。在運維時，提供了消息軌迹、消息查詢以及消息回放等治理能力。
服務能力
阿裡雲消息的服務能力是經過多年錘煉的：
- 高可用：核心交易鍊路12年，雙十一10年曆程，在雲上承諾的可用性SLA為99.95%，可靠性8個9。
- 高性能：雙 11 消息收發 TPS 峰值過億，日消息收發總量3萬億；擁有全球最大的業務消息叢集之一。
- 低延遲：在雙 11 萬億級資料洪峰下，消息發送99.996%在毫秒級響應；消息釋出平均響應時間不超過 3 毫秒。
統一的消息核心
阿裡雲消息隊列的另一核心競争力為統一的消息核心，整個消息雲産品簇都建設在統一的RocketMQ核心之上，所有的雲産品提供一緻的底層能力。
RocketMQ 核心主要包含以下幾個子產品：
富用戶端
RocketMQ 提供一個輕量級的富用戶端，暴露Push、Pull以及Pop三種消費模式，同時内置了重試、熔斷等高可用功能，産品簇的衆多用戶端都是通過對核心的富用戶端進行二次開發的。
注冊中心
也就是RocketMQ開發者熟知的NameServer，以簡單可靠的方式提供叢集管理、中繼資料管理、Topic路由和發現等功能，節點無狀态，最終一緻的語義確定NameServer具有超高的可用性。
計算節點
Broker中的計算部分包含一個高性能的傳輸層，以及一個可擴充的RPC架構，以支援各個産品的豐富的業務需求。
存儲引擎
Broker中的核心為存儲引擎，經過多年錘煉的存儲引擎包含幾個核心特點：
- 低延遲讀寫互斥：通過在PageCache層完成消息的讀寫互斥，來大幅度保障寫鍊路的低延遲。
- 日志與索引分離：整個存儲層将消息以Append-Only的方式集中式存儲在CommitLog中，同時以索引派發這種可擴充的方法來支援事務、定時、查詢以及百萬隊列等進階特性。
- 一緻性多副本：提供多套一緻性多副本實作來滿足不同的部署場景和需求，比如Master-Slave架構、基于Raft的Dleger和正在自研的秒級RTO多副本協定。
- 多模存儲：在未來存儲的方式肯定是多樣化的，存儲引擎抽象來統一的存儲接口，并提供了本地塊裝置、雲存儲以及盤古原生存儲等實作。
- 多級存儲：越來越的使用者對消息生命周期有了更高的要求，在過去，消息作為應用開發的中間狀态，往往隻會被存儲數天，通過Deep Storage，将以低成本的方式大幅延長消息的生命周期，将消息轉化為使用者的資料資産，以挖掘更多的諸如消息分析、消息計算需求。
全方面的穩定性建設
穩定性永遠是前面的1，業務發展和創新是後面的0。--叔同
穩定性的重要性是不言而喻的，穩定性是使用者做技術和産品選型的時候考察第一要素，阿裡雲消息隊列在穩定性方面做了全面的建設。
阿裡雲消息隊列主要從以下幾個次元進行穩定性建設：
架構開發
整個系統是面向失敗設計的，除了最核心的元件，所有的外部依賴都是弱依賴；在産品疊代階段，建立了完善的Code Review、單元測試、內建測試、性能測試以及容災測試流程。
變更管理
風險往往來自于變更，我們對變更的要求是可灰階、可監控、可復原以及可降級的。
穩定性防護
限流、降級、容量評估、應急方案、大促保障、故障演練、預案演練、定期風險梳理等都是我們的穩定性防護手段。
體系化巡檢
分為黑盒巡檢和白盒巡檢，黑盒巡檢會站在使用者視角對産品功能進行全方面掃描，包含了50+檢測項；白盒巡檢會自動化檢測JVM運作時名額、核心系統名額、叢集統計名額等，并在名額異常時及時預警。
故障應急
我們建設了一套完整的故障應急流程，從監控報警->故障發生->快速止血->排查根因->故障複盤，整個鍊路都是順暢的。
雲原生消息展望
在消息産品矩陣小節中提到，EventBridge是作為我們下一代的消息産品形态，該産品也即将迎來公測，本章節主要介紹EventBridge的産品定位。
消息與事件
消息和事件是兩種不同形态的抽象，也意味着滿足不同的場景：
消息：消息是比事件更通用的抽象，常用于微服務調用之間的異步解耦，微服務調用之間往往需要等到服務能力不對等時才會去通過消息對服務調用進行異步化改造；消息的内容往往綁定了較強的業務屬性，消息的發送方對消息處理邏輯是有明确的預期的。
事件：事件相對于消息更加具像化，代表了事情的發送、條件和狀态的變化；事件源來自不同的組織和環境，是以事件總線天然需要跨組織；事件源對事件将被如何響應沒有任何預期的，是以采用事件的應用架構是更徹底的解耦，采用事件的應用架構将更加具備可擴充性和靈活性。
EventBridge：中心化事件總線
EventBridge作為我們即将釋出的新産品，其核心能力之一便是提供中心化的事件總線能力。
EventBridge将提供雲産品之間、雲應用之間、雲産品與雲應用之間，以及它們與SaaS提供商之間的內建與被內建能力。
在中心化事件總線中有幾個重要的概念：
事件源：事件源可以是阿裡雲服務，比如對象存儲、ECS、資料庫等，也可以是使用者的應用程式或者第三方SaaS，這些事件源将提供豐富的業務事件、雲産品運維事件、事件流等。
資源管理：EventBridge内部将提供總線管理、規則管理以及Schema管理，提供全托管的事件服務。
事件處理：EventBridge将提供事件傳輸、事件過濾、事件路由、事件查詢、回放、重試、追蹤等核心的事件處理能力。
事件目标：事件最終投遞的目标服務包羅萬象，既可以觸發一個Serverless的Function，也可以投遞至消息隊列其它産品，運維事件還可以通過短信、郵件以及日志服務觸達運維人員。
EventBridge：EDA服務架構
EventBridge另一個核心能力是EDA服務架構。微服務有兩種驅動方式：請求驅動和事件驅動。在請求驅動模式下，服務之間調用是同步調用，這種模式優點是延遲低，但是服務之間的耦合是比較重的，相比之下事件驅動有幾個優點：
- 異步化，所有的調用通過事件異步化驅動，服務之間沒有顯示的依賴關系。
- 松耦合，通過事件總線解除所有服務之間的耦合關系。
- 可擴充，可擴充能力非常強，基于總線和事件Schema完成業務的擴充非常簡單。
- 零改造，請求驅動的微服務，在遇到服務之間能力不對等時，往往需要進行基于消息異步化改造，避免慢調用、逾時等異常情況在整個分布式叢集觸發雪崩效應。基于事件驅動的微服務天然具備力異步、削峰等能力，是以在業務規模擴大時不會帶來額外的改造成本。
上圖是設想的一個采用EDA的應用架構圖：
- 基于EventBridge可以實踐流行的CQRS和Event Souring範式。
- 可以從IoT端裝置上接入Event Streaming。
- 基于事件驅動的微服務程式也可以通過API網關暴露傳統的Request請求方式，供前端通路。
- EventBridge還可以連接配接第三方SaaS提供商，雲提供商，不同組織的觀察者，與分布式的事件微服務內建。
- 事件驅動和請求驅動是相輔相成的關系，通過統一Event APIs和REST APIs打通事件驅動的微服務與請求驅動的微服務，來進行架構上的融合與統一。
EDA成熟度模型
我們通過Gartner報告總結的EDA成熟度模型，展望以下EDA架構的未來：
- Incidental：偶發性地使用事件通知機制來進行一些狀态的捕獲，沒有明确的事件處理政策。
- Brokered：提供托管的事件代理服務，組織中部分應用開始采用基于消息或者事件的異步化架構。
- Centralized：以戰略的形式提出中心化的EDA解決方案，有專門的組織團隊提供EDA實作，EDA架構開始廣泛被采用。
- Advanced：EDA架構開始觸達更多的業務領域，比如流計算，資料分析，AI，以及API市場等，跨組織的事件生态開始形成并進行擴張。
- Pervasive：事件變得無處不在，龐大的事件生态形成，組織間的隔離被事件徹底打通，企業的關鍵業務都将采取EDA架構；事件驅動與請求驅動兩個生态完成融合。
總結
阿裡雲消息團隊在EDA領域的探索目前是處于第三個階段，未來還有很長的路要走。
加入我們
雲原生消息中間件團隊招聘中，這裡有足夠多的業務場景、足夠大的消息生态、足夠深的分布式技術等着大家前來探索，有興趣的同學可以通過郵件溝通：
技術崗請投遞：[email protected]
産品崗請投遞：[email protected]
作者資訊：周新宇（花名：塵央），阿裡雲技術專家，Apache RocketMQ PMC Member/Committer，在消息和雲原生領域有多年的研發經驗，目前在阿裡雲消息中間件團隊從事 RocketMQ 産品的研發工作。