基于 RocketMQ 构建阿里云事件驱动引擎EventBridge
作者 | 六翁
以 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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 7张图揭晓RocketMQ存储设计的精髓
- 下一篇: MSE | 阿里巴巴云原生网关三位一体的