前言：
從初代開源訊息佇列崛起，到 PC 網際網路、移動網際網路爆發式發展，再到如今 IoT、雲端計算、雲原生引領了新的技術趨勢，訊息中介軟體的發展已經走過了 30 多個年頭。
目前，訊息中介軟體在國內許多行業的關鍵應用中扮演著至關重要的角色。隨著數字化轉型的深入，客戶在使用訊息技術的過程中往往同時涉及交叉場景，比如同時進行物聯網訊息、微服務訊息的處理，同時進行應用整合、資料整合、實時分析等，企業需要為此維護多套訊息系統，付出更多的資源成本和學習成本。
在這樣的背景下，2022 年，RocketMQ 5.0 正式釋出，相對於 RocketMQ 4.0，架構走向雲原生化，並且覆蓋了更多的業務場景。
1. 背景
事件驅動是一個經典的概念，這篇文章主要探討雲時代的事件驅動和傳統的事件驅動相比有哪些不同？第一部分從技術理念的層面瞭解一下事件驅動的概念，第二部分會介紹 RocketMQ 5.0 面向雲時代的事件驅動架構推出的子產品 EventBridge，最後再結合幾個具體的案例幫助大家瞭解雲時代的事件驅動的常見場景和最佳實踐。
2. 事件驅動架構
2.1 事件驅動架構定義
先從事件驅動的定義來看，事件驅動本質上是一種軟體設計模式，它能夠最大化降低不同模組以及不同系統之間的耦合度。
這裡有一個典型的事件驅動架構圖，首先是事件生產者傳送事件到 EventBroker，然後 EventBroker 會把事件路由到對應的消費者進行事件處理。事件處理能夠靈活擴充套件，隨時增減事件消費者，事件生產者對此透明。
為什麼說事件驅動是個很經典的設計模式呢？因為早在幾十年前，就出現過多種事件驅動的技術，比如桌面客戶端程式設計框架，點選按鈕就可以觸發 onclick 事件，開發者編寫業務邏輯響應事件。在程式語言上，也經常會採用事件驅動的程式碼模式，比如 callback、handler 這類的函式。進入分散式系統的時代，系統之間的通訊協同也會採用事件驅動的方式。
閱讀過《RocketMQ 5.0 架構解析：如何基於雲原生架構支撐多元化場景》一文的讀者可能會發現，這裡的圖和之前 RocketMQ 的訊息應用解耦圖很像。沒錯，無論是訊息的釋出訂閱，還是事件的生產消費，都是為了進行程式碼解耦、系統解耦。訊息佇列更偏技術實現，大部分的 EventBroker 都是基於訊息佇列實現的，而事件驅動則更偏向於架構理念。
2.2 事件的特徵
從技術角度來看，訊息佇列是和 RPC 對應的，一個是同步通訊，一個是非同步通訊。訊息佇列並不會規定訊息的內容，只負責傳輸二進位制內容。如果從技術實現來看，的確，EDA 需要的核心技術就是訊息佇列的技術。事件驅動跟訊息驅動最大的區別就是：事件是一種特殊的訊息，只有訊息滿足了某些特徵，才能把它叫做事件。
打個比方，看左邊這個圖。訊息就像是一個抽象類，有多種子類，最主要的就是 Command 和 Event 兩種。以訊號燈為例，向訊號燈傳送開啟的訊息，這就是一種 Command，訊號燈接受這個 Command 並開燈。開燈後，訊號燈對外發出訊號燈變成綠色的訊息，這個就是一種 Event。
對於事件（Event）來說，有四個主要的特徵：
1. 不可變的，事件就是表示已經發生了的事情，已經成為事實。
2. 有時間概念，並且對同一個實體來說事件的傳送是有序的。如訊號燈按順序傳送了綠、黃、紅等事件。
3. 無預期的，這個就是 EDA 架構之所以能夠實現最大化解耦的特點，事件的產生者對於誰是事件消費者、怎麼消費這個事件是不關心的。
4. 徹底解耦的，並且對於下游怎麼去消費事件沒有預期，所以事件是具象化的，應該包括儘可能詳盡的資訊，讓下游消費者各取所需。比如交通訊號燈事件，包含多個欄位：它的來源是誰？它的型別是什麼？它的主題是什麼？是具體哪一個訊號燈？它還會包含唯一的 ID 便於跟蹤，以及事件發生時間、事件內容。
2.3 雲時代的事件驅動
在全行業數字化轉型的時代，事件驅動架構應用範圍擴大，成為 Gartner 年度十大技術趨勢。在新型的數字化商業解決方案裡，會有 60% 採納 EDA 架構。
事件驅動作為一個經典的架構模式，為什麼會在雲時代再度成為焦點呢？主要有幾個原因：
1. 因為雲原生技術的快速發展和廣泛應用，其中之一是微服務。微服務是雲原生應用架構的核心，引入微服務架構，數字化企業能夠按照小型化的業務單元和團隊劃分，以“高內聚、低耦合”的方式高效協作。但是微服務架構也會帶來新的問題，比如大量同步微服務會面臨延遲增大、可用性降低等風險，採用事件驅動的微服務體系，可提高微服務的韌性，降低延遲，實現更徹底的解耦。
2. 雲原生代表技術 Serverless 架構正規化本身也是事件驅動的。現在主要的 Serverless 產品形態，無論是阿里雲函式計算 FC、還是 AWS Lambda，它們的主要觸發源都是各種形態的事件，比如雲產品事件，OSS 檔案上傳，觸發使用者基於函式進行檔案加工處理計算；使用者業務事件，EventBroker 觸發函式執行消費邏輯；雲產品運維事件，使用者透過響應事件，在雲平臺的基礎上擴充套件自己的自動化運維體系。事件驅動架構的大規模使用，能夠幫助數字化企業釋放雲端計算 Serverless 的技術紅利。
3. IoT 也是事件驅動架構的重要推動力，有大量的 IoT 應用構建都是基於事件驅動的，比如感測器上報裝置事件，溫度變化事件、地址位置變化事件等等，雲端應用訂閱這些事件觸發對應的業務流程。
4. 數字經濟時代，在全行業大規模數字化轉型後，跨組織業務逐步從線下搬到線上，數字化商業生態規模會持續擴大，跨組織業務協同更需要徹底解耦。而 EDA 天然具備的非同步、解耦的特性，就可以解決這一系列的問題。比如阿里聚石塔業務就是事件驅動的模式，聚石塔實時釋出交易事件，合作伙伴包括 ISV、軟體服務商、品牌商家訂閱消費交易事件，建設個性化的 CRM、商家運營、後臺管理系統等等，形成一個龐大的電子商務數字化生態。
3. EventBridge
3.1 雲時代的事件驅動能力抽象
接下來進入第二部分，RocketMQ 5.0 的 EventBridge。在系統瞭解技術實現之前，我們先來了解一下 EventBridge 對事件驅動的通用能力抽象，也可以瞭解到 EventBridge 的領域模型。
我們從左往右看這張圖。
最左邊是事件源，因為這個事件是希望被跨平臺消費的，所以我們希望採用業界標準的事件格式。同時，事件是有可能被跨組織消費的，所以我們需要一個統一的事件中心，讓這些不同的事件源都註冊到這個事件中心。對消費者來說，就好比是一個事件商店，能夠選擇自己感興趣的事件訂閱。
在事件消費者開始編寫消費邏輯的時候，還需要對這個事件的格式有更清楚的瞭解，需要知道這個事件有哪些內容，有哪些欄位，分別是什麼含義，才能編寫正確的消費業務邏輯。所以，EventBridge 還提供了 schema 中心，消費者對於事件格式也就一目瞭然，不用跟事件源的發起者進行溝通了，整個效率也得到了大幅度的提升。
再往右看，就到了事件消費的環節，因為事件的消費者種類很多，不同消費者關注不同的事件型別，EventBridge 需要提供豐富的過濾規則。即便多個消費者對同一個事件感興趣，但可能只需要事件的部分內容，EventBridge 還提供了事件轉換的能力。
這就是 RocketMQ 5.0 對事件驅動的能力抽象。
3.2 統一事件標準
在雲端計算以及大規模數字化轉型的時代，我們強調事件驅動架構往往跨越了不同的組織，不同的平臺。所以事件驅動架構需要一個統一的事件標準。在 EventBridge 產品中，我們採用了 CNCF 基金會的 CloudEvents 標準，這是業界事件的事實標準，為了簡化事件宣告，提升事件在跨服務、跨平臺的互操作性。
CloudEvents 帶來了很多價值：
- 提供了一種規範，使得跨組織、跨平臺的事件整合，有了共同語言，加速更多的事件整合。
- 隨著 Serverless 的普及，各大雲廠商都提供函式計算的服務，有了 CloudEvents 規範，使用者在函式計算的使用上就可以實現無廠商繫結。
- webhook 是一種通用的整合模式，有了 CloudEvents 規範作為統一格式，不同系統的 webhook 能實現更好的互操作性。
- 基於這樣統一的規範，更有利於沉澱事件驅動的基礎軟體設施，比如跨服務的事件 Tracing 鏈路追蹤。
3.3 RocketMQ - EventBridge
下圖是 RocketMQ 面向 EDA 場景全新推出的產品形態 EventBridge。它的核心技術都是基於 RocketMQ，但是在產品介面上面向事件驅動的業務進行一層抽象，核心領域物件從訊息變成 CloudEvents。基於統一事件標準來構建事件驅動的數字生態。
它的事件源是多樣化的，可以是雲產品事件，可以是 SaaS 平臺事件，應用自定義事件、通用的 WebHook。當然，它的事件目標更是多樣化的，透過事件規則引擎把事件路由到不同的消費者，典型的消費者比如函式計算，儲存系統，訊息通知（如釘釘、簡訊），還有通用的 webhook。透過事件驅動這種徹底解耦的架構，更適合建設混合雲、多雲的數字化系統。
事件 Schema
為了提升事件驅動的研發效率，EventBridge 也支援 Schema 的特性，支援事件資訊的解釋、預覽，甚至還可以自動化的生成程式碼，讓開發者以低程式碼、0 程式碼的方式完成事件整合。
事件規則引擎
EventBridge 的另一個比較重要的特性是事件規則引擎。因為不同的事件消費者，對於事件的興趣是不一樣的。所以我們提供了七種事件過濾模式，包括字首匹配、字尾匹配、除外匹配、數值匹配等等，可以進行各種複雜的組合邏輯過濾，只推送消費者感興趣的事件。
當然，就算都關心同一個事件，不同消費者對事件內部的資訊關注點也會有所不同。為了提升事件消費效率，我們也提供了四種事件轉化器，可以只推送給消費者它關心的事件欄位。還可以對事件進行自定義的模板轉化，滿足更靈活的業務訴求。
事件可觀測
作為 RocketMQ 的子專案，在 EventBridge 裡也同樣提供了完整的可觀測能力。能夠根據事件的時間、型別查詢事件列表。每個事件都會生成唯一 ID。使用者可以根據唯一 ID 去精確的定位事件的內容、發生時間、對應的事件規則，下游的消費狀況，精準排查問題。
4. 典型案例
接下來結合幾個典型案例來看 EventBridge 的使用場景。
4.1 案例一：多種雲產品事件處理場景
C 客戶是一家以智慧消費終端為核心的科技公司，希望收集賬號裡全部的雲上事件，方便後續做分析或故障處理。公共雲的 EventBridge 匯聚了所有的雲產品事件，透過 EventBridge，客戶能收集全量的事件並對其進行自定義的業務處理。還能夠配置事件規則，過濾異常事件推送給監控系統或者釘釘，及時關注處理。
4.2 案例二：SaaS 事件整合場景
現在隨著整個雲端計算生態的繁榮，有不少企業不僅使用了公共雲的 IaaS、PaaS 產品，也會同時使用三方的 SaaS 產品，比如各種 ERP、CRM 等系統。基於 EventBridge 標準的 HTTP、webhook 的整合能力，能夠無縫連線三方 SaaS 系統作為事件源，企業能夠收集到他所關心的所有 SaaS 事件，方便後續管理，比如申請單、入職單、報銷單、訂單等等這些場景。
4.3 案例三：SaaS 平臺整合場景
以釘釘為例，釘釘是典型的 SaaS 平臺，有繁榮的生態，擁有 4000+ 家的生態夥伴，包括 ISV 生態夥伴、硬體生態夥伴、服務商、諮詢生態和交付生態夥伴等等。透過 EventBridge 把公共雲的 Paas 層生態和釘釘的 SaaS 層生態連線起來，而且依賴 EventBridge 完成整體事件生命週期的管理，以 WebHook 的形式推送給下游 ISV 接收端。比如釘釘的官方事件源，包括視訊會議、日程、通訊錄、審批流、釘盤、宜搭等，企業和 SaaS 廠商可以充分利用這些官方應用的事件構建企業級的應用系統，也可以把釘釘的官方資料流和其他系統做深度整合。
5. 總結
透過這篇文章，我們深入探討了雲時代 EDA 的新內涵，它在雲時代再次流行的主要驅動力，包括技術驅動力，（如物聯網技術、雲原生技術）和商業驅動力（伴隨著數字化商業生態的繁榮被更多的採納）。
之後，我們重點介紹了，面向雲時代的事件驅動場景，RocketMQ 5.0 推出的子產品 EventBridge，它的特點就是擁抱行業標準，使其具備跨平臺、跨組織的事件連結能力。它提供了強大的規則引擎，可以靈活連線事件上下游。同時，它還提供了 Schema 能力，使得整個事件驅動的使用者體驗和研發生產力有進一步的提升。
最後，我們透過幾個雲時代事件驅動的典型案例，幫助大家進一步瞭解雲時代事件驅動的常見場景和最佳實踐。比如，在使用者全面上雲之後，怎麼統一管理雲產品事件；怎麼利用多個 SaaS 平臺的事件建設自己的業務系統；作為 SaaS 平臺本身，又要如何基於 EventBridge 對外開放標準事件，構建平臺生態。
作者：林清山（隆基）
原文連結
本文為阿里雲原創內容，未經允許不得轉載。