云原生時(shí)代消息中間件的演進(jìn)路線

阿里巴巴中間件

文  |  塵央

引言

---

本文以一張?jiān)七M(jìn)化歷史圖開(kāi)場(chǎng)，來(lái)談?wù)勗圃鷷r(shí)代消息中間件的演進(jìn)路線，但本文絕對(duì)不是“開(kāi)局一張圖，內(nèi)容全靠編”。 

從虛擬化技術(shù)誕生以來(lái)，IaaS/PaaS/SaaS 概念陸續(xù)被提了出來(lái)，各種容器技術(shù)層出不窮。到 2015 年， Cloud Native 概念應(yīng)運(yùn)而生，一時(shí)間，各種云廠商，云服務(wù)以及云應(yīng)用都加上了“云原生”前綴。
我們也一直在思考，傳統(tǒng)的消息中間件需要做些什么才能加上云原生這個(gè)修飾詞，這也是本文探討的主題：傳統(tǒng)的消息中間件如何持續(xù)進(jìn)化為云原生的消息服務(wù)。

云原生消息服務(wù)

---

什么是云原生

 
首先來(lái)談?wù)勈裁词窃圃?，云原生是一個(gè)天然適用于云計(jì)算的架構(gòu)理念，實(shí)踐云原生技術(shù)理念的應(yīng)用可以最大化享受云計(jì)算的技術(shù)紅利，包括彈性伸縮、按量付費(fèi)、無(wú)廠商綁定、高 SLA 等。
應(yīng)用在實(shí)踐云原生技術(shù)理念時(shí)一般會(huì)遵循四個(gè)要素：

• 采取 DevOps 領(lǐng)域的最佳實(shí)踐來(lái)管理研發(fā)和運(yùn)維流程。
• 通過(guò) CICD 工具鏈做到應(yīng)用的快速迭代和持續(xù)交付。
• 采取微服務(wù)架構(gòu)。
• 采取容器及相關(guān)技術(shù)進(jìn)行應(yīng)用的托管。

消息服務(wù)作為應(yīng)用的通信基礎(chǔ)設(shè)施，是微服務(wù)架構(gòu)應(yīng)用的核心依賴，也是實(shí)踐云原生的核心設(shè)計(jì)理念的關(guān)鍵技術(shù)，通過(guò)消息服務(wù)能夠讓用戶很容易架構(gòu)出分布式的、高性能的、彈性的、魯棒的應(yīng)用程序。消息服務(wù)在云原生的重要性也導(dǎo)致其極可能成為應(yīng)用實(shí)踐云原生的阻塞點(diǎn)，所以消息服務(wù)的云原生化是至關(guān)重要的。

什么是云原生消息服務(wù)

 
先說(shuō)結(jié)論，我們認(rèn)為云原生消息服務(wù)是云原生的通信基礎(chǔ)設(shè)施。2015 年成立的 CNCF 基金會(huì)大范圍推廣了云原生的技術(shù)理念，并提供了一套完整的實(shí)踐技術(shù)工具集，幫助開(kāi)發(fā)者落地云原生理念。這套工具集收錄于 CNCF 云原生全景圖，其中消息中間件處于應(yīng)用定義和開(kāi)發(fā)層的 Streaming 和 Messaging 類目。
消息中間件在云原生的應(yīng)用場(chǎ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ù)鏈路的性能。

云原生消息服務(wù)演進(jìn)方向

 
云原生時(shí)代對(duì)云服務(wù)有著更高的要求，傳統(tǒng)的消息服務(wù)在云原生這個(gè)大背景下如何持續(xù)進(jìn)化為云原生的消息服務(wù)，我們認(rèn)為方向有這么幾個(gè)：
高 SLA 云原生應(yīng)用將對(duì)消息這種云原生 BaaS 服務(wù)有更高的SLA要求，應(yīng)用將假設(shè)其依賴的云原生服務(wù)具備跟云一樣的可用性，從而不需要去建設(shè)備份鏈路來(lái)提高應(yīng)用的可用性，降低架構(gòu)的復(fù)雜度。只有做到與云一樣的可用性，云在服務(wù)就在，才能稱為真正的云原生服務(wù)。
低成本 在過(guò)去，每家公司自建消息中間件集群，或是自研的、或是開(kāi)源的，需要投入巨大的研發(fā)、運(yùn)維成本。云原生時(shí)代的消息服務(wù)借助 Serverless 等彈性技術(shù)，無(wú)需預(yù)先Book服務(wù)器資源，無(wú)需容量規(guī)劃，采取按量付費(fèi)這種更經(jīng)濟(jì)的模式將大幅度降低成本。
易用性
在云原生時(shí)代，消息服務(wù)第一步將進(jìn)化成為一種所見(jiàn)即所得、開(kāi)箱即用的服務(wù)，易用性極大的提高。接下來(lái)，消息服務(wù)將以網(wǎng)格的形式觸達(dá)更復(fù)雜的部署環(huán)境，小到IoT設(shè)備，大到自建 IDC ，都能以跟公有云同樣易用的方式接入消息服務(wù)，且能輕易地滿足云邊端一體化、跨 IDC 、跨云等互通需求，真正成為應(yīng)用層的通信基礎(chǔ)設(shè)施。
多樣性 云原生消息服務(wù)將致力于建設(shè)大而全的消息生態(tài)，來(lái)涵蓋豐富的業(yè)務(wù)場(chǎng)景，提供各式各樣的解決方案，從而滿足不同用戶的多樣性需求。阿里云消息隊(duì)列目前建設(shè)了多個(gè)子產(chǎn)品線來(lái)支撐豐富的業(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í)是無(wú)法完成真正的按需遷移，所以只能稱為某朵云上的原生應(yīng)用，無(wú)法稱為真正的云原生應(yīng)用。因此，消息服務(wù)需要做到標(biāo)準(zhǔn)化，消除用戶關(guān)于廠商鎖定的擔(dān)憂，目前阿里云消息隊(duì)列采納了很多社區(qū)標(biāo)準(zhǔn)，支持了多種開(kāi)源的 API 協(xié)議，同時(shí)也在打造自己標(biāo)準(zhǔn)化接口。
總結(jié)一下，傳統(tǒng)的消息隊(duì)列將從高 SLA 、低成本、易用性、多樣性和標(biāo)準(zhǔn)化幾個(gè)方向持續(xù)進(jìn)化為云原生的消息服務(wù)。

云原生消息三化

---

談到云原生，離不開(kāi) Kubernetes、Serverless 以及 Service Mesh ，接下來(lái)為大家分享下我們?nèi)绾卫?K8s 社區(qū)的生態(tài)紅利，如何實(shí)踐 Serverless 和 Service Mesh 技術(shù)理念。

云原生消息 Kubernetes 化

Kubernetes 項(xiàng)目當(dāng)下絕對(duì)是大紅大紫，在容器編排和應(yīng)用托管領(lǐng)域絕對(duì)的事實(shí)標(biāo)準(zhǔn)，整個(gè)社區(qū)也是生機(jī)盎然。所以，必須將我們的消息服務(wù)升級(jí)為 K8s 環(huán)境開(kāi)箱即用的服務(wù)。  
云原生消息 Kubernetes 化是指通過(guò)自定義 CRD 資源將有狀態(tài)的消息集群托管至 Kubernetes 集群中，充分利用。
K8s 提供的部署、升級(jí)、自愈等能力提高運(yùn)維效率，同時(shí)盡可能享受 K8s 的社區(qū)生態(tài)紅利。
我們?cè)?RocketMQ 開(kāi)源社區(qū)也提供了 CRD 描述文件以及相應(yīng)的 Operator 實(shí)現(xiàn)，通過(guò)這套實(shí)現(xiàn)，可以快速部署 RocketMQ 集群至 K8s 環(huán)境；利用 K8s 的能力低成本運(yùn)維RocketMQ 集群；也可以使用云原生的 Prometheus 觀察集群指標(biāo)。
RocketMQ 完成 Kubernetes 化后，就變成了 Kubernetes 環(huán)境原生可訪問(wèn)的一個(gè)消息服務(wù)，將給開(kāi)發(fā)者帶來(lái)極大的便利性。
同時(shí)，在商業(yè)化環(huán)境，我們也正在依賴 Kubeone 將消息隊(duì)列系列產(chǎn)品完成 Kubernetes 化。

云原生消息 Serverless 化

Serverless 最核心的理念是“按需”，云原生消息 Serverless 化主要是從兩個(gè)維度落地按需的概念。一方面根據(jù)業(yè)務(wù)規(guī)模自動(dòng)化擴(kuò)縮容實(shí)例規(guī)格、隊(duì)列數(shù)等邏輯資源；另一方面，根據(jù)服務(wù)端負(fù)載自動(dòng)化擴(kuò)縮容計(jì)算、存儲(chǔ)等物理資源。  
邏輯資源按需擴(kuò)縮容： 在用戶側(cè)，更關(guān)心的是消息實(shí)例提供的邏輯資源是否充足，比如購(gòu)買的實(shí)例 TPS 規(guī)格是否足夠，隊(duì)列數(shù)量是否能滿足擴(kuò)展性需求。比如一個(gè)商業(yè)化的 MQ 實(shí)例中，可以根據(jù)用戶的流量對(duì)實(shí)例規(guī)格進(jìn)行自動(dòng)的升降配，從 2W TPS 至 10W TPS 按需調(diào)整；也可以根據(jù)用戶分布式消費(fèi)者的數(shù)量規(guī)模，對(duì)邏輯隊(duì)列數(shù)量進(jìn)行動(dòng)態(tài)調(diào)整；用戶完全不需要進(jìn)行容量評(píng)估。
物理資源按需擴(kuò)縮容：
在云服務(wù)開(kāi)發(fā)者側(cè)，我們更關(guān)心的是如何通過(guò) Serverless 降低運(yùn)維成本，避免手動(dòng)的機(jī)器購(gòu)買、VIP 申請(qǐng)、磁盤申請(qǐng)以及集群擴(kuò)縮容等。在 Kubernetes 化完成后，可以很輕易地根據(jù)集群 Load 等指標(biāo)自動(dòng)擴(kuò)容 MQ 物理資源；在集群縮容的處理上，會(huì)比較麻煩，因?yàn)槊總€(gè) MQ 節(jié)點(diǎn)其實(shí)是有狀態(tài)的，圖中的某個(gè) PV 代表了一個(gè) CommitLog ，我們?cè)趦?nèi)部通過(guò)在 ASI 上支持 PV 漂移，在 RocketMQ 存儲(chǔ)層支持多 CommitLog 掛載來(lái)完成自動(dòng)化縮容。

云原生消息 Mesh 化

 

Service Mesh 出發(fā)點(diǎn)是解決微服務(wù)架構(gòu)的網(wǎng)絡(luò)問(wèn)題，將服務(wù)之間的通信問(wèn)題從業(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 是國(guó)內(nèi)第二個(gè)成功進(jìn)入 Service Mesh 官方社區(qū)的中間件產(chǎn)品，在進(jìn)行 Envoy 適配的過(guò)程中推動(dòng)了Envoy社區(qū)加速對(duì) on-demand CDS 的支持，創(chuàng)新性地使用 Pop 消費(fèi)模式來(lái)適配 Mesh 的無(wú)狀態(tài)網(wǎng)絡(luò)模型。

云原生消息生態(tài)

---

在云原生消息服務(wù)演進(jìn)方向小節(jié)中提到，云原生消息服務(wù)需要大而全的消息生態(tài)來(lái)覆蓋業(yè)務(wù)方豐富的業(yè)務(wù)場(chǎng)景，本小節(jié)介紹我們?cè)谏鷳B(tài)建設(shè)方面做的一些努力。

云原生消息產(chǎn)品矩陣

 
阿里云消息產(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ù)場(chǎng)景，為云原生客戶提供一站式消息解決方案。

• 消息隊(duì)列 RocketMQ ：阿里巴巴自主研發(fā)及雙 11 交易核心鏈路消息產(chǎn)品，阿里云主打品牌，主要面向業(yè)務(wù)消息處理，打造金融級(jí)高可靠消息服務(wù)。
• 消息隊(duì)列 Kafka ：聚焦大數(shù)據(jù)生態(tài)鏈，100% 融合 Kafka 開(kāi)源社區(qū)，大數(shù)據(jù)應(yīng)用領(lǐng)域中不可或缺的消息產(chǎn)品。
• 微消息隊(duì)列 MQTT ：基于 MQTT 標(biāo)準(zhǔn)協(xié)議自研，拓展消息產(chǎn)品的領(lǐng)域與邊界，延伸到移動(dòng)互聯(lián)網(wǎng)以及物聯(lián)網(wǎng)，實(shí)現(xiàn)端與云的連接。
• 消息隊(duì)列 AMQP ：100% 兼容 AMQP 事實(shí)標(biāo)準(zhǔn)協(xié)議，全面融合 RabbitMQ 開(kāi)源社區(qū)生態(tài)。
• 消息服務(wù) MNS ：聚焦云產(chǎn)品生態(tài)集成 & 消息通知服務(wù)（HTTP Endpoint、Function Compute、事件通知、移動(dòng)推送等）。
• 事件總線 EventBridge ：作為我們下一代的消息產(chǎn)品形態(tài)，原生支持 CloudEvents 標(biāo)準(zhǔn)，提供中心化事件服務(wù)能力，加速云原生生態(tài)集成，EDA首選。

云原生消息生態(tài)

 
在生態(tài)建設(shè)方面，我們?cè)谏虡I(yè)化和開(kāi)源兩個(gè)生態(tài)都取得了不錯(cuò)得成功。
在阿里云消息商業(yè)化生態(tài)中，消息隊(duì)列產(chǎn)品線已經(jīng)支持 11 BU，30+云產(chǎn)品或者解決方案，有些對(duì)用戶是可見(jiàn)的，有些是不可見(jiàn)的，真正做到了云原生通信基礎(chǔ)設(shè)施的定位。
在開(kāi)源方面，開(kāi)源 RocketMQ 已經(jīng)完成了云原生技術(shù)棧的集成，包括Knative中的事件源，Prometheus 的 Exporter，K8s 的 Operator等；也支持了微服務(wù)框架 Dubbo、SpringCloud 以及函數(shù)計(jì)算框架 OpenWhisk ；同時(shí)開(kāi)發(fā)了很多 Connector 作為 Sink 或者 Source 去連接了 ELK、Flume、Flink、Hadoop 等大數(shù)據(jù)和數(shù)據(jù)分析領(lǐng)域的優(yōu)秀開(kāi)源產(chǎn)品。

云原生消息標(biāo)準(zhǔn)

最開(kāi)始我們就提到標(biāo)準(zhǔn)化是云原生消息中間件的進(jìn)化方向之一，我們從兩個(gè)維度打磨產(chǎn)品的標(biāo)準(zhǔn)化建設(shè)。
 
社區(qū)標(biāo)準(zhǔn) ： 在消息領(lǐng)域，無(wú)論是接口還是協(xié)議，社區(qū)一直有很多事實(shí)上的“標(biāo)準(zhǔn)”，比如 Kafka 提供的 API 和協(xié)議，JMS API，CloudEvents 規(guī)范，MQTT 中的協(xié)議和模型，AMQP 的協(xié)議和模型等，阿里云消息隊(duì)列產(chǎn)品線對(duì)這些事實(shí)標(biāo)準(zhǔn)都提供了相應(yīng)的接入方式，用戶可以低成本完成遷移上云。
自建標(biāo)準(zhǔn) ： 事實(shí)上的“標(biāo)準(zhǔn)”如果太多，其實(shí)就沒(méi)有標(biāo)準(zhǔn)，開(kāi)源方面一直在推動(dòng)自建標(biāo)準(zhǔn) OpenMessaging，OMS 將提供六大核心特性：多領(lǐng)域、流、平臺(tái)無(wú)關(guān)、標(biāo)準(zhǔn)的 Benchmark ，面向云，線路層可插拔。目前，國(guó)內(nèi)有很多云提供商都接入了 OMS 標(biāo)準(zhǔn)。

云原生消息核心競(jìng)爭(zhēng)力

---

作為云原生的消息，核心競(jìng)爭(zhēng)力在哪，特別是開(kāi)源生態(tài)愈發(fā)蓬勃，用戶可選的解決方案非常多，如何讓用戶選擇我們?cè)圃南⒎?wù)，我們認(rèn)為核心競(jìng)爭(zhēng)力主要有這么幾個(gè)。

領(lǐng)先的消息服務(wù)能力

 
阿里云的消息服務(wù)，在多個(gè)方面都具備絕對(duì)領(lǐng)先的服務(wù)能力。
接入&遷移 整個(gè)產(chǎn)品線支撐了多協(xié)議、多API、多語(yǔ)言、多終端以及多生態(tài)的接入，做到了“0”接入成本，開(kāi)源或自建用戶都可以無(wú)縫上云；同時(shí)全球消息路由也支持跨地域的消息同步，異構(gòu)的消息遷移同步等。
多租戶 阿里云消息服務(wù)支持命名空間隔離、標(biāo)準(zhǔn)的訪問(wèn)控制；支持實(shí)例限流、資源隔離、多租戶的海量堆積。
消息類型 在業(yè)務(wù)消息領(lǐng)域，阿里云消息有多年的業(yè)務(wù)沉淀，消息類型上支持：普通消息、事務(wù)消息、定時(shí)消息、順序消息、重試消息以及死信消息等。
消費(fèi)&治理 在消費(fèi)和治理領(lǐng)域，云消息服務(wù)支持 Pub/Sub 模式，廣播/集群消費(fèi)模式，消費(fèi)過(guò)程中支持 Tag 過(guò)濾、 SQL 過(guò)濾。在運(yùn)維時(shí)，提供了消息軌跡、消息查詢以及消息回放等治理能力。
服務(wù)能力 阿里云消息的服務(wù)能力是經(jīng)過(guò)多年錘煉的：

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

統(tǒng)一的消息內(nèi)核

阿里云消息隊(duì)列的另一核心競(jìng)爭(zhēng)力為統(tǒng)一的消息內(nèi)核，整個(gè)消息云產(chǎn)品簇都建設(shè)在統(tǒng)一的 RocketMQ 內(nèi)核之上，所有的云產(chǎn)品提供一致的底層能力。  
RocketMQ 內(nèi)核主要包含以下幾個(gè)模塊：
富客戶端 RocketMQ 提供一個(gè)輕量級(jí)的富客戶端，暴露 Push、Pull 以及 Pop 三種消費(fèi)模式，同時(shí)內(nèi)置了重試、熔斷等高可用功能，產(chǎn)品簇的眾多客戶端都是通過(guò)對(duì)內(nèi)核的富客戶端進(jìn)行二次開(kāi)發(fā)的。
注冊(cè)中心 也就是 RocketMQ 開(kāi)發(fā)者熟知的 NameServer ，以簡(jiǎn)單可靠的方式提供集群管理、元數(shù)據(jù)管理、Topic 路由和發(fā)現(xiàn)等功能，節(jié)點(diǎn)無(wú)狀態(tài)，最終一致的語(yǔ)義確保 NameServer 具有超高的可用性。
計(jì)算節(jié)點(diǎn) Broker 中的計(jì)算部分包含一個(gè)高性能的傳輸層，以及一個(gè)可擴(kuò)展的 RPC 框架，以支持各個(gè)產(chǎn)品的豐富的業(yè)務(wù)需求。
存儲(chǔ)引擎 Broker 中的核心為存儲(chǔ)引擎，經(jīng)過(guò)多年錘煉的存儲(chǔ)引擎包含幾個(gè)核心特點(diǎn)：

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

全方面的穩(wěn)定性建設(shè)

穩(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)開(kāi)發(fā) 整個(gè)系統(tǒng)是面向失敗設(shè)計(jì)的，除了最核心的組件，所有的外部依賴都是弱依賴；在產(chǎn)品迭代階段，建立了完善的 Code Review 、單元測(cè)試、集成測(cè)試、性能測(cè)試以及容災(zāi)測(cè)試流程。
變更管理 風(fēng)險(xiǎn)往往來(lái)自于變更，我們對(duì)變更的要求是可灰度、可監(jiān)控、可回滾以及可降級(jí)的。
穩(wěn)定性防護(hù) 限流、降級(jí)、容量評(píng)估、應(yīng)急方案、大促保障、故障演練、預(yù)案演練、定期風(fēng)險(xiǎn)梳理等都是我們的穩(wěn)定性防護(hù)手段。
體系化巡檢 分為黑盒巡檢和白盒巡檢，黑盒巡檢會(huì)站在用戶視角對(duì)產(chǎn)品功能進(jìn)行全方面掃描，包含了 50+ 檢測(cè)項(xiàng)；白盒巡檢會(huì)自動(dòng)化檢測(cè) 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)品也即將迎來(lái)公測(cè)，本章節(jié)主要介紹 EventBridge 的產(chǎn)品定位。

消息與事件

 
消息和事件是兩種不同形態(tài)的抽象，也意味著滿足不同的場(chǎng)景：
消息：消息是比事件更通用的抽象，常用于微服務(wù)調(diào)用之間的異步解耦，微服務(wù)調(diào)用之間往往需要等到服務(wù)能力不對(duì)等時(shí)才會(huì)去通過(guò)消息對(duì)服務(wù)調(diào)用進(jìn)行異步化改造；消息的內(nèi)容往往綁定了較強(qiáng)的業(yè)務(wù)屬性，消息的發(fā)送方對(duì)消息處理邏輯是有明確的預(yù)期的。
事件：事件相對(duì)于消息更加具像化，代表了事情的發(fā)送、條件和狀態(tài)的變化；事件源來(lái)自不同的組織和環(huán)境，所以事件總線天然需要跨組織；事件源對(duì)事件將被如何響應(yīng)沒(méi)有任何預(yù)期的，所以采用事件的應(yīng)用架構(gòu)是更徹底的解耦，采用事件的應(yīng)用架構(gòu)將更加具備可擴(kuò)展性和靈活性。

EventBridge：中心化事件總線

EventBridge 作為我們即將發(fā)布的新產(chǎn)品，其核心能力之一便是提供中心化的事件總線能力。  
EventBridge 將提供云產(chǎn)品之間、云應(yīng)用之間、云產(chǎn)品與云應(yīng)用之間，以及它們與 SaaS 提供商之間的集成與被集成能力。
在中心化事件總線中有幾個(gè)重要的概念：
事件源：事件源可以是阿里云服務(wù)，比如對(duì)象存儲(chǔ)、ECS、數(shù)據(jù)庫(kù)等，也可以是用戶的應(yīng)用程序或者第三方 SaaS ，這些事件源將提供豐富的業(yè)務(wù)事件、云產(chǎn)品運(yùn)維事件、事件流等。
資源管理：EventBridge 內(nèi)部將提供總線管理、規(guī)則管理以及 Schema 管理，提供全托管的事件服務(wù)。
事件處理：EventBridge 將提供事件傳輸、事件過(guò)濾、事件路由、事件查詢、回放、重試、追蹤等核心的事件處理能力。
事件目標(biāo)：事件最終投遞的目標(biāo)服務(wù)包羅萬(wàn)象，既可以觸發(fā)一個(gè) Serverless 的 Function ，也可以投遞至消息隊(duì)列其它產(chǎn)品，運(yùn)維事件還可以通過(guò)短信、郵件以及日志服務(wù)觸達(dá)運(yùn)維人員。

EventBridge：EDA服務(wù)框架

 
EventBridge 另一個(gè)核心能力是 EDA 服務(wù)框架。微服務(wù)有兩種驅(qū)動(dòng)方式：請(qǐng)求驅(qū)動(dòng)和事件驅(qū)動(dòng)。在請(qǐng)求驅(qū)動(dòng)模式下，服務(wù)之間調(diào)用是同步調(diào)用，這種模式優(yōu)點(diǎn)是延遲低，但是服務(wù)之間的耦合是比較重的，相比之下事件驅(qū)動(dòng)有幾個(gè)優(yōu)點(diǎn)：

• 異步化，所有的調(diào)用通過(guò)事件異步化驅(qū)動(dòng)，服務(wù)之間沒(méi)有顯示的依賴關(guān)系。
• 松耦合，通過(guò)事件總線解除所有服務(wù)之間的耦合關(guān)系。
• 可擴(kuò)展，可擴(kuò)展能力非常強(qiáng)，基于總線和事件 Schema 完成業(yè)務(wù)的擴(kuò)展非常簡(jiǎn)單。
• 零改造，請(qǐng)求驅(qū)動(dòng)的微服務(wù)，在遇到服務(wù)之間能力不對(duì)等時(shí)，往往需要進(jìn)行基于消息異步化改造，避免慢調(diào)用、超時(shí)等異常情況在整個(gè)分布式集群觸發(fā)雪崩效應(yīng)?；谑录?qū)動(dòng)的微服務(wù)天然具備力異步、削峰等能力，所以在業(yè)務(wù)規(guī)模擴(kuò)大時(shí)不會(huì)帶來(lái)額外的改造成本。

設(shè)想的一個(gè)采用 EDA 的應(yīng)用架構(gòu)圖：

• 基于 EventBridge 可以實(shí)踐流行的 CQRS 和 Event Souring 范式。
• 可以從 IoT 端設(shè)備上接入 Event Streaming 。
• 基于事件驅(qū)動(dòng)的微服務(wù)程序也可以通過(guò) API 網(wǎng)關(guān)暴露傳統(tǒng)的 Request 請(qǐng)求方式，供前端訪問(wèn)。
• EventBridge 還可以連接第三方SaaS提供商，云提供商，不同組織的觀察者，與分布式的事件微服務(wù)集成。
• 事件驅(qū)動(dòng)和請(qǐng)求驅(qū)動(dòng)是相輔相成的關(guān)系，通過(guò)統(tǒng)一 Event APIs 和 REST APIs 打通事件驅(qū)動(dòng)的微服務(wù)與請(qǐng)求驅(qū)動(dòng)的微服務(wù)，來(lái)進(jìn)行架構(gòu)上的融合與統(tǒng)一。

EDA 成熟度模型

 
我們通過(guò) Gartner 報(bào)告總結(jié)的 EDA 成熟度模型，展望以下 EDA 架構(gòu)的未來(lái)：

• Incidental：偶發(fā)性地使用事件通知機(jī)制來(lái)進(jìn)行一些狀態(tài)的捕獲，沒(méi)有明確的事件處理策略。
• Brokered：提供托管的事件代理服務(wù)，組織中部分應(yīng)用開(kāi)始采用基于消息或者事件的異步化架構(gòu)。
• Centralized：以戰(zhàn)略的形式提出中心化的 EDA 解決方案，有專門的組織團(tuán)隊(duì)提供 EDA 實(shí)現(xiàn)， EDA 架構(gòu)開(kāi)始廣泛被采用。
• Advanced：EDA 架構(gòu)開(kāi)始觸達(dá)更多的業(yè)務(wù)領(lǐng)域，比如流計(jì)算，數(shù)據(jù)分析，AI，以及 API 市場(chǎng)等，跨組織的事件生態(tài)開(kāi)始形成并進(jìn)行擴(kuò)張。
• Pervasive：事件變得無(wú)處不在，龐大的事件生態(tài)形成，組織間的隔離被事件徹底打通，企業(yè)的關(guān)鍵業(yè)務(wù)都將采取 EDA 架構(gòu)；事件驅(qū)動(dòng)與請(qǐng)求驅(qū)動(dòng)兩個(gè)生態(tài)完成融合。

作者信息：

周新宇（花名：塵央），阿里云技術(shù)專家，Apache RocketMQ PMC Member/Committer，在消息和云原生領(lǐng)域有多年的研發(fā)經(jīng)驗(yàn)，目前在阿里云消息中間件團(tuán)隊(duì)從事 RocketMQ 產(chǎn)品的研發(fā)工作。

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：
			

		

長(zhǎng)按訂閱更多精彩▼
			

		
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝