基于事件驅動的系統架構在日常的平臺開發中早已司空見慣，通過消息隊列進行事件的發送，然后分別構建對應的生產者和消費者。不過在傳統的業務開發模式不同的事件會有不同的格式，不同的生產者生成出的事件格式也各不相同，消費者能消費的格式也是千差萬別，本質上事件、生產者、消費者還是耦合的。那如何解決該問題呢？那就是我們今天要聊的CloudEvent。

CloudEvent簡介

從官網的CloudEvents描述中我們可以看出，CloudEvent本質上就是一個描述事件數據的規范。所以對于CloudEvents的學習有的時候，我們更多的應該是取理解其設計規范，而不是其所呈現出的數據結構形態。就像大家去學tcp協議一樣， 你不是去學的這個字段叫什么，而是要理解為什么會有這個字段，其解決的問題是什么。

如何解耦

對于CloudEvents的學習筆者采用自頂向下的方式來進行學習，即先去了解CloudEvents是如何在平臺上進行事件、消費者、生產者的解耦，然后在去思考底層的相關字段的細節一個事件的生命周期通常會包含生產、傳輸、消費三個環節，下面我們分別對這三個環節來進行介紹cloudevent與傳統事件開發模式的區別。

事件生產

在傳統的開發模式下不同的業務生產的的事件也各不相同，并且事件本身數據會相對較少，更多的是類似信號傳遞的角色，即通知后端服務某個類型事件發生了，然后由對應的系統構建事件的上下文數據，進行業務邏輯處理。而在Cloudevents中則更注重事件的一致性與完整性。為了保證事件可以被統一的分發、解析與處理，Cloudevents采用了類似分層的事件封裝機制，即"事件協議"與"事件數據"兩層。事件協議是指Cloudevent定義了底層事件的格式，即大家都按照一套標準的規范來進行事件的封裝，這樣事件就可以被統一的處理和分發。而事件專有的數據則存儲在對應的數據字段里面

完整性是我個人的理解，即我們在Cloud的環境中構建的事件需要包含其當前的完整上下文數據，以便后續系統有足夠的信息可以進行業務邏輯處理與決策。這樣可以避免后端系統在接收到事件后，需要進行當前事件對應上下文的組裝，主要是解決由于傳輸存在的延遲導致相關數據可能已經不再是事件發生時的狀態，存在狀態不一致的情況

事件傳輸

事件產生后通常要發送到對應的消息代理服務進行暫存，在傳統的業務中通常會選擇特定的消息協議來進行傳輸，這中間通常會涉及兩部分：序列化與傳輸協議。在傳輸協議中Cloudevents中支持常見的行業標準協議比如HTTP、 AMQP、 MQTT、 SMT等，并支持常見的供應商與平臺比如kafka、AWS Kinesis、 Azure 事件網格、Alibaba Cloud EventBridge，用戶可以根據自己的場景選擇對應的供應商分發對應的事件

在序列化方面cloudevents支持HTTP、 AMQP、 Kafka等常見的標準協議，而不需要用戶手動進行相關協議的序列化

事件消費

事件的消費端通常會對其關注的事件類型感興趣，并且由于消息的格式是統一的我們很容易就可以通過對應的平臺來根據消息體里面的內容進行消息路由，分發給對應的事件消費者，事件的消費者只要負責對應事件的接收即可，而并不關注其他的信息

關于Cloudevents事件更多的內容，后面再繼續分享，然后接下來就介紹下我們基于cloudevent是怎么設計系統的

入門場景

在前面的文章中，介紹過我們的服務目錄系統，服務目錄中要接入不同的基礎服務，基礎服務的格式各不相同，而且還要對接計費、效率統計等系統，后期可能還會對接公司的事件流平臺，那如何對這些這些異構模塊中異構的數據進行統一的分發和處理，我們的架構如下：

消息處理流程

首先在消息發送端，我們基于cloudevent構建對應的消息，并且將當前事件的上下文數據統一封裝到data中，然后發送給公司的消息隊列系統。由公司的消息隊列來完成對應的事件分發與路由，對應的事件接收端只需要定義自己關注的事件，而不需要去監聽具體的MQ，只需要定義一個接受消息的HTTP接口接口，對應消息的路由與分發功能由公司的MQ來實現服務消費端解析消息隊列傳遞過來的事件信息，解析出對應的數據結構，然后進行業務處理即可。后續如果增加模塊，或者增加新的事件消費需求，只需要實現對應的邏輯即可

數據結構

結合Cloudevents的規范，我們定義自己內部的系統的數據結構。主要使用的結構如下：

這里主要介紹下我們附加的一些字段以及根據自己場景的定義：

type

從表面上看Source和type都描述了當前事件發生的系統，不同的是type中是一個結構化的數據，按照這個結構我們對應的計費、效率統計模塊，就可以拿到這個數據去做相關一些支線邏輯的處理了。

resources：變更資源列表

即標識當前事件觸發了哪些相關資源的改變，比如虛機添加硬盤，實際上是包含了兩種資源即虛機與對應的磁盤資源

整合服務目錄

前面提到我們使用服務和提供的API規范實現了一個服務代理模塊，在服務代理模塊中Cloudevent的主要使用場景如下：1.服務目錄接收到服務變更請求后，保存數據庫后，發生對應的cloudevent事件到消息隊列2.在消息隊列中設定對應的路由轉發規則，將對應的事件發生給服務代理模塊3.服務代理模塊根據type字段進行解析，獲取對應的后端服務地址，并從消息中解析出對應的數據，將數據發送給后端真實的服務4.后端真實服務接收到結構化數據后，進行自己的業務邏輯處理，處理完成后發送對應的事件5.服務代理模塊根據事件解析出相關的資源，調用對應的平臺獲取當前資源的數據，生成事件6.服務目錄模塊接收到對應的服務實例數據，存儲到自己的數據庫中

如果后續有變更則只需要產生對應的事件發生到消息隊列中，會重復進行5-6階段

鏈路雖然有點長，但其實整個鏈路的系統設計非常簡單，系統之間的通信、可靠性、容錯、耦合性都不需要關注(消息隊列服務來保障)，后續如果要擴展，就再懟個模塊就可以了。要消費新的事件，就再寫個新的接口，然后編輯下路由規則，就可以實現新的模塊的接入了。