作者：沈林

(資料圖片)

前言

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

不管怎么樣，現(xiàn)實是已經(jīng)有越來越多的公司，開始或則經(jīng)把事件驅(qū)動架構(gòu)應(yīng)用到企業(yè)的核心業(yè)務(wù)中，包括：阿里巴巴、喜力、聯(lián)合利華、美國聯(lián)邦航空管理局、銀行資本市場等等。市場上，也有很多公司推出了自己的產(chǎn)品或解決方案，比如阿里云、AWS、Google，Solace。行業(yè)里也孕育出了事件的標(biāo)準(zhǔn)：CloudEventsGartener，則把事件驅(qū)動定義為未來十大趨勢之一；

這個時候，我們就要問了，事件驅(qū)動架構(gòu)到底是什么呢？為什么現(xiàn)在，被越來越多的人，開始關(guān)注事件驅(qū)動架構(gòu)了呢？

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

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

什么是事件？

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

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

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

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

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

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

2、那什么是 Event 消息呢？再看下面右邊這張圖，本系統(tǒng)收到外部 Command 操作請求，系統(tǒng)內(nèi)部發(fā)生改變之后，就產(chǎn)生了 Event；

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

事件的特性 1：已發(fā)生且不可變的

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

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

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

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

Event 則是明確已經(jīng)發(fā)生的事情。比如：

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

事件的特性2：無期望的

事件的第二個特性是：無期望的。事件是客觀的描述一個事物的狀態(tài)或?qū)傩灾档淖兓珜τ谌绾翁幚硎录旧聿]有做任何期望。相比之下，Commond 則是有期望的，它希望系統(tǒng)做出改變；但是 Event，它只是客觀描述系統(tǒng)的一個變化。我們舉一個例子：交通信號燈從綠燈變成紅燈，它就是一個事件。事件本身并沒有任何期望，說要求行人或汽車禁止通行，而是交通法規(guī)需要紅綠燈，并賦予了其規(guī)則。

所以，系統(tǒng)，一般不會定向的、單獨向一個指定的系統(tǒng)發(fā)送事件，而是統(tǒng)一的告訴“事件中心”。“事件中心”那里面有各個系統(tǒng)上報上來的，各式各樣的事件。系統(tǒng)會向事件中心說明：自己這個系統(tǒng)，會產(chǎn)生哪些事件，這些事件的格式是怎么樣的；別的系統(tǒng)如果感興趣，就可以來主動訂閱這些事件；真正賦予事件價值的，是事件消費者。事件消費者想看看，某個系統(tǒng)發(fā)生了什么變化？OK，那他就去訂閱這些事件，所以事件是消費者驅(qū)動的。

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

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

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

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

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

事件的特性 4：具象化

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

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

什么是事件驅(qū)動架構(gòu)？

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

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

這里我們有三種方式來實現(xiàn)上游交易系統(tǒng)和下游物流、積分、營銷系統(tǒng)的集成。

上下游集成

方式 1：主動調(diào)用

一種最簡單的實現(xiàn)方式是：交易系統(tǒng)依次調(diào)用每個系統(tǒng)，把訂單信息發(fā)出去。比如下圖這種方式：

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

方式 2：消息異步解耦

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

方式 3：事件驅(qū)動架構(gòu)

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

這里我們圍繞上游和下游，看看事件驅(qū)動架構(gòu)帶來了什么改變。

面向下游

1、耦合的膨脹

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

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

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

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

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

2、耦合方向

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

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

3、影響系統(tǒng)穩(wěn)定的因子有哪些？

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

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

4、可測試性和可維護性

在事件驅(qū)動架構(gòu)模式中，下游系統(tǒng)只需要提供一個 API 入口。

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

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

5、Serverless

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

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

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

面向上游

SaaS 集成

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

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

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

所以，對于上游系統(tǒng)來說，能夠省心省力的與生態(tài)內(nèi)的產(chǎn)品方便集成，是最重要的事情。而在事件驅(qū)動架構(gòu)模式中，門禁打卡系統(tǒng)只需要以事件的形式，把員工打卡事件記錄下來，交給事件中心，剩下的事情就不用操心了。事件中心會統(tǒng)一負(fù)責(zé)下游生態(tài)的集成對接。

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

如何做一個優(yōu)秀的事件驅(qū)動引擎

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

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

需要什么樣的能力？

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

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

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

第四，我們得給消費者一個，把投遞事件到目標(biāo)端的能力，并且投遞前，可以對事件進行過濾和轉(zhuǎn)換，讓它可以適配目標(biāo)端 API 接收參數(shù)的格式，我們把這個過程統(tǒng)一叫做訂閱規(guī)則。

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

如何描述事件

關(guān)于剛才提到的第一點事件標(biāo)準(zhǔn)，這個很重要。事件標(biāo)準(zhǔn)，就相當(dāng)于不同系統(tǒng)之間交流的語言，如果語言都不通，相互交流肯定會出很多問題。我們推薦使用 CNCF 旗下的開源 CloudEvents 協(xié)議，目前已經(jīng)很多公司廣泛集成，算是一個事實上的標(biāo)準(zhǔn)。CloudEvent 協(xié)議也很簡單，我們有一個簡單的例子, 詳細(xì)可以參考官網(wǎng) [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":""}

事件中心

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

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

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

Schema

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

事件過濾和轉(zhuǎn)換

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

RocketMQEventBridge 技術(shù)架構(gòu)

最后，我們 RocketMQ 圍繞事件驅(qū)動推出的產(chǎn)品，叫做 EventBridge，他的整個架構(gòu)可以分為兩部分：上面是我們的控制面、下面是我們的數(shù)據(jù)面。

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

歡迎加入我們

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

RocketMQ EventBridge：

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

RocketMQ 學(xué)習(xí)社區(qū)體驗地址

RocketMQ 學(xué)習(xí)社區(qū)重磅上線！AI 互動，一秒了解 RocketMQ 功能源碼。RocketMQ 學(xué)習(xí)社區(qū)是國內(nèi)首個基于 AIGC 提供的知識服務(wù)社區(qū)，旨在成為 RocketMQ 學(xué)習(xí)路上的“貼身小二”。

PS：RocketMQ 社區(qū)以 RocketMQ 5.0 資料為主要訓(xùn)練內(nèi)容，持續(xù)優(yōu)化迭代中，回答內(nèi)容均由人工智能模型生成，其準(zhǔn)確性和完整性無法保證，且不代表 RocketMQ 學(xué)習(xí)社區(qū)的態(tài)度或觀點。

相關(guān)鏈接：

[1]官網(wǎng)https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md

點擊此處，立即體驗RocketMQ 學(xué)習(xí)社區(qū)（建議 PC 端體驗完整功能）

關(guān)鍵詞：