基于数据驱动服务发现的增强微服务架构

◆王娟

操作系统、网络体系与服务器技术

基于数据驱动服务发现的增强微服务架构

◆王娟

（公安部第三研究所网络安全技术研发中心 上海 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）当客户端程序收到新列表时，它发现了所有现有的微服务，选择在机器性能，网络性能，请求的参数等方面最合适的实例进行交互。在发现期间，为满足客户的需求，微服务实例在运行时被复制。

通信策略描述了两种类型的请求：用于在注册表中查找服务的“发现请求”和从发现的微服务中获得服务的“访问请求”。客户端与所选微服务之间的任何交互都是直接的，发现过程如图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.