基於 RocketMQ 構建阿里雲事件驅動引擎EventBridge https://mp.weixin.qq.com/s/OUAuQCm3mITlOhx3amvPTA

原創塵央阿里巴巴中介軟體2021-11-04

作者：塵央稽核&校對：白璵

編輯&排版：酒圓

以 Kubernetes 為基礎設施的雲原生技術，徹底改變了我們的開發和思維模式。事件作為雲原生領域的一等公民，已經無處不在，是雲原生架構體系鬆耦合、靈活性的基礎。
作為 Gartner 定義的 10 大戰略技術趨勢之一，事件驅動架構（EDA）逐漸成為主流技術架構。根據 Gartner 的預估，到 2022 年，在新型數字化商業的解決方案中，將有 6 成使用 EDA，在商業組織參與的技術棧中，EDA 有一半的佔比。
本文將介紹事件、事件驅動架構、阿里雲事件驅動引擎 EventBridge 及其在事件的標準化、中心化、事件驅動架構上的能力。

事件及事件驅動架構

Aliware

1
事件

事件是已經發生的事實，並且是不可變的。相比而言，訊息是一個服務為了另一個服務的消費或儲存而生產的原始資料，訊息是可以被修改的。
事件的生產者如實地產生和投遞事件，它不關心這個事件將由誰、因何，以及怎樣去處理。而訊息的生產者是知道誰來消費的，並且知道封裝哪些因素到訊息中，以便消費者處理。
事件的 Broker 被設計為提供事實日誌。事件在超時時間後被刪除，這個超時時間是由組織或者業務定義的。而訊息的 Broker 被設計為處理各類問題的，當消費者感知到訊息後，訊息即可被刪除。

• 離散事件：描述狀態(state)的變化 可執行的
• 連續事件：描述處於怎樣的狀態(condition) 可分析的

通常，事件是離散的，用於描述一個事物的狀態變化，可以被執行。消費者根據離散事件所描述的狀態，執行相應的動作。
事件也可以是連續資料流中的一部分，用來描述一個事物當前處於某種狀態下。這些連續的事件是可分析的，消費者可以根據這些狀態的變化，分析出某種趨勢及背後的原因。
事件應當被設計為最小尺寸、最簡型別、單一目的。這裡要著重介紹下 CloudEvents。CloudEvents 在 2018 年 5 月進入 CNCF 基金會的沙箱專案，然後只用了1年多時間就成為 CNCF 的孵化專案，其發展速度非常快。CloudEvents 將會成為雲服務之間，事件通訊的標準協議。同時要強調的是，CloudEvents 已經發布了多個訊息中介軟體的繫結規範。
CloudEvents

• 2017 年 12 月 啟動
• 2018 年 05 月 CNCF 沙箱專案
• 2019 年 10 月 1.0 CNCF 孵化專案
• 2020 年 12 月 1.0.1

2
事件驅動

事件驅動架構是一種圍繞著事件的生產、探測、消費，及響應的軟體架構正規化。為雲原生應用的分散式和伸縮性，提供了基礎保證。事件驅動架構天然的非同步特性，使雲原生應用在設計上，可以根據DDD理論，清晰地劃分出服務間的上下文邊界，優雅地實現鬆耦合。

1、事件的傳遞模式

我們走近事件驅動，來看一下事件的傳遞模式。與請求驅動不同，事件驅動的兩端不是直連的。
事件的傳遞模式包含如下三種。

基於佇列的生產者-消費者模式。這是一種單一接收者的模式，用於兩個服務之間的事件傳遞。生產者服務並不關心消費者服務如何處理事件。

基於佇列的非同步請求-回撥模式。這種模式和請求驅動的 request-response 類似，是非同步的 request-reply 或者叫 request-callback，同樣用於兩個服務之間的事件傳遞。生成者服務會關心消費者服務隨後生產的響應事件。

基於主題的釋出者-訂閱者模式。這是一種多對多的模式。釋出者服務可能生產不同型別的事件，並將其傳輸給不同的主題，訂閱者服務可能訂閱一個或者多個主題，以實現對不同型別事件的處理。

2、事件的服務定義模式

我們再來了解下事件的服務定義模式。

我們已經知道，事件的生產者並不知道消費者是誰，因此不能像訊息那樣預先定義訊息的格式。因此，在事件驅動架構中，需要一個 Schema Registry 為生產者提供序列化依據，為消費者提供反序列化依據。

Schema 類似 gRPC 中的 proto 定義。在請求驅動模式下，gRPC 的服務端和客戶端會分別根據 proto 定義，生成 stub 模板程式碼。然後將模板程式碼提供給自己的上層程式碼呼叫，從而實現序列化和反序列化。

與之類似，在事件驅動模式下，消費者在獲取事件後，可以根據 CloudEvents 標準協議，解析出 Schema 和 Content（通常是二進位制），然後通過消費者呼叫 Schema Registry 服務，將 Content 反序列化為事件體。

可以看到，事件的服務定義模式，可以將事件的生產者和消費者充分地解耦。

3
EventBridge

通過上面的介紹，相信你已經對事件和事件驅動的概念有了較清晰的認識。接下來我介紹下 EventBridge。

EventBridge 是為使用者提供構建鬆耦合、分散式的事件驅動架構的 Serverless 事件匯流排服務。EventBridge 的事件傳輸和儲存遵循 CloudEvents 協議。

在 EventBridge 中，事件的生產者稱為事件源，傳輸和儲存事件的介質稱為事件匯流排，事件的消費者稱為事件目標。事件由事件規則轉換、匹配、聚合，並路由到事件目標。

EventBridge 連線了事件生產和消費的兩端，利用雲原生基礎設施的能力及 Serverless 按需消費的特點，為使用者提供了低程式碼、鬆耦合、高可用的事件處理能力。使用者可以以極簡的投入，實現強響應能力的 EDA 雲原生應用。

同時，EventBridge 基於標準的事件協議，有利於促進各類事件源的事件標準統一，使事件孤島逐步融合進完整的事件生態體系之中。因此，EventBridge 正成為雲原生事件驅動架構的標準正規化。

那麼，EventBridge 是如何結合 Serverless 實現極簡的 EDA 應用的呢？在接下來的事件匯流排正規化及應用場景中，我將會詳細介紹。

事件匯流排

Aliware

EventBridge 的一大特點是標準事件協議的管道。那麼，我們一起來看一下，阿里雲事件匯流排 EventBridge 實現這個管道能力的各個組成部分。

1
EventBridge的組成

1、事件源

阿里雲 EventBridge 的事件源包羅永珍。可以是阿里雲的各類雲產品、阿里雲第三方SaaS 服務，也可以是阿里雲使用者自己的服務，甚至可以是其他雲廠商、邊緣服務、私有機房內的服務。使用者使用 CloudEvents 的 SDK，即可將事件推送到阿里雲事件匯流排，從而實現事件上雲。

2、事件匯流排

為了提供開箱即用的雲產品事件處理能力，阿里雲 EventBridge 為每個使用者提供了租戶隔離的預設事件匯流排。使用者所使用的雲產品產生的事件，會由這條事件匯流排傳輸和儲存。

使用者可以通過自定義事件匯流排對接各類事件源，將不同的資料來源產生的事件統一採集、儲存和響應。

3、事件規則

EventBridge 的事件規則的兩端分別是事件匯流排和事件目標。使用者通過配置匹配規則、轉換規則等，以低程式碼甚至無程式碼的方式，實現從事件匯流排到事件目標的事件過濾、轉換和路由。

4、事件目標

事件目標是事件被最終處理的地方。阿里雲 EventBridge 目前已經支援了多種事件目標，為使用者帶來開箱即用的體驗。我們可以為一個告警事件指定釘釘機器人，可以將一個訂單事件通過 HTTP 閘道器傳輸給使用者服務，也可以將事件投遞給訊息服務實現事件上雲。

當然，雲原生的經典事件目標是由 Serverless 服務，因為 Serverless 服務充分展現了雲原生的優勢。

• Serverless 的資源是按需消費的，將彈性發揮到極致

• 輕量級的函式具有低延遲、高可用的能力，且無運維成本

• 使用者編寫事件處理函式的學習門檻低、開發程式碼量小

5、舉個例子

我這裡給大家展示個小例子，一起感受下 EventBridge+Serverless 實現 EDA 的輕量化。

首先我們自定義一個事件匯流排，將 Kubernenets 容器服務作為事件源，將 Serverless 服務(函式計算)作為事件目標。

然後我們為容器內的資源狀態變化事件定義一個事件規則，當這類事件進入事件匯流排後，將被路由到函式計算服務。

最後，我們編寫並部署一個處理這類事件的函式到函式計算服務，在函式內，首先接收到 CloudEvents 標準協議的事件，通過 Schema Registry 解析事件，最後由函式自身完成事件處理——比如呼叫容器服務的 API，對資源進行相關操作。

從這個小例子中，我們可以看到，EventBridge+Serverless 可以讓使用者以很低的成本快速實現一個事件驅動的業務。四兩撥千斤。

接下來，我將介紹兩種事件驅動架構的編排模式，並給出相應的例子，拋磚引玉，希望能激發你的腦洞，結合自身業務，得到因地制宜的事件匯流排最佳實踐。

2
事件驅動架構的編排模式

1、調停者模式

對於處理較複雜的事件驅動場景，調停者模式能幫助我們有條不紊地對事件進行拆解和分析，並最終執行指定的動作。調停者模式由三個角色組成：外部服務、調停者、執行者。

首先，外部服務作為一個事件匯流排的事件源，將事件傳輸給事件匯流排。作為調停者的微服務或者函式是這個事件匯流排的事件目標，接收並處理來自某個事件源的事件。

調停者函式在執行過程中，會將事件處理的多箇中間狀態作為新的事件，傳輸到對應的事件匯流排。此時，調停者是作為這些事件匯流排的事件源。作為執行者的函式是這些事件匯流排的事件目標。這些函式從事件匯流排中接收並處理事件，然後產生一個回撥事件並傳輸到相應的事件匯流排中。可以看出，這裡調停者和執行者之間，是前面講到的非同步請求-回撥模式。

調停者接收到回撥事件後，執行調停邏輯，並將結果作為回撥事件，經過事件匯流排，傳輸給外部服務。

2、示例：智慧家居

接下來，我來展示一個使用調停者模式實現智慧家居的例子。

在這個例子中，我們將 IoT 裝置/感測器作為外部服務，將使用者的全屋系統作為調停者，將使用者在函式計算中建立的函式作為執行者。

首先，感測器產生一條"空氣質量超標"事件，並將其傳輸到使用者自定義的"空氣質量"事件匯流排。

使用者的全屋系統接收到這個事件後，分別計算室內外空氣質量，得出室外空氣超標，然後將窗內外空氣質量事件傳送到使用者自定義的"窗內外空氣"事件匯流排，窗戶控制函式作為執行者，向 IoT 服務發出關窗指令，然後傳輸窗戶狀態事件。

全屋系統得知窗戶都已關閉後，繼續根據使用者定義的全屋邏輯，向新風控制、燈控等對應的事件匯流排傳送相應的事件，以完成全屋控制。

調停者模式的示例就介紹到這兒。接下來，我來介紹管道和過濾器模式。

3、管道和過濾器模式

管道和過濾器模式由三個角色組成：源服務、管道函式、目標服務。

源服務產生的事件，經歷多個事件匯流排，被相應的管道函式執行轉換、過濾、聚合等操作，最終將新的事件，經事件匯流排傳輸給目標服務。

4、示例：線上學習

接下來，我來展示一個使用管道和過濾器模式實現人工智慧服務線上學習的例子。

我們都知道，AI 的興起源自大資料。我們今天所使用的各類人工智慧服務，背後都有一個或多個業務演算法模型。這些模型通常是由演算法架構+離線的、批量的大資料反覆訓練而成的。由於這些服務具有天然的資料相關性，因此實時發生的線上資料會對模型的改進有一定的幫助。

這裡，我們假定出行推薦系統為源服務，出行模型訓練服務為目標服務，中間的各個函式為管道函式。出行推薦系統將實時的路況事件傳輸到實時交通事件匯流排。

實時交通事件匯流排的事件目標是兩個功能不同的函式。

• 第一個函式負責完成資料清洗和特徵提取，然後生成特徵事件，傳輸到特徵事件匯流排。

• 第二個函式負責資料標註，將原始資料打標後，生成標註資料事件，傳輸到標註資料事件匯流排。

特徵資料事件匯流排的事件目標同樣是兩個功能不同的函式。這裡不再冗述。

最終出行模型訓練服務會根據實時資料，訓練出一個新的模型。這裡省去了模型迴歸等工業化流程細節。

事件中心

Aliware

到這裡，我們對 EventBridge 作為事件傳輸、儲存和路由的管道能力有了一定認識。接下來，我將介紹 EventBridge 的另一大特點，事件的中心化查詢、展示、分析能力。

如前所述，EventBridge 基於標準的事件協議 CloudEvents，正逐步將事件孤島統一、融合到一起，形成完整的事件生態體系。

在這個生態體系下，事件中心將使用者使用的雲產品、第三方 SaaS 服務、使用者服務、雲下服務所產生的事件統一到一起，為使用者提供全方位的事件查詢、視覺化和分析能力。

• 事件中心以租戶維度，為使用者提供一個或者多個事件匯流排的查詢和分析。

• 針對事件特徵鮮明的服務或者雲產品，事件中心提供了大盤和圖表，方便使用者實時觀測。

• 同時，事件中心提供了事件告警和事件卡片，實現使用者以0程式碼的方式處理特定的事件。

事件中心讓事件的價值最大化，從事件角度為使用者的雲原生服務提供可追蹤、可度量、可觀測性。

展望

Aliware

阿里雲事件匯流排 EventBridge 作為雲上的事件樞紐，最核心的能力是連線。無論是線上業務場景、IoT 場景、還是大資料場景，無論是阿里雲、其他雲廠商，還是私有 IDC 機房，我們都將提供安全可靠的整合方式。

未來，EventBridge 會重點發展生態網路。雲時代下這麼龐大的神經中樞系統，不是一日可以建成的，我們需要並期待與你一起共建雲原生事件驅動架構生態。