Photo @ Julien Riedel
文 | 塵央
引言
本文以一張?jiān)七M(jìn)化歷史圖開場，來談?wù)勗圃鷷r(shí)代消息中間件的演進(jìn)路線，但本文絕對不是“開局一張圖，內(nèi)容全靠編”。
從虛擬化技術(shù)誕生以來，IaaS/PaaS/SaaS 概念陸續(xù)被提了出來，各種容器技術(shù)層出不窮。到 2015 年， Cloud Native 概念應(yīng)運(yùn)而生，一時(shí)間，各種云廠商，云服務(wù)以及云應(yīng)用都加上了“云原生”前綴。
我們也一直在思考，傳統(tǒng)的消息中間件需要做些什么才能加上云原生這個(gè)修飾詞，這也是本文探討的主題：傳統(tǒng)的消息中間件如何持續(xù)進(jìn)化為云原生的消息服務(wù)。
首先來談?wù)勈裁词窃圃圃且粋€(gè)天然適用于云計(jì)算的架構(gòu)理念，實(shí)踐云原生技術(shù)理念的應(yīng)用可以最大化享受云計(jì)算的技術(shù)紅利，包括彈性伸縮、按量付費(fèi)、無廠商綁定、高 SLA 等。
應(yīng)用在實(shí)踐云原生技術(shù)理念時(shí)一般會遵循四個(gè)要素：
消息服務(wù)作為應(yīng)用的通信基礎(chǔ)設(shè)施，是微服務(wù)架構(gòu)應(yīng)用的核心依賴，也是實(shí)踐云原生的核心設(shè)計(jì)理念的關(guān)鍵技術(shù)，通過消息服務(wù)能夠讓用戶很容易架構(gòu)出分布式的、高性能的、彈性的、魯棒的應(yīng)用程序。消息服務(wù)在云原生的重要性也導(dǎo)致其極可能成為應(yīng)用實(shí)踐云原生的阻塞點(diǎn)，所以消息服務(wù)的云原生化是至關(guān)重要的。
先說結(jié)論，我們認(rèn)為云原生消息服務(wù)是云原生的通信基礎(chǔ)設(shè)施。2015 年成立的 CNCF 基金會大范圍推廣了云原生的技術(shù)理念，并提供了一套完整的實(shí)踐技術(shù)工具集，幫助開發(fā)者落地云原生理念。這套工具集收錄于 CNCF 云原生全景圖，其中消息中間件處于應(yīng)用定義和開發(fā)層的 Streaming 和 Messaging 類目。
消息中間件在云原生的應(yīng)用場景，主要是為微服務(wù)和EDA架構(gòu)提供核心的解耦、異步和削峰的能力，在云原生全景圖定義的其它層次領(lǐng)域，消息服務(wù)還發(fā)揮著數(shù)據(jù)通道、事件驅(qū)動(dòng)、集成與被集成等重要作用。
另外云原生倡導(dǎo)面向性能設(shè)計(jì)，基于消息隊(duì)列的異步調(diào)用能夠顯著降低前端業(yè)務(wù)的響應(yīng)時(shí)間，提高吞吐量；基于消息隊(duì)列還能實(shí)現(xiàn)削峰填谷，把慢服務(wù)分離到后置鏈路，提升整個(gè)業(yè)務(wù)鏈路的性能。
云原生時(shí)代對云服務(wù)有著更高的要求，傳統(tǒng)的消息服務(wù)在云原生這個(gè)大背景下如何持續(xù)進(jìn)化為云原生的消息服務(wù)，我們認(rèn)為方向有這么幾個(gè)：
高 SLA
云原生應(yīng)用將對消息這種云原生 BaaS 服務(wù)有更高的SLA要求，應(yīng)用將假設(shè)其依賴的云原生服務(wù)具備跟云一樣的可用性，從而不需要去建設(shè)備份鏈路來提高應(yīng)用的可用性，降低架構(gòu)的復(fù)雜度。只有做到與云一樣的可用性，云在服務(wù)就在，才能稱為真正的云原生服務(wù)。
低成本
在過去，每家公司自建消息中間件集群，或是自研的、或是開源的，需要投入巨大的研發(fā)、運(yùn)維成本。云原生時(shí)代的消息服務(wù)借助 Serverless 等彈性技術(shù)，無需預(yù)先Book服務(wù)器資源，無需容量規(guī)劃，采取按量付費(fèi)這種更經(jīng)濟(jì)的模式將大幅度降低成本。
易用性
在云原生時(shí)代，消息服務(wù)第一步將進(jìn)化成為一種所見即所得、開箱即用的服務(wù)，易用性極大的提高。接下來，消息服務(wù)將以網(wǎng)格的形式觸達(dá)更復(fù)雜的部署環(huán)境，小到IoT設(shè)備，大到自建 IDC ，都能以跟公有云同樣易用的方式接入消息服務(wù)，且能輕易地滿足云邊端一體化、跨 IDC 、跨云等互通需求，真正成為應(yīng)用層的通信基礎(chǔ)設(shè)施。
多樣性
云原生消息服務(wù)將致力于建設(shè)大而全的消息生態(tài)，來涵蓋豐富的業(yè)務(wù)場景，提供各式各樣的解決方案，從而滿足不同用戶的多樣性需求。阿里云消息隊(duì)列目前建設(shè)了多個(gè)子產(chǎn)品線來支撐豐富的業(yè)務(wù)需求，比如消息隊(duì)列 RocketMQ ，Kafka ，微消息隊(duì)列等。
標(biāo)準(zhǔn)化
容器鏡像這項(xiàng)云原生的核心技術(shù)輕易地實(shí)現(xiàn)了不可變基礎(chǔ)設(shè)施，不可變的鏡像消除了 IaaS 層的差異，讓云原生應(yīng)用可以在不同的云廠商之間隨意遷移。但實(shí)際上，很多云服務(wù)提供的接入形式并不是標(biāo)準(zhǔn)的，所以依賴這些非標(biāo)準(zhǔn)化云服務(wù)的應(yīng)用形成了事實(shí)上的廠商鎖定，這些應(yīng)用在運(yùn)行時(shí)是無法完成真正的按需遷移，所以只能稱為某朵云上的原生應(yīng)用，無法稱為真正的云原生應(yīng)用。因此，消息服務(wù)需要做到標(biāo)準(zhǔn)化，消除用戶關(guān)于廠商鎖定的擔(dān)憂，目前阿里云消息隊(duì)列采納了很多社區(qū)標(biāo)準(zhǔn)，支持了多種開源的 API 協(xié)議，同時(shí)也在打造自己標(biāo)準(zhǔn)化接口。
總結(jié)一下，傳統(tǒng)的消息隊(duì)列將從高 SLA 、低成本、易用性、多樣性和標(biāo)準(zhǔn)化幾個(gè)方向持續(xù)進(jìn)化為云原生的消息服務(wù)。
談到云原生，離不開 Kubernetes、Serverless 以及 Service Mesh ，接下來為大家分享下我們?nèi)绾卫?K8s 社區(qū)的生態(tài)紅利，如何實(shí)踐 Serverless 和 Service Mesh 技術(shù)理念。
Kubernetes 項(xiàng)目當(dāng)下絕對是大紅大紫，在容器編排和應(yīng)用托管領(lǐng)域絕對的事實(shí)標(biāo)準(zhǔn)，整個(gè)社區(qū)也是生機(jī)盎然。所以，必須將我們的消息服務(wù)升級為 K8s 環(huán)境開箱即用的服務(wù)。
云原生消息 Kubernetes 化是指通過自定義 CRD 資源將有狀態(tài)的消息集群托管至 Kubernetes 集群中，充分利用。
K8s 提供的部署、升級、自愈等能力提高運(yùn)維效率，同時(shí)盡可能享受 K8s 的社區(qū)生態(tài)紅利。
我們在 RocketMQ 開源社區(qū)也提供了 CRD 描述文件以及相應(yīng)的 Operator 實(shí)現(xiàn)，通過這套實(shí)現(xiàn)，可以快速部署 RocketMQ 集群至 K8s 環(huán)境；利用 K8s 的能力低成本運(yùn)維RocketMQ 集群；也可以使用云原生的 Prometheus 觀察集群指標(biāo)。
RocketMQ 完成 Kubernetes 化后，就變成了 Kubernetes 環(huán)境原生可訪問的一個(gè)消息服務(wù)，將給開發(fā)者帶來極大的便利性。
同時(shí)，在商業(yè)化環(huán)境，我們也正在依賴 Kubeone 將消息隊(duì)列系列產(chǎn)品完成 Kubernetes 化。
Serverless 最核心的理念是“按需”，云原生消息 Serverless 化主要是從兩個(gè)維度落地按需的概念。一方面根據(jù)業(yè)務(wù)規(guī)模自動(dòng)化擴(kuò)縮容實(shí)例規(guī)格、隊(duì)列數(shù)等邏輯資源；另一方面，根據(jù)服務(wù)端負(fù)載自動(dòng)化擴(kuò)縮容計(jì)算、存儲等物理資源。
邏輯資源按需擴(kuò)縮容：
在用戶側(cè)，更關(guān)心的是消息實(shí)例提供的邏輯資源是否充足，比如購買的實(shí)例 TPS 規(guī)格是否足夠，隊(duì)列數(shù)量是否能滿足擴(kuò)展性需求。比如一個(gè)商業(yè)化的 MQ 實(shí)例中，可以根據(jù)用戶的流量對實(shí)例規(guī)格進(jìn)行自動(dòng)的升降配，從 2W TPS 至 10W TPS 按需調(diào)整；也可以根據(jù)用戶分布式消費(fèi)者的數(shù)量規(guī)模，對邏輯隊(duì)列數(shù)量進(jìn)行動(dòng)態(tài)調(diào)整；用戶完全不需要進(jìn)行容量評估。
物理資源按需擴(kuò)縮容：
在云服務(wù)開發(fā)者側(cè)，我們更關(guān)心的是如何通過 Serverless 降低運(yùn)維成本，避免手動(dòng)的機(jī)器購買、VIP 申請、磁盤申請以及集群擴(kuò)縮容等。在 Kubernetes 化完成后，可以很輕易地根據(jù)集群 Load 等指標(biāo)自動(dòng)擴(kuò)容 MQ 物理資源；在集群縮容的處理上，會比較麻煩，因?yàn)槊總€(gè) MQ 節(jié)點(diǎn)其實(shí)是有狀態(tài)的，圖中的某個(gè) PV 代表了一個(gè) CommitLog ，我們在內(nèi)部通過在 ASI 上支持 PV 漂移，在 RocketMQ 存儲層支持多 CommitLog 掛載來完成自動(dòng)化縮容。
Service Mesh 出發(fā)點(diǎn)是解決微服務(wù)架構(gòu)的網(wǎng)絡(luò)問題，將服務(wù)之間的通信問題從業(yè)務(wù)進(jìn)程中進(jìn)行剝離，讓業(yè)務(wù)方更加專注于自身的業(yè)務(wù)邏輯。云原生消息 Mesh 化將消息的富客戶端能力下沉至 Sidecar ，將消息的服務(wù)發(fā)現(xiàn)、負(fù)載均衡、流量監(jiān)控等職責(zé)與業(yè)務(wù)邏輯隔離，在運(yùn)行時(shí)完成透明組裝，同時(shí)提供細(xì)粒度的消息灰度和治理能力。
目前阿里云消息隊(duì)列 RocketMQ 是國內(nèi)第二個(gè)成功進(jìn)入 Service Mesh 官方社區(qū)的中間件產(chǎn)品，在進(jìn)行 Envoy 適配的過程中推動(dòng)了Envoy社區(qū)加速對 on-demand CDS 的支持，創(chuàng)新性地使用 Pop 消費(fèi)模式來適配 Mesh 的無狀態(tài)網(wǎng)絡(luò)模型。
在云原生消息服務(wù)演進(jìn)方向小節(jié)中提到，云原生消息服務(wù)需要大而全的消息生態(tài)來覆蓋業(yè)務(wù)方豐富的業(yè)務(wù)場景，本小節(jié)介紹我們在生態(tài)建設(shè)方面做的一些努力。
阿里云消息產(chǎn)品矩陣包含消息隊(duì)列 RocketMQ、Kafka、AMQP、微消息隊(duì)列 MQTT、消息通知服務(wù) MNS 以及即將發(fā)布的 EventBridge ，涵蓋互聯(lián)網(wǎng)、大數(shù)據(jù)、移動(dòng)互聯(lián)網(wǎng)、物聯(lián)網(wǎng)等領(lǐng)域的業(yè)務(wù)場景，為云原生客戶提供一站式消息解決方案。
在生態(tài)建設(shè)方面，我們在商業(yè)化和開源兩個(gè)生態(tài)都取得了不錯(cuò)得成功。
在阿里云消息商業(yè)化生態(tài)中，消息隊(duì)列產(chǎn)品線已經(jīng)支持 11 BU，30+云產(chǎn)品或者解決方案，有些對用戶是可見的，有些是不可見的，真正做到了云原生通信基礎(chǔ)設(shè)施的定位。
在開源方面，開源 RocketMQ 已經(jīng)完成了云原生技術(shù)棧的集成，包括Knative中的事件源，Prometheus 的 Exporter，K8s 的 Operator等；也支持了微服務(wù)框架 Dubbo、SpringCloud 以及函數(shù)計(jì)算框架 OpenWhisk ；同時(shí)開發(fā)了很多 Connector 作為 Sink 或者 Source 去連接了 ELK、Flume、Flink、Hadoop 等大數(shù)據(jù)和數(shù)據(jù)分析領(lǐng)域的優(yōu)秀開源產(chǎn)品。
最開始我們就提到標(biāo)準(zhǔn)化是云原生消息中間件的進(jìn)化方向之一，我們從兩個(gè)維度打磨產(chǎn)品的標(biāo)準(zhǔn)化建設(shè)。
社區(qū)標(biāo)準(zhǔn) ：
在消息領(lǐng)域，無論是接口還是協(xié)議，社區(qū)一直有很多事實(shí)上的“標(biāo)準(zhǔn)”，比如 Kafka 提供的 API 和協(xié)議，JMS API，CloudEvents 規(guī)范，MQTT 中的協(xié)議和模型，AMQP 的協(xié)議和模型等，阿里云消息隊(duì)列產(chǎn)品線對這些事實(shí)標(biāo)準(zhǔn)都提供了相應(yīng)的接入方式，用戶可以低成本完成遷移上云。
自建標(biāo)準(zhǔn) ：
事實(shí)上的“標(biāo)準(zhǔn)”如果太多，其實(shí)就沒有標(biāo)準(zhǔn)，開源方面一直在推動(dòng)自建標(biāo)準(zhǔn) OpenMessaging，OMS 將提供六大核心特性：多領(lǐng)域、流、平臺無關(guān)、標(biāo)準(zhǔn)的 Benchmark ，面向云，線路層可插拔。目前，國內(nèi)有很多云提供商都接入了 OMS 標(biāo)準(zhǔn)。
OpenMessaging：
https://github.com/openmessaging
作為云原生的消息，核心競爭力在哪，特別是開源生態(tài)愈發(fā)蓬勃，用戶可選的解決方案非常多，如何讓用戶選擇我們云原生的消息服務(wù)，我們認(rèn)為核心競爭力主要有這么幾個(gè)。
阿里云的消息服務(wù)，在多個(gè)方面都具備絕對領(lǐng)先的服務(wù)能力。
接入&遷移
整個(gè)產(chǎn)品線支撐了多協(xié)議、多API、多語言、多終端以及多生態(tài)的接入，做到了“0”接入成本，開源或自建用戶都可以無縫上云；同時(shí)全球消息路由也支持跨地域的消息同步，異構(gòu)的消息遷移同步等。
多租戶
阿里云消息服務(wù)支持命名空間隔離、標(biāo)準(zhǔn)的訪問控制；支持實(shí)例限流、資源隔離、多租戶的海量堆積。
消息類型
在業(yè)務(wù)消息領(lǐng)域，阿里云消息有多年的業(yè)務(wù)沉淀，消息類型上支持：普通消息、事務(wù)消息、定時(shí)消息、順序消息、重試消息以及死信消息等。
消費(fèi)&治理
在消費(fèi)和治理領(lǐng)域，云消息服務(wù)支持 Pub/Sub 模式，廣播/集群消費(fèi)模式，消費(fèi)過程中支持 Tag 過濾、 SQL 過濾。在運(yùn)維時(shí)，提供了消息軌跡、消息查詢以及消息回放等治理能力。
服務(wù)能力
阿里云消息的服務(wù)能力是經(jīng)過多年錘煉的：
阿里云消息隊(duì)列的另一核心競爭力為統(tǒng)一的消息內(nèi)核，整個(gè)消息云產(chǎn)品簇都建設(shè)在統(tǒng)一的 RocketMQ 內(nèi)核之上，所有的云產(chǎn)品提供一致的底層能力。
RocketMQ 內(nèi)核主要包含以下幾個(gè)模塊：
富客戶端
RocketMQ 提供一個(gè)輕量級的富客戶端，暴露 Push、Pull 以及 Pop 三種消費(fèi)模式，同時(shí)內(nèi)置了重試、熔斷等高可用功能，產(chǎn)品簇的眾多客戶端都是通過對內(nèi)核的富客戶端進(jìn)行二次開發(fā)的。
注冊中心
也就是 RocketMQ 開發(fā)者熟知的 NameServer ，以簡單可靠的方式提供集群管理、元數(shù)據(jù)管理、Topic 路由和發(fā)現(xiàn)等功能，節(jié)點(diǎn)無狀態(tài)，最終一致的語義確保 NameServer 具有超高的可用性。
計(jì)算節(jié)點(diǎn)
Broker 中的計(jì)算部分包含一個(gè)高性能的傳輸層，以及一個(gè)可擴(kuò)展的 RPC 框架，以支持各個(gè)產(chǎn)品的豐富的業(yè)務(wù)需求。
存儲引擎
Broker 中的核心為存儲引擎，經(jīng)過多年錘煉的存儲引擎包含幾個(gè)核心特點(diǎn)：
穩(wěn)定性永遠(yuǎn)是前面的1，業(yè)務(wù)發(fā)展和創(chuàng)新是后面的0。--叔同
穩(wěn)定性的重要性是不言而喻的，穩(wěn)定性是用戶做技術(shù)和產(chǎn)品選型的時(shí)候考察第一要素，阿里云消息隊(duì)列在穩(wěn)定性方面做了全面的建設(shè)。
阿里云消息隊(duì)列主要從以下幾個(gè)維度進(jìn)行穩(wěn)定性建設(shè)：
架構(gòu)開發(fā)
整個(gè)系統(tǒng)是面向失敗設(shè)計(jì)的，除了最核心的組件，所有的外部依賴都是弱依賴；在產(chǎn)品迭代階段，建立了完善的 Code Review 、單元測試、集成測試、性能測試以及容災(zāi)測試流程。
變更管理
風(fēng)險(xiǎn)往往來自于變更，我們對變更的要求是可灰度、可監(jiān)控、可回滾以及可降級的。
穩(wěn)定性防護(hù)
限流、降級、容量評估、應(yīng)急方案、大促保障、故障演練、預(yù)案演練、定期風(fēng)險(xiǎn)梳理等都是我們的穩(wěn)定性防護(hù)手段。
體系化巡檢
分為黑盒巡檢和白盒巡檢，黑盒巡檢會站在用戶視角對產(chǎn)品功能進(jìn)行全方面掃描，包含了 50+ 檢測項(xiàng)；白盒巡檢會自動(dòng)化檢測 JVM 運(yùn)行時(shí)指標(biāo)、內(nèi)核系統(tǒng)指標(biāo)、集群統(tǒng)計(jì)指標(biāo)等，并在指標(biāo)異常時(shí)及時(shí)預(yù)警。
故障應(yīng)急
我們建設(shè)了一套完整的故障應(yīng)急流程，從監(jiān)控報(bào)警->故障發(fā)生->快速止血->排查根因->故障復(fù)盤，整個(gè)鏈路都是順暢的。
在消息產(chǎn)品矩陣小節(jié)中提到， EventBridge 是作為我們下一代的消息產(chǎn)品形態(tài)，該產(chǎn)品也即將迎來公測，本章節(jié)主要介紹 EventBridge 的產(chǎn)品定位。
消息和事件是兩種不同形態(tài)的抽象，也意味著滿足不同的場景：
消息：消息是比事件更通用的抽象，常用于微服務(wù)調(diào)用之間的異步解耦，微服務(wù)調(diào)用之間往往需要等到服務(wù)能力不對等時(shí)才會去通過消息對服務(wù)調(diào)用進(jìn)行異步化改造；消息的內(nèi)容往往綁定了較強(qiáng)的業(yè)務(wù)屬性，消息的發(fā)送方對消息處理邏輯是有明確的預(yù)期的。
事件：事件相對于消息更加具像化，代表了事情的發(fā)送、條件和狀態(tài)的變化；事件源來自不同的組織和環(huán)境，所以事件總線天然需要跨組織；事件源對事件將被如何響應(yīng)沒有任何預(yù)期的，所以采用事件的應(yīng)用架構(gòu)是更徹底的解耦，采用事件的應(yīng)用架構(gòu)將更加具備可擴(kuò)展性和靈活性。
EventBridge 作為我們即將發(fā)布的新產(chǎn)品，其核心能力之一便是提供中心化的事件總線能力。
EventBridge 將提供云產(chǎn)品之間、云應(yīng)用之間、云產(chǎn)品與云應(yīng)用之間，以及它們與 SaaS 提供商之間的集成與被集成能力。
在中心化事件總線中有幾個(gè)重要的概念：
事件源：事件源可以是阿里云服務(wù)，比如對象存儲、ECS、數(shù)據(jù)庫等，也可以是用戶的應(yīng)用程序或者第三方 SaaS ，這些事件源將提供豐富的業(yè)務(wù)事件、云產(chǎn)品運(yùn)維事件、事件流等。
資源管理：EventBridge 內(nèi)部將提供總線管理、規(guī)則管理以及 Schema 管理，提供全托管的事件服務(wù)。
事件處理：EventBridge 將提供事件傳輸、事件過濾、事件路由、事件查詢、回放、重試、追蹤等核心的事件處理能力。
事件目標(biāo)：事件最終投遞的目標(biāo)服務(wù)包羅萬象，既可以觸發(fā)一個(gè) Serverless 的 Function ，也可以投遞至消息隊(duì)列其它產(chǎn)品，運(yùn)維事件還可以通過短信、郵件以及日志服務(wù)觸達(dá)運(yùn)維人員。
EventBridge 另一個(gè)核心能力是 EDA 服務(wù)框架。微服務(wù)有兩種驅(qū)動(dòng)方式：請求驅(qū)動(dòng)和事件驅(qū)動(dòng)。在請求驅(qū)動(dòng)模式下，服務(wù)之間調(diào)用是同步調(diào)用，這種模式優(yōu)點(diǎn)是延遲低，但是服務(wù)之間的耦合是比較重的，相比之下事件驅(qū)動(dòng)有幾個(gè)優(yōu)點(diǎn)：
上圖是設(shè)想的一個(gè)采用 EDA 的應(yīng)用架構(gòu)圖：
我們通過 Gartner 報(bào)告總結(jié)的 EDA 成熟度模型，展望以下 EDA 架構(gòu)的未來：
阿里云消息團(tuán)隊(duì)在 EDA 領(lǐng)域的探索目前是處于第三個(gè)階段，未來還有很長的路要走。
加入我們
云原生消息中間件團(tuán)隊(duì)招聘中，這里有足夠多的業(yè)務(wù)場景、足夠大的消息生態(tài)、足夠深的分布式技術(shù)等著大家前來探索，有興趣的同學(xué)可以通過郵件溝通：
技術(shù)崗請投遞：xinyuzhou.zxy@alibaba-inc.com
產(chǎn)品崗請投遞：manhong.yqd@alibaba-inc.com
作者信息：
周新宇（花名：塵央），阿里云技術(shù)專家，Apache RocketMQ PMC Member/Committer，在消息和云原生領(lǐng)域有多年的研發(fā)經(jīng)驗(yàn)，目前在阿里云消息中間件團(tuán)隊(duì)從事 RocketMQ 產(chǎn)品的研發(fā)工作。
