![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/4a93f85870f84d88bded8e81d5e2a0c2.png)

作者 | 周禮（不銘）  阿里巴巴集團訊息中介軟體架構師

> **導讀**：本文整理自作者於 2020 年雲原生微服務大會上的分享《雲原生時代的訊息中介軟體演進》，主要探討了傳統的訊息中介軟體如何持續進化為雲原生的訊息服務。

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

# 引言

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

![1.png](https://ucc.alicdn.com/pic/developer-ecology/37526b7d57bc42859d45d27b80937d06.png)

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

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

# 雲原生訊息服務

## 1. 什麼是雲原生

![2.png](https://ucc.alicdn.com/pic/developer-ecology/2f77479bc9dc4966adce4681d7beeebb.png)

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

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

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

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

## 2. 什麼是雲原生訊息服務

![3.png](https://ucc.alicdn.com/pic/developer-ecology/f898e36da2b54afa82bd10382639bd0e.png)

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

訊息中介軟體在雲原生的應用場景，主要是為微服務和 EDA 架構提供核心的解耦、非同步和削峰的能力，在雲原生全景圖定義的其它層次領域，訊息服務還發揮著資料通道、事件驅動、整合與被整合等重要作用。

另外雲原生倡導面向效能設計，基於訊息佇列的非同步呼叫能夠顯著降低前端業務的響應時間，提高吞吐量；基於訊息佇列還能實現削峰填谷，把慢服務分離到後置鏈路，提升整個業務鏈路的效能。

## 3. 雲原生訊息服務演進方向

![4.png](https://ucc.alicdn.com/pic/developer-ecology/2b4314808c9247b999930d08d693c814.png)

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

### 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 環境開箱即用的服務。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/cd1487c2b2dc4ac98ea2486181562dca.png)

雲原生訊息 Kubernetes 化是指透過自定義 CRD 資源將有狀態的訊息叢集託管至 Kubernetes 叢集中，充分利用

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

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

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

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

## 2. 雲原生訊息 Serverless 化

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

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

![6.png](https://ucc.alicdn.com/pic/developer-ecology/e9b1bac314a04f658d536db808aeaf8c.png)

### 1）邏輯資源按需擴縮容

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

### 2）物理資源按需擴縮容

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

## 3. 雲原生訊息 Mesh 化

![7.png](https://ucc.alicdn.com/pic/developer-ecology/98661ef5afb44834a2d87934a556437c.png)

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

目前阿里雲訊息佇列 RocketMQ 是國內第二個成功進入 Service Mesh 官方社群的中介軟體產品，在進行 Envoy 適配的過程中推動了 Envoy 社群加速對 on-demand CDS 的支援，創新性地使用 Pop 消費模式來適配 Mesh 的無狀態網路模型。

更詳細的 Mesh 化介紹參考文章：[Apache RocketMQ 的 Service Mesh 開源之旅](https://www.atatech.org/articles/170727)

# 雲原生訊息生態

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

## 1. 雲原生訊息產品矩陣

![8.png](https://ucc.alicdn.com/pic/developer-ecology/77a4753714904542b97e11932348c805.png)

阿里雲訊息產品矩陣包含訊息佇列 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. 雲原生訊息生態

![9.png](https://ucc.alicdn.com/pic/developer-ecology/2ad803bbd6204be2933f9087a7648e5a.png)

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

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

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

## 3. 雲原生訊息標準

最開始我們就提到標準化是雲原生訊息中介軟體的進化方向之一，我們從兩個維度打磨產品的標準化建設。

![10.png](https://ucc.alicdn.com/pic/developer-ecology/f09f6005aeed4ecaadea085d3009f2e7.png)

### 1）社群標準

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

### 2）自建標準

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

# 雲原生訊息核心競爭力

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

## 1. 領先的訊息服務能力

![11.png](https://ucc.alicdn.com/pic/developer-ecology/4809db62b5cd47019d83a0e0ee5c6d64.png)

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

### 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 核心之上，所有的雲產品提供一致的底層能力。

![12.png](https://ucc.alicdn.com/pic/developer-ecology/dccee54e49274adb9c89d967754b43ff.png)

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。
> —— 叔同

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

![13.png](https://ucc.alicdn.com/pic/developer-ecology/9d1ffc7ab4f9484887f018dee84d529f.png)

阿里雲訊息佇列主要從以下幾個維度進行穩定性建設：

### 1）架構開發

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

### 2）變更管理

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

### 3）穩定性防護

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

### 4）體系化巡檢

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

### 5）故障應急

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

# 雲原生訊息展望

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

## 1. 訊息與事件

![14.png](https://ucc.alicdn.com/pic/developer-ecology/01c73e99905b40f598061d535ed5fac4.png)

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

### 1）訊息

訊息是比事件更通用的抽象，常用於微服務呼叫之間的非同步解耦，微服務呼叫之間往往需要等到服務能力不對等時才會去透過訊息對服務呼叫進行非同步化改造；訊息的內容往往繫結了較強的業務屬性，訊息的傳送方對訊息處理邏輯是有明確的預期的。

### 2）事件

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

## 2. EventBridge：中心化事件匯流排

EventBridge 作為我們即將釋出的新產品，其核心能力之一便是提供中心化的事件匯流排能力。

![15.png](https://ucc.alicdn.com/pic/developer-ecology/cf39ee22187e4bf18b345701a7cbcbe3.png)

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

在中心化事件匯流排中有幾個重要的概念：

- **事件源**：事件源可以是阿里雲服務，比如物件儲存、ECS、資料庫等，也可以是使用者的應用程式或者第三方 SaaS，這些事件源將提供豐富的業務事件、雲產品運維事件、事件流等；
- **資源管理**：EventBridge 內部將提供匯流排管理、規則管理以及 Schema 管理，提供全託管的事件服務；
- **事件處理**：EventBridge 將提供事件傳輸、事件過濾、事件路由、事件查詢、回放、重試、追蹤等核心的事件處理能力；
- **事件目標**：事件最終投遞的目標服務包羅永珍，既可以觸發一個 Serverless 的 Function，也可以投遞至訊息佇列其它產品，運維事件還可以透過簡訊、郵件以及日誌服務觸達運維人員。

## 3. EventBridge：EDA 服務框架

![16.png](https://ucc.alicdn.com/pic/developer-ecology/755b0edf41034cd9a7c0cb982daed760.png)

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

- **非同步化**：所有的呼叫透過事件非同步化驅動，服務之間沒有顯示的依賴關係；
- **松耦合**：透過事件匯流排解除所有服務之間的耦合關係；
- **可擴充套件**：可擴充套件能力非常強，基於匯流排和事件 Schema 完成業務的擴充套件非常簡單；
- **零改造**：請求驅動的微服務，在遇到服務之間能力不對等時，往往需要進行基於訊息非同步化改造，避免慢呼叫、超時等異常情況在整個分散式叢集觸發雪崩效應。基於事件驅動的微服務天然具備力非同步、削峰等能力，所以在業務規模擴大時不會帶來額外的改造成本。

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

- 基於 EventBridge 可以實踐流行的 CQRS 和 Event Souring 正規化；
- 可以從 IoT 端裝置上接入 Event Streaming；
- 基於事件驅動的微服務程式也可以透過 API 閘道器暴露傳統的 Request 請求方式，供前端訪問；
- EventBridge 還可以連線第三方 SaaS 提供商，雲提供商，不同組織的觀察者，與分散式的事件微服務整合；
- 事件驅動和請求驅動是相輔相成的關係，透過統一 Event APIs 和 REST APIs 打通事件驅動的微服務與請求驅動的微服務，來進行架構上的融合與統一。

## 4. EDA 成熟度模型

![17.png](https://ucc.alicdn.com/pic/developer-ecology/a76efef052e84d49b4c00920ab6953b6.png)

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

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

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

> “[阿里巴巴雲原生](https://mp.weixin.qq.com/s/5i8PucCcKfFOq8MNQgrr1Q)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

雲原生時代訊息中介軟體的演進路線

相關文章