作者：肯夢

阿里雲消息隊列 RocketMQ 5.0 實現了全新升級，實現了從“消息”到“消息、事件、流”的大融合，基於此，Message-Driven、Event-Driven、Streaming 這三個詞是近期消息領域高頻詞，但由於概念過於新，很多同學其實是不太理解這裏的異同。本文把三個概念重新整理下，梳理出比較明確的概念講給大家。

背景

首先這三個概念具體翻譯如下：

• Message-Driven： 消息驅動的通信；
• Event- Driven： 事件驅動的通信；
• Streaming： 流模式。

這三個模式都是類似異步通信的模式，發送消息的服務不會等待消費消息服務響應任何數據，做服務解耦是三個模式共同的特性；

只要是在服務通訊領域內，在選型時還要考慮如下特性：

• 排序： 是否可以保證特定的順序交付；
• 事務： 生產者或消費者是否可以參與分佈式事務；
• 持久化： 數據如何被持久化，以及是否可以重放數據；
• 訂閲過濾： 是否擁有根據Tag或其他字段做訂閲過濾的能力；
• At – least -once（最少交付一次），At-most-once（最多交付一次），Exactly-once （精確交付）。

通用背景介紹完，依次來看看各個模型代表的是什麼意思。

消息驅動 Message-Driven

在消息驅動通信中，一般鏈路就是消息生產者（Producer）向消息消費者（Consumer）發送消息。模型如下：

消息驅動模式下通常會用到中間件，比較常見的中間組件有 RocketMQ，Kafka，RabbitMQ 等。這些中間件的目的是緩存生產者投遞的消息直到消費者準備接收這些消息，以此將兩端系統解耦。

在消息驅動架構中，消息的格式是基於消費者的需求制定的；消息傳遞可以是一對一，多對多，一對多或多對一。

消息驅動通訊比較常見的一個例子是商品訂單推送，上游組件負責生成訂單，下游組件負責接收訂單並處理。通過這樣的通訊方式上游生成組件其實無需關心整個訂單的生命週期，更專注於如何快速生成訂單，使單個組件的性能得以提升。!

消息驅動模式在服務之間提供了輕的耦合（這部分耦合指代 Producer/Consumer SDK），並可以對生產和消費服務根據訴求進行擴展。

事件驅動 Event-Driven

首先要申明一個觀點：事件驅動其實是對消息驅動方法的改進，它對消息體大小，消息格式做了較為嚴格的限制，這層基於消息的限制封裝其實就稱為事件（Event）。

在事件驅動模式中，生產者發佈事件來表示系統變更，任何感興趣且有權限接入的服務都可以訂閲這些事件，並將這些事件作為觸發器來啓動某些邏輯/存儲/任務。​

事件驅動的模式可以是一對一，多對一，一對多或多對多。通常情況下一般是多個目標根據過濾條件執行不同的事件。

在事件驅動架構中，事件的格式是由生產者根據事件標準協議制定的；由於更規範限制和封裝，事件的生產者完全不需要關心有哪些系統正在消費它生成的事件。

事件不是命令，事件不會告訴消費者如何處理信息，他們的作用只是告訴消費者此時此刻有個事件發生了；事件是一份不可變的數據，重要的數據，它與消息的數據價值相同；通常情況下當某個事件發生並執行時，往往伴隨着另一個事件的產生。

事件驅動提供了服務間的最小耦合，並允許生產服務和消費服務根據需求進行擴展；事件驅動可以在不影響現有服務的情況下添加各類新增組件。

事件驅動也可以舉一個非常貼切的例子，我們以“客户購買完一款商品”為一個事件，舉證在事件場景的應用：

• CRM（客户關係系統）系統接收到客户購買信息，可自行更新客户的購買記錄；
• EMR（庫存管理系統） 系統接收到客户購買信息，動態調整庫存並及時補貨；
• 快遞服務接收到客户購買信息，自行打單並通知快遞公司派送。

這麼看，事件驅動模式是不是可以應用並出現在任何地方！

在 EventBridge 產品化方向，也正是由於針對消息做了一些標準化封裝，才有可能實現譬如針對事件本身的 filter（過濾） ，transform（轉換），schema（事件結構），search（查詢） 等能力。這些能力也拓展出更多針對事件驅動特有的場景功能及相關特性。

流 Streaming

流是一組有序的無界事件或數據，執行操作通常是固定的某個事件段（e.g. 00:00 – 12:00）或一個相對事件（E.g. 過去 12 小時）。

通常情況下單個事件往往就是使用事件本身，但是對於流可能的操作大概率是過濾，組合，拆分，映射等等。

流的操作可以是無狀態也可以是有狀態的：

• 對於單個事件操作是無狀態的，包括過濾和映射；
• 依賴消息在流的時間或位置（e.g. offset，time）是有狀態的。有狀態操作中，流處理邏輯必須保留一些已被消費消息的內存。有狀態包括對數據做 Batch Size，Batch Window 等。

流這裏也可以舉一個比較簡單的例子，比如我們的物流系統在物品通過一個物流節點時會生成一個事件，但是要查到這個物品完整的流轉狀態事件，則必須是各個物流節點單個事件的聚合，那這個聚合事件就是流事件。

Kafka 是最典型的流式中間件，在流式場景中，事件的位置信息至關重要。通常情況下位置信息（E.g. offset）是由消費者託管的。

事件規範標準

聊完 Event 和 Streaming 是什麼，再來補充一點有關於它們的規範。

事件規範存在的目的是為了清晰事件生產者和消費者的關係，目前主要有兩部分：AsyncAPI 和 CloudEvents；

AsyncAPI： 基於事件 API 提供了與之對應的 Open API 和 Swagger 等；CloudEvents： 側重於處理事件的元數據。

下面也重點介紹一些關於 CloudEvents 的相關概念參考：CloudEvents 的核心其實是定義了一組關於不同組件間傳輸事件的元數據，以及這些元數據應該如何出現在消息體中。

其主旨大抵如下：

• 事件規範化；
• 降低平台集成難度；
• 提高 FaaS 的可移植性；
• 源事件可追蹤；
• 提升事件關聯性

準確的事件體，事件信息才可以做出更穩定的系統架構，永遠保持對事件的敬畏。

附 一些術語及定義：

Occurrence： 發生，指事件邏輯上的發生，基於某種情況，事件出現了；

Event： 事件，表示事件以及上下文的數據記錄。可以根據事件中的信息決定路由，但事件本身並不包含路由信息；

Producer： 生產者，真正創造事件的實例或組件；

Source： 源，事件發生的上下文，可以由多個 producer 組成；

Consumer： 消費者，接收事件並對事件進行消費；

Intermediary：中介，接收包含事件的消息（message），並轉發給下一個接收方，類似路由器；

Context： 上下文，上下文元數據被封裝到 context attributes 中，用來判斷事件與其它系統的關係；

Data： 數據，也可以叫做 payload；

EventFormat：事件格式，例如 json；

Message： 消息，封裝事件並將其從 source 傳遞到 destination；

Protocol： 協議，可以是行業標準如 http，開源協議如 Kafka 或者供應商協議如 AWS Kinesis；

Protocol Binding： 協議綁定，描述如何通過給定的協議收發事件，如何將事件放到消息裏。

重磅推薦

本文旨在幫助大家對近期消息領域的高頻詞“消息驅動（Message-Driven），事件驅動（Event-Driven）和流（Streaming）”有更清晰的瞭解和認知，其中事件驅動 EDA 作為 Gartner 預測的十大技術趨勢之一， EventBridge 作為下一代消息中間件，也是目前的重點方向之一。如果大家感興趣，想要有更多瞭解，可關注「阿里雲 EventBridge 系列公開課」，完整課程正火熱開講中！

點擊​​此處​​，可以直接觀看課程視頻～