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

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

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

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

到 2022 年，事件通知的軟件模型將成為超過 60% 的新型數(shù)字化商業(yè)的解決方案；
到 2022 年，超過 50% 的商業(yè)組織將參與到事件驅(qū)動(dòng)的數(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.（不懂歷史的人注定會(huì)重蹈覆轍）。我們以史為鑒，來看看為什么會(huì)架構(gòu)會(huì)演進(jìn)到事件驅(qū)動(dòng)。

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

單體架構(gòu)：在單節(jié)點(diǎn)服務(wù)中，單體應(yīng)用的所有模塊都封裝在單個(gè)進(jìn)程運(yùn)行，通信通過相同堆棧調(diào)用完成。這種模式下非常容易導(dǎo)致結(jié)構(gòu)和關(guān)系不明確，難以對(duì)系統(tǒng)進(jìn)行更改和重構(gòu)。就像一個(gè)不透明的，粘稠的，脆弱的，僵硬的 Big Ball of Mud！
分層架構(gòu)：在經(jīng)典的分層架構(gòu)中，層以相當(dāng)謹(jǐn)慎的方式使用。即一個(gè)層只能知道它下方層的數(shù)據(jù)。在隨后的實(shí)際應(yīng)用中，更多的方式是一個(gè)層可以訪問它下面的任何層。分層架構(gòu)解決了單體架構(gòu)的的邏輯分離問題，每一層都可以被等效替換，層區(qū)分也更加標(biāo)準(zhǔn)化，同時(shí)一個(gè)層可以被幾個(gè)不同/更高級(jí)別的層使用。當(dāng)然，層也有比較明顯的缺點(diǎn)，層不能封裝掉一切，比如添加到UI的某個(gè)字段，可能也需要添加到DB，而且額外多余的層會(huì)嚴(yán)重?fù)p害系統(tǒng)性能。
MVC 架構(gòu)：MVC 架構(gòu)產(chǎn)生的原因其實(shí)很簡(jiǎn)單，隨著業(yè)務(wù)系統(tǒng)的復(fù)雜性增加，之前所謂“全棧工程師”已經(jīng)不適用大部分場(chǎng)景。為了降低前端和后臺(tái)的集成復(fù)雜性，故而開始推廣 MVC 架構(gòu)。其中，Model 代表業(yè)務(wù)邏輯，View 代表視圖層比如前端UI的某個(gè)小組件，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ú)立的對(duì)象模型構(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)。表示每一個(gè)功能都是通過一個(gè)獨(dú)立的服務(wù)來提供，服務(wù)定義了明確的可調(diào)用接口，服務(wù)之間的編排調(diào)用完成一個(gè)完整的業(yè)務(wù)。其實(shí)這個(gè)架構(gòu)也是目前架構(gòu)中最成熟的，日常使用最多的架構(gòu)模式。

什么是 EDA 架構(gòu)

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

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

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

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

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

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

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

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

當(dāng)客戶購(gòu)買汽車并且其狀態(tài)從 For Sale 變?yōu)?Sold 是一個(gè)事件。
成功交易后，從帳戶中扣除金額是一個(gè)事件。
單擊預(yù)訂試駕后，從將預(yù)約信息添加到指定用戶就是一個(gè)事件。
每個(gè)事件都可能觸發(fā)一個(gè)或多個(gè)選項(xiàng)作為響應(yīng)。

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

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

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

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

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

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

For Event Capturing（事件收集）：具備采集事件的能力
For Routing（事件路由）：通過事件內(nèi)容將事件路由分發(fā)至于下游的能力的
For Event Processing（事件過濾/替換）：對(duì)事件進(jìn)行脫敏或初步過濾&篩選的能力
通常情況下，要實(shí)現(xiàn)這三個(gè)能力是比較困難的，比如：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ū)動(dòng)還需要包括這些核心能力。

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

松耦合：事件驅(qū)動(dòng)架構(gòu)是高度松耦合且高度分布式的架構(gòu)模型，事件的創(chuàng)建者（來源）只知道發(fā)生的事件，并不知道事件的處理方式，也關(guān)心有多少相關(guān)方訂閱該事件。
異步執(zhí)行：EDA 架構(gòu)是異步場(chǎng)景下最適合的執(zhí)行工具，我們可以將需要事件保留在隊(duì)列中，直到狀態(tài)正常后執(zhí)行。
可擴(kuò)展性：事件驅(qū)動(dòng)架構(gòu)可以通過路由&過濾能力快速劃分服務(wù)，提供更便捷的擴(kuò)展與路由分發(fā)。
敏捷性：事件驅(qū)動(dòng)架構(gòu)可以通過將事件分發(fā)至任何地方，提供更敏捷高效的部署方案。
當(dāng)然，劣勢(shì)也很明顯：
架構(gòu)復(fù)雜：事件驅(qū)動(dòng)架構(gòu)復(fù)雜，路由節(jié)點(diǎn)多，系統(tǒng)結(jié)成復(fù)雜，功能要求多。
路由分發(fā)難：事件路由及分發(fā)難，靈活的事件路由需要依賴強(qiáng)大的實(shí)時(shí)計(jì)算能力，對(duì)整體分發(fā)系統(tǒng)要求較高。
無法追蹤：事件追蹤是整個(gè) EDA 架構(gòu)保證，EDA 架構(gòu)中往往很難追蹤到事件處理狀態(tài)，需要大量的定制化開發(fā)。
可靠性差：事件驅(qū)動(dòng)由于需要多系統(tǒng)集成，可靠性通常較差，且交付無法保障。

阿里云 EventBridge 如何解決 EDA 場(chǎng)景下的困境

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

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

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

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

可靠性差：支持 DLQ/ 重試機(jī)制，大幅度保證由于用戶下游系統(tǒng)導(dǎo)致的事件故障與延遲。同時(shí)，在此基礎(chǔ)上 EventBridge 支持 82 種阿里云產(chǎn)品，847 種事件類型。

阿里云 EventBridge 更多場(chǎng)景介紹

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

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

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