CN114579199A - 一种服务网格中代理的扩展方法、系统及存储介质 - Google Patents

Abstract

本申请实施例提供一种服务网格中代理的扩展方法、系统及存储介质。在本申请实施例中，以代理插件的方式预先编写了现有网格代理功能之外的众多扩展功能，基于此，可在服务网格的控制平面层中对用户定义的扩展需求内容进行分析，以感知用户的扩展需求；可由控制平面层提供代理扩展配置参数并触发数据平面层引入目标代理插件对应的插件数据，这使得数据平面层下具备了代理扩展基础。据此，通过在控制平面层发起代理扩展事件，并由控制平面层控制用户所指定的目标代理插件在数据平面层生效，可在控制平面层和数据平面层之间实现网格代理的扩展部署的联动，从而支持网格代理的热更新，可有效改善服务网格的代理扩展能力。

Description

一种服务网格中代理的扩展方法、系统及存储介质

技术领域

本申请涉及服务网格技术领域，尤其涉及一种服务网格中代理的扩展方法、系统及存储介质。

背景技术

随着单体应用向分布式应用微服务化的方向发展，服务网格(service mesh)被用于在服务间进行通信，并成为一种基础设施层。它负责通过包含云原生应用程序的复杂服务拓扑来可靠地传递请求。服务网格逻辑上分为控制平面层和数据平面层两部分。控制平面层负责一些控制管理的功能，以驱动数据平面层中网格代理的行为。数据平面层则可包含一系列以边车sidecar形式部署在每个服务实例旁边的网格代理proxy，网格代理proxy用于增强服务调用之间的网络安全性、可靠性以及可观测性等。

目前，对网格代理的扩展方案通常包括静态预编译和手动加载等方式，但是这些扩展方式的代价都很大，无法支持热更新，这给网格代理的发展带来了瓶颈。

发明内容

本申请的多个方面提供一种服务网格中代理的扩展方法、系统及存储介质，用以支持对服务网格中的网格代理进行热更新。

本申请实施例提供一种服务网格中代理的扩展方法，所述服务网格包含控制平面层和数据平面层，所述方法包括：

在所述控制平面层中，对用户定义的扩展需求内容进行分析，以确定代理扩展配置参数、用户所指定的目标代理插件以及所述数据平面层中需要扩展的目标网格代理；

通过所述控制平面层触发所述数据平面层从预置的代理插件库中为所述目标网格代理拉取所述目标代理插件对应的插件数据；

通过所述控制平面层将所述代理扩展配置参数提供给所述目标网格代理，以在所述目标网格代理中激活所述目标代理插件对应的插件数据。

本申请实施例还提供一种服务网格系统，包括部署于控制平面层中的代理插件控制器和扩展触发器，以及部署在数据平面层的插件加载器和插件更新器；

所述代理插件控制器，用于对用户定义的扩展需求内容进行分析，以确定代理扩展配置参数、用户所指定的目标代理插件以及所述数据平面层中需要扩展的目标网格代理；

所述扩展触发器，用于触发所述数据平面层中的插件加载器从预置的代理插件库中为所述目标网格代理拉取所述目标代理插件对应的插件数据；

所述扩展触发器，还用于将所述代理扩展配置参数提供给所述插件更新器，以触发所述插件更新器在所述目标网格代理中激活所述目标代理插件对应的插件数据。

本申请实施例还提供一种分布式微服务系统，包括多个第一节点和第二节点，每个第一节点包括微服务应用和网格代理，所述第二节点包括控制组件；所述第二节点中的控制组件，用于：

对用户定义的扩展需求内容进行分析，以确定代理扩展配置参数、用户所指定的目标代理插件以及需要扩展的目标网格代理；

触发所述目标网格代理所在的第一节点从预置的代理插件库中为所述目标网格代理拉取所述目标代理插件对应的插件数据；

将所述代理扩展配置参数提供给所述目标网格代理，以在所述目标网格代理中激活所述目标代理插件对应的插件数据。

本申请实施例还提供一种存储计算机指令的计算机可读存储介质，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行前述的服务网格中代理的扩展方法。

在本申请实施例中，以代理插件的方式预先编写了现有网格代理功能之外的众多扩展功能，基于此，可在服务网格的控制平面层中对用户定义的扩展需求内容进行分析，以确定出代理扩展配置参数、用户所指定的目标代理插件以及所述数据平面层中需要扩展的目标网格代理；并可由控制平面层触发服务网格的数据平面层为目标网格代理拉取目标代理插件对应的插件数据，从而将目标代理插件引入到数据平面层中；控制平面层还可将代理扩展配置参数提供给目标网格代理，这使得，目标网格代理可基于代理扩展配置参数和目标代理插件的插件数据进行扩展。据此，本申请实施例中，提出在控制平面层发起代理扩展事件，并由控制平面层控制用户所指定的目标代理插件在数据平面层生效，这可在控制平面层和数据平面层之间实现网格代理的扩展部署的联动，从而支持网格代理的热更新，不再需要修改源代码，也不再需要对服务网格进行多次重启，可有效改善服务网格的代理扩展能力。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请一示例性实施例提供的一种示例性的服务网格的架构图；

图2a为本申请一示例性实施例提供的一种服务网格中代理的扩展方法的流程示意图；

图2b为本申请一示例性实施例提供的一种服务网格中代理的扩展方法的逻辑程示意图；

图3为本申请另一示例性实施例提供的一种服务网格系统的结构示意图；

图4为本申请又一示例性实施例提供的一种分布式微服务系统的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

目前，对网格代理的扩展方案通常包括静态预编译和手动加载等方式，但是这些扩展方式的代价都很大，无法支持热更新。为此，本申请的一些实施例中：以代理插件的方式预先编写了现有网格代理功能之外的众多扩展功能，基于此，可在服务网格的控制平面层中对用户定义的扩展需求内容进行分析，以确定出代理扩展配置参数、用户所指定的目标代理插件以及所述数据平面层中需要扩展的目标网格代理；并可由控制平面层触发服务网格的数据平面层为目标网格代理拉取目标代理插件对应的插件数据，从而将目标代理插件引入到数据平面层中；控制平面层还可将代理扩展配置参数提供给目标网格代理，这使得，目标网格代理可基于代理扩展配置参数和目标代理插件的插件数据进行扩展。据此，本申请实施例中，提出在控制平面层发起代理扩展事件，并由控制平面层控制用户所指定的目标代理插件在数据平面层生效，这可实现在控制平面层和数据平面层联动完成网格代理的扩展部署，从而支持网格代理的热更新，不再需要修改源代码，也不再需要对服务网格进行多次重启，可有效改善服务网格的代理扩展能力。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图2a为本申请一示例性实施例提供的一种服务网格中代理的扩展方法的流程示意图。图2为本申请一示例性实施例提供的一种服务网格中代理的扩展方法的逻辑示意图。参考图2a和图2，服务网格可包括控制平面层和数据平面层，该方法可包括：

步骤100、在控制平面层中，对用户定义的扩展需求内容进行分析，以确定代理扩展配置参数、用户所指定的目标代理插件以及数据平面层中需要扩展的目标网格代理；

步骤101、通过控制平面层触发数据平面层从预置的代理插件库中为目标网格代理拉取目标代理插件对应的插件数据；

步骤102、通过控制平面层将代理扩展配置参数提供给目标网格代理，以在目标网格代理中激活目标代理插件对应的插件数据。

本实施例提供的扩展方案可应用于对服务网格中的网格代理进行扩展的应用场景中。以下先对该应用场景中涉及到的几个技术概念进行简单解释：

服务网格Mesh，是一种微服务架构，用于处理服务间通信的基础设施层。它负责通过包含云原生应用程序的复杂服务拓扑来可靠地传递请求。在基于服务网格的应用模型中，一个应用程序可能会包含数百个服务，每个服务又有数百个实例构成，每一个服务实例中包括了一个Sidecar形式的网格代理。这些网格代理可形成一个网状的数据平面层，通过该数据平面层处理和观察所有服务间的流量。数据平面层扮演了一个用来建立、保护和控制通过网格的流量的角色。

负责数据平面层如何执行的管理组件称为控制平面层。前述的成百上千个应用程序的网格代理如何统一管理，这就是服务网格中定义的控制平面层部分要解决的问题。控制平面层是服务网格的大脑，并为网格使用人员提供公开API，以便较容易地操纵网络行为。

图1为本申请一示例性实施例提供的一种示例性的服务网格的架构图。参考图1，该服务网格100主要用于方便多个微服务之间进行安全和可靠的通信，微服务是指将应用程序分解为多个较小的服务或者实例，并分布在不同的集群/机器上运行。

如图所示，微服务包括应用服务实例A和应用服务实例B，应用服务实例A和应用服务实例B形成服务网格100的功能应用层。在一种实施方式中，应用服务实例A和B以容器/进程的形式运行在机器/工作负载容器组108(POD)。

在一种实施方式中，应用服务实例A可以是商品查询服务，应用服务实例B可以是商品下单服务。

如图1所示，应用服务实例A和网格代理(sidecar)103共存于机器工作负载容器组114，应用服务实例B和网格代理105共存于机器工作负载容器组114。网格代理103和105形成服务网格100的数据平面层(data plane)。其中，网格代理103和105分别以容器/进程104,106的形式在运行，并且网格代理103和应用服务实例A之间可以双向通信，网格代理105和应用服务实例B之间可以双向通信。此外，网格代理103和网格代理105之间还可以双向通信。

在一种实施方式中，应用服务实例A的所有流量都通过网格代理103被路由到合适的目的地，应用服务实例B的所有网络流量都通过网格代理105被路由到合适的目的地。需要说明的是，在此提及的网络流量包括但不限于HTTP,REST,gRPC,Redis等形式。

在一种实施方式中，可以通过为服务网格100中的代理(Envoy)编写自定义的过滤器(Filter)来实现扩展数据平面层的功能，服务网格代理配置可以是为了使服务网格正确地代理服务流量，实现服务互通和服务治理。网格代理103和网格代理105可以被配置成执行至少如下功能中的一种：服务发现(service discovery)，健康检查(health checking)，路由(Routing)，负载均衡(Load Balancing)，认证和授权(authentication andauthorization)，以及可观测性(observability)。

如图1所示，该服务网格100还包括控制平面层。其中，控制平面层可以是由一组在一个专用的命名空间中运行的服务，在机器/工作负载容器组(machine/Pod)102由托管控制面组件101来托管这些服务。如图1所示，托管控制面组件101与网格代理103和网格代理105进行双向通信。托管控制面组件101被配置成执行一些控制管理的功能。例如，托管控制面组件101接收网格代理103和网格代理105传送的遥测数据，可以进一步对这些遥测数据做聚合。这些服务，托管控制面组件101还可以提供面向用户的应用程序接口(API)，以便较容易地操纵网络行为，以及向网格代理103和网格代理105提供配置数据等。

当然图1所示的服务网格的结构仅是示例性的，本实施例中对服务网格的具体结构并不做限定，本实施例主要关注服务网格中的网格代理。

目前，网格代理已经具备了一些基础功能，但是随着用户需求的不断变化，网格代理的现有功能已经无法满足用户需求，为此，本实施例提供了一种支持热更新的扩展方案，以对网格代理的功能进行高效扩展。本实施例中对网格代理的扩展包括但不限于对现有功能的修改或增加新的功能，也即是，代理插件可用于对网格代理中已有过滤器Filter进行修改，也可用于在网格代理中新增过滤器Filter。

参考图2a和图2b，在步骤100中，可在控制平面层中，对用户定义的扩展需求内容进行分析，以确定代理扩展配置参数、用户所指定的目标代理插件以及数据平面层中需要扩展的目标网格代理。其中，本实施例中，控制平面层可面向用户提供声明式API，这样，用户可采用声明式API的方式来定义扩展需求内容，也即是，本实施例中扩展需求内容可包含用户期望的网格代理扩展的终态内容。在一种实际应用中，可按照扩展需求编写对应API对象的YAML文件交给控制平面层(而不是使用一些命令来直接操作API)；所谓“声明式”，指的就是用户只需要提交一个定义好的API对象来“声明”(这个YAML文件其实就是一种“声明”)，表示所期望的最终状态是什么样子就可以了。可选地，本实施例中，扩展需求内容可包括但不限于扩展生效范围、期望使用的代理插件的属性信息以及部分配置参数等，当然，扩展需求内容中还可包含其它信息，本实施例并不限于此。

一种示例性的扩展需求内容的数据结构可以是：

其中，上述数据结构中的“workloadSelector”部分用于定义所述扩展生效范围，“plugin”部分用于定义期望使用的代理插件的属性信息，“configuration”部分用于定义期望使用的代理插件的部分配置参数。应当理解的是，上述示例性数据结构中所定义的内容均是示例性的，不应造成对本申请中扩展需求内容的限制。

这样，本实施例中，可基于扩展需求内容中的扩展生效范围，从数据平面层包含的网格代理中，选择与扩展生效范围适配的网格代理，作为需要扩展的目标网格代理。其中，扩展生效范围可包含用户期望扩展的网格代理的筛选条件。在一些示例性方案中，可基于插件标签和/或插件版本等来定义扩展生效范围，其中，可预先为插件和网格代理关联标签和/或版本，且预先定义插件标签与网格代理的标签之间的对应关系，预先定于插件版本与网格代理的版本之间的对应关系；这样，在扩展生效范围中指定有插件标签的情况下，基于插件标签与网格代理的标签之间的对应关系，从数据平面层包含的网格代理中，选择与指定插件标签适配的网格代理，作为目标网格代理；目标网格代理的标签与指定插件标签相对应；和/或，在扩展生效范围中指定有插件版本的情况下，基于插件版本与网格代理的版本之间的对应关系，从数据平面层包含的网格代理中，选择与指定插件版本适配的网格代理，作为目标网格代理；目标网格代理的版本与指定插件版本相对应。当然，除了“标签”和“版本”维度，本实施例中还可从其它维度来定义扩展生效范围。

也即是，本实施例中，可采用约束机制在扩展需求内容中指定扩展生效范围，从而从数据平面层包含的网格代理中筛选出目标代理插件所应作用的网格代理范围，而不会直接在扩展需求内容中指定出目标网格代理。这使得控制平面层更加简洁、更加全面地感知到需要扩展的目标网格代理。

本实施例中，可预先构建代理插件库，代理插件库中可包含若干预先编写好的代理插件的插件数据。其中，代理插件的存在形式可以是多样的，代理插件可以是容器镜像、可以是二进制文件等，本实施例对代理插件的存在形式不做限定。另外，可选地，本实施例中，可采用WebAssembly(WASM)编程语言来编写代理插件，关于代理插件的编写方案在本申请中将不做阐述，本申请支持各种代理插件的编写方案，只需约定代理插件的插件数据格式能够与数据平面层中的网格代理的格式要求相适配即可。

在服务网格中，网格代理的扩展通常是为网格代理编写自定义的过滤器Filter来扩展网格代理的功能，而本实施例中提供的代理插件则可以是在过滤器之外抽象出的一层产品。本实施例中，代理插件的本质是一种插件，但代理插件可以对应网格代理中的单个过滤器Filter，也可以对应网格代理中的过滤器链FilterChain，还可代表网格代理中单个过滤器的子功能Sub-Filter。这样，本实施例中，可基于代理插件更加灵活、更加完善地为网格代理提供扩展基础。在网格代理的扩展过程中，只需从代理插件库中按需取用所需的代理插件，即可将代理插件的插件数据引入到数据平面层中，从而支持网格代理的扩展。

在此基础上，本实施例中，可通过解析前述的扩展需求内容包含的期望使用的代理插件的属性信息来确定用户所指定的目标代理插件。其中，目标代理插件可以是代理插件库中的部分或全部代理插件，用户可按需指定，本实施例对此不做限定。

本实施例中，至少可提供以下几种获取代理插件的途径，当然，本实施例并不限于此：

·集群配置项：Kubernetes集群提供的一种用于以键值对方式存储的非机密性的数据。

·集群保密字典：与集群配置项类似,但不同的是存储的数据为机密性的数据。

·OCI镜像地址：以OCI镜像格式存储的文件可访问地址。

·远程地址：其他任意类型的文件可访问地址。

据此，前述的扩展需求内容中包含的期望使用的代理插件的属性信息可包括但不限于目标代理插件的名称、拉取途径或运行所需的外部参数等，其中，拉取途径即为上述提及的获取代理插件的途径。

另外，本实施例中，还可通过解析扩展需求内容中期望使用的代理插件的属性信息获得插件描述信息，其中，插件描述信息中包含的信息相交于扩展需求内容中定义的期望使用的代理插件的属性信息可以更加丰富，对此，本实施例中，在对扩展需求内容进行分析的过程中，可根据确定出的目标代理插件的名称及拉取途径等，对接代理插件库，以获得目标代理插件采用的技术实现类型、路径参数、所需的运行环境等更多信息，以完善插件描述信息。在此基础上，可将插件描述信息结合扩展需求内容中期望使用的代理插件的部分配置参数，来产生代理扩展配置参数。本实施例中，代理扩展配置参数可用于指示目标代理插件的使用规则，也即是，相关的网格代理可根据代理扩展配置参数来获知如何使用目标代理插件的插件数据，从而使目标代理插件发挥出功能。本实施例中，代理扩展配置参数中可包括但不限于插件名称、插件采用的技术实现类型、所需的运行环境、运行所需的外部参数等等。可知，本实施例中的代理扩展配置参数实质上来源于用户定义的扩展需求内容以及与代理数据库建连而获得的丰富的插件属性信息，控制平面层可对扩展需求内容进行解析及格式转换等，产生数据平面层中的网格代理可理解的代理扩展配置参数。

一种示例性的代理扩展配置参数的数据结构可以是：

其中，“typed_config”部分用于描述插件的技术实现类型，该示例性插件的技术实现类型为Wasm；“config”部分用于代理前述的插件描述信息，其中的“runtime”部分用于描述插件所需的运行环境，“filename”部分用于描述路径参数，通过路径参数可找到对应的插件数据；“configuration”部分用于描述插件运行所需的外部参数。应当理解的是，上述示例性数据结构中所定义的内容均是示例性的，不应造成对本申请中代理扩展配置参数的限制。

另外，对于不同类型的网格代理，所能理解的代理扩展配置参数的数据格式可能存在差别，所需的代理扩展配置参数中包含的参数种类可能存在差别，本实施例中，在控制面中，可针对服务网格中采用的网格代理的类型，适应性地产生与网格代理的类型相适配的代理扩展配置参数。

本实施例中，在控制平面层中增加了扩展需求感知能力(可参考后文实施例中提及的代理插件控制器)可感知到代理扩展配置参数、用户所指定的目标代理插件以及数据平面层中需要扩展的目标网格代理，且控制平面层可基于感知到的这些信息发起代理扩展事件，来触发目标代理插件在数据平面层进行生效。参考图2a和图2b，在步骤101中，可通过控制平面层触发数据平面层从预置的代理插件库中为目标网格代理拉取目标代理插件对应的插件数据。本实施例中，为控制平面层增加了代理扩展触发能力(可参考后文实施例中提及的扩展触发器)，为数据平面层增加了代理插件引入能力(可参考后文实施例中提及的插件加载器和插件更新器)，这样，控制平面层和数据平面层可联动进行网格代理的扩展部署工作。

本实施例中，为支持控制平面层的触发能力，在控制平面层中对扩展需求内容进行分析的过程中，还可从扩展需求内容中解析出目标代理插件对应的拉取路径及路径参数。承接前文提及的几种示例性的拉取路径，这里的路径参数可包括但不限于：

·集群配置项所在的集群访问信息、所在的命名空间和名称；

·集群保密字典所在的集群访问信息、所在的命名空间和名称；

·以OCI镜像格式存储的文件可访问地址,以及所需的访问账号密码等；

·其他任意类型的文件可访问地址,以及所需的访问账号密码等。

基于此，控制平面层可从扩展需求内容中解析出的拉取路径及路径参数提供给数据平面层。在数据平面层中，可按照控制平面层提供的拉取路径及路径参数，从前述的代理插件库中拉取目标代理插件的插件数据。承接上文提及的几种示例性的拉取途径，这里，拉取目标代理插件的插件数据的过程具体可以是：

·通过集群配置项获取插件扩展内容；

·通过集群保密字典获取插件扩展内容；

·通过OCI镜像库获取打包之后的插件镜像；

·通过访问URL或文件路径获取插件内容。

应当理解的是，这里仅是为了示出各种拉取路径下的代理插件拉取过程，并不是限定本实施例中必须在上述的每个拉取路径下都执行拉取操作，本实施例中，可按照控制平面层的触发，仅在目标代理插件对应的拉取途径下按照路径参数执行拉取操作，即可拉取到目标代理插件的插件数据。

这样，目标代理插件的插件数据可成功引入到数据平面层中，而整个引入过程是在控制平面层的触发下发生的，控制平面层中同步记录了数据平面层中发生的目标代理插件的引入事件，这种控制平面层和数据平面层之间扩展事件联动的机制下，不再需要对服务网格进行重启即可实现控制平面层和数据平面层之间联动进行网格代理的扩展部署，这可为控制平面层在目标网格代理的扩展工作完成后，无障碍地针对目标网格代理发起对应的目标代理插件的控制动作提供支持，也即是可为目标网格代理的热更新提供支持。

至此，数据平面层中已经为目标网格代理成功从外部引入了目标代理插件。在一种可选的实现方式中，在通过控制平面层触发数据平面层从代理插件库中拉取目标代理插件对应的插件数据后，可在数据平面层中，将插件数据挂载至目标网格代理，以建立目标网格代理和目标代理插件之间的使用关系，从而可使目标网格代理在无须外部控制的情况下自主读取到目标代理插件的插件数据。其中，若插件数据按照文件的形式存在，则可采用文件挂载的方式来将目标代理插件的插件数据挂载至目标网格代理；而若插件数据采用内存的形式存在，则可采用内存挂载的方式将目标代理插件的插件数据挂载至目标网格代理，当然，本实施例对挂载方式不做限定。通俗来讲，将插件数据挂载至目标网格代理可理解为将目标代理插件的插件数据放置在目标网格代理约定的一个存储位置中，这样，目标网格代理可在需要使用目标代理插件时，按照该默认的存储位置自主读取目标代理插件的插件数据即可。

参考图2a和图2b，除了将目标代理插件的插件数据引入到目标网格代理下之外，在步骤102中，还可通过控制平面层将代理扩展配置参数提供给目标网格代理，以在目标网格代理中激活目标代理插件对应的插件数据。正如前文提及的，代理扩展配置参数可用于指示目标代理插件的使用规则，这样，在目标网格代理已知代理扩展配置参数且已经挂载上目标代理插件的插件数据的情况下，即完成了目标代理插件在目标网格代理中的激活工作。这里的激活可理解为目标网格代理在接收到控制平面层发起的针对目标代理插件的控制动作时，可无障碍的运行目标代理插件以发挥目标代理插件的功能。

综上，本实施例中，以代理插件的方式预先编写了现有网格代理功能之外的众多扩展功能，基于此，可在服务网格的控制平面层中对用户定义的扩展需求内容进行分析，以确定出代理扩展配置参数、用户所指定的目标代理插件以及所述数据平面层中需要扩展的目标网格代理；并可由控制平面层触发服务网格的数据平面层为目标网格代理拉取目标代理插件对应的插件数据，从而将目标代理插件引入到数据平面层中；控制平面层还可将代理扩展配置参数提供给目标网格代理，这使得，目标网格代理可基于代理扩展配置参数和目标代理插件的插件数据进行扩展。据此，本申请实施例中，提出在控制平面层发起代理扩展事件，并由控制平面层控制用户所指定的目标代理插件在数据平面层生效，这可实现在控制平面层和数据平面层联动完成网格代理的扩展部署，从而支持网格代理的热更新，不再需要修改源代码，也不再需要对服务网格进行多次重启，可有效改善服务网格的代理扩展能力。在方案实施的过程中，用户通过扩展需求内容可指定期望使用的插件代理，通过本实施例提供的扩展方案，即可在数据平面层中的相关网格代理下激活用户指定的插件代理，整个过程中，不需要重启，不需要修改源代码，是一种支持对网格代理进行热更新的扩展方案。

需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如101、102等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。

图3为本申请另一示例性实施例提供的一种服务网格系统的结构示意图，参考图3，该服务网格系统包括部署于控制平面层中的代理插件控制器30和扩展触发器31，以及部署在数据平面层的插件加载器32和插件更新器33。其中，本实施例中不限定代理插件控制器30和扩展触发器31在服务网格中的物理部署位置，两者在逻辑上位于控制平面层即可；同样，本实施例中也不限定插件加载器32和插件更新器33在服务网格中的物理部署位置，两者在逻辑上位于数据平面层即可。在物理部署位置方面，举例来说，它们可以分布在公有云上托管侧的资源上，为用户提供托管服务；它们也可分布在专有云中用户的集群上，本实施例对此不做限定。

基于此，参考图3，本实施例中，代理插件控制器30，用于对用户定义的扩展需求内容进行分析，以确定代理扩展配置参数、用户所指定的目标代理插件以及数据平面层中需要扩展的目标网格代理；

扩展触发器31，用于触发数据平面层中的插件加载器32从预置的代理插件库中为目标网格代理拉取目标代理插件对应的插件数据；

扩展触发器31，还用于将代理扩展配置参数提供给插件更新器33，以触发插件更新器33在目标网格代理中激活目标代理插件对应的插件数据。

其中，扩展需求内容中可包括但不限于扩展生效范围、期望使用的代理插件的属性信息以及部分配置参数等，当然，扩展需求内容中还可包含其它信息。

其中，扩展触发器31为控制平面层增加了扩展触发能力，这使得控制平面层可在用户发起扩展需求时，及时、畅通地触发数据平面层同步进行网格代理的扩展部署。插件加载器32为数据平面层增加了从外部引入代理插件的能力，以支持与控制平面层联动进行网格代理的扩展部署。

在一可选实施例中，控制平面层中还包含插件管理器34；代理插件控制器30在确定用户所指定的目标代理插件过程中，用于：

将从扩展需求内容中解析出的期望使用的代理插件的属性信息提供给插件管理器34；

插件管理器34，用于对期望使用的代理插件的属性信息进行检查校验，以产生用户所指定的目标代理插件的插件描述信息；将目标代理插件的插件描述信息返回给代理插件控制器30，以供代理插件控制器30确定目标代理插件。其中，插件管理器34可与代理插件库关联，并可方便地获取代理插件库中各代理插件的更多属性信息，基于此，检查校验的过程中，插件管理器34可根据确定出的目标代理插件的名称及拉取途径等，对接代理插件库，以获得目标代理插件采用的技术实现类型、路径参数、所需的运行环境等更多信息，以完善插件描述信息。

实际应用中，可以代理插件控制器30作为面向扩展需求内容的唯一入口，代理插件控制器30可将扩展需求内容中期望使用的代理插件的属性信息转换为内存模型数据后，提供给插件管理器34，插件管理器34可用于对代理插件库进行管理，这样，插件管理器34可准确地确定出目标代理插件的插件描述信息并返回给代理插件控制器。而代理插件控制器30可整合目标代理插件的插件描述信息和从扩展需求内容中解析出的部分配置参数，而产生代理扩展配置参数。这部分的具体技术逻辑可参考前文中的方法实施例，在此不再重复赘述，且本实施例中未出现在方法实施例中的内容也可补充于方法实施例中。

参考图3，在一可选实施例中，数据平面层中还包括插件缓存器35，插件缓存器35用于：对插件加载器32所拉取的插件数据进行按需缓存。尤其是针对前文中通过远程地址而拉取到的插件数据，插件缓存器35可将插件数据进行本地缓存，插件加载器32可在后续直接从插件缓存器35中拉取相关的插件数据，而无需在从远程拉取，可有效提高插件拉取效率。

在一可选的实施例中，插件更新器33，可具体用于：将插件加载器32拉取到的目标代理插件对应的插件数据挂载至目标网格代理；基于目标代理插件对应的插件数据和代理扩展配置参数，在目标网格代理中激活目标代理插件。关于插件数据的挂载方案可参考前述方法实施例中的描述，在此不再重复赘述。目标网格代理36中扩展出的目标代理插件的功能可被应用服务37使用。

综上，通过在服务网格的控制平面层和数据平面层中增加多种功能器件，可为控制平面层增加扩展需求感知能力、扩展触发能力等，为数据平面层增加代理插件引入能力、自主激活能力等，这使得控制平面层和数据平面层之间可联动进行网格代理的扩展部署，从而可支持网格代理的热更新，而不再需要通过修改源代码或者重启服务网格的方式来进行网格代理的更新。

值得说明的是，上述关于服务网格中代理的扩展系统对应的各实施例中的技术细节，可参考前述的方法实施例中的相关描述，为节省篇幅，在此不再赘述，但这不应造成本申请保护范围的损失。

图4为本申请又一示例性实施例提供的一种分布式微服务系统的结构示意图。参考图4，该系统可包括多个第一节点和第二节点，每个第一节点包括微服务应用和网格代理，所述第二节点包括控制组件。

本实施例提供的分布式微服务系统可应用在云计算环境中，云计算是计算机技术发展最快的趋势之一，它涉及通过网络提供托管服务。云计算是一种服务交付模式，旨在实现，按需网络访问共享的可配置计算资源池(例如，网络、网络带宽、服务器、处理、内存、存储、应用程序、虚拟机和服务)，这些资源可以通过最小的管理工作或与服务提供商的交互来快速调配和发布。云计算环境将计算和存储资源作为服务提供给最终用户，最终用户可以向提供的服务发出请求以进行处理。云计算环境可包括一个或多个云计算节点，云消费者使用的本地计算设备，例如个人数字助理(PDA)或蜂窝电话、台式计算机、膝上型计算机和/或汽车计算机系统可以与之通信。节点之间可以彼此通信，它们可以在一个或多个网络中物理地或虚拟地分组(未示出)，例如私有、社区、公共或混合云，或其组合。这允许云计算环境将基础设施、平台和/或软件作为服务提供，云消费者不需要在本地计算设备上维护资源。其中，计算节点和云计算环境可以通过任何类型的网络和/或网络可寻址连接(例如，使用web浏览器)与任何类型的计算机化设备通信。

本实施例中的第一节点和第二节点即可采用云计算环境中的云计算节点，第一节点和第二节点在物理实现形式上可以是计算机系统、服务器、或诸如通信设备之类的便携式电子设备，还可以是容器组POD等，其可与许多其他通用或专用计算系统环境或配置一起使用。其中，这些可与第一节点和第二节点一起使用的已知计算系统、环境和/或配置的示例包括但不限于个人计算机系统、服务器计算机系统、瘦客户端、厚客户端、手持或笔记本电脑设备、多处理器系统、基于微处理器的系统、机顶盒、可编程消费电子产品、网络PC(个人计算机)、小型计算机系统、大型计算机系统和分布式云计算环境，包括上述任何系统或设备等。

应当理解的是，尽管这里公开了关于云计算的详细描述，但是，本实施例提供的分布式微服务系统的实现并不限于云计算环境，相反，本实施例提供的分布式微服务系统能够结合现在已知或以后开发的任何其他类型的计算环境来实现。

本实施例提供的微服务分布系统可采用服务网格作为基础架构。在基于服务网格的应用模型中，一个应用程序可能会包含数百个服务，每个服务又有数百个实例构成，每一个服务实例中包括了一个Sidecar形式的网格代理。这些网格代理可形成一个网状的数据平面层，通过该数据平面层处理和观察所有服务间的流量。数据平面层扮演了一个用来建立、保护和控制通过网格的流量的角色。负责数据平面层如何执行的管理组件称为控制平面层。前述的成百上千个应用程序的网格代理如何统一管理，这就是服务网格中定义的控制平面层部分要解决的问题。控制平面层是服务网格的大脑，并为网格使用人员提供公开API，以便较容易地操纵网络行为。

其中，本实施例中的多个第一节点中包含的网格代理可形成服务网格中的数据平面层，而第二节点中的控制组件则可用于实现控制平面层的相关逻辑。

基于此，本实施例中，第二节点中的控制组件，可用于：

对用户定义的扩展需求内容进行分析，以确定代理扩展配置参数、用户所指定的目标代理插件以及需要扩展的目标网格代理；

触发目标网格代理所在的第一节点从预置的代理插件库中为目标网格代理拉取目标代理插件对应的插件数据；

将代理扩展配置参数提供给目标网格代理，以在目标网格代理中激活目标代理插件对应的插件数据。

在一可选实施例中，控制组件中可包括代理插件控制器、扩展触发器，第二节点中则可包括插件加载器和插件更新器。这里，并不限定插件控制器和扩展触发器必须分布在同一控制组件中，其只要分布在位于服务网格的控制平面层中即可，而对其具体分布位置不做限定。而每个第二节点中均可配置插件加载器和插件更新器，当然，多个第二节点也可共有插件加载器和插件更新器，本实施例对此不做限定。

在该可选实施例中，代理插件控制器，可用于在控制平面层中对用户定义的扩展需求内容进行分析，以确定代理扩展配置参数、用户所指定的目标代理插件以及数据平面层中需要扩展的目标网格代理；扩展触发器，可用于触发数据平面层中的插件加载器从预置的代理插件库中为目标网格代理拉取目标代理插件对应的插件数据；扩展触发器，还可用于将代理扩展配置参数提供给插件更新器，以触发插件更新器在目标网格代理中激活目标代理插件对应的插件数据。

在一可选实施例中，控制组件中还可包含插件管理器；代理插件控制器在确定用户所指定的目标代理插件过程中，可用于：

将从扩展需求内容中解析出的期望使用的代理插件的属性信息提供给插件管理器；

插件管理器，用于对期望使用的代理插件的属性信息进行检查校验，以产生用户所指定的目标代理插件的插件描述信息；将目标代理插件的插件描述信息返回给代理插件控制器，以供代理插件控制器确定目标代理插件。

在一可选实施例中，第二节点还可包括插件缓存器，插件缓存器用于：

对插件加载器所拉取的插件数据进行按需缓存。

在一可选实施例中，插件更新器，具体用于：

将插件加载器拉取到的目标代理插件对应的插件数据挂载至目标网格代理；

基于目标代理插件对应的插件数据和代理扩展配置参数，在目标网格代理中激活目标代理插件。

值得说明的是，上述关于分布式微服务系统对应的各实施例中的技术细节，可参考前述的方法实施例中的相关描述，为节省篇幅，在此不再赘述，但这不应造成本申请保护范围的损失。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述方法实施例中执行的各步骤。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带式磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (12)

1.一种服务网格中代理的扩展方法，所述服务网格包含控制平面层和数据平面层，所述方法包括：

在所述控制平面层中，对用户定义的扩展需求内容进行分析，以确定代理扩展配置参数、用户所指定的目标代理插件以及所述数据平面层中需要扩展的目标网格代理；

通过所述控制平面层触发所述数据平面层从预置的代理插件库中为所述目标网格代理拉取所述目标代理插件对应的插件数据；

通过所述控制平面层将所述代理扩展配置参数提供给所述目标网格代理，以在所述目标网格代理中激活所述目标代理插件对应的插件数据。

2.根据权利要求1所述的方法，所述扩展需求内容中包含扩展生效范围，所述对用户定义的扩展需求内容进行分析，以确定所述数据平面层中需要扩展的目标网格代理，包括：

从数据平面层包含的网格代理中，选择与所述扩展生效范围适配的网格代理，作为所述目标网格代理。

3.根据权利要求2所述的方法，所述从数据平面层包含的网格代理中，选择与所述扩展生效范围适配的网格代理，作为所述目标网格代理，包括：

在所述扩展生效范围中指定有插件标签的情况下，基于插件标签与网格代理的标签之间的对应关系，从所述数据平面层包含的网格代理中，选择与所述指定插件标签适配的网格代理，作为所述目标网格代理；所述目标网格代理的标签与所述指定插件标签相对应；和/或，

在所述扩展生效范围中指定有插件版本的情况下，基于插件版本与网格代理的版本之间的对应关系，从所述数据平面层包含的网格代理中，选择与所述指定插件版本适配的网格代理，作为所述目标网格代理；所述目标网格代理的版本与所述指定插件版本相对应。

4.根据权利要求1所述的方法，所述扩展需求内容采用声明式API的方式写入所述控制平面层。

5.根据权利要求1所述的方法，所述通过所述控制平面层触发所述数据平面层从预置的代理插件库中为所述目标网格代理拉取所述目标代理插件对应的插件数据，包括：

通过所述控制平面层触发所述数据平面层从所述代理插件库中拉取所述目标代理插件对应的插件数据；

在所述数据平面层中，将所述插件数据挂载至所述目标网格代理，以供所述目标网格代理读取所述插件数据。

6.根据权利要求1所述的方法，所述代理扩展配置参数包括所述目标代理插件的名称、类型、拉取途径及路径参数、所需的运行环境和运行所需的外部参数中的一种或多种参数；所述拉取途径包括集群配置项、集群保密字典、OCI镜像地址和远程地址中的一种或多种。

7.一种服务网格系统，包括部署于控制平面层中的代理插件控制器和扩展触发器，以及部署在数据平面层的插件加载器和插件更新器；

所述代理插件控制器，用于在所述控制平面层中对用户定义的扩展需求内容进行分析，以确定代理扩展配置参数、用户所指定的目标代理插件以及所述数据平面层中需要扩展的目标网格代理；

所述扩展触发器，用于触发所述数据平面层中的插件加载器从预置的代理插件库中为所述目标网格代理拉取所述目标代理插件对应的插件数据；

所述扩展触发器，还用于将所述代理扩展配置参数提供给所述插件更新器，以触发所述插件更新器在所述目标网格代理中激活所述目标代理插件对应的插件数据。

8.根据权利要求7所述的服务网格系统，所述控制平面层中还包含插件管理器；所述代理插件控制器在确定用户所指定的目标代理插件过程中，用于：

将从所述扩展需求内容中解析出的期望使用的代理插件的属性信息提供给所述插件管理器；

所述插件管理器，用于对所述期望使用的代理插件的属性信息进行检查校验，以产生用户所指定的目标代理插件的插件描述信息；将所述目标代理插件的插件描述信息返回给所述代理插件控制器，以供所述代理插件控制器确定所述目标代理插件。

9.根据权利要求7所述的服务网格系统，所述数据平面层中还包括插件缓存器，所述插件缓存器用于：

对所述插件加载器所拉取的插件数据进行按需缓存。

10.根据权利要求7所述的服务网格系统，所述插件更新器，具体用于：

将所述插件加载器拉取到的所述目标代理插件对应的插件数据挂载至所述目标网格代理；

基于所述目标代理插件对应的插件数据和所述代理扩展配置参数，在所述目标网格代理中激活所述目标代理插件。

11.一种分布式微服务系统，包括多个第一节点和第二节点，每个第一节点包括微服务应用和网格代理，所述第二节点包括控制组件；所述第二节点中的控制组件，用于：

对用户定义的扩展需求内容进行分析，以确定代理扩展配置参数、用户所指定的目标代理插件以及需要扩展的目标网格代理；

触发所述目标网格代理所在的第一节点从预置的代理插件库中为所述目标网格代理拉取所述目标代理插件对应的插件数据；

将所述代理扩展配置参数提供给所述目标网格代理，以在所述目标网格代理中激活所述目标代理插件对应的插件数据。

12.一种存储计算机指令的计算机可读存储介质，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行权利要求1-6任一项所述的服务网格中代理的扩展方法。

Images