Apache RocketMQ EventBridge：構(gòu)建下一代事件驅(qū)動(dòng)引擎-世界微資訊

作者：沈林

(資料圖片)

前言

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

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

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

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

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

什么是事件？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

事件的特性2：無期望的

事件的第二個(gè)特性是：無期望的。事件是客觀的描述一個(gè)事物的狀態(tài)或?qū)傩灾档淖兓?，但?duì)于如何處理事件本身并沒有做任何期望。相比之下，Commond 則是有期望的，它希望系統(tǒng)做出改變；但是 Event，它只是客觀描述系統(tǒng)的一個(gè)變化。我們舉一個(gè)例子：交通信號(hào)燈從綠燈變成紅燈，它就是一個(gè)事件。事件本身并沒有任何期望，說要求行人或汽車禁止通行，而是交通法規(guī)需要紅綠燈，并賦予了其規(guī)則。

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

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

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

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

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

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

事件的特性 4：具象化

事件的第四個(gè)特性是：“具象化”。事件會(huì)盡可能的把“案發(fā)現(xiàn)場”完整的記錄下來，因?yàn)樗膊恢老M(fèi)者會(huì)如何使用它，所以它會(huì)做到盡量的詳盡，包括：什么時(shí)候發(fā)生？是由誰產(chǎn)生的事件？是什么類型的事件？是誰發(fā)送的事件？事件的唯一性標(biāo)志是什么？事件的內(nèi)容是什么？等等。

再對(duì)比我們常見的消息，因?yàn)樯舷掠我话闶谴_定的，常常為了性能和傳輸效率，則會(huì)做到盡可能的精簡，只要滿足“計(jì)劃經(jīng)濟(jì)”指定安排的消費(fèi)者需求即可。

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

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

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

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

上下游集成

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

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

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

方式 2：消息異步解耦

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

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

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

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

面向下游

1、耦合的膨脹

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

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

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

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

如果在事件驅(qū)動(dòng)架構(gòu)中，客戶的營銷系統(tǒng)，需要怎么做呢？他什么都不需要，只要登高一聲大喊：“我需要什么樣的訂單事件格式，我提供一個(gè) API，其他系統(tǒng)就按這個(gè)訂單事件格式發(fā)給我就可以了”。EventBroker 會(huì)將上游的事件轉(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ū)動(dòng)：A 不依賴于 B，B 也不依賴于 A；（所有的耦合，都由中間的 Event Broker 來統(tǒng)一處理和維護(hù)）

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

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

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

4、可測試性和可維護(hù)性

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

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

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

5、Serverless

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

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

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

面向上游

SaaS 集成

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

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

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

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

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

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

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

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

需要什么樣的能力？

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

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

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

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

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

如何描述事件

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

事件中心

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

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

這樣消費(fèi)者拿到這個(gè)事件的時(shí)候，才知道是什么，怎么用，用的放心。

Schema

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

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

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

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

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

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

歡迎加入我們

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

RocketMQ EventBridge：

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

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

RocketMQ 學(xué)習(xí)社區(qū)重磅上線！AI 互動(dòng)，一秒了解 RocketMQ 功能源碼。RocketMQ 學(xué)習(xí)社區(qū)是國內(nèi)首個(gè)基于 AIGC 提供的知識(shí)服務(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)度或觀點(diǎn)。

相關(guān)鏈接：

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

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

關(guān)鍵詞：