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

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

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

CloudEvent簡介

從官網(wǎng)的CloudEvents描述中我們可以看出，CloudEvent本質(zhì)上就是一個描述事件數(shù)據(jù)的規(guī)范。所以對于CloudEvents的學(xué)習(xí)有的時候，我們更多的應(yīng)該是取理解其設(shè)計(jì)規(guī)范，而不是其所呈現(xiàn)出的數(shù)據(jù)結(jié)構(gòu)形態(tài)。就像大家去學(xué)tcp協(xié)議一樣， 你不是去學(xué)的這個字段叫什么，而是要理解為什么會有這個字段，其解決的問題是什么。

如何解耦

對于CloudEvents的學(xué)習(xí)筆者采用自頂向下的方式來進(jìn)行學(xué)習(xí)，即先去了解CloudEvents是如何在平臺上進(jìn)行事件、消費(fèi)者、生產(chǎn)者的解耦，然后在去思考底層的相關(guān)字段的細(xì)節(jié) 一個事件的生命周期通常會包含生產(chǎn)、傳輸、消費(fèi)三個環(huán)節(jié)，下面我們分別對這三個環(huán)節(jié)來進(jìn)行介紹cloudevent與傳統(tǒng)事件開發(fā)模式的區(qū)別。

事件生產(chǎn)

在傳統(tǒng)的開發(fā)模式下不同的業(yè)務(wù)生產(chǎn)的的事件也各不相同，并且事件本身數(shù)據(jù)會相對較少，更多的是類似信號傳遞的角色，即通知后端服務(wù)某個類型事件發(fā)生了，然后由對應(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ù)則存儲在對應(yīng)的數(shù)據(jù)字段里面

完整性是我個人的理解，即我們在Cloud的環(huán)境中構(gòu)建的事件需要包含其當(dāng)前的完整上下文數(shù)據(jù)，以便后續(xù)系統(tǒng)有足夠的信息可以進(jìn)行業(yè)務(wù)邏輯處理與決策。這樣可以避免后端系統(tǒng)在接收到事件后，需要進(jìn)行當(dāng)前事件對應(yīng)上下文的組裝，主要是解決由于傳輸存在的延遲導(dǎo)致相關(guān)數(shù)據(jù)可能已經(jīng)不再是事件發(fā)生時的狀態(tài)，存在狀態(tài)不一致的情況

事件傳輸

事件產(chǎn)生后通常要發(fā)送到對應(yīng)的消息代理服務(wù)進(jìn)行暫存，在傳統(tǒng)的業(yè)務(wù)中通常會選擇特定的消息協(xié)議來進(jìn)行傳輸，這中間通常會涉及兩部分：序列化與傳輸協(xié)議。 在傳輸協(xié)議中Cloudevents中支持常見的行業(yè)標(biāo)準(zhǔn)協(xié)議比如HTTP、 AMQP、 MQTT、 SMT等，并支持常見的供應(yīng)商與平臺比如kafka、AWS Kinesis、 Azure 事件網(wǎng)格、Alibaba Cloud EventBridge，用戶可以根據(jù)自己的場景選擇對應(yīng)的供應(yīng)商分發(fā)對應(yīng)的事件

在序列化方面cloudevents支持HTTP、 AMQP、 Kafka等常見的標(biāo)準(zhǔn)協(xié)議，而不需要用戶手動進(jìn)行相關(guān)協(xié)議的序列化

事件消費(fèi)

事件的消費(fèi)端通常會對其關(guān)注的事件類型感興趣，并且由于消息的格式是統(tǒng)一的我們很容易就可以通過對應(yīng)的平臺來根據(jù)消息體里面的內(nèi)容進(jìn)行消息路由，分發(fā)給對應(yīng)的事件消費(fèi)者，事件的消費(fèi)者只要負(fù)責(zé)對應(yīng)事件的接收即可，而并不關(guān)注其他的信息

關(guān)于Cloudevents事件更多的內(nèi)容，后面再繼續(xù)分享，然后接下來就介紹下我們基于cloudevent是怎么設(shè)計(jì)系統(tǒng)的

入門場景

在前面的文章中，介紹過我們的服務(wù)目錄系統(tǒng)，服務(wù)目錄中要接入不同的基礎(chǔ)服務(wù)，基礎(chǔ)服務(wù)的格式各不相同，而且還要對接計(jì)費(fèi)、效率統(tǒng)計(jì)等系統(tǒng)，后期可能還會對接公司的事件流平臺，那如何對這些這些異構(gòu)模塊中異構(gòu)的數(shù)據(jù)進(jìn)行統(tǒng)一的分發(fā)和處理，我們的架構(gòu)如下：

消息處理流程

首先在消息發(fā)送端，我們基于cloudevent構(gòu)建對應(yīng)的消息，并且將當(dāng)前事件的上下文數(shù)據(jù)統(tǒng)一封裝到data中，然后發(fā)送給公司的消息隊(duì)列系統(tǒng)。由公司的消息隊(duì)列來完成對應(yīng)的事件分發(fā)與路由，對應(yīng)的事件接收端只需要定義自己關(guān)注的事件，而不需要去監(jiān)聽具體的MQ，只需要定義一個接受消息的HTTP接口接口，對應(yīng)消息的路由與分發(fā)功能由公司的MQ來實(shí)現(xiàn) 服務(wù)消費(fèi)端解析消息隊(duì)列傳遞過來的事件信息，解析出對應(yīng)的數(shù)據(jù)結(jié)構(gòu)，然后進(jìn)行業(yè)務(wù)處理即可。后續(xù)如果增加模塊，或者增加新的事件消費(fèi)需求，只需要實(shí)現(xiàn)對應(yīng)的邏輯即可

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

結(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中是一個結(jié)構(gòu)化的數(shù)據(jù)，按照這個結(jié)構(gòu)我們對應(yīng)的計(jì)費(fèi)、效率統(tǒng)計(jì)模塊，就可以拿到這個數(shù)據(jù)去做相關(guān)一些支線邏輯的處理了。

resources： 變更資源列表

即標(biāo)識當(dāng)前事件觸發(fā)了哪些相關(guān)資源的改變，比如虛機(jī)添加硬盤，實(shí)際上是包含了兩種資源即虛機(jī)與對應(yīng)的磁盤資源

整合服務(wù)目錄

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

1.服務(wù)目錄接收到服務(wù)變更請求后，保存數(shù)據(jù)庫后，發(fā)生對應(yīng)的cloudevent事件到消息隊(duì)列 2.在消息隊(duì)列中設(shè)定對應(yīng)的路由轉(zhuǎn)發(fā)規(guī)則，將對應(yīng)的事件發(fā)生給服務(wù)代理模塊 3.服務(wù)代理模塊根據(jù)type字段進(jìn)行解析，獲取對應(yīng)的后端服務(wù)地址，并從消息中解析出對應(yīng)的數(shù)據(jù)，將數(shù)據(jù)發(fā)送給后端真實(shí)的服務(wù) 4.后端真實(shí)服務(wù)接收到結(jié)構(gòu)化數(shù)據(jù)后，進(jìn)行自己的業(yè)務(wù)邏輯處理，處理完成后發(fā)送對應(yīng)的事件 5.服務(wù)代理模塊根據(jù)事件解析出相關(guān)的資源，調(diào)用對應(yīng)的平臺獲取當(dāng)前資源的數(shù)據(jù)，生成事件 6.服務(wù)目錄模塊接收到對應(yīng)的服務(wù)實(shí)例數(shù)據(jù)，存儲到自己的數(shù)據(jù)庫中

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

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

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

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

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

廣告

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