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

基於事件驅動的系統架構在平常的平臺開發中早已司空見慣，經過消息隊列進行事件的發送，而後分別構建對應的生產者和消費者。不過在傳統的業務開發模式不一樣的事件會有不一樣的格式，不一樣的生產者生成出的事件格式也各不相同，消費者能消費的格式也是千差萬別，本質上事件、生產者、消費者仍是耦合的。那如何解決該問題呢？那就是咱們今天要聊的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階段

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

後續

最近身體很差，今天剛去完醫院，不能老熬夜。但願接下來能把項目進度遇上，後面就會有更多的場景了，年前要是進度遇上了，我就把想作的應用管理那個模塊這塊的代碼實踐抽空給寫了，而後給你們分享下應用管理那塊基於上述的實踐，不過要是項目被砍了，就到這了吧。等最近上層的概念介紹完了， 就給你們分享一些源碼上的設計，若是跟我作相似方向的朋友，也歡迎加微信交流交流。

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