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

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

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

首先做一個自我介紹，我是 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）添加雲原生小助手！獲取更多相關資訊！