作者｜肯夢

當(dāng)下比較成功的企業(yè)已然認(rèn)識到，要想最大限度提升運(yùn)營效率和客戶體驗(yàn)，務(wù)必將業(yè)務(wù)和技術(shù)兩方面的舉措緊密結(jié)合起來。運(yùn)營事件或業(yè)務(wù)形勢的變化是時下眾多企業(yè)關(guān)注的焦點(diǎn)，這些變化能夠?yàn)槠髽I(yè)領(lǐng)導(dǎo)者帶來切實(shí)有用的信息，而架構(gòu)設(shè)計(jì)的主旨恰恰是從客戶聯(lián)系人、交易、運(yùn)營等方面的信息中獲取洞見，兩者相輔相成。傳統(tǒng)技術(shù)歷來對企業(yè)從事件中獲取洞見的速度有著諸多限制，比如用于記錄、收集和處理此類事件的批處理 ETL（提取、轉(zhuǎn)換、加載）。

事件驅(qū)動型架構(gòu) (EDA) 方興未艾，作為一種 Serverless 化的應(yīng)用概念對云原生架構(gòu)具有著深遠(yuǎn)影響。當(dāng)我們討論到一個具體架構(gòu)時，首當(dāng)其沖的是它的發(fā)展是否具有技術(shù)先進(jìn)性。這里從我們熟悉的 MVC 架構(gòu)，SOA 架構(gòu)談起，聊一聊關(guān)于消息事件領(lǐng)域的歷史與發(fā)展趨勢。

消息事件領(lǐng)域的發(fā)展趨勢

早在 2018 年，Gartner 評估報(bào)告將 Event-Driven Model 列為 10 大戰(zhàn)略技術(shù)趨勢之一，事件驅(qū)動架構(gòu)（EDA）將成為未來微服務(wù)的主流，并做出以下斷言：

• 到 2022 年，事件通知的軟件模型將成為超過 60% 的新型數(shù)字化商業(yè)的解決方案；
• 到 2022 年，超過 50% 的商業(yè)組織將參與到事件驅(qū)動的數(shù)字化商業(yè)服務(wù)的生態(tài)系統(tǒng)當(dāng)中；

George Santayana 在《 The Life of Reason》曾提到， Those who fail to learn History are doomed to repeat it.（不懂歷史的人注定會重蹈覆轍）。我們以史為鑒，來看看為什么會架構(gòu)會演進(jìn)到事件驅(qū)動。

架構(gòu)本身沒有優(yōu)劣之分，它本身就是一組技術(shù)決策，決定后續(xù)項(xiàng)目的所有功能開發(fā)（框架，編碼規(guī)范，文檔，流程….），這里聊聊為什么會引入某些框架，這個框架解決了軟件開發(fā)中的什么問題。

• 單體架構(gòu)：在單節(jié)點(diǎn)服務(wù)中，單體應(yīng)用的所有模塊都封裝在單個進(jìn)程運(yùn)行，通信通過相同堆棧調(diào)用完成。這種模式下非常容易導(dǎo)致結(jié)構(gòu)和關(guān)系不明確，難以對系統(tǒng)進(jìn)行更改和重構(gòu)。就像一個不透明的，粘稠的，脆弱的，僵硬的 Big Ball of Mud！
• 分層架構(gòu)：在經(jīng)典的分層架構(gòu)中，層以相當(dāng)謹(jǐn)慎的方式使用。即一個層只能知道它下方層的數(shù)據(jù)。在隨后的實(shí)際應(yīng)用中，更多的方式是一個層可以訪問它下面的任何層。分層架構(gòu)解決了單體架構(gòu)的的邏輯分離問題，每一層都可以被等效替換，層區(qū)分也更加標(biāo)準(zhǔn)化，同時一個層可以被幾個不同/更高級別的層使用。當(dāng)然，層也有比較明顯的缺點(diǎn)，層不能封裝掉一切，比如添加到UI的某個字段，可能也需要添加到DB，而且額外多余的層會嚴(yán)重?fù)p害系統(tǒng)性能。
• MVC 架構(gòu)：MVC 架構(gòu)產(chǎn)生的原因其實(shí)很簡單，隨著業(yè)務(wù)系統(tǒng)的復(fù)雜性增加，之前所謂“全棧工程師”已經(jīng)不適用大部分場景。為了降低前端和后臺的集成復(fù)雜性，故而開始推廣 MVC 架構(gòu)。其中，Model 代表業(yè)務(wù)邏輯，View 代表視圖層比如前端UI的某個小組件，Controller 提供 View 和 Model 的協(xié)調(diào)比如將用戶某項(xiàng)操作轉(zhuǎn)為業(yè)務(wù)邏輯等。這里還有很多擴(kuò)展架構(gòu)，譬如 Model-View-Presenter ，Model-View-Presenter-ViewModel，Resource-Method-Representation，Action-Domain-Responder 。
• EBI 架構(gòu)：即 Entity，Boundary（接口），Interactor（控制）。EBI架構(gòu)將系統(tǒng)邊界視為完整連接，而不僅僅是視圖，控制器或接口。EBI 的實(shí)體代表持有數(shù)據(jù)并結(jié)束相關(guān)行為的實(shí)際實(shí)體，很類似阿里云的 POP API。EBI 主要還是后端概念，他是與 MVC 相輔相成的。
• 洋蔥架構(gòu)：洋蔥架構(gòu)是一種低耦合，高內(nèi)聚的架構(gòu)模型。所有的應(yīng)用程序圍繞獨(dú)立的對象模型構(gòu)建，內(nèi)層定義接口外層實(shí)現(xiàn)接口，耦合方向向中心內(nèi)聚，所有代碼都可以獨(dú)立與基礎(chǔ)設(shè)施進(jìn)行編譯和運(yùn)行。
• SOA 架構(gòu)：SOA 是 Service Orientated Architure 的縮寫，即面向服務(wù)架構(gòu)。表示每一個功能都是通過一個獨(dú)立的服務(wù)來提供，服務(wù)定義了明確的可調(diào)用接口，服務(wù)之間的編排調(diào)用完成一個完整的業(yè)務(wù)。其實(shí)這個架構(gòu)也是目前架構(gòu)中最成熟的，日常使用最多的架構(gòu)模式。

什么是 EDA 架構(gòu)

我們聊完之前全部的架構(gòu)趨勢后，再回過頭看看什么是 EDA 架構(gòu)。

EDA 事件驅(qū)動架構(gòu)( Event-Driven Architecture ) 是一種系統(tǒng)架構(gòu)模型，它的核心能力在于能夠發(fā)現(xiàn)系統(tǒng)“事件”或重要的業(yè)務(wù)時刻（例如交易節(jié)點(diǎn)、站點(diǎn)訪問等）并實(shí)時或接近實(shí)時地對相應(yīng)的事件采取必要行動。這種模式取代了傳統(tǒng)的“ request/response ”模型，在這種傳統(tǒng)架構(gòu)中，服務(wù)必須等待回復(fù)才能進(jìn)入下一個任務(wù)。事件驅(qū)動架構(gòu)的流程是由事件提供運(yùn)行的。

上圖其實(shí)很好的解釋了 EDA 架構(gòu)的模型，但是其實(shí)還不夠明確。所以，這里我們和單體架構(gòu)一起對比看看他們之間差異。

在如上對比圖中，我們其實(shí)可以較為清楚看到它與傳統(tǒng)架構(gòu)的區(qū)別。在一般傳統(tǒng)架構(gòu)中，創(chuàng)建訂單操作發(fā)生后，一系列的操作其實(shí)都是通過一個系統(tǒng)完成的。而事件驅(qū)動的概念則是將全部操作都轉(zhuǎn)換為 “事件” 概念，下游通過捕獲某個 “事件” 來決定調(diào)用什么系統(tǒng)完成什么樣的操作。

總結(jié)來看，事件驅(qū)動其實(shí)是將比較重要的業(yè)務(wù)時刻封裝成“事件”，并通過某個 EventBus 將事件路由給下游系統(tǒng)。

我們了解了 EDA 架構(gòu)的整個處理過程，但是還沒解決這個所謂的“EventBUS”到底是啥樣。

上圖就是事件驅(qū)動的核心邏輯架構(gòu)。是不是非常像某個傳統(tǒng) MQ？別著急，下面我會講到這個架構(gòu)的復(fù)雜部分。講完 EventBus，我們回過頭來看“事件”，剛剛介紹中比較重要部分其實(shí)是將操作轉(zhuǎn)換為某類事件進(jìn)行分發(fā)。那這的事件我們怎么定義呢？

簡單來看，其實(shí)事件就是狀態(tài)的顯著變化，當(dāng)用戶采取特定行動時觸發(fā)。以 4S 店售賣汽車為例：

• 當(dāng)客戶購買汽車并且其狀態(tài)從 For Sale 變?yōu)?Sold 是一個事件。
• 成功交易后，從帳戶中扣除金額是一個事件。
• 單擊預(yù)訂試駕后，從將預(yù)約信息添加到指定用戶就是一個事件。

每個事件都可能觸發(fā)一個或多個選項(xiàng)作為響應(yīng)。

關(guān)于事件其實(shí)云原生 CNCF 基金會在 2018 年托管了開源 CloudEvents 項(xiàng)目，該項(xiàng)目旨在用統(tǒng)一和規(guī)范的格式來描述事件，來加強(qiáng)不同的服務(wù)、平臺以及系統(tǒng)之間的互操作性。在該項(xiàng)目定義下，通用的事件規(guī)范是這樣的：

事件主要由 Json 體構(gòu)成，通過不同字段描述發(fā)生的事件。

EDA 架構(gòu)的落地實(shí)踐思考

在開始介紹落地實(shí)踐時，我們先來看一個經(jīng)典的 EDA 架構(gòu)模型：

這是一個非常經(jīng)典 EDA 訂單架構(gòu)，該架構(gòu)主要使用了 EventBridge 和 FC 函數(shù)計(jì)算（如果不太熟悉 FaaS 的同學(xué)可以把 FC 節(jié)點(diǎn)當(dāng)作 ECS 或 K8s 的某個 POD 節(jié)點(diǎn)），通過事件驅(qū)動各個業(yè)務(wù)進(jìn)行協(xié)作。

所以這塊的中心節(jié)點(diǎn)（EventBridge）其實(shí)有三個比較重要的能力：

For Event Capturing（事件收集）：具備采集事件的能力

For Routing（事件路由）：通過事件內(nèi)容將事件路由分發(fā)至于下游的能力的

For Event Processing（事件過濾/替換）：對事件進(jìn)行脫敏或初步過濾&篩選的能力

通常情況下，要實(shí)現(xiàn)這三個能力是比較困難的，比如：Event Capturing 可能需要熟悉 Dell Boomi, Snaplogic, MuleSoft, Dataflow, Apache Apex 等，Routing 部分可能通過 RocketMQ，RabbitMQ, ActiveMQ, Apache Kafka ，Event Processing 需要了解 Apache Storm, Apache Flink 。所以之前講的邏輯架構(gòu)其實(shí)非常理想，要想實(shí)現(xiàn)完成的 EDA 事件驅(qū)動還需要包括這些核心能力。

其實(shí)，從剛剛的架構(gòu)中我們也能窺探到一些信息，EDA 架構(gòu)其實(shí)看起來沒有那么簡單，那它有何優(yōu)劣呢？下面我就簡單羅列下 EDA 架構(gòu)在實(shí)踐中的優(yōu)勢：

• 松耦合：事件驅(qū)動架構(gòu)是高度松耦合且高度分布式的架構(gòu)模型，事件的創(chuàng)建者（來源）只知道發(fā)生的事件，并不知道事件的處理方式，也關(guān)心有多少相關(guān)方訂閱該事件。
• 異步執(zhí)行：EDA 架構(gòu)是異步場景下最適合的執(zhí)行工具，我們可以將需要事件保留在隊(duì)列中，直到狀態(tài)正常后執(zhí)行。
• 可擴(kuò)展性：事件驅(qū)動架構(gòu)可以通過路由&過濾能力快速劃分服務(wù)，提供更便捷的擴(kuò)展與路由分發(fā)。
• 敏捷性：事件驅(qū)動架構(gòu)可以通過將事件分發(fā)至任何地方，提供更敏捷高效的部署方案。

當(dāng)然，劣勢也很明顯：

• 架構(gòu)復(fù)雜：事件驅(qū)動架構(gòu)復(fù)雜，路由節(jié)點(diǎn)多，系統(tǒng)結(jié)成復(fù)雜，功能要求多。
• 路由分發(fā)難：事件路由及分發(fā)難，靈活的事件路由需要依賴強(qiáng)大的實(shí)時計(jì)算能力，對整體分發(fā)系統(tǒng)要求較高。
• 無法追蹤：事件追蹤是整個 EDA 架構(gòu)保證，EDA 架構(gòu)中往往很難追蹤到事件處理狀態(tài)，需要大量的定制化開發(fā)。
• 可靠性差：事件驅(qū)動由于需要多系統(tǒng)集成，可靠性通常較差，且交付無法保障。

阿里云 EventBridge 如何解決 EDA 場景下的困境

針對 EDA 場景下面臨的這些問題，阿里云推出了 EventBridge，一款無服務(wù)器事件總線服務(wù)，其使命是作為云事件的樞紐，以標(biāo)準(zhǔn)化的 CloudEvents 1.0 協(xié)議連接云產(chǎn)品和應(yīng)用，應(yīng)用和應(yīng)用，提供中心化的事件治理和驅(qū)動能力，幫助用戶輕松構(gòu)建松耦合、分布式的事件驅(qū)動架構(gòu)；另外，在阿里云之外的云市場上有海量垂直領(lǐng)域的 SaaS 服務(wù)，EventBridge 將以出色的跨產(chǎn)品、跨組織以及跨云的集成與被集成能力，助力客戶打造一個完整的、事件驅(qū)動的、高效可控的上云體驗(yàn)。并針對 EDA 困境提供了針對性的解決方案。

架構(gòu)復(fù)雜：提供業(yè)內(nèi)通用的 Source ，Buses，Rules，Targets 模塊管理能力，同時支持 EventBus 和 EventStream 兩種模式。大幅度降低事件驅(qū)動架構(gòu)難度。

路由分發(fā)：EventBridge 通過事件規(guī)則驅(qū)動，支持 8 大事件模式，4 重轉(zhuǎn)換器，滿足路由分發(fā)的全部訴求。

無法追蹤：獨(dú)家提供事件追蹤能力，事件分析/查詢能力。為用戶完善整體事件鏈路。

可靠性差：支持 DLQ/ 重試機(jī)制，大幅度保證由于用戶下游系統(tǒng)導(dǎo)致的事件故障與延遲。

同時，在此基礎(chǔ)上 EventBridge 支持 82 種阿里云產(chǎn)品，847 種事件類型。

阿里云 EventBridge 更多場景介紹

經(jīng)典 EDA 事件驅(qū)動：事件總線（EventBridge）最重要的能力是通過連接應(yīng)用程序，云服務(wù)和 Serverless 服務(wù)構(gòu)建 EDA（Event-driven Architectures） 事件驅(qū)動架構(gòu)，驅(qū)動應(yīng)用與應(yīng)用，應(yīng)用與云的連接。

流式 ETL 場景：EventBridge 另一個核心能力是為流式的數(shù)據(jù)管道的責(zé)任，提供基礎(chǔ)的過濾和轉(zhuǎn)換的能力，在不同的數(shù)據(jù)倉庫之間、數(shù)據(jù)處理程序之間、數(shù)據(jù)分析和處理系統(tǒng)之間進(jìn)行數(shù)據(jù)同步/跨地域備份等場景，連接不同的系統(tǒng)與不同服務(wù)。

統(tǒng)一事件通知服務(wù)：EventBridge 提供豐富的云產(chǎn)品事件源與事件的全生命周期管理工具，您可以通過總線直接監(jiān)聽云產(chǎn)品產(chǎn)生的數(shù)據(jù)，并上報(bào)至監(jiān)控，通知等下游服務(wù)。

目前事件總線免費(fèi)公測，點(diǎn)擊下方鏈接，立即體驗(yàn)！
https://www.aliyun.com/product/aliware/eventbridge?spm=5176.19720258.J_8058803260.46.70c22c4aFzf3Pq

加入釘群（群號：31481771），及時了解產(chǎn)品最新動態(tài)！

總結(jié)

以上是生活随笔為你收集整理的EDA 事件驱动架构与 EventBridge 二三事的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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