雲原生時代消息中間件的演進路線

時間 2020-06-09

標籤原生時代消息中間件演進路線简体版

原文原文鏈接

引言前端

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

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

咱們也一直在思考，傳統的消息中間件須要作些什麼才能加上雲原生這個修飾詞，這也是本文探討的主題：傳統的消息中間件如何持續進化爲雲原生的消息服務。數據庫

雲原生消息服務服務器

什麼是雲原生網絡

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

應用在實踐雲原生技術理念時通常會遵循四個要素：負載均衡

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

消息服務做爲應用的通訊基礎設施，是微服務架構應用的核心依賴，也是實踐雲原生的核心設計理念的關鍵技術，經過消息服務可以讓用戶很容易架構出分佈式的、高性能的、彈性的、魯棒的應用程序。消息服務在雲原生的重要性也致使其很可能成爲應用實踐雲原生的阻塞點，因此消息服務的雲原生化是相當重要的。框架

什麼是雲原生消息服務less

先說結論，咱們認爲雲原生消息服務是雲原生的通訊基礎設施。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的應用架構圖：