共計 2673 個字符，預計需要花費 7 分鐘才能閱讀完成。
本篇文章給大家分享的是有關基于云原生 CloudEvent 如何實現服務目錄，丸趣 TV 小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著丸趣 TV 小編一起來看看吧。
基于事件驅動的系統架構在日常的平臺開發中早已司空見慣，通過消息隊列進行事件的發送，然后分別構建對應的生產者和消費者。不過在傳統的業務開發模式不同的事件會有不同的格式，不同的生產者生成出的事件格式也各不相同，消費者能消費的格式也是千差萬別，本質上事件、生產者、消費者還是耦合的。那如何解決該問題呢？那就是我們今天要聊的 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 階段
鏈路雖然有點長，但其實整個鏈路的系統設計非常簡單，系統之間的通信、可靠性、容錯、耦合性都不需要關注 (消息隊列服務來保障)，后續如果要擴展，就再懟個模塊就可以了。要消費新的事件，就再寫個新的接口，然后編輯下路由規則，就可以實現新的模塊的接入了。
以上就是基于云原生 CloudEvent 如何實現服務目錄，丸趣 TV 小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注丸趣 TV 行業資訊頻道。
