本篇文章給大家分享的是有關(guān)基于云原生CloudEvent如何實(shí)現(xiàn)服務(wù)目錄，小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說(shuō)，跟著小編一起來(lái)看看吧。

我們擁有10年網(wǎng)頁(yè)設(shè)計(jì)和網(wǎng)站建設(shè)經(jīng)驗(yàn)，從網(wǎng)站策劃到網(wǎng)站制作，我們的網(wǎng)頁(yè)設(shè)計(jì)師為您提供的解決方案。為企業(yè)提供做網(wǎng)站、成都網(wǎng)站制作、微信開發(fā)、小程序開發(fā)、手機(jī)網(wǎng)站制作設(shè)計(jì)、H5建站、等業(yè)務(wù)。無(wú)論您有什么樣的網(wǎng)站設(shè)計(jì)或者設(shè)計(jì)方案要求，我們都將富于創(chuàng)造性的提供專業(yè)設(shè)計(jì)服務(wù)并滿足您的需求。

基于事件驅(qū)動(dòng)的系統(tǒng)架構(gòu)在日常的平臺(tái)開發(fā)中早已司空見慣，通過(guò)消息隊(duì)列進(jìn)行事件的發(fā)送，然后分別構(gòu)建對(duì)應(yīng)的生產(chǎn)者和消費(fèi)者。不過(guò)在傳統(tǒng)的業(yè)務(wù)開發(fā)模式不同的事件會(huì)有不同的格式，不同的生產(chǎn)者生成出的事件格式也各不相同，消費(fèi)者能消費(fèi)的格式也是千差萬(wàn)別，本質(zhì)上事件、生產(chǎn)者、消費(fèi)者還是耦合的。那如何解決該問(wèn)題呢？那就是我們今天要聊的CloudEvent。

CloudEvent簡(jiǎn)介

從官網(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è)字段，其解決的問(wèn)題是什么。

如何解耦

對(duì)于CloudEvents的學(xué)習(xí)筆者采用自頂向下的方式來(lái)進(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é)來(lái)進(jìn)行介紹cloudevent與傳統(tǒng)事件開發(fā)模式的區(qū)別。

事件生產(chǎn)

在傳統(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ī)范來(lái)進(jìn)行事件的封裝，這樣事件就可以被統(tǒng)一的處理和分發(fā)。而事件專有的數(shù)據(jù)則存儲(chǔ)在對(duì)應(yīng)的數(shù)據(jù)字段里面

完整性是我個(gè)人的理解，即我們?cè)贑loud的環(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é)議來(lái)進(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ù)自己的場(chǎng)景選擇對(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)

事件的消費(fèi)端通常會(huì)對(duì)其關(guān)注的事件類型感興趣，并且由于消息的格式是統(tǒng)一的我們很容易就可以通過(guò)對(duì)應(yīng)的平臺(tái)來(lá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ù)分享，然后接下來(lái)就介紹下我們基于cloudevent是怎么設(shè)計(jì)系統(tǒng)的

入門場(chǎng)景

在前面的文章中，介紹過(guò)我們的服務(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ì)列來(lái)完成對(duì)應(yīng)的事件分發(fā)與路由，對(duì)應(yīng)的事件接收端只需要定義自己關(guān)注的事件，而不需要去監(jiān)聽具體的MQ，只需要定義一個(gè)接受消息的HTTP接口接口，對(duì)應(yīng)消息的路由與分發(fā)功能由公司的MQ來(lái)實(shí)現(xiàn) 服務(wù)消費(fèi)端解析消息隊(duì)列傳遞過(guò)來(lái)的事件信息，解析出對(duì)應(yīng)的數(shù)據(jù)結(jié)構(gòu)，然后進(jìn)行業(yè)務(wù)處理即可。后續(xù)如果增加模塊，或者增加新的事件消費(fèi)需求，只需要實(shí)現(xiàn)對(duì)應(yīng)的邏輯即可

數(shù)據(jù)結(jié)構(gòu)

結(jié)合Cloudevents的規(guī)范，我們定義自己內(nèi)部的系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)。主要使用的結(jié)構(gòu)如下：

這里主要介紹下我們附加的一些字段以及根據(jù)自己場(chǎng)景的定義：

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ù)目錄

前面提到我們使用服務(wù)和提供的API規(guī)范實(shí)現(xiàn)了一個(gè)服務(wù)代理模塊，在服務(wù)代理模塊中Cloudevent的主要使用場(chǎng)景如下：

1.服務(wù)目錄接收到服務(wù)變更請(qǐng)求后，保存數(shù)據(jù)庫(kù)后，發(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ù)庫(kù)中

如果后續(xù)有變更則只需要產(chǎn)生對(duì)應(yīng)的事件發(fā)生到消息隊(duì)列中，會(huì)重復(fù)進(jìn)行5-6階段

鏈路雖然有點(diǎn)長(zhǎng)，但其實(shí)整個(gè)鏈路的系統(tǒng)設(shè)計(jì)非常簡(jiǎn)單，系統(tǒng)之間的通信、可靠性、容錯(cuò)、耦合性都不需要關(guān)注(消息隊(duì)列服務(wù)來(lái)保障)，后續(xù)如果要擴(kuò)展，就再懟個(gè)模塊就可以了。要消費(fèi)新的事件，就再寫個(gè)新的接口，然后編輯下路由規(guī)則，就可以實(shí)現(xiàn)新的模塊的接入了。

以上就是基于云原生CloudEvent如何實(shí)現(xiàn)服務(wù)目錄，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見到或用到的。希望你能通過(guò)這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

當(dāng)前文章：基于云原生CloudEvent如何實(shí)現(xiàn)服務(wù)目錄
本文地址：http://www.2m8n56k.cn/article32/pchgpc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站維護(hù)、App設(shè)計(jì)、全網(wǎng)營(yíng)銷推廣、企業(yè)建站、動(dòng)態(tài)網(wǎng)站、域名注冊(cè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：[email protected]。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)