簡介：阿里云事件總線 EventBridge 作為云上的事件樞紐，最核心的能力是連接。無論是在線業(yè)務場景、IoT 場景、還是大數(shù)據(jù)場景，無論是阿里云、其他云廠商，還是私有 IDC 機房，我們都將提供安全可靠的集成方式。

作者 | 六翁

以 Kubernetes 為基礎設施的云原生技術，徹底改變了我們的開發(fā)和思維模式。事件作為云原生領域的一等公民，已經(jīng)無處不在，是云原生架構(gòu)體系松耦合、靈活性的基礎。

作為 Gartner 定義的 10 大戰(zhàn)略技術趨勢之一，事件驅(qū)動架構(gòu)（EDA）逐漸成為主流技術架構(gòu)。根據(jù) Gartner 的預估，到 2022 年，在新型數(shù)字化商業(yè)的解決方案中，將有 6 成使用 EDA，在商業(yè)組織參與的技術棧中，EDA 有一半的占比。

本文將介紹事件、事件驅(qū)動架構(gòu)、阿里云事件驅(qū)動引擎 EventBridge 及其在事件的標準化、中心化、事件驅(qū)動架構(gòu)上的能力。

事件及事件驅(qū)動架構(gòu)

1、事件

事件是已經(jīng)發(fā)生的事實，并且是不可變的。相比而言，消息是一個服務為了另一個服務的消費或存儲而生產(chǎn)的原始數(shù)據(jù)，消息是可以被修改的。

事件的生產(chǎn)者如實地產(chǎn)生和投遞事件，它不關心這個事件將由誰、因何，以及怎樣去處理。而消息的生產(chǎn)者是知道誰來消費的，并且知道封裝哪些因素到消息中，以便消費者處理。

事件的 Broker 被設計為提供事實日志。事件在超時時間后被刪除，這個超時時間是由組織或者業(yè)務定義的。而消息的 Broker 被設計為處理各類問題的，當消費者感知到消息后，消息即可被刪除。

	事件	消息
Data	已經(jīng)發(fā)生的事實，并且不可變(Immutable)	為消費或存儲而生產(chǎn)的原始數(shù)據(jù)
Producer/Consumer	生產(chǎn)者不知道消費者是誰以及如何處理	生產(chǎn)者知道消費者是誰以及如何處理
Broker	提供事實日志 超時時間后，事件被刪除	處理各類問題 被消費者感知后，消息被刪除

• 離散事件：描述狀態(tài)(state)的變化 可執(zhí)行的
• 連續(xù)事件：描述處于怎樣的狀態(tài)(condition) 可分析的

通常，事件是離散的，用于描述一個事物的狀態(tài)變化，可以被執(zhí)行。消費者根據(jù)離散事件所描述的狀態(tài)，執(zhí)行相應的動作。

事件也可以是連續(xù)數(shù)據(jù)流中的一部分，用來描述一個事物當前處于某種狀態(tài)下。這些連續(xù)的事件是可分析的，消費者可以根據(jù)這些狀態(tài)的變化，分析出某種趨勢及背后的原因。

事件應當被設計為最小尺寸、最簡類型、單一目的。這里要著重介紹下 CloudEvents。CloudEvents 在 2018 年 5 月進入 CNCF 基金會的沙箱項目，然后只用了1年多時間就成為 CNCF 的孵化項目，其發(fā)展速度非常快。CloudEvents 將會成為云服務之間，事件通訊的標準協(xié)議。同時要強調(diào)的是，CloudEvents 已經(jīng)發(fā)布了多個消息中間件的綁定規(guī)范。

CloudEvents

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

2、事件驅(qū)動

事件驅(qū)動架構(gòu)是一種圍繞著事件的生產(chǎn)、探測、消費，及響應的軟件架構(gòu)范式。為云原生應用的分布式和伸縮性，提供了基礎保證。事件驅(qū)動架構(gòu)天然的異步特性，使云原生應用在設計上，可以根據(jù)?DDD?理論，清晰地劃分出服務間的上下文邊界，優(yōu)雅地實現(xiàn)松耦合。

1) 事件的傳遞模式

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

基于隊列的生產(chǎn)者-消費者模式。這是一種單一接收者的模式，用于兩個服務之間的事件傳遞。生產(chǎn)者服務并不關心消費者服務如何處理事件。

基于隊列的異步請求-回調(diào)模式。這種模式和請求驅(qū)動的 request-response 類似，是異步的 request-reply 或者叫 request-callback，同樣用于兩個服務之間的事件傳遞。生成者服務會關心消費者服務隨后生產(chǎn)的響應事件。

基于主題的發(fā)布者-訂閱者模式。這是一種多對多的模式。發(fā)布者服務可能生產(chǎn)不同類型的事件，并將其傳輸給不同的主題，訂閱者服務可能訂閱一個或者多個主題，以實現(xiàn)對不同類型事件的處理。

2) 事件的服務定義模式

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

我們已經(jīng)知道，事件的生產(chǎn)者并不知道消費者是誰，因此不能像消息那樣預先定義消息的格式。因此，在事件驅(qū)動架構(gòu)中，需要一個 Schema Registry 為生產(chǎn)者提供序列化依據(jù)，為消費者提供反序列化依據(jù)。

Schema 類似 gRPC 中的 proto 定義。在請求驅(qū)動模式下，gRPC 的服務端和客戶端會分別根據(jù) proto 定義，生成 stub 模板代碼。然后將模板代碼提供給自己的上層代碼調(diào)用，從而實現(xiàn)序列化和反序列化。

與之類似，在事件驅(qū)動模式下，消費者在獲取事件后，可以根據(jù) CloudEvents 標準協(xié)議，解析出 Schema 和 Content（通常是二進制），然后通過消費者調(diào)用 Schema Registry 服務，將 Content 反序列化為事件體。

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

3、EventBridge

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

EventBridge 是為用戶提供構(gòu)建松耦合、分布式的事件驅(qū)動架構(gòu)的 Serverless 事件總線服務。EventBridge 的事件傳輸和存儲遵循 CloudEvents 協(xié)議。

在 EventBridge 中，事件的生產(chǎn)者稱為事件源，傳輸和存儲事件的介質(zhì)稱為事件總線，事件的消費者稱為事件目標。事件由事件規(guī)則轉(zhuǎn)換、匹配、聚合，并路由到事件目標。

EventBridge 連接了事件生產(chǎn)和消費的兩端，利用云原生基礎設施的能力及 Serverless 按需消費的特點，為用戶提供了低代碼、松耦合、高可用的事件處理能力。用戶可以以極簡的投入，實現(xiàn)強響應能力的 EDA 云原生應用。

同時，EventBridge 基于標準的事件協(xié)議，有利于促進各類事件源的事件標準統(tǒng)一，使事件孤島逐步融合進完整的事件生態(tài)體系之中。因此，EventBridge 正成為云原生事件驅(qū)動架構(gòu)的標準范式。

那么，EventBridge 是如何結(jié)合 Serverless 實現(xiàn)極簡的 EDA 應用的呢？在接下來的事件總線范式及應用場景中，我將會詳細介紹。

事件總線

EventBridge 的一大特點是標準事件協(xié)議的管道。那么，我們一起來看一下，阿里云事件總線 EventBridge 實現(xiàn)這個管道能力的各個組成部分。

1、EventBridge的組成

1）事件源

阿里云 EventBridge 的事件源包羅萬象。可以是阿里云的各類云產(chǎn)品、阿里云第三方SaaS 服務，也可以是阿里云用戶自己的服務，甚至可以是其他云廠商、邊緣服務、私有機房內(nèi)的服務。用戶使用 CloudEvents 的 SDK，即可將事件推送到阿里云事件總線，從而實現(xiàn)事件上云。

2）事件總線

為了提供開箱即用的云產(chǎn)品事件處理能力，阿里云 EventBridge 為每個用戶提供了租戶隔離的默認事件總線。用戶所使用的云產(chǎn)品產(chǎn)生的事件，會由這條事件總線傳輸和存儲。

用戶可以通過自定義事件總線對接各類事件源，將不同的數(shù)據(jù)源產(chǎn)生的事件統(tǒng)一采集、存儲和響應。

3）事件規(guī)則

EventBridge 的事件規(guī)則的兩端分別是事件總線和事件目標。用戶通過配置匹配規(guī)則、轉(zhuǎn)換規(guī)則等，以低代碼甚至無代碼的方式，實現(xiàn)從事件總線到事件目標的事件過濾、轉(zhuǎn)換和路由。

4）事件目標

事件目標是事件被最終處理的地方。阿里云 EventBridge 目前已經(jīng)支持了多種事件目標，為用戶帶來開箱即用的體驗。我們可以為一個告警事件指定釘釘機器人，可以將一個訂單事件通過 HTTP 網(wǎng)關傳輸給用戶服務，也可以將事件投遞給消息服務實現(xiàn)事件上云。

當然，云原生的經(jīng)典事件目標是由 Serverless 服務，因為 Serverless 服務充分展現(xiàn)了云原生的優(yōu)勢。

• Serverless 的資源是按需消費的，將彈性發(fā)揮到極致
• 輕量級的函數(shù)具有低延遲、高可用的能力，且無運維成本
• 用戶編寫事件處理函數(shù)的學習門檻低、開發(fā)代碼量小

5）舉個例子

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

首先我們自定義一個事件總線，將 Kubernenets 容器服務作為事件源，將 Serverless 服務(函數(shù)計算)作為事件目標。

然后我們?yōu)槿萜鲀?nèi)的資源狀態(tài)變化事件定義一個事件規(guī)則，當這類事件進入事件總線后，將被路由到函數(shù)計算服務。

最后，我們編寫并部署一個處理這類事件的函數(shù)到函數(shù)計算服務，在函數(shù)內(nèi)，首先接收到 CloudEvents 標準協(xié)議的事件，通過 Schema Registry 解析事件，最后由函數(shù)自身完成事件處理——比如調(diào)用容器服務的 API，對資源進行相關操作。

從這個小例子中，我們可以看到，EventBridge+Serverless 可以讓用戶以很低的成本快速實現(xiàn)一個事件驅(qū)動的業(yè)務。四兩撥千斤。

接下來，我將介紹兩種事件驅(qū)動架構(gòu)的編排模式，并給出相應的例子，拋磚引玉，希望能激發(fā)你的腦洞，結(jié)合自身業(yè)務，得到因地制宜的事件總線最佳實踐。

2、事件驅(qū)動架構(gòu)的編排模式

1）調(diào)停者模式

對于處理較復雜的事件驅(qū)動場景，調(diào)停者模式能幫助我們有條不紊地對事件進行拆解和分析，并最終執(zhí)行指定的動作。調(diào)停者模式由三個角色組成：外部服務、調(diào)停者、執(zhí)行者。

首先，外部服務作為一個事件總線的事件源，將事件傳輸給事件總線。作為調(diào)停者的微服務或者函數(shù)是這個事件總線的事件目標，接收并處理來自某個事件源的事件。

調(diào)停者函數(shù)在執(zhí)行過程中，會將事件處理的多個中間狀態(tài)作為新的事件，傳輸?shù)綄氖录偩€。此時，調(diào)停者是作為這些事件總線的事件源。作為執(zhí)行者的函數(shù)是這些事件總線的事件目標。這些函數(shù)從事件總線中接收并處理事件，然后產(chǎn)生一個回調(diào)事件并傳輸?shù)较鄳氖录偩€中。可以看出，這里調(diào)停者和執(zhí)行者之間，是前面講到的異步請求-回調(diào)模式。

調(diào)停者接收到回調(diào)事件后，執(zhí)行調(diào)停邏輯，并將結(jié)果作為回調(diào)事件，經(jīng)過事件總線，傳輸給外部服務。

2）示例：智能家居

接下來，我來展示一個使用調(diào)停者模式實現(xiàn)智能家居的例子。

在這個例子中，我們將 IoT 設備/傳感器作為外部服務，將用戶的全屋系統(tǒng)作為調(diào)停者，將用戶在函數(shù)計算中創(chuàng)建的函數(shù)作為執(zhí)行者。

首先，傳感器產(chǎn)生一條"空氣質(zhì)量超標"事件，并將其傳輸?shù)接脩糇远x的"空氣質(zhì)量"事件總線。

用戶的全屋系統(tǒng)接收到這個事件后，分別計算室內(nèi)外空氣質(zhì)量，得出室外空氣超標，然后將窗內(nèi)外空氣質(zhì)量事件發(fā)送到用戶自定義的"窗內(nèi)外空氣"事件總線，窗戶控制函數(shù)作為執(zhí)行者，向 IoT 服務發(fā)出關窗指令，然后傳輸窗戶狀態(tài)事件。

全屋系統(tǒng)得知窗戶都已關閉后，繼續(xù)根據(jù)用戶定義的全屋邏輯，向新風控制、燈控等對應的事件總線發(fā)送相應的事件，以完成全屋控制。

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

3）管道和過濾器模式

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

源服務產(chǎn)生的事件，經(jīng)歷多個事件總線，被相應的管道函數(shù)執(zhí)行轉(zhuǎn)換、過濾、聚合等操作，最終將新的事件，經(jīng)事件總線傳輸給目標服務。

4）示例：在線學習

接下來，我來展示一個使用管道和過濾器模式實現(xiàn)人工智能服務在線學習的例子。

我們都知道，AI 的興起源自大數(shù)據(jù)。我們今天所使用的各類人工智能服務，背后都有一個或多個業(yè)務算法模型。這些模型通常是由算法架構(gòu)+離線的、批量的大數(shù)據(jù)反復訓練而成的。由于這些服務具有天然的數(shù)據(jù)相關性，因此實時發(fā)生的在線數(shù)據(jù)會對模型的改進有一定的幫助。

這里，我們假定出行推薦系統(tǒng)為源服務，出行模型訓練服務為目標服務，中間的各個函數(shù)為管道函數(shù)。出行推薦系統(tǒng)將實時的路況事件傳輸?shù)綄崟r交通事件總線。

實時交通事件總線的事件目標是兩個功能不同的函數(shù)。

• 第一個函數(shù)負責完成數(shù)據(jù)清洗和特征提取，然后生成特征事件，傳輸?shù)教卣魇录偩€。
• 第二個函數(shù)負責數(shù)據(jù)標注，將原始數(shù)據(jù)打標后，生成標注數(shù)據(jù)事件，傳輸?shù)綐俗?shù)據(jù)事件總線。

特征數(shù)據(jù)事件總線的事件目標同樣是兩個功能不同的函數(shù)。這里不再冗述。

最終出行模型訓練服務會根據(jù)實時數(shù)據(jù)，訓練出一個新的模型。這里省去了模型回歸等工業(yè)化流程細節(jié)。

事件中心

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

如前所述，EventBridge 基于標準的事件協(xié)議 CloudEvents，正逐步將事件孤島統(tǒng)一、融合到一起，形成完整的事件生態(tài)體系。

在這個生態(tài)體系下，事件中心將用戶使用的云產(chǎn)品、第三方 SaaS 服務、用戶服務、云下服務所產(chǎn)生的事件統(tǒng)一到一起，為用戶提供全方位的事件查詢、可視化和分析能力。

• 事件中心以租戶維度，為用戶提供一個或者多個事件總線的查詢和分析。
• 針對事件特征鮮明的服務或者云產(chǎn)品，事件中心提供了大盤和圖表，方便用戶實時觀測。
• 同時，事件中心提供了事件告警和事件卡片，實現(xiàn)用戶以0代碼的方式處理特定的事件。

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

展望

阿里云事件總線 EventBridge 作為云上的事件樞紐，最核心的能力是連接。無論是在線業(yè)務場景、IoT 場景、還是大數(shù)據(jù)場景，無論是阿里云、其他云廠商，還是私有 IDC 機房，我們都將提供安全可靠的集成方式。

未來，EventBridge 會重點發(fā)展生態(tài)網(wǎng)絡。云時代下這么龐大的神經(jīng)中樞系統(tǒng)，不是一日可以建成的，我們需要并期待與你一起共建云原生事件驅(qū)動架構(gòu)生態(tài)。

﹀

﹀

﹀

搜索釘釘群號 31704055?加入技術交流群，

可獲取云原生詳細解決方案資料與專家答疑。

原文鏈接：https://developer.aliyun.com/article/799537?

版權聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻，版權歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權，亦不承擔相應法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的基于 RocketMQ 构建阿里云事件驱动引擎EventBridge的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。