一种基于微服务调用依赖感知的在线应用动态扩缩容方法

摘要

本发明设计了采用MAPE模式的基于微服务调用依赖感知的在线应用动态扩缩容方法，将整个系统分为监控模块、分析模块、规划模块、执行模块四个部分，监控模块首先读取运行数据，所述运行数据包括区分为集群资源使用数据和服务调用相关数据，分析模块发现并选定待扩容或缩容的对象，规划模块计算所需扩缩容容器数目，最后由执行模块调整指定的容器集合中的副本数实现微服务水平扩缩容。这一系统能够通过分析微服务间调用依赖关系及延迟，与历史数据对比，计算并判断当前微服务运行状态及服务能力在请求流量变化时，基于微服务间调用依赖关系及应用延迟等信息，分析微服务服务能力，并对指定微服务进行扩缩容，在保障服务质量同时提升资源使用率。

说明书

技术领域

本发明涉及微服务架构领域，尤其涉及一种基于微服务调用依赖感知的在线应用动态扩缩容方法。

背景技术

在互联网中活跃着的大量应用与服务中，在线应用占有很大一部分比重。其中很多面向用户的应 用对延迟十分敏感，如网页搜索，在线票务系统，电商系统等。这些应用的用户流量往往随时间显现 出周期性或突发性波动。流量波动也就是工作负载波动，影响着应用所需资源进而影响服务质量。在 降低资源利用率的同时满足用户对延迟的要求，是在线服务优化的重要方向。微服务架构的提出和广 泛应用，得益于其灵活的部署、水平扩缩容能力，为这一问题带来了新的挑战和可能的解决方案。

微服务被认为是一种新的软件架构，用于构建部署在云上的高度模块化、松散耦合的应用程序集 合。微服务架构将传统的单体服务解耦成多个微服务组件，服务组件之间利用轻量级通信方式，如 http、rpc进行通信，各服务组件能够独立的开发、部署和运行。微服务的特点是体量小，强独立性 和松耦合性，有利于开发人员的持续集成和部署。

单个微服务体量较小，使用传统的物理机或虚拟机部署方式不利于体现微服务架构自身的灵活性 优势。现有的解决方案中，微服务往往以容器形式部署在云上，以Dokcer为代表的容器技术提供了 轻量级的运行环境隔离解决方案。容器是一个标准的软件单元，它将代码及其所有依赖项打包，从而 使应用程序能够从一个计算环境快速可靠地运行到另一个计算环境。Docker容器映像是一个轻量级 的、独立的、可执行的软件包，包含运行应用程序所需的一切:代码、运行时、系统工具、系统库和 设置。以kubernetes为代表的容器编排引擎为容器的自动化部署、自动扩缩容、编排提供产品级解 决方案。

上述技术的支持使得开发者能够较为容易的在云上部署以微服务架构组织的应用。应用在运行过 程中，其负载特性会动态变化。特别是对在线应用而言，随着用户请求量的变化，应用所需资源也会 随之动态变化，在线应用部署在集群中，需要随用户请求量等特征的变化进行动态扩缩容。对于微服 务而言，由于容器的轻量、灵活等特点，能够很好的实现水平扩缩容。水平扩缩容是指根据微服务对 资源的需决定添加或删除容器实例，以提升性能或降低资源使用率。如何在流量不断变化过程中，对 微服务进行动态扩缩容，根据所需资源情况调整容器实例数目，是微服务架构的一个研究方向。

对于用微服务架构组织的在线应用动态扩缩容问题，目前已有一些研究成果和技术方案，如基于 阈值的方法、预测未来资源使用量变化，引入时序预测方法。

但现有技术往往对单个微服务执行扩缩容判断和操作，很少将微服务应用看做一个整体，考虑其 中的调用依赖关系对扩缩容方法的影响。

微服务的特点是体量小、低耦合，与此同时，微服务与微服务之间有着较为复杂的调用依赖关系。 调用依赖使得微服务与上下游服务在服务质量与资源利用率上互相影响。

本发明旨在解决微服务架构下，在线应用如何根据所感知到的微服务调用依赖关系进行动态扩缩 容，以保证用户延迟和提升资源使用率。

发明内容

为了解决目前微服务扩缩容系统的一些弊端，我们提出一种基于微服务调用依赖感知的在线应用 动态扩缩容方法，微服务调度编排领域中的常见的MAPE模式，即整个系统分为监控模块、分析模块、 规划模块、执行模块四个部分：

所述监控模块首先读取运行数据，所述运行数据包括区分为集群资源使用数据和服务调用相关数 据；其中，所述集群资源使用数据利用kubernetes集群监控和数据采集方式获取，使用node_export 结合prometheus来采集，在kubernetes集群每个节点部署node_export，用于将节点中容器运行数 据以http形式上报，由所述prometheus抓取数据，存储到时序数据库里并对外提供查询api；所述 服务调用相关数据，采用服务链路跟踪方式获取，用于探测服务调用链，通过选用与所述kubernetes 集群紧密结合的服务网格工具，将通过边车容器获取的服务运行数据保存在内置的所述prometheus 中，通过所述prometheus服务所述api，指定时间间隔和指标统计方式获取服务请求QPS、服务请求 延迟信息，通过内置的可观察性工具kiali-api，获取微服务结点信息以及节点间流量信息，分析出 微服务间调用关系和调用流量，并每隔一定的时间间隔，将所获取以上所述信息，传入分析模块进行 数据分析；

所述分析模块可以分为两个分析步骤：首先分析微服务通过监控模块中获取的监控信息发现应用 中存在的可能需要扩容瓶颈微服务或服务能力过剩可能需要缩容的微服务，之后对选定的微服务扩容 或缩容；

分析所述瓶颈微服务利用微服务间调用依赖关系进行，对监控模块中获取的多个微服务节点信息 和节点间流量相结合，分析出各所述微服务间调用关系，并进行拓扑排序，最终得到调用关系图及调 用流量比例，并以数值指标来定义各所述微服务是否为瓶颈微服务；分析所述微服务是否能力过剩通 过两个条件实现，首先为当前延迟不低于一段定时历史时间内的历史延迟，其次为请求流量有相应降 低，通过另一个数值指标反应器流量降低情况，当所述另一个数值指标达到特定阈值时认为当前服务 为可能能力过剩需要进行缩容操作；

找到所述需要可能需要扩容瓶颈微服务或服务能力过剩可能需要缩容的微服务后，建立预测模块 利用时序预测方法预测微服务扩缩容数量，所述预测模块输入为之前一段历史使用量数据时间的微服 务资源使用量组成的一组时序数据，预测模块输出为未来一段时期的时序数据，所述预测模块得到的 结果为一个时序序列，表示未来一段时间资源使用量，并选取预测序列中的最大值，表示所述未来一 段时间微服务可能达到的资源使用量最大值，作为主要指标传递给规划模块；

规划模块根据资源使用情况预测结果的未来一段时间微服务可能达到的资源使用量最大值，通过 特定算法计算所需扩缩容容器数目，所述规划模块中得到的输入信息是指定微服务在所述未来一段时 间分钟内可能达到的资源使用量最大值，输出此时指定微服务是否需要扩缩容，以及具体扩缩容数量 至执行模块；

执行模块使用kubernetes接口，根据规划模块输入的是否需要扩缩容，以及具体扩缩容数量进 行动态扩缩容，每个所述微服务定义为kubernetes集群中一个服务作为一个提供资源接入点的抽象 对象，可以与指定的容器集合相关联，所述指定的容器集合根据一个容器镜像启动一个或多个容器实 例，每个容器实例启动时申请指定数量的资源，容器实例数量被称为副本数，调整指定的容器集合中 的副本数即可实现微服务水平扩缩容，Kubernetes对外提供命令行以及api接口修改副本数目。

所述服务链路跟踪方式为服务网格方式获取或日志打点方式，所述服务网格工具为Istio或 ZipKin、pinpoint调用链监控工具。

所述指定时间间隔和指标统计方式包括avg、p90或p95等。

所述时间间隔为30s。

所述数值指标定义为α，用于指示当前微服务是否为应用瓶颈，α计算方式为：

f1＝lat

f2＝lat

α＝f1/f2

α＞threshold(1.2)

其中f表示将监控到的服务延迟数据与下游服务延迟剥离后，将服务延迟与下游服务延迟与请求 比例乘积和作差，f1为当前自身延迟，f2为历史自身延迟。

所述当前延迟不低于一段定时历史时间内的历史延迟的判断方法为利用所述数值指标α＜1，定 义指标β表示请求流量变化值，

α≤1&β＜0.8

β为当前1min请求流量与历史1h平均流量比值，当β小于0.8时，认为当前服务为可能能力过剩需要 进行缩容操作。

所述微服务资源使用量为cpu使用量，所述历史使用量数据时间长度为2h，预测结果的所述未 来一段时间为未来20min，所述预测模块的输入通过所述监控模块查询获取历史值，所述预测算法为 XGBoost算法、Arima模型、RNN模型或LSTM模型。

所述特定算法具体为：在kubernetes集群中由resources limit配置指定资源使用量的限制量， 通过监控接口确定微服务当前实例数为n，n为正整数，将预测值平均到n个实例与所述实例启动时 所指定的资源使用量的限制量进行比较，达到某个扩容阈值时，进行扩容；将预测值平均到n-1个实 例时，资源使用量与限制量相比低于某个缩容阈值时，进行缩容，所述扩容与缩容设置阈值不同，若 计算出的所述所需扩缩容容器数目与现有实例数不等，则将微服务信息与计算出的所需扩缩容容器数 目传递给执行模块进行实际扩缩容操作。

所述扩容阈值设置为80％，所述缩容阈值设置为75％。

所述无状态服务使用deployment。

与传统的推荐系统的方法相比，本申请的扩容缩容方法具有以下优势：

1.本发明提出一种遵循MAPE(监控、分析、规划、执行)模式的基于微服务间调用依赖关系感知 的在线应用动态扩缩容方法。支持在请求流量变化时，基于微服务间调用依赖关系及应用延迟等信息， 分析微服务服务能力，并对指定微服务进行扩缩容。以保障服务质量同时提升资源使用率。

2.本发明提出一种判断微服务是否为瓶颈服务以及是否服务能力过剩的方法。能够通过分析微服 务间调用依赖关系及延迟，与历史数据对比，计算并判断当前微服务运行状态及服务能力，进而支持 对指定微服务进行扩缩容的操作。

附图说明

图1整体流程图；

图2调用关系示意图；

图3扩缩容数量规划算法图：

具体实施方式

以下是本发明的优选实施例并结合附图，对本发明的技术方案作进一步的描述，但本发明并不限 于此实施例。

一种基于微服务调用依赖感知的在线服务动态扩缩容方法。所述方法遵循在微服务调度编排领域 中的常见的MAPE模式，即监控(monitor)、分析(analyze)、规划(plan)、执行(execute)。其中监控 模块主要用于获取资源使用情况、微服务请求流量、微服务延迟、微服务间调用依赖关系等信息。分 析模块根据微服务间调用关系与延迟情况分析微服务性能瓶颈，进一步根据瓶颈微服务的历史资源使 用信息预测未来一段时间资源使用情况。规划模块根据资源使用情况预测结果计算所需扩缩容容器数 目。执行模块根据计算结果执行扩缩容行为。所述方法通过以上步骤实现在用户流量实时变化时，准 确定位性能瓶颈微服务，执行相应扩缩容操作，图1为方法流程图。

监控模块

本发明所需要的应用运行数据包括：资源利用率(cpu、内存使用率)，微服务请求调用延迟、请 求流量、微服务间调用关系。可以区分为集群资源使用数据和服务调用相关数据，前者可以利用 kubernetes集群监控和数据采集方式获取，后者则需要使用能够探测服务调用链的方法。

对于集群资源使用数据，使用node_export结合prometheus来采集。在kubernetes集群每个节 点部署node_export，用于将节点中容器运行数据以http形式上报。由prometheus抓取数据，存储 到时序数据库里并对外提供查询api。

对于服务调用相关数据，本发明采用服务网格方式获取。也可使用日志打点方式等其他服务链路 跟踪方式。服务网格是一种应用程序无感知的服务间通信基础设施，通过在每个容器边部署一种特殊 的“边车”(sidecar)容器，代理和控制服务间通信从而帮助解决服务发现、流量控制等问题，同时 监控和记录服务请求指标。本发明选用与kubernetes集群紧密结合的服务网格工具istio，istio 将通过“边车”容器获取的服务运行数据保存在内置的prometheus中。通过prometheus服务api， 可以获取服务请求QPS、服务请求延迟信息，可指定时间间隔和指标统计方式(avg，p90，p95等)。 通过内置的可观察性工具kialiapi，可以获取微服务结点信息以及节点间流量信息，获取部分信息 简单示例：

表1微服务节点信息示例

表2节点间流量信息示例

通过上述信息，可以分析出微服务间调用关系和调用流量。监控模块每隔一定的时间间隔(默认30s)，获取以上所述信息，传入分析模块进行数据分析。

分析模块

分析模块可以分为两个分析步骤。首先解决需要对哪个微服务进行扩缩容的问题，通过监控模块 中获取的监控信息发现应用中可能存在的瓶颈微服务(可能需要扩容)或服务能力过剩的微服务(可能 需要缩容)。之后对选定的微服务解决应怎样扩缩容的问题，本发明中使用短期时序预测的方法，根 据对资源使用量的预测值和当前值判断应该扩缩容的数目。

其中分析微服务瓶颈时，我们考虑微服务间调用依赖关系。对监控模块中获取的微服务节点信息 和节点间流量相结合，分析出微服务间调用关系，并进行拓扑排序。最终得到调用关系图及调用流量 比例，图2展示对微服务示例应用hipster-shop使用上述方法进行节点间调用关系和拓扑分析得到 的调用关系。

判断当前微服务是否为应用瓶颈可以理解为判断当前微服务是否服务能力不足。在在线应用中， 服务能力不足的主要表现为延迟过高。本发明中定义指标α指示当前微服务是否为应用瓶颈，α计算 方式由下述中公式给出。

f1＝lat

f2＝lat

α＝f1/f2

α＞threshold(1.2)

为了准确表示当前应用自身延迟，将监控到的服务延迟数据与下游服务延迟剥离，即将服务延迟 与下游服务延迟与请求比例乘积和作差，记做f。通过自身延迟判断服务质量时，本发明不使用固定 SQA的方法，而是采用更为灵活的比较方法，将微服务当前自身延迟与历史延迟的比较来判断当前服 务延迟是否不满足预期。当前自身延迟记做f1，历史自身延迟记做f2，α定义为1h(历史)内自身延 迟除以1min(当前)内自身延迟p90结果。当α大于某个阈值，默认为1.2时，认为当前服务为应用瓶 颈，可能需要进行扩容操作。

将微服务能力过剩转换为可观察指标，应当体现为微服务当前延迟处于较低水平，即当前资源可 以满足应用需求。在此前提之下，若微服务请求流量低于历史水平，则当前微服务可能能力过剩，即 当前所占用资源超出所需资源。

判断微服务是否能力过剩，首先应满足当前延迟不低于历史延迟，本发明中表述为α＜＝1。其次 满足请求流量有相应降低。我们定义指标β表示请求流量变化值，β为当前1min请求流量与历史1h 平均流量比值。当β小于某个阈值，默认为0.8时，认为当前服务为可能能力过剩需要进行缩容操作。 所述计算公式表示如下：

α≤1&β<0.8

前文所述为寻找应用中的瓶颈微服务和能力过剩微服务方法。在找到这些待操作的微服务之后， 需要一个短期预测方法来预测未来一段时间微服务所需资源，来决定微服务扩缩容数量。可以看做是 一个时序预测问题，预测模块输入为之前一段时间微服务资源使用量(此处为cpu使用量)组成的一组 时序数据，预测模块输出为短期的未来时序数据。本方法中取预测所需历史历史使用量数据时间长度 为2h，预测结果为未来20min资源使用量。预测模块的输入也需要通过监控模块查询获取历史值。

时序预测方法往往被分为两类传统方法和机器学习方法，传统方法包括arima、holt-winter模 型，对平稳序列和周期性较强序列有较好的预测结果，适用于对待预测特征有较清晰的理解的情况。 机器学习方法往往将时序预测问题转换为一类回归问题，构建监督学习模型进行训练和预测。以RNN、 LSTM为代表的的循环神经网络方法能够取得较好的预测效果，但其模型训练所需时间较长。XGBoost 是GBDT方法的工程实现，作为一种提升树模型在算法竞赛和工程中被广泛使用，在速度和效率上都 有较好的表现。本方法兼顾训练时间与准确性，选用XGBoost作为预测算法。

预测模块得到的结果为一个时序序列，表示未来一段时间资源使用量。为了保证服务质量，既用 户感知延迟不上升。我们选取预测序列中的最大值，表示未来20分钟微服务可能达到的资源使用量 最大值,记做v，作为主要指标传递给规划模块，进行下一步规划。

规划模块

规划模块根据资源使用情况预测结果计算所需扩缩容容器数目。规划模块中得到的输入信息是指 定微服务在未来20分钟内可能达到的资源使用量最大值。需要输出的值为此时该模块是否需要扩缩 容，以及具体扩缩容数量。此处结合阈值控制方法部分思想，规划模块输入为特定微服务所有实例资 源使用量和，通过监控接口可以得知微服务当前实例数为n。将预测值平均到n个实例，与实例启动 时所指定的限制资源使用量(在kubernetes集群中由resources limit配置指定)进行比较，达到 某个阈值(设置为80％)时，进行扩容。将预测值平均到n-1个实例时，资源使用量与限制量相比低于 某个阈值(设置为75％)时，进行缩容。此处扩容与缩容设置阈值不同的原因是为了避免小范围数据波动时无效扩缩容操作。上述方法具体计算过程可表示为图3的伪代码模式。

若计算出N与现有实例数不等，则将微服务信息与计算结果N传递给执行模块进行实际扩缩容操 作。

执行模块

以docker为代表的容器技术，是一种轻量级的虚拟化方案。其优势在于可以根据预先打包好的 容器镜像，快速自动化部署容器。容器编排工具kubernetes通过特定配置文件(yaml)中指明的部署 编排方式，自动化进行容器创建、部署，抽象成服务提供对内对外访问接口并解决服务发现、负载均 衡等问题。每个微服务可以看做kubernetes集群中一个服务(service)。Service是一个提供资源接 入点的抽象对象，可以与指定的容器集合(无状态服务中通常使用deployment)相关联。Deployment 往往根据一个容器镜像启动一个或多个容器实例，每个容器实例启动时申请指定数量的资源，容器实 例数量被称为副本数。调整deployment中的副本数即可实现微服务水平扩缩容。Kubernetes对外提 供命令行以及api接口修改副本数目。本发明中执行模块使用是上述kubernetes接口，指定实例数 进行动态扩缩容。