作者｜肯夢

當下比較成功的企業已然認識到，要想最大限度提升運營效率和客戶體驗，務必將業務和技術兩方面的舉措緊密結合起來。運營事件或業務形勢的變化是時下眾多企業關注的焦點，這些變化能夠為企業領導者帶來切實有用的資訊，而架構設計的主旨恰恰是從客戶聯絡人、交易、運營等方面的資訊中獲取洞見，兩者相輔相成。傳統技術歷來對企業從事件中獲取洞見的速度有著諸多限制，比如用於記錄、收集和處理此類事件的批處理 ETL（提取、轉換、載入）。

事件驅動型架構 (EDA) 方興未艾，作為一種 Serverless 化的應用概念對雲原生架構具有著深遠影響。當我們討論到一個具體架構時，首當其衝的是它的發展是否具有技術先進性。這裡從我們熟悉的 MVC 架構，SOA 架構談起，聊一聊關於訊息事件領域的歷史與發展趨勢。

訊息事件領域的發展趨勢

圖片 1.png

早在 2018 年，Gartner 評估報告將 Event-Driven Model 列為 10 大戰略技術趨勢之一，事件驅動架構（EDA）將成為未來微服務的主流，並做出以下斷言：

到 2022 年，事件通知的軟體模型將成為超過 60% 的新型數字化商業的解決方案；
到 2022 年，超過 50% 的商業組織將參與到事件驅動的數字化商業服務的生態系統當中；

George Santayana 在《 The Life of Reason》曾提到， Those who fail to learn History are doomed to repeat it.（不懂歷史的人註定會重蹈覆轍）。我們以史為鑑，來看看為什麼會架構會演進到事件驅動。

圖片 2.png

架構本身沒有優劣之分，它本身就是一組技術決策，決定後續專案的所有功能開發（框架，編碼規範，文件，流程….），這裡聊聊為什麼會引入某些框架，這個框架解決了軟體開發中的什麼問題。

單體架構：在單節點服務中，單體應用的所有模組都封裝在單個程式執行，通訊通過相同堆疊呼叫完成。這種模式下非常容易導致結構和關係不明確，難以對系統進行更改和重構。就像一個不透明的，粘稠的，脆弱的，僵硬的 Big Ball of Mud！
分層架構：在經典的分層架構中，層以相當謹慎的方式使用。即一個層只能知道它下方層的資料。在隨後的實際應用中，更多的方式是一個層可以訪問它下面的任何層。分層架構解決了單體架構的的邏輯分離問題，每一層都可以被等效替換，層區分也更加標準化，同時一個層可以被幾個不同/更高階別的層使用。當然，層也有比較明顯的缺點，層不能封裝掉一切，比如新增到UI的某個欄位，可能也需要新增到DB，而且額外多餘的層會嚴重損害系統效能。
MVC 架構：MVC 架構產生的原因其實很簡單，隨著業務系統的複雜性增加，之前所謂“全棧工程師”已經不適用大部分場景。為了降低前端和後臺的整合複雜性，故而開始推廣 MVC 架構。其中，Model 代表業務邏輯，View 代表檢視層比如前端UI的某個小元件，Controller 提供 View 和 Model 的協調比如將使用者某項操作轉為業務邏輯等。這裡還有很多擴充套件架構，譬如 Model-View-Presenter ，Model-View-Presenter-ViewModel，Resource-Method-Representation，Action-Domain-Responder 。
EBI 架構：即 Entity，Boundary（介面），Interactor（控制）。EBI架構將系統邊界視為完整連線，而不僅僅是檢視，控制器或介面。EBI 的實體代表持有資料並結束相關行為的實際實體，很類似阿里雲的 POP API。EBI 主要還是後端概念，他是與 MVC 相輔相成的。
洋蔥架構：洋蔥架構是一種低耦合，高內聚的架構模型。所有的應用程式圍繞獨立的物件模型構建，內層定義介面外層實現介面，耦合方向向中心內聚，所有程式碼都可以獨立與基礎設施進行編譯和執行。
SOA 架構：SOA 是 Service Orientated Architure 的縮寫，即面向服務架構。表示每一個功能都是通過一個獨立的服務來提供，服務定義了明確的可呼叫介面，服務之間的編排呼叫完成一個完整的業務。其實這個架構也是目前架構中最成熟的，日常使用最多的架構模式。

什麼是 EDA 架構

我們聊完之前全部的架構趨勢後，再回過頭看看什麼是 EDA 架構。

EDA 事件驅動架構( Event-Driven Architecture ) 是一種系統架構模型，它的核心能力在於能夠發現系統“事件”或重要的業務時刻（例如交易節點、站點訪問等）並實時或接近實時地對相應的事件採取必要行動。這種模式取代了傳統的“ request/response ”模型，在這種傳統架構中，服務必須等待回覆才能進入下一個任務。事件驅動架構的流程是由事件提供執行的。

圖片 3.png

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

圖片 4.png

在如上對比圖中，我們其實可以較為清楚看到它與傳統架構的區別。在一般傳統架構中，建立訂單操作發生後，一系列的操作其實都是通過一個系統完成的。而事件驅動的概念則是將全部操作都轉換為 “事件” 概念，下游通過捕獲某個 “事件” 來決定呼叫什麼系統完成什麼樣的操作。

總結來看，事件驅動其實是將比較重要的業務時刻封裝成“事件”，並通過某個 EventBus 將事件路由給下游系統。

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

圖片 5.png

上圖就是事件驅動的核心邏輯架構。是不是非常像某個傳統 MQ？彆著急，下面我會講到這個架構的複雜部分。講完 EventBus，我們回過頭來看“事件”，剛剛介紹中比較重要部分其實是將操作轉換為某類事件進行分發。那這的事件我們怎麼定義呢？

簡單來看，其實事件就是狀態的顯著變化，當使用者採取特定行動時觸發。以 4S 店售賣汽車為例：

當客戶購買汽車並且其狀態從 For Sale 變為 Sold 是一個事件。
成功交易後，從帳戶中扣除金額是一個事件。
單擊預訂試駕後，從將預約資訊新增到指定使用者就是一個事件。

每個事件都可能觸發一個或多個選項作為響應。

關於事件其實雲原生 CNCF 基金會在 2018 年託管了開源 CloudEvents 專案，該專案旨在用統一和規範的格式來描述事件，來加強不同的服務、平臺以及系統之間的互操作性。在該專案定義下，通用的事件規範是這樣的：

圖片 6.png

事件主要由 Json 體構成，通過不同欄位描述發生的事件。

EDA 架構的落地實踐思考

在開始介紹落地實踐時，我們先來看一個經典的 EDA 架構模型：

圖片 7.png

這是一個非常經典 EDA 訂單架構，該架構主要使用了 EventBridge 和 FC 函式計算（如果不太熟悉 FaaS 的同學可以把 FC 節點當作 ECS 或 K8s 的某個 POD 節點），通過事件驅動各個業務進行協作。

所以這塊的中心節點（EventBridge）其實有三個比較重要的能力：

For Event Capturing（事件收集）：具備採集事件的能力
For Routing（事件路由）：通過事件內容將事件路由分發至於下游的能力的
For Event Processing（事件過濾/替換）：對事件進行脫敏或初步過濾&篩選的能力

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

圖片 8.png

其實，從剛剛的架構中我們也能窺探到一些資訊，EDA 架構其實看起來沒有那麼簡單，那它有何優劣呢？下面我就簡單羅列下 EDA 架構在實踐中的優勢：

鬆耦合：事件驅動架構是高度鬆耦合且高度分散式的架構模型，事件的建立者（來源）只知道發生的事件，並不知道事件的處理方式，也關心有多少相關方訂閱該事件。
非同步執行：EDA 架構是非同步場景下最適合的執行工具，我們可以將需要事件保留在佇列中，直到狀態正常後執行。
可擴充套件性：事件驅動架構可以通過路由&過濾能力快速劃分服務，提供更便捷的擴充套件與路由分發。
敏捷性：事件驅動架構可以通過將事件分發至任何地方，提供更敏捷高效的部署方案。

當然，劣勢也很明顯：

架構複雜：事件驅動架構複雜，路由節點多，系統結成複雜，功能要求多。
路由分發難：事件路由及分發難，靈活的事件路由需要依賴強大的實時計算能力，對整體分發系統要求較高。
無法追蹤：事件追蹤是整個 EDA 架構保證，EDA 架構中往往很難追蹤到事件處理狀態，需要大量的定製化開發。
可靠性差：事件驅動由於需要多系統整合，可靠性通常較差，且交付無法保障。

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

針對 EDA 場景下面臨的這些問題，阿里雲推出了 EventBridge，一款無伺服器事件匯流排服務，其使命是作為雲事件的樞紐，以標準化的 CloudEvents 1.0 協議連線雲產品和應用，應用和應用，提供中心化的事件治理和驅動能力，幫助使用者輕鬆構建鬆耦合、分散式的事件驅動架構；另外，在阿里雲之外的雲市場上有海量垂直領域的 SaaS 服務，EventBridge 將以出色的跨產品、跨組織以及跨雲的整合與被整合能力，助力客戶打造一個完整的、事件驅動的、高效可控的上雲體驗。並針對 EDA 困境提供了針對性的解決方案。

圖片 9.png