基于數(shù)據(jù)驅(qū)動(dòng)服務(wù)發(fā)現(xiàn)的增強(qiáng)微服務(wù)架構(gòu)

◆王娟

操作系統(tǒng)、網(wǎng)絡(luò)體系與服務(wù)器技術(shù)

基于數(shù)據(jù)驅(qū)動(dòng)服務(wù)發(fā)現(xiàn)的增強(qiáng)微服務(wù)架構(gòu)

◆王娟

（公安部第三研究所網(wǎng)絡(luò)安全技術(shù)研發(fā)中心 上海 201204）

微服務(wù)利用動(dòng)態(tài)分配資源以有效的粒度保證了服務(wù)的優(yōu)勢(shì)。當(dāng)前架構(gòu)中，數(shù)據(jù)生產(chǎn)者和使用者被創(chuàng)建為支持不同數(shù)據(jù)對(duì)象和服務(wù)質(zhì)量的分離組件。服務(wù)Mesh網(wǎng)絡(luò)旨在設(shè)計(jì)實(shí)現(xiàn)總體系統(tǒng)目標(biāo)的方法，缺乏對(duì)數(shù)據(jù)驅(qū)動(dòng)范式的支持?？捎媒M件的多樣性要求將用戶需求和數(shù)據(jù)產(chǎn)品集成到發(fā)現(xiàn)機(jī)制中。本文提出了一種基于配置文件匹配的數(shù)據(jù)驅(qū)動(dòng)的服務(wù)發(fā)現(xiàn)框架，該框架使用了以數(shù)據(jù)為中心的服務(wù)描述，設(shè)計(jì)了一種微服務(wù)架構(gòu)，該架構(gòu)可為服務(wù)Mesh網(wǎng)絡(luò)提供一組獨(dú)立的組件，用來(lái)管理多個(gè)地理區(qū)域內(nèi)的數(shù)據(jù)配置文件。

微服務(wù)；數(shù)據(jù)驅(qū)動(dòng)；軟件架構(gòu)

1 前言

近年來(lái)，微服務(wù)架構(gòu)（MSA）廣受歡迎，它利用模塊化，自包含組件在高動(dòng)態(tài)應(yīng)用中有巨大優(yōu)勢(shì)。MSA在行業(yè)中被廣泛用于要求可伸縮性、彈性和可用性的應(yīng)用程序中。隨著服務(wù)提供商數(shù)量和復(fù)雜性的增加，服務(wù)發(fā)現(xiàn)（SD）的重要性越來(lái)越高。在當(dāng)前的實(shí)踐中，SD實(shí)現(xiàn)是基于目標(biāo)的，旨在根據(jù)用戶所需的功能來(lái)實(shí)現(xiàn)總體系統(tǒng)目標(biāo)?？蛻敉ㄟ^(guò)其標(biāo)識(shí)符發(fā)現(xiàn)所請(qǐng)求服務(wù)的提供者的位置。

云計(jì)算和邊緣計(jì)算系統(tǒng)是數(shù)據(jù)驅(qū)動(dòng)的。數(shù)據(jù)的生產(chǎn)者和消費(fèi)者使用不同的數(shù)據(jù)格式、分辨率和預(yù)期的服務(wù)質(zhì)量（QoS）。這種情況下，基于目標(biāo)的服務(wù)發(fā)現(xiàn)方法就存在局限性。首先，使用基于服務(wù)標(biāo)識(shí)符構(gòu)建的方法，不能發(fā)現(xiàn)新創(chuàng)建的微服務(wù)以及不具有顯式標(biāo)識(shí)符的微服務(wù)。此外，使用主要基于網(wǎng)絡(luò)信息和標(biāo)識(shí)符的數(shù)據(jù)模型來(lái)描述服務(wù)會(huì)阻止客戶端程序使用滿足其特定需求的微服務(wù)。因此，本文提出了一個(gè)數(shù)據(jù)驅(qū)動(dòng)的SD框架來(lái)解決這些問(wèn)題。該框架支持創(chuàng)建上下文感知的微服務(wù)架構(gòu)，該架構(gòu)能夠在聯(lián)網(wǎng)環(huán)境中分配資源并復(fù)制服務(wù)。在客戶端，它允許根據(jù)對(duì)象和數(shù)據(jù)產(chǎn)品發(fā)現(xiàn)服務(wù)。在服務(wù)提供者端，它允許將第三方服務(wù)與上下文感知功能集成在一起，確保了應(yīng)用程序和管理服務(wù)的性能，具有彈性和可伸縮性。

2 數(shù)據(jù)驅(qū)動(dòng)的服務(wù)發(fā)現(xiàn)過(guò)程

在當(dāng)前的動(dòng)態(tài)微服務(wù)體系結(jié)構(gòu)中，采用三種不同的服務(wù)發(fā)現(xiàn)策略：基于DNS的服務(wù)發(fā)現(xiàn)，專用服務(wù)發(fā)現(xiàn)和固定的數(shù)據(jù)存儲(chǔ)，例如MySQL。本文假設(shè)用戶事先不知道哪些微服務(wù)可用，旨在使用以數(shù)據(jù)為中心的服務(wù)描述模型來(lái)保證數(shù)據(jù)驅(qū)動(dòng)的發(fā)現(xiàn)過(guò)程。

微服務(wù)架構(gòu)中的服務(wù)發(fā)現(xiàn)通常實(shí)現(xiàn)兩種模式：客戶端服務(wù)發(fā)現(xiàn)和服務(wù)器端服務(wù)發(fā)現(xiàn)。在實(shí)施客戶端發(fā)現(xiàn)時(shí)，客戶端負(fù)責(zé)啟動(dòng)服務(wù)發(fā)現(xiàn)過(guò)程并選擇目標(biāo)例。但是，在服務(wù)端發(fā)現(xiàn)中，中間組件充當(dāng)中間人，以攔截客戶端請(qǐng)求并完成發(fā)現(xiàn)過(guò)程，同時(shí)從客戶端提取發(fā)現(xiàn)詳細(xì)信息。

本文旨在設(shè)計(jì)一種數(shù)據(jù)驅(qū)動(dòng)的服務(wù)發(fā)現(xiàn)過(guò)程，該過(guò)程允許使用混合服務(wù)發(fā)現(xiàn)模式在數(shù)據(jù)產(chǎn)品和服務(wù)之間進(jìn)行匹配。此方法有兩個(gè)設(shè)計(jì)目標(biāo)。首先，設(shè)計(jì)一個(gè)數(shù)據(jù)模型能夠發(fā)現(xiàn)分類部署在平臺(tái)中的微服務(wù)。其次，設(shè)計(jì)一種結(jié)合兩種服務(wù)發(fā)現(xiàn)模式的通信協(xié)議。這樣，在確保對(duì)注冊(cè)數(shù)據(jù)進(jìn)行授權(quán)訪問(wèn)的同時(shí)，客戶端可以完全控制發(fā)現(xiàn)過(guò)程。該協(xié)議由客戶端、服務(wù)注冊(cè)表和API網(wǎng)關(guān)之間的交互組成。

2.1 數(shù)據(jù)模型

服務(wù)發(fā)現(xiàn)的主要目標(biāo)是向客戶顯示平臺(tái)中部署的可用微服務(wù)。為此，每個(gè)微服務(wù)都使用數(shù)據(jù)模型在平臺(tái)中注冊(cè)，以聲明其對(duì)發(fā)現(xiàn)客戶端的可用性。該數(shù)據(jù)模型通常至少包含服務(wù)名稱和有關(guān)服務(wù)提供商的網(wǎng)絡(luò)位置的信息。在數(shù)據(jù)驅(qū)動(dòng)的服務(wù)發(fā)現(xiàn)中，應(yīng)指定與服務(wù)性能和所提供功能有關(guān)的其他信息。輸入類型、輸入?yún)?shù)和測(cè)量的性能被視為微服務(wù)配置文件中的主要屬性，這些配置文件在數(shù)據(jù)驅(qū)動(dòng)的服務(wù)發(fā)現(xiàn)過(guò)程中進(jìn)行了檢查。當(dāng)客戶端程序啟動(dòng)發(fā)現(xiàn)過(guò)程時(shí)，必須指定有關(guān)客戶端數(shù)據(jù)屬性的信息，例如數(shù)據(jù)類型、數(shù)據(jù)格式或大小。

2.2 服務(wù)發(fā)現(xiàn)過(guò)程

該平臺(tái)中使用的混合發(fā)現(xiàn)模式在發(fā)現(xiàn)過(guò)程中涉及兩個(gè)組件：服務(wù)注冊(cè)表和API網(wǎng)關(guān)。

服務(wù)注冊(cè)表代表一個(gè)數(shù)據(jù)庫(kù)集群，其中包含平臺(tái)中部署的可用微服務(wù)的數(shù)據(jù)模型，可以動(dòng)態(tài)創(chuàng)建和銷毀新實(shí)例。部署新服務(wù)實(shí)例后，其數(shù)據(jù)模型將在服務(wù)注冊(cè)表中注冊(cè)以聲明其可用性。當(dāng)微服務(wù)不再可用時(shí)，將刪除此服務(wù)描述。存在兩種不同的模式來(lái)處理服務(wù)注冊(cè)表中的微服務(wù)注冊(cè)和注銷。該過(guò)程可以直接自我注冊(cè)或通過(guò)中間組件（第三方注冊(cè)模式）完成。在此平臺(tái)上，使用第二種模式，因?yàn)樗宫F(xiàn)有的微服務(wù)與注冊(cè)過(guò)程解耦。這有助于我們部署與平臺(tái)無(wú)關(guān)的微服務(wù)，該微服務(wù)無(wú)須實(shí)施任何注冊(cè)邏輯即可加入我們的平臺(tái)。在服務(wù)發(fā)現(xiàn)期間，發(fā)現(xiàn)客戶端會(huì)查詢服務(wù)注冊(cè)表，以找到與其數(shù)據(jù)對(duì)象匹配的配置文件。API網(wǎng)關(guān)會(huì)攔截發(fā)現(xiàn)過(guò)程中客戶端與注冊(cè)表之間的交互。

（1）客戶端通過(guò)向服務(wù)注冊(cè)表發(fā)送請(qǐng)求來(lái)啟動(dòng)服務(wù)發(fā)現(xiàn)；

（2）服務(wù)注冊(cè)表過(guò)濾存儲(chǔ)的微服務(wù)集，并向客戶端返回一個(gè)列表，其中包含可以應(yīng)用于此類型對(duì)象的所有可用功能的名稱；

（3）客戶根據(jù)自己的目標(biāo)選擇最適合的功能，向注冊(cè)表指定所選功能以及其數(shù)據(jù)對(duì)象和質(zhì)量要求的詳細(xì)信息；

（4）注冊(cè)表根據(jù)這些特征創(chuàng)建一個(gè)新列表，列表包含平臺(tái)中所有支持客戶端對(duì)象的現(xiàn)有微服務(wù)的完整描述；

（5）當(dāng)客戶端程序收到新列表時(shí)，它發(fā)現(xiàn)了所有現(xiàn)有的微服務(wù)，選擇在機(jī)器性能，網(wǎng)絡(luò)性能，請(qǐng)求的參數(shù)等方面最合適的實(shí)例進(jìn)行交互。在發(fā)現(xiàn)期間，為滿足客戶的需求，微服務(wù)實(shí)例在運(yùn)行時(shí)被復(fù)制。

通信策略描述了兩種類型的請(qǐng)求：用于在注冊(cè)表中查找服務(wù)的“發(fā)現(xiàn)請(qǐng)求”和從發(fā)現(xiàn)的微服務(wù)中獲得服務(wù)的“訪問(wèn)請(qǐng)求”?？蛻舳伺c所選微服務(wù)之間的任何交互都是直接的，發(fā)現(xiàn)過(guò)程如圖1所示：

圖1 客戶端啟動(dòng)到API網(wǎng)關(guān)和服務(wù)注冊(cè)表的數(shù)據(jù)驅(qū)動(dòng)服務(wù)發(fā)現(xiàn)的工作流程

3 數(shù)據(jù)驅(qū)動(dòng)的微服務(wù)架構(gòu)

服務(wù)發(fā)現(xiàn)過(guò)程及其在服務(wù)mesh[1]中的集成依賴于幾個(gè)系統(tǒng)組件的交互來(lái)管理微服務(wù)的創(chuàng)建和資源分配。隨著服務(wù)和基礎(chǔ)架構(gòu)的復(fù)雜性增加，需要減少與發(fā)現(xiàn)過(guò)程有關(guān)的管理服務(wù)的數(shù)量，防止系統(tǒng)性能下降。

為此，本文提出以下基于數(shù)據(jù)驅(qū)動(dòng)的體系結(jié)構(gòu)：（1）一個(gè)專用API網(wǎng)關(guān)，專用于現(xiàn)有微服務(wù)支持的每種數(shù)據(jù)類型，允許基于數(shù)據(jù)的服務(wù)管理；（2）區(qū)域管理，允許客戶發(fā)現(xiàn)特定地理區(qū)域中的服務(wù)，并平衡區(qū)域之間的負(fù)載；（3）點(diǎn)對(duì)點(diǎn)模型，在區(qū)域之間創(chuàng)建覆蓋網(wǎng)絡(luò)。這樣就可以發(fā)現(xiàn)部署在多個(gè)站點(diǎn)上的資源。

客戶端和微服務(wù)之間的通信使用兩種主要模型實(shí)現(xiàn)[2]：通用API后端和前端后端（BFF）。通用API后端為后端服務(wù)提供了一個(gè)入口點(diǎn)，而B(niǎo)FF為每種類型的客戶端引入了多個(gè)入口點(diǎn)。使用此模型，傳入的負(fù)載在針對(duì)每個(gè)客戶端需求量身定制的多個(gè)定制網(wǎng)關(guān)之間共享。這減少了這些入口點(diǎn)中出現(xiàn)瓶頸的可能性。

本文架構(gòu)采用定制的前后端（BFF）通信模型。該模型創(chuàng)建專用于每種微服務(wù)類別的入口點(diǎn)。每個(gè)BFF網(wǎng)關(guān)都鏈接到服務(wù)注冊(cè)表集群，以管理屬于同一數(shù)據(jù)類別的微服務(wù)。該群集僅負(fù)責(zé)存儲(chǔ)由該BFF網(wǎng)關(guān)管理的微服務(wù)的數(shù)據(jù)模型。

本文在系統(tǒng)中使用了區(qū)域和可用區(qū)的概念。區(qū)域設(shè)計(jì)為彼此完全隔離，以確保系統(tǒng)的穩(wěn)定性，但是區(qū)域內(nèi)的可用區(qū)連接在一起。屬于同一地理區(qū)域的資源鏈接到一個(gè)區(qū)域內(nèi)的同一可用區(qū)。每個(gè)區(qū)域都有自己的BFF后端和服務(wù)注冊(cè)表。它包含一個(gè)區(qū)域管理器（ZM）組件，用于管理傳入的請(qǐng)求。該組件代表每個(gè)區(qū)域中體系結(jié)構(gòu)的入口點(diǎn)，從位于其區(qū)域中的客戶端接收請(qǐng)求，并確定這些請(qǐng)求應(yīng)轉(zhuǎn)發(fā)到哪個(gè)BFF網(wǎng)關(guān)。選定的BFF網(wǎng)關(guān)從其專用注冊(cè)表接收到可用微服務(wù)的列表后，會(huì)將結(jié)果發(fā)送回ZM，ZM再將其傳遞給客戶端。

4 小結(jié)

本文提出了一個(gè)獨(dú)立的數(shù)據(jù)驅(qū)動(dòng)服務(wù)發(fā)現(xiàn)框架，該框架允許客戶端程序根據(jù)其數(shù)據(jù)對(duì)象發(fā)現(xiàn)可用的功能和微服務(wù)。它建立在以數(shù)據(jù)為中心的模型上，可以在數(shù)據(jù)產(chǎn)品需求和服務(wù)之間進(jìn)行匹配。此外，它使用了具有對(duì)等網(wǎng)絡(luò)的數(shù)據(jù)驅(qū)動(dòng)微服務(wù)架構(gòu)，該架構(gòu)支持可擴(kuò)展的服務(wù)發(fā)現(xiàn)并可能集成地理特征?；谖⒎?wù)的數(shù)據(jù)驅(qū)動(dòng)模型和點(diǎn)對(duì)點(diǎn)架構(gòu)確保了應(yīng)用程序和管理服務(wù)的性能和可擴(kuò)展性。

[1]Thramboulidis K，Vachtsevanou D C，Solanos A . Cyber-Physical Microservices：An IoT-based Framework for Manufacturing Systems[J]. 2018.

[2]Fernandez，Vidal，Valera. Enabling the Orchestration of IoT Slices through Edge and Cloud Microservice Platforms[J]. Sensors，2019，19（13）：2980.