EventBridge 事件匯流排及 EDA 架構解析
簡介：EventBridge 是事件驅動的具體落地產品，也是 EDA 的最佳實踐方式。
作者：肯夢
作為 Gartner 定義的 10 大戰略技術趨勢之一，事件驅動架構（EDA）逐漸成為主流技術架構。根據 Gartner 的預估，在新型數字化商業的解決方案中，將有 60%使用 EDA，在商業組織參與的技術棧中，EDA 有一半的佔比。
當下比較成功的企業已然認識到，要想最大限度提升運營效率和客戶體驗，務必要將業務和技術兩方面的舉措緊密結合起來。運營事件或業務形勢的變化是時下眾多企業關注的焦點，這些變化能夠為企業領導者帶來切實有用的資訊，而架構設計的主旨恰恰是從客戶聯絡人、交易、運營等方面的資訊中獲取洞見，兩者相輔相成。傳統技術歷來對企業從事件中獲取洞見的速度有著諸多限制，比如用於記錄、收集和處理此類事件的批處理 ETL（提取、轉換、載入）等。基於以上背景，阿里雲 EventBridge 應運而生。
EventBridge 是事件驅動的具體落地產品，也是 EDA 的最佳實踐方式。
事件驅動（EDA）是什麼
早在 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.（不懂歷史的人註定會重蹈覆轍）。我們以史為鑑，來看看為什麼會架構會演進到事件驅動。
- 單體架構：在單節點服務中，單體應用的所有模組都封裝在單個程序執行，通訊通過相同堆疊呼叫完成。這種模式下非常容易導致結構和關係不明確，難以對系統進行更改和重構。就像一個不透明的，粘稠的，脆弱的，僵硬的 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 就不在細說了，感興趣的同學可以 wiki 搜尋下。
- EBI 架構：即 Entity，Boundary（介面），Interactor （控制）。EBI 架構將系統邊界視為完整連線，而不僅僅是檢視，控制器或介面。EBI 的實體代表持有資料並結束相關行為的實際實體，很類似阿里雲的 POP API。EBI 主要還是後端概念，它是與 MVC 相輔相成的。
- 洋蔥架構：洋蔥架構是一種低耦合，高內聚的架構模型。所有的應用程式圍繞獨立的物件模型構建，內層定義介面，外層實現介面，耦合方向向中心內聚，所有程式碼都可以獨立與基礎設施進行編譯和執行。
- SOA 架構：SOA 是 Service Orientated Architure 的縮寫，即面向服務架構。表示每一個功能都是通過一個獨立的服務來提供，服務定義了明確的可呼叫介面，服務之間的編排呼叫可完成一個完整的業務。其實這個架構也是目前架構中最成熟的，日常使用最多的架構模式。
在介紹完之前全部的架構趨勢後，在回過頭看看什麼是 EDA 架構。
EDA 事件驅動架構( Event-Driven Architecture ) 是一種系統架構模型，它的核心能力在於能夠發現系統“事件”或重要的業務時刻（例如交易節點、站點訪問等）並實時或接近實時地對相應的事件採取必要行動。這種模式取代了傳統的“ request/response ”模型，在這種傳統架構中，服務必須等待回覆才能進入下一個任務。事件驅動架構的流程是由事件提供執行的。
我們回過頭來看“事件”，剛剛介紹中比較的重要部分其實是將操作轉換為某類事件進行分發。那這的事件我們怎麼定義呢？
簡單來看，其實事件就是狀態的顯著變化，當用戶採取特定行動時觸發。以 4S 店售賣汽車為例：
- 當客戶購買汽車並且其狀態從 For Sale 變為 Sold 是一個事件；
- 成功交易後，從帳戶中扣除金額是一個事件；
- 單擊預訂試駕後，從將預約資訊新增到指定使用者就是一個事件；
每個事件都可能觸發一個或多個選項作為響應。
事件其實雲原生 CNCF 基金會在 2018 年託管了開源 CloudEvents 專案，該專案旨在用統一和規範的格式來描述事件，來加強不同的服務、平臺以及系統之間的互操作性。在該專案定義下，通用的事件規範是這樣的：
總結來看，事件驅動其實是將比較重要的業務時刻封裝成“事件”，並通過某個 EventBus 將事件路由給下游系統。
瞭解了 EDA 架構的整個處理過程，但是還沒解決這個所謂的“EventBus”到底是什麼？
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 架構的保證，EDA 架構中往往很難追蹤到事件處理狀態，需要大量的定製化開發；
可靠性差：事件驅動由於需要多系統整合，可靠性通常較差，且交付無法保障。
如何解決 EDA 場景下的困境
針對 EDA 場景面臨的這些問題，阿里雲推出了 EventBridge，一款無伺服器事件匯流排服務，其使命是作為雲事件的樞紐，以標準化的 CloudEvents 1.0 協議連線雲產品和應用、應用和應用，提供中心化的事件治理和驅動能力，幫助使用者輕鬆構建鬆耦合、分散式的事件驅動架構；另外，在阿里雲之外的雲市場上有海量垂直領域的 SaaS 服務，EventBridge 將以出色的跨產品、跨組織以及跨雲的整合與被整合能力，助力客戶打造一個完整的、事件驅動的、高效可控的上雲體驗。
阿里雲對 EventBridge 做了定義，核心價值包括：
- 統一事件樞紐：統一事件介面，定義事件標準，打破雲產品事件孤島；
- 事件驅動引擎：海量事件源，毫秒級觸發能力，加速 EDA/Serverless 架構升級；
- 開放與整合：提供豐富的跨產品、跨平臺連線能力，促進雲產品、應用程式、SaaS 服務相互整合。
架構層面
針對架構複雜問題，EventBridge 提供業內通用的 Source ，Buses，Rules，Targets 模組管理能力，同時支援 EventBus 和 EventStream 兩種模式，大幅度降低事件驅動架構難度。
功能層面
在功能層面，EventBridge 的核心亮點應用包括：
1）事件規則驅動
針對基於事件的路由分發，EventBridge 通過事件規則驅動，支援 8 大事件模式，4 重轉換器，滿足路由分發的全部訴求。
針對事件無法追蹤，獨家提供事件追蹤能力，事件分析/查詢能力。為使用者完善的全鏈路事件查詢分析能力。
針對可靠性差，支援 DLQ/重試機制，與事件全流程觸發，大幅度保證由於使用者下游系統導致的事件故障與延遲。
針對事件管理複雜，支援 Schema 註冊中心，支援事件資訊的解釋、預覽和上下游程式碼生成能力，幫助使用者低程式碼完成事件的收發處理。解決跨部門資訊溝通困難，業務程式碼冗餘等一系列事件管理問題。
5）同時，基於以上功能 EventBridge 支援對接 85 種以上的阿里雲產品，847 種事件型別。
阿里雲 EventBridge 更多場景介紹
經典 EDA 事件驅動
事件匯流排（EventBridge）最重要的能力是通過連線應用程式、雲服務和 Serverless 服務來構建 EDA（Event-driven Architectures） 事件驅動架構，驅動應用與應用，應用與雲的連線。
流式 ETL 場景
EventBridge 另一個核心能力是為流式的資料管道的責任，提供基礎的過濾和轉換的能力，在不同的資料倉庫之間、資料處理程式之間、資料分析和處理系統之間進行資料同步/跨地域備份等場景，連線不同的系統與不同服務。
統一事件通知服務
EventBridge 提供豐富的雲產品事件源與事件的全生命週期管理工具，您可以通過匯流排直接監聽雲產品產生的資料，並上報至監控，通知等下游服務。
重磅推薦
本篇是對 EventBridge 事件匯流排及 EDA 架構進行了整體介紹，若您意猶未盡，想要了解更多場景應用，可關注「阿里雲 EventBridge 系列公開課」，完整課程現已重磅推出！本次系列直播課共包含有 5 個 Topic ，帶您一起深入瞭解阿里雲 EventBridge 事件匯流排的核心功能及應用。
後期系列課具體安排如下，有興趣的小夥伴不要錯過哦～
本文為阿里雲原創內容，未經允許不得轉載。