基于數據驅動服務發現的增強微服務架構

◆王娟

操作系統、網絡體系與服務器技術

基于數據驅動服務發現的增強微服務架構

◆王娟

（公安部第三研究所網絡安全技術研發中心 上海 201204）

微服務利用動態分配資源以有效的粒度保證了服務的優勢。當前架構中，數據生產者和使用者被創建為支持不同數據對象和服務質量的分離組件。服務Mesh網絡旨在設計實現總體系統目標的方法，缺乏對數據驅動范式的支持。可用組件的多樣性要求將用戶需求和數據產品集成到發現機制中。本文提出了一種基于配置文件匹配的數據驅動的服務發現框架，該框架使用了以數據為中心的服務描述，設計了一種微服務架構，該架構可為服務Mesh網絡提供一組獨立的組件，用來管理多個地理區域內的數據配置文件。

微服務；數據驅動；軟件架構

1 前言

近年來，微服務架構（MSA）廣受歡迎，它利用模塊化，自包含組件在高動態應用中有巨大優勢。MSA在行業中被廣泛用于要求可伸縮性、彈性和可用性的應用程序中。隨著服務提供商數量和復雜性的增加，服務發現（SD）的重要性越來越高。在當前的實踐中，SD實現是基于目標的，旨在根據用戶所需的功能來實現總體系統目標。客戶通過其標識符發現所請求服務的提供者的位置。

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

2 數據驅動的服務發現過程

在當前的動態微服務體系結構中，采用三種不同的服務發現策略：基于DNS的服務發現，專用服務發現和固定的數據存儲，例如MySQL。本文假設用戶事先不知道哪些微服務可用，旨在使用以數據為中心的服務描述模型來保證數據驅動的發現過程。

微服務架構中的服務發現通常實現兩種模式：客戶端服務發現和服務器端服務發現。在實施客戶端發現時，客戶端負責啟動服務發現過程并選擇目標例。但是，在服務端發現中，中間組件充當中間人，以攔截客戶端請求并完成發現過程，同時從客戶端提取發現詳細信息。

本文旨在設計一種數據驅動的服務發現過程，該過程允許使用混合服務發現模式在數據產品和服務之間進行匹配。此方法有兩個設計目標。首先，設計一個數據模型能夠發現分類部署在平臺中的微服務。其次，設計一種結合兩種服務發現模式的通信協議。這樣，在確保對注冊數據進行授權訪問的同時，客戶端可以完全控制發現過程。該協議由客戶端、服務注冊表和API網關之間的交互組成。

2.1 數據模型

服務發現的主要目標是向客戶顯示平臺中部署的可用微服務。為此，每個微服務都使用數據模型在平臺中注冊，以聲明其對發現客戶端的可用性。該數據模型通常至少包含服務名稱和有關服務提供商的網絡位置的信息。在數據驅動的服務發現中，應指定與服務性能和所提供功能有關的其他信息。輸入類型、輸入參數和測量的性能被視為微服務配置文件中的主要屬性，這些配置文件在數據驅動的服務發現過程中進行了檢查。當客戶端程序啟動發現過程時，必須指定有關客戶端數據屬性的信息，例如數據類型、數據格式或大小。

2.2 服務發現過程

該平臺中使用的混合發現模式在發現過程中涉及兩個組件：服務注冊表和API網關。

服務注冊表代表一個數據庫集群，其中包含平臺中部署的可用微服務的數據模型，可以動態創建和銷毀新實例。部署新服務實例后，其數據模型將在服務注冊表中注冊以聲明其可用性。當微服務不再可用時，將刪除此服務描述。存在兩種不同的模式來處理服務注冊表中的微服務注冊和注銷。該過程可以直接自我注冊或通過中間組件（第三方注冊模式）完成。在此平臺上，使用第二種模式，因為它使現有的微服務與注冊過程解耦。這有助于我們部署與平臺無關的微服務，該微服務無須實施任何注冊邏輯即可加入我們的平臺。在服務發現期間，發現客戶端會查詢服務注冊表，以找到與其數據對象匹配的配置文件。API網關會攔截發現過程中客戶端與注冊表之間的交互。

（1）客戶端通過向服務注冊表發送請求來啟動服務發現；

（2）服務注冊表過濾存儲的微服務集，并向客戶端返回一個列表，其中包含可以應用于此類型對象的所有可用功能的名稱；

（3）客戶根據自己的目標選擇最適合的功能，向注冊表指定所選功能以及其數據對象和質量要求的詳細信息；

（4）注冊表根據這些特征創建一個新列表，列表包含平臺中所有支持客戶端對象的現有微服務的完整描述；

（5）當客戶端程序收到新列表時，它發現了所有現有的微服務，選擇在機器性能，網絡性能，請求的參數等方面最合適的實例進行交互。在發現期間，為滿足客戶的需求，微服務實例在運行時被復制。

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

圖1 客戶端啟動到API網關和服務注冊表的數據驅動服務發現的工作流程

3 數據驅動的微服務架構

服務發現過程及其在服務mesh[1]中的集成依賴于幾個系統組件的交互來管理微服務的創建和資源分配。隨著服務和基礎架構的復雜性增加，需要減少與發現過程有關的管理服務的數量，防止系統性能下降。

為此，本文提出以下基于數據驅動的體系結構：（1）一個專用API網關，專用于現有微服務支持的每種數據類型，允許基于數據的服務管理；（2）區域管理，允許客戶發現特定地理區域中的服務，并平衡區域之間的負載；（3）點對點模型，在區域之間創建覆蓋網絡。這樣就可以發現部署在多個站點上的資源。

客戶端和微服務之間的通信使用兩種主要模型實現[2]：通用API后端和前端后端（BFF）。通用API后端為后端服務提供了一個入口點，而BFF為每種類型的客戶端引入了多個入口點。使用此模型，傳入的負載在針對每個客戶端需求量身定制的多個定制網關之間共享。這減少了這些入口點中出現瓶頸的可能性。

本文架構采用定制的前后端（BFF）通信模型。該模型創建專用于每種微服務類別的入口點。每個BFF網關都鏈接到服務注冊表集群，以管理屬于同一數據類別的微服務。該群集僅負責存儲由該BFF網關管理的微服務的數據模型。

本文在系統中使用了區域和可用區的概念。區域設計為彼此完全隔離，以確保系統的穩定性，但是區域內的可用區連接在一起。屬于同一地理區域的資源鏈接到一個區域內的同一可用區。每個區域都有自己的BFF后端和服務注冊表。它包含一個區域管理器（ZM）組件，用于管理傳入的請求。該組件代表每個區域中體系結構的入口點，從位于其區域中的客戶端接收請求，并確定這些請求應轉發到哪個BFF網關。選定的BFF網關從其專用注冊表接收到可用微服務的列表后，會將結果發送回ZM，ZM再將其傳遞給客戶端。

4 小結

本文提出了一個獨立的數據驅動服務發現框架，該框架允許客戶端程序根據其數據對象發現可用的功能和微服務。它建立在以數據為中心的模型上，可以在數據產品需求和服務之間進行匹配。此外，它使用了具有對等網絡的數據驅動微服務架構，該架構支持可擴展的服務發現并可能集成地理特征。基于微服務的數據驅動模型和點對點架構確保了應用程序和管理服務的性能和可擴展性。

[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.