這篇文章給大家介紹如何基于CloudEvent實(shí)現(xiàn)服務(wù)目錄集成，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。
創(chuàng)新互聯(lián)建站服務(wù)項(xiàng)目包括岳普湖網(wǎng)站建設(shè)、岳普湖網(wǎng)站制作、岳普湖網(wǎng)頁制作以及岳普湖網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，岳普湖網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到岳普湖省份的部分城市，未來相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！
基于事件驅(qū)動(dòng)的系統(tǒng)架構(gòu)在日常的平臺(tái)開發(fā)中早已司空見慣，通過消息隊(duì)列進(jìn)行事件的發(fā)送，然后分別構(gòu)建對(duì)應(yīng)的生產(chǎn)者和消費(fèi)者。不過在傳統(tǒng)的業(yè)務(wù)開發(fā)模式不同的事件會(huì)有不同的格式，不同的生產(chǎn)者生成出的事件格式也各不相同，消費(fèi)者能消費(fèi)的格式也是千差萬別，本質(zhì)上事件、生產(chǎn)者、消費(fèi)者還是耦合的。那如何解決該問題呢？那就是我們今天要聊的CloudEvent。
從官網(wǎng)的CloudEvents描述中我們可以看出，CloudEvent本質(zhì)上就是一個(gè)描述事件數(shù)據(jù)的規(guī)范。所以對(duì)于CloudEvents的學(xué)習(xí)有的時(shí)候，我們更多的應(yīng)該是取理解其設(shè)計(jì)規(guī)范，而不是其所呈現(xiàn)出的數(shù)據(jù)結(jié)構(gòu)形態(tài)。就像大家去學(xué)tcp協(xié)議一樣， 你不是去學(xué)的這個(gè)字段叫什么，而是要理解為什么會(huì)有這個(gè)字段，其解決的問題是什么。
對(duì)于CloudEvents的學(xué)習(xí)筆者采用自頂向下的方式來進(jìn)行學(xué)習(xí)，即先去了解CloudEvents是如何在平臺(tái)上進(jìn)行事件、消費(fèi)者、生產(chǎn)者的解耦，然后在去思考底層的相關(guān)字段的細(xì)節(jié)
一個(gè)事件的生命周期通常會(huì)包含生產(chǎn)、傳輸、消費(fèi)三個(gè)環(huán)節(jié)，下面我們分別對(duì)這三個(gè)環(huán)節(jié)來進(jìn)行介紹cloudevent與傳統(tǒng)事件開發(fā)模式的區(qū)別。
在傳統(tǒng)的開發(fā)模式下不同的業(yè)務(wù)生產(chǎn)的的事件也各不相同，并且事件本身數(shù)據(jù)會(huì)相對(duì)較少，更多的是類似信號(hào)傳遞的角色，即通知后端服務(wù)某個(gè)類型事件發(fā)生了，然后由對(duì)應(yīng)的系統(tǒng)構(gòu)建事件的上下文數(shù)據(jù)，進(jìn)行業(yè)務(wù)邏輯處理。而在Cloudevents中則更注重事件的一致性與完整性。
為了保證事件可以被統(tǒng)一的分發(fā)、解析與處理，Cloudevents采用了類似分層的事件封裝機(jī)制，即"事件協(xié)議"與"事件數(shù)據(jù)"兩層。事件協(xié)議是指Cloudevent定義了底層事件的格式，即大家都按照一套標(biāo)準(zhǔn)的規(guī)范來進(jìn)行事件的封裝，這樣事件就可以被統(tǒng)一的處理和分發(fā)。而事件專有的數(shù)據(jù)則存儲(chǔ)在對(duì)應(yīng)的數(shù)據(jù)字段里面
完整性是我個(gè)人的理解，即我們在Cloud的環(huán)境中構(gòu)建的事件需要包含其當(dāng)前的完整上下文數(shù)據(jù)，以便后續(xù)系統(tǒng)有足夠的信息可以進(jìn)行業(yè)務(wù)邏輯處理與決策。這樣可以避免后端系統(tǒng)在接收到事件后，需要進(jìn)行當(dāng)前事件對(duì)應(yīng)上下文的組裝，主要是解決由于傳輸存在的延遲導(dǎo)致相關(guān)數(shù)據(jù)可能已經(jīng)不再是事件發(fā)生時(shí)的狀態(tài)，存在狀態(tài)不一致的情況
事件產(chǎn)生后通常要發(fā)送到對(duì)應(yīng)的消息代理服務(wù)進(jìn)行暫存，在傳統(tǒng)的業(yè)務(wù)中通常會(huì)選擇特定的消息協(xié)議來進(jìn)行傳輸，這中間通常會(huì)涉及兩部分：序列化與傳輸協(xié)議。
在傳輸協(xié)議中Cloudevents中支持常見的行業(yè)標(biāo)準(zhǔn)協(xié)議比如HTTP、 AMQP、 MQTT、 SMT等，并支持常見的供應(yīng)商與平臺(tái)比如kafka、AWS Kinesis、 Azure 事件網(wǎng)格、Alibaba Cloud EventBridge，用戶可以根據(jù)自己的場景選擇對(duì)應(yīng)的供應(yīng)商分發(fā)對(duì)應(yīng)的事件
在序列化方面cloudevents支持HTTP、 AMQP、 Kafka等常見的標(biāo)準(zhǔn)協(xié)議，而不需要用戶手動(dòng)進(jìn)行相關(guān)協(xié)議的序列化
事件的消費(fèi)端通常會(huì)對(duì)其關(guān)注的事件類型感興趣，并且由于消息的格式是統(tǒng)一的我們很容易就可以通過對(duì)應(yīng)的平臺(tái)來根據(jù)消息體里面的內(nèi)容進(jìn)行消息路由，分發(fā)給對(duì)應(yīng)的事件消費(fèi)者，事件的消費(fèi)者只要負(fù)責(zé)對(duì)應(yīng)事件的接收即可，而并不關(guān)注其他的信息
關(guān)于Cloudevents事件更多的內(nèi)容，后面再繼續(xù)分享，然后接下來就介紹下我們基于cloudevent是怎么設(shè)計(jì)系統(tǒng)的
在前面的文章中，介紹過我們的服務(wù)目錄系統(tǒng)，服務(wù)目錄中要接入不同的基礎(chǔ)服務(wù)，基礎(chǔ)服務(wù)的格式各不相同，而且還要對(duì)接計(jì)費(fèi)、效率統(tǒng)計(jì)等系統(tǒng)，后期可能還會(huì)對(duì)接公司的事件流平臺(tái)，那如何對(duì)這些這些異構(gòu)模塊中異構(gòu)的數(shù)據(jù)進(jìn)行統(tǒng)一的分發(fā)和處理，我們的架構(gòu)如下：
首先在消息發(fā)送端，我們基于cloudevent構(gòu)建對(duì)應(yīng)的消息，并且將當(dāng)前事件的上下文數(shù)據(jù)統(tǒng)一封裝到data中，然后發(fā)送給公司的消息隊(duì)列系統(tǒng)。由公司的消息隊(duì)列來完成對(duì)應(yīng)的事件分發(fā)與路由，對(duì)應(yīng)的事件接收端只需要定義自己關(guān)注的事件，而不需要去監(jiān)聽具體的MQ，只需要定義一個(gè)接受消息的HTTP接口接口，對(duì)應(yīng)消息的路由與分發(fā)功能由公司的MQ來實(shí)現(xiàn)服務(wù)消費(fèi)端解析消息隊(duì)列傳遞過來的事件信息，解析出對(duì)應(yīng)的數(shù)據(jù)結(jié)構(gòu)，然后進(jìn)行業(yè)務(wù)處理即可。后續(xù)如果增加模塊，或者增加新的事件消費(fèi)需求，只需要實(shí)現(xiàn)對(duì)應(yīng)的邏輯即可
結(jié)合Cloudevents的規(guī)范，我們定義自己內(nèi)部的系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)。主要使用的結(jié)構(gòu)如下：
這里主要介紹下我們附加的一些字段以及根據(jù)自己場景的定義：
type
從表面上看Source和type都描述了當(dāng)前事件發(fā)生的系統(tǒng)，不同的是type中是一個(gè)結(jié)構(gòu)化的數(shù)據(jù)，按照這個(gè)結(jié)構(gòu)我們對(duì)應(yīng)的計(jì)費(fèi)、效率統(tǒng)計(jì)模塊，就可以拿到這個(gè)數(shù)據(jù)去做相關(guān)一些支線邏輯的處理了。
resources：變更資源列表
即標(biāo)識(shí)當(dāng)前事件觸發(fā)了哪些相關(guān)資源的改變，比如虛機(jī)添加硬盤，實(shí)際上是包含了兩種資源即虛機(jī)與對(duì)應(yīng)的磁盤資源
前面提到我們使用服務(wù)和提供的API規(guī)范實(shí)現(xiàn)了一個(gè)服務(wù)代理模塊，在服務(wù)代理模塊中Cloudevent的主要使用場景如下：
1.服務(wù)目錄接收到服務(wù)變更請(qǐng)求后，保存數(shù)據(jù)庫后，發(fā)生對(duì)應(yīng)的cloudevent事件到消息隊(duì)列2.在消息隊(duì)列中設(shè)定對(duì)應(yīng)的路由轉(zhuǎn)發(fā)規(guī)則，將對(duì)應(yīng)的事件發(fā)生給服務(wù)代理模塊3.服務(wù)代理模塊根據(jù)type字段進(jìn)行解析，獲取對(duì)應(yīng)的后端服務(wù)地址，并從消息中解析出對(duì)應(yīng)的數(shù)據(jù)，將數(shù)據(jù)發(fā)送給后端真實(shí)的服務(wù)4.后端真實(shí)服務(wù)接收到結(jié)構(gòu)化數(shù)據(jù)后，進(jìn)行自己的業(yè)務(wù)邏輯處理，處理完成后發(fā)送對(duì)應(yīng)的事件5.服務(wù)代理模塊根據(jù)事件解析出相關(guān)的資源，調(diào)用對(duì)應(yīng)的平臺(tái)獲取當(dāng)前資源的數(shù)據(jù)，生成事件6.服務(wù)目錄模塊接收到對(duì)應(yīng)的服務(wù)實(shí)例數(shù)據(jù)，存儲(chǔ)到自己的數(shù)據(jù)庫中
如果后續(xù)有變更則只需要產(chǎn)生對(duì)應(yīng)的事件發(fā)生到消息隊(duì)列中，會(huì)重復(fù)進(jìn)行5-6階段
鏈路雖然有點(diǎn)長，但其實(shí)整個(gè)鏈路的系統(tǒng)設(shè)計(jì)非常簡單，系統(tǒng)之間的通信、可靠性、容錯(cuò)、耦合性都不需要關(guān)注(消息隊(duì)列服務(wù)來保障)，后續(xù)如果要擴(kuò)展，就再懟個(gè)模塊就可以了。要消費(fèi)新的事件，就再寫個(gè)新的接口，然后編輯下路由規(guī)則，就可以實(shí)現(xiàn)新的模塊的接入了。
關(guān)于如何基于CloudEvent實(shí)現(xiàn)服務(wù)目錄集成就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。
重慶分公司
重慶分公司
