CN111541746B - 面向用户需求变化的多版本并存的微服务自适应方法 - Google Patents

Abstract

本发明公开了一种面向用户需求变化的多版本并存的微服务自适应方法，所述方法包括如下步骤：步骤S1、构建微服务依赖模型；步骤S2、收集服务系统信息；步骤S3、分析、处理信息；步骤S4、计算系统演化方案；步骤S5、实施演化方案。本发明能够在系统运行时监控用户需求的变化，并针对这些变化结合微服务之间的版本依赖关系，计算出合适的系统演化方案，最后进行方案的自动化实施，以达到针对用户需求变化的自适应调整，从而满足用户的新需求以及确保稳定的服务质量。

Description

面向用户需求变化的多版本并存的微服务自适应方法

技术领域

本发明属于计算机服务技术领域，涉及一种面向用户需求变化的多版本并存的微服务自适应方法及系统，具体涉及一种考量了多版本并存的微服务依赖模型的自适应方法及系统。

背景技术

随着各式各样的服务，各种业务逻辑不断复杂，传统的一体化软件架构(Monolithic Architecture)也有了越来越多的限制，逐渐难以应对越来越复杂的业务需求。一体化软件架构是指在有着功能逻辑模块划分的机构下，依然将应用程序打包成单一的可运行程序并进行部署。由于业务逻辑的不断复杂，功能逻辑模块的不断增加，单一模块的修改会导致整个应用程序受到不必要的影响，导致一体化软件架构越来越难以开发和持续交付。而微服务是一种软件架构风格，它是以专注于单一责任与功能的小型功能模块为基础，利用模块化的方式组合出复杂的大型应用程序，各个模块之间高度解耦，能够各自独立的进行开发、测试、部署、拓展等而不影响其它模块。因此越来越多的复杂系统开始从一体化软件架构转变为微服务架构。

然而，微服务架构中各个模块的独立也让各个模块之间形成了特定的依赖关系。各个模块在独立的开发升级中，各自的业务逻辑以及向外暴露的接口均可能发生不向后兼容的变化。考虑到用户偏好，服务的提供者很难让服务系统中所有的微服务都保持最新版本，因此在服务系统的长期运行下，系统中将同时存在着同一个服务的不同版本。而部分微服务在完成相应的业务逻辑时，需要通过网络调用对其它特定版本的微服务暴露出的接口进行调用，从而形成了多版本并存的微服务依赖关系。

目前常用的微服务开发框架中微服务之间的调用是通过微服务名称进行请求的路由，没有考虑微服务之间的版本差异，这导致多版本并存的系统中很难处理具备指定版本微服务依赖的调用。目前已有的方法主要为在请求过程中，通过请求头或者请求路径携带版本信息并发往网关，网关通过携带的版本信息进行具体的请求转发以确保请求的正确响应。然而这些方法不具备拓展性，服务之间的版本依赖关系往往硬编码在代码中，无法主动适应未来的变化。

此外，用户对微服务的版本依赖也是不断变化的，当用户由于更新了客户端等原因请求了其他版本的微服务时，传统的微服务系统无法在系统中没有相应微服务实例的情况下响应用户的请求，往往需要人工干预，部署对应的微服务实例。而微服务之间的依赖导致微服务的部署变得较为复杂，往往需要考虑依赖关系是否满足。目前已有的服务实例的管理主要集中在以容器为基础的实例、微服务实例的横向拓展，通过增加或者减少相同服务的实例部署数量，来确保用户请求响应的稳定性以及较少的资源消耗。容器作为应用程序级别的虚拟化，允许单个内核上有多个独立的用户空间实例。它提供了将应用程序的代码、运行时、系统工具、系统库和配置打包到一个实体中的标准方法，能够让服务在各种异构的服务器环境中，快速的启动和稳定的运行。然而这些方法无法解决新用户需求出现的问题，不能在满足依赖关系的情况下，部署相关的服务实例。

基于上述研究背景可以发现，微服务、容器的使用，以及对微服务依赖关系的充分利用，能够构建一个稳定高效的、面向用户需求变化的、多版本并存的微服务系统。

发明内容

为了解决现有技术中存在的以上问题，本发明对于面向用户需求变化的、多版本共存的微服务系统的自适应问题，提供了一种面向用户需求变化的多版本并存的微服务自适应方法。本发明能够在系统运行时监控用户需求的变化，并针对这些变化结合微服务之间的版本依赖关系，计算出合适的系统演化方案，最后进行方案的自动化实施，以达到针对用户需求变化的自适应调整，从而满足用户的新需求以及确保稳定的服务质量。

本发明的目的是通过以下技术方案实现的：

一种面向用户需求变化的多版本并存的微服务自适应方法，包括如下步骤：

步骤S1、构建微服务依赖模型：

通过分析微服务源代码自动构建多版本共存的微服务依赖模型，具体步骤如下：

通过微服务编程框架的配合，让微服务具备指定版本的依赖表达以及请求能力，并让系统能够按照源代码自动构建出包含以下三种类型的微服务依赖模型：1)指定服务名称，接口以及版本；2)指定服务名称，接口以及期望的SLA；3)指定期望的功能以及SLA；

步骤S2、收集服务系统信息：

收集系统中用户需求信息以及微服务实例相关信息，具体步骤如下：

(1)在每个用户可以直接发送请求的服务器节点上，均部署一个网关服务实例；

(2)通过使用框架、网关，对服务系统运行时的用户需求信息、微服务实例相关信息进行收集；

(3)通过分析所有的微服务实例相关信息，构建微服务之间的版本依赖模型；

步骤S3、分析、处理信息：

通过对步骤S2中收集到的服务系统信息的处理，预测出未来一段时间内需要进行调整的用户需求变化，判断是否需要进行服务系统的演化，如需进行演化，则执行步骤S4，否则等待固定时间窗口后，执行步骤S2，具体步骤如下：

(1)针对每个用户需求进行分析，如果用户需求在服务系统中没有得到响应，则将该需求标记为待调整；

(2)利用全局用户需求信息，通过利用最近若干个时间窗口的历史数据，对后续若干个时间窗口内系统中各种需求类型的数量进行预测，具体预测时间长度视集群规模由系统维护者手动指定；

(3)结合未来的用户需求数量以及待调整用户需求，得到未来一段时间内需要处理的用户需求；

步骤S4、计算系统演化方案：

对整个服务系统进行建模，考量可能的基本演化操作，并计算出演化方案，得到微服务实例部署情况，具体步骤如下：

(1)利用步骤S2所获取到的收集到的服务系统信息，构建模型以对服务系统现状进行刻画，其中：所述模型包括：1)服务：用来描述服务系统的每个服务的相关信息，包括服务所包含的所有接口，对应的请求路径，接口传入传出的数据量的大小，接口所提供的功能描述，接口所提供的服务等级，该服务的容器镜像地址，该服务的代码仓库地址，服务版本信息，以及该服务正常运行所需要的资源大小；2)微服务依赖模型：用来描述不同微服务不同版本之间的依赖关系；3)服务器节点：用来描述云—边缘—端中云端以及边缘端服务器的相关信息，包括服务器的地理位置，服务器所具备的资源能力以及每个服务器对应的节点标识；4)服务实例：用来描述服务系统中所有服务的实例，包括该实例对应的服务名称，该实例所在服务器节点标识信息；5)用户需求：用来描述用户需求的分配情况，包括用户的唯一标识，以及步骤S1中所描述的微服务依赖模型；

(2)利用步骤S3中得到的未来一段时间内需要处理的用户需求，在考量不同微服务不同版本之间的依赖关系情况下，计算出演化方案，得到微服务实例部署情况，其中：使用目标优化算法进行实例部署方案的计算，该算法的优化目标为：1)服务系统的平均相应时间最短；2)演化的时间代价最小；3)保整多版本并存的微服务依赖关系；演化方案主要分为：1)服务相关：服务依赖的变更；2)服务实例相关：服务实例的部署、删除；3)用户需求的重新分配；

步骤S5、实施演化方案：

对步骤S4所得到的微服务实例部署情况进行自动化实施，以从当前的微服务实例部署情况在尽可能不影响用户的情况下转变为目标部署情况，具体步骤为：

(1)利用步骤S4计算出的微服务实例部署情况和当前实际的微服务实例部署情况进行对比，结合具体的服务演化手段，得到代价最小的演化方案，其中：服务演化手段主要包括：1)服务实例相关：服务实例的部署、删除；2)服务相关：服务之间依赖关系的调整；

(2)实施具体的演化方案。

一种实现上述面向用户需求变化的多版本并存的微服务自适应方法的系统，包括中央控制程序模块、构建中心程序模块、微服务依赖分析模块、用户需求变化预测模块、网关模块和集群中间件程序模块，其中：

所述中央控制程序模块包括服务系统信息收集模块，分析、处理模块，部署方案计算模块，演化方案计算和执行模块；

所述服务系统信息收集模块负责在系统运行过程中，定期对服务系统内部的一些运行时信息进行收集；

所述分析、处理模块负责对收集到的数据进行处理分析，并判断出是否需要演化以及哪些用户需求需要参与演化；

所述部署方案计算模块负责计算出合适的微服务实例部署情况；

所述演化方案计算和执行模块负责演化方案的计算以及自动化执行；

所述构建中心程序模块负责自动从代码仓库中拉取指定代码，并进行可执行程序的构建以及容器镜像的打包推送；

所述微服务依赖分析模块负责分析微服务的版本信息以及微服务之间的依赖关系；

所述用户需求变化预测模块负责通过历史数据预测未来一段时间内的用户需求变化；

所述网关模块负责接收来用用户以及来自微服务对其它微服务的请求；

所述集群中间件程序模块负责和集群进行沟通，从中抽取相关信息以及执行服务实例以及用户需求相关的演化操作。

相比于现有技术，本发明具有如下优点：

1、本发明通过自编程框架的开发，通过网关以及集群中间件等组件的相互协同操作，将原本单一的、需要硬编码的、不具备指定版本的微服务之间的请求拓展为了可以在运行过程中变更的依赖请求，包括：1)指定服务名称，接口以及版本；2)指定服务名称，接口以及期望的SLA；3)指定期望的功能以及SLA。

2、本发明通过自编程框架以及微服务分析组件，允许通过分析微服务的源代码，自动获取微服务之间复杂的依赖关系，构建出多版本并存的微服务依赖模型。

3、本发明通过基于MAPE-K模型的自适应结构与自编程框架、自动构建中心等的协同，能够在服务系统中用户需求发生变化时，结合微服务之间的依赖关系，自动计算出演化方案，并自动化进行方案的执行。

4、本发明充分考虑到了用户需求的变化、多种版本同时共存的微服务系统以及微服务之间复杂的依赖关系，根据用户的需求、边缘以及云端服务器的资源限制、服务器之间的延迟以及带宽等因素，通过利用开发出来的框架，来为系统提供各个服务的运行时信息，利用过去一段时间内的历史信息，预测未来一段时间内的需求变化，同时考量了多种的演化手段，包括服务实例的部署、删除，服务的依赖运行时变更等操作，计算出合理的系统演化方案，并进行自动化的实施。

附图说明

图1为本发明的面向用户需求变化的多版本共存的微服务自适应方法的流程图；

图2为多版本微服务依赖分析示意图；

图3为分析、处理及计算流程图；

图4为系统组件图；

图5为具体部署情况。

具体实施方式

下面结合附图对本发明的技术方案作进一步的说明，但并不局限于此，凡是对本发明技术方案进行修改或者等同替换，而不脱离本发明技术方案的精神和范围，均应涵盖在本发明的保护范围中。

本发明提供一种面向用户需求的多版本共存的微服务自适应方法，如图1所示，所述方法包括以下步骤：

步骤S1、构建微服务依赖模型。

如图2所示，本步骤主要针对系统中所有微服务的各个版本之间的依赖模型的自动化构建。该步骤要求系统中微服务的开发者能够使用提供的微服务编程框架进行微服务的开发。开发者在代码仓库中使用标签标记不同版本，系统通过解析对应服务对应版本的源代码及配置文件，获取服务的名称、版本以及对其它服务的依赖关系。通过与编程框架的配合，在代码级别对服务的接口进行描述，并通过解析源代码进行自动化解析，获取到不同类型的版本依赖请求，包括：1)指定服务名称，接口以及版本；2)指定服务名称，接口以及期望的SLA；3)指定期望的功能以及SLA，构建出微服务依赖模型。

步骤S2、收集服务系统信息。

本步骤主要是针对系统的所有用户需求，以及系统中各个服务实例的具体信息。利用S1中收集到的依赖信息，对系统中每个服务实例进行依赖判断，构建出完整的服务系统实例的依赖拓扑，构成依赖模型。

为了收集用户需求，需要使用网关组件来确保所有的用户请求均通过该组件进入系统。为了确保系统的正常运行，需要在每个用户可以直接发送请求的服务器节点上，均部署一个网关服务实例。在网关中，会对用户的需求进行记录并构建用户请求序列，并按照序列依次进行响应，同时保存无法响应的用户需求。为了收集系统中各个服务实例的具体信息，通过集群中间件及微服务编程框架的配合，获取到运行时信息。

步骤S3、分析、处理信息。

如图3所示，本步骤需要针对步骤S2中收集到的数据，进行分析以及处理。系统收集到指定的信息之后，通过对历史数据的分析，预测出未来一段时间内用户需求的变化情况，并将这些信息传递至步骤S4。

步骤S4、计算系统演化方案。

首先需要针对服务系统进行建模，以进行相关的演化计算。基本的模型包括：

(1)服务：用来描述服务系统的每个服务的相关信息，包括服务所包含的所有接口，对应的请求路径，接口传入传出的数据量的大小，接口所提供的功能描述，接口所提供的服务等级，该服务的容器镜像地址，该服务的代码仓库地址，服务的版本信息，以及该服务正常运行所需要的资源大小。

(2)服务依赖模型：由步骤S1获取到的依赖模型，描述了微服务之间的，特定版本之间的调用关系。

(3)服务器节点：用来描述云—边缘—端中云端以及边缘端服务器的相关信息，包括服务器的地理位置，服务器所具备的资源能力以及每个服务器对应的节点标识。

(4)服务实例：用来描述服务系统中所有服务的实例，包括该实例对应的服务名称，该实例所在服务器节点标识等信息。

(5)用户需求：用来描述用户需求的分配情况，包括用户的唯一标识，以及步骤S1中所描述的具体依赖。

利用步骤S2所获取到的相关信息，构建出上述的模型以对系统现状进行刻画。接着通过考虑可能的演化操作，并进行计算。基本的演化操作有：服务实例的创建、删除，服务的依赖更新；用户需求重新分配。主要需要考量：1)服务系统的平均相应时间最短；2)演化的时间代价最小。

步骤S5、实施演化方案。

本步骤主要是对步骤S4所得到的演化方案进行自动化实施。

为了实现服务实例相关的演化操作，需要使用K8S等集群中的容器管理工具。通过开发K8S集群中间件，提供在指定的节点上部署指定的服务实例，删除指定节点上指定的服务实例，限制指定服务实例的资源使用等操作。中央控制程序将相关任务分发给该中间件进行执行，执行完毕后，中间件发送任务完成信息给中央控制程序。

为了实现服务实例的依赖变更，中央控制程序将对应的指令下发至集群中间件，并最终发送至对应的服务实例。通过编程框架提供的额外功能来实现依赖的运行时变更。

为了实现用户需求重新分配的演化操作，需要使用网关模块。网关模块将对每个用户需求对应的服务实例的唯一IP地址进行记录，维护一个指定时间窗口内的路由表。用户需求进入网关时，进行查表操作，已获取目标服务实例的IP以及相关信息。如果查询失败，则请求失败并缓存请求等待下一个时间窗口的请求响应，否则将请求转发至对应的服务实例。

需要注意的是，为了统筹步骤S1、S2、S3、S4以及S5，需要中央控制模块。该模块主要使用MAPE-K模型对上述各个步骤进行组织，同时在步骤S5中，承担任务分发任务以确保整个演化方案的顺利执行。具体如图4所示。

需要说明的是，本发明中的各个模块(或单元)是逻辑意义上的，具体实现时，多个模块(或单元)可以合并成一个模块(或单元)，一个模块(或单元)也可拆分成多个模块(或单元)。

实施例：

本实施例由5个虚拟机构成的边缘集群，2个云服务器构成的云端服务器构成。其中边缘集群节点配置为8vCPU，16GB内存，云端服务器视为配置按需使用，无上限。边缘集群使用v1.18.0版本的Kubernetes以及19.03.8版本的Docker，边缘集群内部延迟小于1ms，带宽为100Mb/s；边缘集群与云端服务器延迟约为30ms，带宽为20Mb/s，具体部署情况如图5所示。

服务集合人工构建了一个10个服务的服务集合，每个服务均有2～3的不同版本，不同版本之间有着不同的依赖、功能以及SLA。整体上覆盖了三种不同类型的依赖情况。用户需求变化方面构造了60分种的数据，其中每1分钟，部分用户需求发生变化。

实验结果表明，当用户需求发生变化时，如果系统能够满足新需求，则能够立即得到满足；不能满足时，会等到下一个时间窗口系统进行演化后，得到满足。在部署新的服务实例时，能够在满足依赖的情况下，进行合理部署。

Claims (5)

1.一种面向用户需求变化的多版本并存的微服务自适应方法，其特征在于所述方法包括如下步骤：

步骤S1、构建微服务依赖模型：

通过分析微服务源代码自动构建多版本共存的微服务依赖模型，具体步骤如下：

通过微服务编程框架的配合，让微服务具备指定版本的依赖表达以及请求能力，并让系统能够按照源代码自动构建出包含以下三种类型的微服务依赖模型：1）指定服务名称，接口以及版本；2）指定服务名称，接口以及期望的SLA；3）指定期望的功能以及SLA；

步骤S2、收集服务系统信息：

收集系统中用户需求信息以及微服务实例相关信息，具体步骤如下：

（1）在每个用户可以直接发送请求的服务器节点上，均部署一个网关服务实例；

（2）通过使用框架、网关，对服务系统运行时的用户需求信息、微服务实例相关信息进行收集；

（3）通过分析所有的微服务实例相关信息，构建微服务之间的版本依赖模型；

步骤S3、分析、处理信息：

通过对步骤S2中收集到的服务系统信息的处理，预测出未来一段时间内需要进行调整的用户需求变化，判断是否需要进行服务系统的演化，如需进行演化，则执行步骤S4，否则等待固定时间窗口后，执行步骤S2，具体步骤如下：

（1）针对每个用户需求进行分析，如果用户需求在服务系统中没有得到响应，则将该需求标记为待调整；

（2）利用全局用户需求信息，通过利用最近若干个时间窗口的历史数据，对后续若干个时间窗口内系统中各种需求类型的数量进行预测，具体预测时间长度视集群规模由系统维护者手动指定；

（3）结合未来的用户需求数量以及待调整用户需求，得到未来一段时间内需要处理的用户需求；

步骤S4、计算系统演化方案：

对整个服务系统进行建模，考量可能的基本演化操作，并计算出演化方案，得到微服务实例部署情况，具体步骤如下：

（1）利用步骤S2所获取到的收集到的服务系统信息，构建模型以对服务系统现状进行刻画，其中：所述模型包括：1）服务：用来描述服务系统的每个服务的相关信息，包括服务所包含的所有接口，对应的请求路径，接口传入传出的数据量的大小，接口所提供的功能描述，接口所提供的服务等级，该服务的容器镜像地址，该服务的代码仓库地址，服务版本信息，以及该服务正常运行所需要的资源大小；2）微服务依赖模型：用来描述不同微服务不同版本之间的依赖关系；3）服务器节点：用来描述云—边缘—端中云端以及边缘端服务器的相关信息，包括服务器的地理位置，服务器所具备的资源能力以及每个服务器对应的节点标识；4）服务实例：用来描述服务系统中所有服务的实例，包括该实例对应的服务名称，该实例所在服务器节点标识信息；5）用户需求：用来描述用户需求的分配情况，包括用户的唯一标识，以及步骤S1中所描述的微服务依赖模型；

（2）利用步骤S3中得到的未来一段时间内需要处理的用户需求，在考量不同微服务不同版本之间的依赖关系情况下，计算出演化方案，得到微服务实例部署情况，其中：使用目标优化算法进行实例部署方案的计算，该算法的优化目标为：1）服务系统的平均相应时间最短；2）演化的时间代价最小；3）保整多版本并存的微服务依赖关系；演化方案主要分为：1）服务相关：服务依赖的变更；2）服务实例相关：服务实例的部署、删除；3）用户需求的重新分配；

步骤S5、实施演化方案：

对步骤S4所得到的微服务实例部署情况进行自动化实施，以从当前的微服务实例部署情况在尽可能不影响用户的情况下转变为目标部署情况，具体步骤为：

（1）利用步骤S4计算出的微服务实例部署情况和当前实际的微服务实例部署情况进行对比，结合具体的服务演化手段，得到代价最小的演化方案，其中：服务演化手段主要包括：1）服务实例相关：服务实例的部署、删除；2）服务相关：服务之间依赖关系的调整；

（2）实施具体的演化方案。

2.根据权利要求1所述的面向用户需求变化的多版本并存的微服务自适应方法，其特征在于所述模型包括：1）服务：用来描述服务系统的每个服务的相关信息，包括服务所包含的所有接口，对应的请求路径，接口传入传出的数据量的大小，接口所提供的功能描述，接口所提供的服务等级，该服务的容器镜像地址，该服务的代码仓库地址，服务版本信息，以及该服务正常运行所需要的资源大小；2）微服务依赖模型：用来描述不同微服务不同版本之间的依赖关系；3）服务器节点：用来描述云—边缘—端中云端以及边缘端服务器的相关信息，包括服务器的地理位置，服务器所具备的资源能力以及每个服务器对应的节点标识；4）服务实例：用来描述服务系统中所有服务的实例，包括该实例对应的服务名称，该实例所在服务器节点标识信息；5）用户需求：用来描述用户需求的分配情况，包括用户的唯一标识，以及步骤S1中所描述的微服务依赖模型。

3.根据权利要求1所述的面向用户需求变化的多版本并存的微服务自适应方法，其特征在于所述步骤S4（2）中，使用目标优化算法进行实例部署方案的计算，该算法的优化目标为：1）服务系统的平均相应时间最短；2）演化的时间代价最小；3）保整多版本并存的微服务依赖关系；所述演化方案主要分为：1）服务相关：服务依赖的变更；2）服务实例相关：服务实例的部署、删除；3）用户需求的重新分配。

4.根据权利要求1所述的面向用户需求变化的多版本并存的微服务自适应方法，其特征在于所述服务演化手段主要包括：1）服务实例相关：服务实例的部署、删除；2）服务相关：服务之间依赖关系的调整。

5.一种实现权利要求1-4任一项所述的面向用户需求变化的多版本并存的微服务自适应方法的系统，其特征在于所述系统包括中央控制程序模块、构建中心程序模块、微服务依赖分析模块、用户需求变化预测模块、网关模块和集群中间件程序模块，其中：

所述中央控制程序模块包括服务系统信息收集模块，分析、处理模块，部署方案计算模块，演化方案计算和执行模块；

所述服务系统信息收集模块负责在系统运行过程中，定期对服务系统内部的一些运行时信息进行收集；

所述分析、处理模块负责对收集到的数据进行处理分析，并判断出是否需要演化以及哪些用户需求需要参与演化；

所述部署方案计算模块负责计算出合适的微服务实例部署情况；

所述演化方案计算和执行模块负责演化方案的计算以及自动化执行；

所述构建中心程序模块负责自动从代码仓库中拉取指定代码，并进行可执行程序的构建以及容器镜像的打包推送；

所述微服务依赖分析模块负责分析微服务的版本信息以及微服务之间的依赖关系；

所述用户需求变化预测模块负责通过历史数据预测未来一段时间内的用户需求变化；

所述网关模块负责接收来用用户以及来自微服务对其它微服务的请求；

所述集群中间件程序模块负责和集群进行沟通，从中抽取相关信息以及执行服务实例以及用户需求相关的演化操作。

Images