EDA 事件驅動架構與 EventBridge 二三事
簡介：事件驅動型架構 (EDA) 方興未艾，作為一種 Serverless 化的應用概念對雲原生架構具有著深遠影響。當我們討論到一個具體架構時，首當其衝的是它的發展是否具有技術先進性。這裡從我們熟悉的 MVC 架構，SOA 架構談起，聊一聊關於訊息事件領域的歷史與發展趨勢。
作者｜肯夢
當下比較成功的企業已然認識到，要想最大限度提升運營效率和客戶體驗，務必將業務和技術兩方面的舉措緊密結合起來。運營事件或業務形勢的變化是時下眾多企業關注的焦點，這些變化能夠為企業領導者帶來切實有用的資訊，而架構設計的主旨恰恰是從客戶聯絡人、交易、運營等方面的資訊中獲取洞見，兩者相輔相成。傳統技術歷來對企業從事件中獲取洞見的速度有著諸多限制，比如用於記錄、收集和處理此類事件的批處理 ETL（提取、轉換、載入）。
事件驅動型架構 (EDA) 方興未艾，作為一種 Serverless 化的應用概念對雲原生架構具有著深遠影響。當我們討論到一個具體架構時，首當其衝的是它的發展是否具有技術先進性。這裡從我們熟悉的 MVC 架構，SOA 架構談起，聊一聊關於訊息事件領域的歷史與發展趨勢。
訊息事件領域的發展趨勢
- 到 2022 年，事件通知的軟體模型將成為超過 60% 的新型數字化商業的解決方案；
- 到 2022 年，超過 50% 的商業組織將參與到事件驅動的數字化商業服務的生態系統當中；
George Santayana 在《 The Life of Reason》曾提到， Those who fail to learn History are doomed to repeat it.（不懂歷史的人註定會重蹈覆轍）。我們以史為鑑，來看看為什麼會架構會演進到事件驅動。
- 單體架構：在單節點服務中，單體應用的所有模組都封裝在單個程序執行，通訊通過相同堆疊呼叫完成。這種模式下非常容易導致結構和關係不明確，難以對系統進行更改和重構。就像一個不透明的，粘稠的，脆弱的，僵硬的 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 ”模型，在這種傳統架構中，服務必須等待回覆才能進入下一個任務。事件驅動架構的流程是由事件提供執行的。
總結來看，事件驅動其實是將比較重要的業務時刻封裝成“事件”，並通過某個 EventBus 將事件路由給下游系統。
我們瞭解了 EDA 架構的整個處理過程，但是還沒解決這個所謂的“EventBUS”到底是啥樣。
簡單來看，其實事件就是狀態的顯著變化，當用戶採取特定行動時觸發。以 4S 店售賣汽車為例：
- 當客戶購買汽車並且其狀態從 For Sale 變為 Sold 是一個事件。
- 成功交易後，從帳戶中扣除金額是一個事件。
- 單擊預訂試駕後，從將預約資訊新增到指定使用者就是一個事件。
每個事件都可能觸發一個或多個選項作為響應。
關於事件其實雲原生 CNCF 基金會在 2018 年託管了開源 CloudEvents 專案，該專案旨在用統一和規範的格式來描述事件，來加強不同的服務、平臺以及系統之間的互操作性。在該專案定義下，通用的事件規範是這樣的：
EDA 架構的落地實踐思考
在開始介紹落地實踐時，我們先來看一個經典的 EDA 架構模型：
所以這塊的中心節點（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 事件驅動還需要包括這些核心能力。
- 鬆耦合：事件驅動架構是高度鬆耦合且高度分散式的架構模型，事件的建立者（來源）只知道發生的事件，並不知道事件的處理方式，也關心有多少相關方訂閱該事件。
- 非同步執行：EDA 架構是非同步場景下最適合的執行工具，我們可以將需要事件保留在佇列中，直到狀態正常後執行。
- 可擴充套件性：事件驅動架構可以通過路由&過濾能力快速劃分服務，提供更便捷的擴充套件與路由分發。
- 敏捷性：事件驅動架構可以通過將事件分發至任何地方，提供更敏捷高效的部署方案。
當然，劣勢也很明顯：
- 架構複雜：事件驅動架構複雜，路由節點多，系統結成複雜，功能要求多。
- 路由分發難：事件路由及分發難，靈活的事件路由需要依賴強大的實時計算能力，對整體分發系統要求較高。
- 無法追蹤：事件追蹤是整個 EDA 架構保證，EDA 架構中往往很難追蹤到事件處理狀態，需要大量的定製化開發。
- 可靠性差：事件驅動由於需要多系統整合，可靠性通常較差，且交付無法保障。
阿里雲 EventBridge 如何解決 EDA 場景下的困境
針對 EDA 場景下面臨的這些問題，阿里雲推出了 EventBridge，一款無伺服器事件匯流排服務，其使命是作為雲事件的樞紐，以標準化的 CloudEvents 1.0 協議連線雲產品和應用，應用和應用，提供中心化的事件治理和驅動能力，幫助使用者輕鬆構建鬆耦合、分散式的事件驅動架構；另外，在阿里雲之外的雲市場上有海量垂直領域的 SaaS 服務，EventBridge 將以出色的跨產品、跨組織以及跨雲的整合與被整合能力，助力客戶打造一個完整的、事件驅動的、高效可控的上雲體驗。並針對 EDA 困境提供了針對性的解決方案。
路由分發：EventBridge 通過事件規則驅動，支援 8 大事件模式，4 重轉換器，滿足路由分發的全部訴求。
無法追蹤：獨家提供事件追蹤能力，事件分析/查詢能力。為使用者完善整體事件鏈路。
可靠性差：支援 DLQ/ 重試機制，大幅度保證由於使用者下游系統導致的事件故障與延遲。同時，在此基礎上 EventBridge 支援 82 種阿里雲產品，847 種事件型別。
阿里雲 EventBridge 更多場景介紹
1. 經典 EDA 事件驅動：事件匯流排（EventBridge）最重要的能力是通過連線應用程式，雲服務和 Serverless 服務構建 EDA（Event-driven Architectures） 事件驅動架構，驅動應用與應用，應用與雲的連線。
本文為阿里雲原創內容，未經允許不得轉載。