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