基於雲原生CloudEvent實現服務目錄

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

CloudEvent簡介

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

如何解耦

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

事件生產

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

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

事件傳輸

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

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

事件消費

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

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

入門場景

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

消息處理流程

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

數據結構

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

image.png

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

type
從表面上看Source和type都描述了當前事件發生的系統,不同的是type中是一個結構化的數據,按照這個結構我們對應的計費、效率統計模塊,就可以拿到這個數據去做相關一些支線邏輯的處理了。
resources: 變更資源列表
即標識當前事件觸發了哪些相關資源的改變,比如虛機添加硬盤,實際上是包含了兩種資源即虛機與對應的磁盤資源


整合服務目錄

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






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

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

後續

最近身體不好,今天剛去完醫院,不能老熬夜。希望接下來能把項目進度趕上,後面就會有更多的場景了,年前要是進度趕上了,我就把想做的應用管理那個模塊這塊的代碼實踐抽空給寫了,然後給大家分享下應用管理那塊基於上述的實踐,不過要是項目被砍了,就到這了吧。等最近上層的概念介紹完了, 就給大家分享一些源碼上的設計,如果跟我做類似方向的朋友,也歡迎加微信交流交流。

雲原生學習筆記地址: https://www.yuque.com/baxiaoshi/tyado3
微信號:baxiaoshi2020 公共號: 圖解源碼
圖解源碼

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章