作者：沈林

(資料圖片)

前言

事件驅動，這個詞在部分人印象中，它是一個過時的技術——沒什么新意。從時間上看，確實也是這樣，上世紀 60 年代，事件驅動就已經被正式提出，經常會被在 GUI 編程中。但是在有些人印象中，事件驅動又是一個非常陌生，非常新穎的技術。

不管怎么樣，現實是已經有越來越多的公司，開始或則經把事件驅動架構應用到企業的核心業務中，包括：阿里巴巴、喜力、聯合利華、美國聯邦航空管理局、銀行資本市場等等。市場上，也有很多公司推出了自己的產品或解決方案，比如阿里云、AWS、Google，Solace。行業里也孕育出了事件的標準：CloudEventsGartener，則把事件驅動定義為未來十大趨勢之一；

這個時候，我們就要問了，事件驅動架構到底是什么呢？為什么現在，被越來越多的人，開始關注事件驅動架構了呢？

5 月 28 日，GOTC 2023 全球開源技術峰會上，阿里云智能技術專家沈林發表主題演講：Apache RocketMQ 事件驅動引擎。

Apache RocketMQ PMC&阿里云智能技術專家：沈林

什么是事件？

說到事件驅動架構，大家第一印象往往會把重點放在“架構”這兩個字上，但是，事件驅動架構很大的魅力其實來源于前面“事件”兩個字，所以今天，我們先一起看下什么是事件。RocketMQ 之前一直給人的印象是一個消息引擎，那為什么我們在前段時間發布的 5.0 版本中，引入了事件？消息跟事件，又有什么區別呢？

事件，如果我們查閱字典，他會給你這樣一個解釋：事件是指過去已經發生的事，尤其是比較重要的事。

這個很好理解啊。比如，GOTC 大會今天在上海正式開幕了；剛才我的手機鈴聲響了；這些都是過去已經發生的事件。

但是，如果我們接著剛才的問題問：事件跟消息有什么區別呢？這個時候，大家是不是覺得事件這個定義，好像又不那么清晰了？剛才我們說的那些事件，是不是也可以理解為消息？如果這個時候，老張給我發送了一條短信，那這個短信，算是事件，還是消息呢？

我們可以通過這張圖，來簡單理解消息和事件的關系。消息包含兩類，一類是 Command 消息，另一類就是 Event 消息。

1、Command 消息是什么？我們看下面左邊這張圖，外部系統發送給本系統的一條操作命令，就是Command消息；

2、那什么是 Event 消息呢？再看下面右邊這張圖，本系統收到外部 Command 操作請求，系統內部發生改變之后，就產生了 Event；

所以，事件和消息稍微有些不同。事件，可以理解為是一種特殊的消息，那事件特殊在什么地方呢？主要包含 4 個方面：

事件的特性 1：已發生且不可變的

事件，一定是“已發的”?！耙寻l生”的代表什么呢？不可變的。我們不可能改變過去，除非你有超能力。這個特性非常重要，在我們處理事件、分析事件的時候，這就意味著，我們絕對可以相信這些事件，只要是收到的事件，一定是系統真實發生過的行為，而且是 Immutable，不可修改。

對比 Command 消息，Command 的中文是什么？命令！很顯然，它還是沒有發生的，而是表達了一種期望。我們知道，“期望的”不一定會成功發生。比如：

• 把廚房的燈打開；
• 去按下門鈴；
• 轉給 A 賬戶 10w；

這些都是 Commond，都是期望發生的行為。但是，最終有沒有發生呢？并不知道。

Event 則是明確已經發生的事情。比如：

• 廚房燈被打開了；
• 有人按了門鈴；
• A 賬戶收到了 10w

事件的特性2：無期望的

事件的第二個特性是：無期望的。事件是客觀的描述一個事物的狀態或屬性值的變化，但對于如何處理事件本身并沒有做任何期望。相比之下，Commond 則是有期望的，它希望系統做出改變；但是 Event，它只是客觀描述系統的一個變化。我們舉一個例子：交通信號燈從綠燈變成紅燈，它就是一個事件。事件本身并沒有任何期望，說要求行人或汽車禁止通行，而是交通法規需要紅綠燈，并賦予了其規則。

所以，系統，一般不會定向的、單獨向一個指定的系統發送事件，而是統一的告訴“事件中心”?！笆录行摹蹦抢锩嬗懈鱾€系統上報上來的，各式各樣的事件。系統會向事件中心說明：自己這個系統，會產生哪些事件，這些事件的格式是怎么樣的；別的系統如果感興趣，就可以來主動訂閱這些事件；真正賦予事件價值的，是事件消費者。事件消費者想看看，某個系統發生了什么變化？OK，那他就去訂閱這些事件，所以事件是消費者驅動的。

這跟消息有什么區別呢？Commond 消息的發送和訂閱，是雙方約定好的，外人不知道，往往是以文檔或代碼的形式，大家按約定好的協議，發送和訂閱消費，這個過程往往是生產者驅動的。

打個比喻，事件就像市場經濟，商品被生產出來，具體有什么價值，有多大價值，很大程度上看其消費者。我們能看到系統中各種各樣的事件，就像櫥窗里擺放了各種各樣的商品；而 Commond 消息，有點像計劃經濟，一出生就帶著很強的目的性，“我”就是要“分配”給誰消費。

事件的特性 3：天然有序且唯一的

事件的第三個特性是：“天然有序且唯一的”。同一個實體，不能同時發生 A 又發生 B，必有先后關系；如果是，則這兩個事件必屬于不同的事件類型。細心的同學，肯定發現了一點，這里其實隱藏了事件的一個額外屬性：因為天然有序，跟時間軸上的某一時刻強綁定，且不能同時發生，所以它一定是唯一的。

如果我們看到了兩個內容一樣的事件，那么一定是發生了兩次，而且一次在前，一次在后。這對于我們處理數據最終一致性、以及系統行為分析都很有價值：我們看到的，不光是系統的一個最終結果，而是看到變成這個結果之前的，一系列中間過程。

事件的特性 4：具象化

事件的第四個特性是：“具象化”。事件會盡可能的把“案發現場”完整的記錄下來，因為它也不知道消費者會如何使用它，所以它會做到盡量的詳盡，包括：什么時候發生？是由誰產生的事件？是什么類型的事件？是誰發送的事件？事件的唯一性標志是什么？事件的內容是什么？等等。

再對比我們常見的消息，因為上下游一般是確定的，常常為了性能和傳輸效率，則會做到盡可能的精簡，只要滿足“計劃經濟”指定安排的消費者需求即可。

什么是事件驅動架構？

講完事件，我們再回過頭來，一起看看，什么是事件驅動架構。為了方便理解，我們舉一個簡單的例子：我們都知道：交易系統在完成訂單交易之后，有很多系統都“需要”知道這個訂單信息，比如：

• 物流系統，需要知道這個訂單信息，來安排發貨；
• 積分系統，需要知道這個訂單信息，來重新計算這個用戶的積分；
• 營銷系統，需要知道這個訂單信息，來計算當天的實時交易額。

這里我們有三種方式來實現上游交易系統和下游物流、積分、營銷系統的集成。

上下游集成

方式 1：主動調用

一種最簡單的實現方式是：交易系統依次調用每個系統，把訂單信息發出去。比如下圖這種方式：

但我們都知道，這個設計，是非常糟糕。尤其當越來越多的系統加進來時，不僅開發成本高，而且萬一其中一個系統出現問題，處理不好，很容易影響其他系統的發送。

方式 2：消息異步解耦

一個很自然的解決方案是：我們將訂單信息，發送到中間的一個消息 broker 服務。然后，物流系統、積分系統、營銷系統只需要去訂閱 Broker 的這些交易訂單消息就可以了，非常簡單清晰。

方式 3：事件驅動架構

那如果是在事件驅動架構中，應該怎么做呢？交易系統，依舊會將交易訂單發送到我們中間的 Broker 服務，但是下游服務不再需要主動訂閱 Broker 中的交易訂單，而往往是 Broker 推送給下游系統。這個時候，大家可能既有疑問了，這個好像跟方式 2 消息異步解耦，沒有太大的區別吧？難道事件驅動架構，就是簡單的把 Pull 模式變成了 Push 模式？

這里我們圍繞上游和下游，看看事件驅動架構帶來了什么改變。

面向下游

1、耦合的膨脹

這里我們衍生一下，很多時候，下游的營銷系統它不是只依賴一個交易系統產生的訂單數據，比如：它可能同時需要淘寶的交易訂單、京東的交易訂單、拼多多的交易訂單，來實時計算一個當前時刻匯總值。這個時候，在“消息異步解偶” 的架構中，客戶的營銷系統需要做兩件事：

第一，訂閱三個 Broker 服務，來獲取淘寶、京東、拼多多的交易訂單數據；

第二，由于淘寶、京東、拼多多的交易訂單數據格式，是不同的，所以客戶的營銷系統，需要對三種數據格式進行適配，先轉換成營銷系統內部期望的數據格式，然后再處理。

而且，如果后面客戶又在抖音開店，客戶的營銷系統需要再適配一遍；如果某家的訂單數據格式發生變化，那客戶營銷額系統也必須聯動的進行更新。

如果在事件驅動架構中，客戶的營銷系統，需要怎么做呢？他什么都不需要，只要登高一聲大喊：“我需要什么樣的訂單事件格式，我提供一個 API，其他系統就按這個訂單事件格式發給我就可以了”。EventBroker 會將上游的事件轉換成客戶營銷系統需要的數據格式，發送給他的 API。不管接多少系統的交易訂單、不管外部系統怎么變，反正我不變。

2、耦合方向

這里我們分析下這三種方式的耦合關系：我們要知道，耦合是有方向性的。

• 方式 1-直接調用:是上游 A 依賴下游 B；（一旦下游 B 發生改變，A 需要同步的改變）
• 方式 2-消息異步解偶：是 B 依賴于 A；（一旦上游 A 的數據格式，發生改變，B 需要同步的改變）
• 方式 3-事件驅動：A 不依賴于 B，B 也不依賴于 A；（所有的耦合，都由中間的 Event Broker 來統一處理和維護）

3、影響系統穩定的因子有哪些？

除了降低依賴，下游系統在開發的時候，最關注的是什么？對大部分業務場景來說，最重要的是：開發維護成本低、穩定又可靠。不過，在消息異步解偶架構中，大家有沒有發現，影響當前下游這個系統發生變化的入口，是不是有兩個？(就是下面咖啡色的部分) 一個是 API；一個是消息訂閱。

一個系統，有兩個入口會引起發生變化，是一件非常麻煩的事。這意味著：我們在開發和維護這個系統的穩定性時，需要守護好兩個口子：無論是身份認證、審計、安全、流控、測試、維護等等，我們都要兩邊考慮。不僅成本高，而且很容易出問題。

4、可測試性和可維護性

在事件驅動架構模式中，下游系統只需要提供一個 API 入口。

• 對外：這個 API，既是用來接收上游的事件，也可以用來和其他系統間的通訊；
• 對內：這個 API 的設計，是圍繞下游系統當前自己的領域模型去設計的，不需要去適配任何其他系統。

所以整個系統，會非常簡約。簡約的好處是：當我們需要變更系統時，只需要保障我們提供的 API 可靠，可測試性和可維護性都大大提升。

5、Serverless

事件驅動還有一個非常大的優勢是可以通過事件的方式，按量驅動 Serverless，去進行消費。還是在我們交易訂單這個場景下：

• 有些小商家的的訂單量其實沒有那么多，那單獨部署一個積分系統服務，7*24 小時一直跑著，是很浪費的一種行為。這個時候，如果通過事件驅動模式：當只有交易訂單事件產生時，才去觸發下游 Serverless 服務，按量計算付費，能夠極大的降低我們的成本；
• 而對有些商家，交易訂單量非常大，尤其是遇到節日大促的時候，流量峰值會非常高，這個時候，如果通過事件驅動模式，按量觸發 Serverless 進行計算，能夠更好的提升系統的處理能力的峰值。
• 另外，如果下游系統會因為某些異常事件，影響系統穩定性。那通過事件驅動觸發 Serverless 的方式，天然的，就可以提供很好的隔離性，并實現快速恢復。

Serverless 已經逐步成為云原生時代一股勢不可擋的趨勢，而事件驅動和 Serverless 則是一對最好的兄弟組合。

面向上游

SaaS 集成

上面都是圍繞下游展開，那對于上游系統來講，事件驅動的意義在哪呢？我們想一下，對上游系統來講，它最關心的是什么？它關心的肯定不是系統的穩定性和解耦這些東西，不是說這些東西不重要，而是對上游系統來講，發送到消息 Broker，和事件 Broker 沒什么區別。那什么對上游系統來說是最重要的呢？這里本質上是，上游系統希望可以和更多的系統實現集成，來打造自己的生態位。

這個怎么理解呢？我們舉一個例子：門禁打卡系統。

門禁打卡系統，賣給不同的公司，需要支持員工打卡的記錄信息同步到不同公司的 ERP 系統中，這個時候，如果門禁打卡系統自己 One By One 去集成適配各個公司的 ERP 系統，成本是非常高的，幾乎不現實；如果不去集成，可能很多公司可能就不買你的了。

所以，對于上游系統來說，能夠省心省力的與生態內的產品方便集成，是最重要的事情。而在事件驅動架構模式中，門禁打卡系統只需要以事件的形式，把員工打卡事件記錄下來，交給事件中心，剩下的事情就不用操心了。事件中心會統一負責下游生態的集成對接。

另外，對于門禁打卡系統本身，它也需要知道新員工的入職事件，因為只有這樣，在新員工打卡的時候，才能夠及時識別。如果通過事件驅動模式，門禁打卡系統就可以輕松的在 SaaS 生態中，從零開始，快速打造自己的生態位。

如何做一個優秀的事件驅動引擎

前面講了這么多，了解了什么是事件以及什么是事件驅動架構。也了解到事件驅動架構獨特的一些魅力：為什么事件驅動架構，被越來越多的公司喜歡。

最后，我們講一下，如果要做一個優秀的事件驅動引擎，需要具備哪些能力？我們 RocketMQ EventBridge 怎么做的？

需要什么樣的能力？

第一，我們肯定得有一個事件標準。因為事件不是給自己看的，也不是給他看的，而是給所有人看的。事件沒有明確的消費者，所有都是潛在的消費者，我們得規范化事件的定義，讓所有人都能看得懂，一目了然；

第二，我們得有一個事件中心，事件中心里有所有系統注冊上來的各種事件。這個有點類似市場經濟大賣場，玲瑯滿目，里面分類擺放了各種各樣的事件，所有人即使不買，也都可以進來瞧一瞧，看一看，有哪些事件，可能是我需要的，那就可以買回去；

第三，我們得有一個事件格式，用來描述事件的具體內容。這相當于市場經濟的一個買賣契約。生產者發送的事件格式是什么，得確定下來，不能總是變；消費者以什么格式接收事件也得確定下來，不然整個市場就亂套了；

第四，我們得給消費者一個，把投遞事件到目標端的能力，并且投遞前，可以對事件進行過濾和轉換，讓它可以適配目標端 API 接收參數的格式，我們把這個過程統一叫做訂閱規則。

第五，我們還得有一個存儲事件的地方，就是最中間的事件總線。

如何描述事件

關于剛才提到的第一點事件標準，這個很重要。事件標準，就相當于不同系統之間交流的語言，如果語言都不通，相互交流肯定會出很多問題。我們推薦使用 CNCF 旗下的開源 CloudEvents 協議，目前已經很多公司廣泛集成，算是一個事實上的標準。CloudEvent 協議也很簡單，我們有一個簡單的例子, 詳細可以參考官網 [1]：

{  "specversion":"1.0",  "type":"com.github.pull_request.opened",  "source":"https://github.com/cloudevents",  "subject":"123",  "id":"A234-1234-1234",  "time":"2018-04-05T17:31:00Z",  "comexampleextension1":"value",  "comexampleothervalue":5,  "datacontenttype":"text/xml",  "data":""}

事件中心

另外，我們必須得有一個事件中心。事件中心對于事件驅動架構來說，是非常重要的一個角色。他就像我們剛才說的市場經濟的大賣場，所有的事件，在這個大賣場里，都有詳細的使用說明，大家都可以進來瞧一瞧，看一看，覺得合適，就訂閱買走。

至于事件中心如何管理，我們可以從API管理里學習很多經驗：我們知道 API 包含注冊、Schema 描述、Sample、文檔、SDK、測試、監控。Event，其實也是一樣，它需要在事件中心被注冊，定義 Schema 描述、Sample、文檔、CodeBinding、測試、監控。

這樣消費者拿到這個事件的時候，才知道是什么，怎么用，用的放心。

Schema

事件的 Schema，是用來描述事件中有哪些屬性、含義等等信息。為什么我們要引入Schema？一方面是，為了讓下游能夠理解事件的格式，方便使用事件；另一方面，也是為了限制上游發送事件的格式，發送和修改都必須保障兼容，一旦契約簽訂，不能輕易修改。我們推薦使用 Json Schema 和 OpenAPI 3.0。

事件過濾和轉換

關于事件的過濾和轉換，RocketMQ 事件驅動引擎 提供了豐富的事件過濾和轉換方式。這些我就不具體一一展開了，詳細大家可以上圖描述。

RocketMQEventBridge 技術架構

最后，我們 RocketMQ 圍繞事件驅動推出的產品，叫做 EventBridge，他的整個架構可以分為兩部分：上面是我們的控制面、下面是我們的數據面。

控制面：面向上游，做好事件的管理。通過 EventSource，把上游產生的事件，管理起來，讓大家找得到需要的事件，找到事件后，知道怎么用；面向下游，可以通過 EventRule，讓消費者，方便的把事件轉換成需要的格式，并推送給自己。中間的 EventBus，是我們存儲事件的地方，底下使用的是我們 RocketMQ 自己的Broker；數據面：是事件的通道，我們除了可以通過API 發送事件到EventBus之外，還可以通過Source Connector主動拉事件到EventBus。消費者創建EventRule之后，則可以通過 Sink Connector 將事件，推送到目標端；除此之外，我們還會有：事件追蹤、事件回放、事件分析、事件歸檔等等。

歡迎加入我們

大家如果想進一步了解 EventBridge，可以點擊下方鏈接，也可以一起參與社區的建設。

RocketMQ EventBridge：

https://github.com/apache/rocketmq-eventbridge

RocketMQ 學習社區體驗地址

RocketMQ 學習社區重磅上線！AI 互動，一秒了解 RocketMQ 功能源碼。RocketMQ 學習社區是國內首個基于 AIGC 提供的知識服務社區，旨在成為 RocketMQ 學習路上的“貼身小二”。

PS：RocketMQ 社區以 RocketMQ 5.0 資料為主要訓練內容，持續優化迭代中，回答內容均由人工智能模型生成，其準確性和完整性無法保證，且不代表 RocketMQ 學習社區的態度或觀點。

相關鏈接：

[1]官網https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md

點擊此處，立即體驗RocketMQ 學習社區（建議 PC 端體驗完整功能）

關鍵詞：