作者：周新宇
稽核&校對：白璵、佳佳
編輯&排版：雯燕

本文內容整理自 中國開源年會 演講

首先做一個自我介紹，我是 RocketMQ 的 PMC member 周新宇，目前負責阿里雲 RocketMQ 以及 EventBridge 的產品研發。今天我的分享主要包括以下幾部分：

• 訊息與事件、微服務與事件驅動架構

• 阿里雲 EventBridge：事件驅動架構實踐

• 基於 RocketMQ 核心構建阿里雲統一的事件樞紐

• 雲原生時代的新趨勢：Serverless+ 事件驅動

• 事件驅動架構的未來展望

訊息與事件、微服務與事件驅動架構

首先，我們先講一下訊息跟事件的區別：大家都知道 RocketMQ 裡面的訊息，它是非常泛化的概念，是一個比事件更加抽象的概念。因為訊息的內容體就是 Byte 陣列，沒有任何一個定義，是個弱 Data，所以它是非常通用的抽象。

與之相反的，事件可能是更加具象化的。一般情況下，它有一個 Schema 來精準描述事件有哪些欄位，比如 CloudEvents 就對事件有一個明確的 Schema 定義。事件也往往代表了某個事情的發生、某個狀態的變化，所以非常具象化。

從用途來講，訊息往往用於微服務的非同步解耦的架構。但這一塊的話，事件驅動跟訊息是稍微類似的。訊息的應用場景往往發生在一個組織內部，訊息的生產方知道這個訊息要將被如何處理。比如說在一個團隊裡，訊息的生產者跟傳送者可能是同一個團隊同一塊業務，對這個訊息內容有一個非常強的約定。相比之下，事件更加鬆耦合，比如說事件傳送方也不知道這個事件將被投遞到什麼地方，將被誰消費，誰對他感興趣，對事件被如何處理是沒有任何預期的。所以說，基於事件的架構是更加解耦的。訊息的應用往往還是脫離不了同一個業務部門，即使一些大公司裡最多涉及到跨部門合作。訊息的使用通過文件進行約束，事件通過 Schema 進行約束，所以我們認為事件是比訊息更加徹底解耦的方式。

接下來，微服務架構跟 EDA 架構有什麼區別？

首先是微服務架構，微服務作為從單體應用演進而來的架構，比如說把一個單體應用拆成了很多微服務，微服務之間通過 RPC 進行組織和串聯。過去一個業務可能是在本地編排了一堆 function，現在通過一堆 RPC 將之串起來。比如說使用者去做一個前端的下單操作，可能後臺就是好幾個微服務進行訂單操作，一個微服務去新建訂單，一個微服務去對訂單進行處理，處理完再調另一個微服務去把訂單已完成的訊息通知出去，這是一個典型的 RPC 架構。

但純粹的 RPC 架構有很多問題，比如所有業務邏輯是耦合在一起的，只是把本地方法呼叫換成了遠端呼叫。當業務增速達到一定階段，會發現各個微服務之間的容量可能是不對等的，比如說簡訊通知可以通過非同步化完成，卻同步完成。這就導致前端有多大流量，簡訊通知也需要準備同樣規模的流量。當準備資源不充足，上下游流量不對等時，就有可能導致某個微服被打掛，從而影響到上游，進而產生雪崩效應。

在這種情況下，大家一般就會引入訊息佇列進行非同步解耦。這個架構已非常接近於事件驅動架構了，還是以使用者前端建立一個訂單舉例，訂單建立的事件就會就發到事件匯流排、event broker、 event bus 上，下游各個不同訂閱方去對這個事件做監聽處理。

不同之處在於訊息訂閱者基於訊息中介軟體廠商提供 SDK 的去做訊息處理，業務往往需要進行改造，也會被廠商提供的技術棧繫結；事件驅動架構中訂閱者屬於泛化訂閱，即不要求訂閱方基於什麼樣的技術棧去開發，可以是一個 HTTP 閘道器，也可以是一個function，甚至可以是歷史遺留的存量系統。只要 event broker 相容業務的協議，就可以把事件推送到不同訂閱方。可以看到，泛化訂閱的用途更加廣泛，更加解耦，改造成本也最低。

阿里雲 EventBridge：事件驅動架構實踐

Gartner 曾預測， EDA 架構將來會成為微服務主流。在 2022 年它將會成為 60% 的新型數字化商業解決方案，也會有 50% 的商業組織參與其中。

同時， CNCF 基金會也提出了 CloudEvents 規範，旨在利用統一的規範格式來宣告事件通訊。EventBridge也是遵循這一標準。CloudEvents作為社群標準，解除了大家對於廠商鎖定的擔憂，提高了各個系統之間的互操作性，相當於說對各個系統約定了統一的語言，這個是非常關鍵的一步。

事件在開源社群有了統一的規範，但在雲上，很多使用者購買了雲廠商很多雲產品，這些雲產品每天可能有數以億計的事件在不停產生，這些事件躺在不同雲服務的日誌、內部實現裡。使用者也看不著，也不知道雲產品例項在雲上發生什麼事情。各個廠商對事件的定義也不一樣，整體是沒有同一類標準。各個雲服務之間的事件是孤立的，就是說沒有打通，這不利於挖掘事件的價值。在使用開源產品時也有類似問題，使用者往往也沒有統一標準進行資料互通，想去把這些生態打通時需要付出二次開發成本。

最後，事件驅動在很多場景應用的現狀是偏離線的，現在比較少的人把 EDA 架構用於線上場景。一方面是因為沒有事件型中介軟體基礎設施，很難做到一個事件被實時獲取，被實時推送的同時，能被業務方把整個鏈路給追蹤起來。所以，以上也是阿里云為什麼要做這款產品的背景。

因此，我們對 EventBridge 做了定義，它有幾個核心價值：

一、統一事件樞紐：統一事件介面，定義事件標準，打破雲產品事件孤島。

二、事件驅動引擎：海量事件源，毫秒級觸發能力，加速 EDA/Serverless 架構升級。

三、開放與整合：提供豐富的跨產品、跨平臺連線能力，促進雲產品、應用程式、SaaS服務相互整合。

首先講一下，EventBridge 基本模型，EventBridge 有四大部分。第一部分是事件源，這其中包括雲服務的事件、自定義應用、SaaS應用、自建資料平臺。

第二個部分就是事件匯流排，這是儲存實體，事件過來，它要存在某個地方進行非同步解耦。類似於說 RocketMQ 裡面 topic 的概念，具備一定儲存的同時，提供了非同步能力。事件匯流排涵蓋兩種，一種預設事件匯流排，用於收集所有云產品的事件，另一種自定義事件匯流排就是使用者自己去管理、去定義、去收發事件，用來實踐 EDA 架構概念。第三部分就是規則，規則與 RocketMQ 的消費者、訂閱比較類似，但我們賦予規則包括過濾跟轉換在內的更多計算能力。第四部分就是事件目標即訂閱方，對某事件感興趣就建立規則關聯這個事件，這其中包括函式計算、訊息服務、HTTP 閘道器等等。

這裡具體講一下這個事件規則，雖然類似於訂閱，但事件規則擁有事件輕量級處理能力。比如在使用訊息時可能需要把這個訊息拿到本地，再決定是否消費掉。但基於規則，可以在服務端就把這個訊息處理掉。

事件規則支援非常複雜的事件模式過濾，包括對指定值的匹配，比如字首匹配、字尾匹配、數值匹配、陣列匹配，甚至把這些規則組合起來形成複雜的邏輯匹配能力。

另一個，就是轉換器能力，事件目標泛化定義，其接受的事件格式可能有很多種，但下游服務不一定。比如說你要把事件推到釘釘，釘釘 API 已經寫好了並只接受固定格式。那麼，把事件推過去，就需要對事件進行轉換。我們提供了包括：

• 完整事件：不做轉換，直接投遞原生 CloudEvents。

• 部分事件：通過 JsonPath 語法從 CloudEvents 中提取部分內容投遞至事件目標。

• 常量：事件只起到觸發器的作用，投遞內容為常量。

• 模板轉換器：通過定義模板，靈活地渲染自定義的內容投遞至事件模板。

• 函式：通過指定處理函式，對事件進行自定義函式處理，將返回值投遞至事件目標。

目前，EventBridge 集成了 80 多種雲產品，約 800 多種事件型別，第一時間打通了訊息生態，比如說 RocketMQ 作為一個微服務生態，我們去實踐訊息事件理念，就可以把 RocketMQ 的事件直接投遞到 EventBridge，通過事件驅動架構去對這些訊息進行處理，甚至 MQTT、KafKa 等訊息生態，都進行打通整合。除了阿里雲訊息產品的打通，下一步也會把一些開源自建的訊息系統進行打通。另一個生態就是 ISV 生態，為什麼 ISV 需要 EventBridge？以釘釘 6.0 舉例，其最近釋出了聯結器能力。釘釘裡面要安裝很多軟體，這些軟體可能是官方提供，也可能是 ISV、第三方開發者提供，這就造成資料的互通性差。因此，我們提供這個能力讓 ISV 的資料流通起來。最後就是事件驅動生態，我們當前能夠觸達到大概 10 多種事件目標，目前也在持續豐富當中。

事件因相對訊息更加解耦、離散，所以事件治理也更加困難。所以，我們製作了事件中心並提供三塊能力：

• 事件追蹤：對每一個事件能有完整的追蹤，它從在哪裡產生，什麼時候被投遞，什麼時候被過濾掉了，什麼時候被投遞到某個目標，什麼時候被處理成功了。使整個生命週期完全追蹤起來。

• 事件洞察&分析：讓使用者從 EDA 程式設計視角變成使用者視角，讓使用者更加迅速的瞭解 EventBridge 裡面到底有哪些事件，並進行視覺化分析。通過 EB 做到就近計算分析，直接把業務訊息匯入到事件匯流排中，對訊息進行及時分析。

• 事件大盤：針對雲產品，引導雲產品對業務事件進行定義，讓雲產品更加開放，從而提供大盤能力。

基於 RocketMQ 核心構建阿里雲統一的事件樞紐

EventBridge 一開始就構建在雲原生的容器服務之上。在這之上首先是 RocketMQ 核心，核心在這個產品裡扮演的角色有兩種，一種就是事件儲存，當成儲存來用；另一方面是利用訂閱能力，把訂閱轉化成泛化訂閱。在 RocketMQ 核心之上就是 connect 叢集。EventBridge 比較重要的能力是連線，所以 EventBridge 首先要具備 Source 的能力，把事件 Source 過來，然後再存下來；其核心是 Connect 叢集，每個 Connect 叢集有很多 Worker。每個 Worker 要負責很多事情，包括事件的攝入，事件過濾，事件轉換，事件回放，事件追蹤等，同時在 Connect 叢集之上有 Connect 控制面，來完成叢集的治理，Worker 的排程等。

在更上面一層是 API Server，一個事件的入口閘道器，EventBridge 的世界裡，攝入事件有兩種方式，一種是通過 Connect 的 Source Connector，把事件主動的 Source 過來，另一種使用者或者雲產品可以通過 API server，通過我們的 SDK 把事件給投遞過來。投遞的方式有很多種，包括有 OpenAPI，有多語言的官方 SDK，同時考慮 CloudEvents 有社群的標準，EventBridge 也完全相容社群開源的 SDK，使用者也可以通過 Webhook 將事件投遞過來。

這個架構優點非常明顯：

（1）減少使用者開發成本

• 使用者無需額外開發進行事件處理

• 編寫規則對事件過濾、轉換

（2）原生 CloudEvents 支援

• 擁抱 CNCF 社群，無縫對接社群 SDK

• 標準協議統一阿里雲事件規範

（3）事件 Schema 支援

• 支援事件 Schema 自動探測和校驗

• Source 和 Target 的 Schema 繫結

（4）全球事件任意互通

• 組建了跨地域、跨賬戶的事件網路

• 支援跨雲、跨資料中心事件路由

雲原生時代的新趨勢：Serverless+ 事件驅動

我們認為 Serverless 加事件驅動是新的研發方式，各個廠商對 Serverless 理解各有側重，但是落地方式大道趨同。

首先，Serverless 基礎設施把底層 IaaS 遮蔽掉，上層 Serverless 執行時即計算託管，託管的不僅僅是微服務應用、K8s 容器，不僅僅是函式。

EventBridge 首先把這種驅動的事件源連線起來，能夠觸發這些執行時。因為 Serverless 最需要的就是驅動方，事件驅動帶給他這樣的能力，即計算入口。EventBridge 驅動 Serverless 執行時，再去連線與後端服務。目前，EventBridge 與 Serverless 結合的場景主要是鬆耦合場景，比如前端應用、SaaS 服務商小程式，以及音視訊編解碼等落地場景。

那麼，Serverless 的 EDA 架構開發模式到底是怎樣的呢？以函式計算為例，首先開發者從應用視角需要轉換為函式視角，將各個業務邏輯在一個個函式中進行實現；一個函式代表了一個程式碼片段，代表了一個具體的業務，當這段程式碼上傳後就變成了一個函式資源，然後 EventBridge 可以通過事件來驅動函式，將函式通過事件編排起來組成一個具體的應用。

這裡面 function 還需要做很多事情，大家也知道 function 有很多弊端，它最受詬病的就是冷啟動。因為 Serverless 需要 scale to zero 按量付費，在沒有請求沒有事件去觸發時，應該是直接收到 0 的，從 0~1 就是一個冷啟動。這個冷啟動有些時候可能要秒級等待，因為它可能涉及到下載程式碼、下載映象，涉及到 namespace 的構建，儲存掛載，root 掛載，這裡面很多事情，各個雲廠商投入很大精力優化這一塊。Serverless 價格優勢很明顯，它資源利用率特別高，因按量付費的，所以能做到接近百分百的資源利用率，也不需要去做容量規劃。

舉一個簡單的例子，就是基於 Serverless 加 EDA 的極簡程式設計正規化，再舉一個具體的例子，新零售場景下 EDA 架構對這個業務進行改造。首先來講，業務中有幾個關鍵資源，可能有 API 閘道器、函式計算，首先可以去打通一些資料，打通 rds 並把 rds 資料同步過來，相容一些歷史架構，同時去觸發計算資源、function、閘道器。整個架構優勢非常明顯，所以具備極致彈效能力，不需要去預留資源。

事件驅動的未來展望

我們認為事件驅動的未來有兩部分，一是要做好連線，做好雲內、跨雲的整合，讓使用者的多元架構更加高效。二是開源生態的整合，我們可以看到開源生態愈發蓬勃，所以也需要把這些開源生態中的資料整合好。此外，還有傳統 IDC 計算能力、邊緣計算能力這些生態都需要有連線性軟體把它連線起來。

EventBridge 是雲原生時代新的計算驅動力，這些資料可以去驅動雲的計算能力，創造更多業務價值。

瞭解更多相關資訊，請掃描下方二維碼或搜尋微訊號（AlibabaCloud888）新增雲原生小助手！獲取更多相關資訊！