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

权利要求书

1.一种基于微服务调用依赖感知的在线应用动态扩缩容方法，其特征在于：所述方法整体架构采用MAPE模式，即整个系统分为监控模块、分析模块、规划模块、执行模块四个部分：

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

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

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

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

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

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

2.如权利要求1所述的一种基于微服务调用依赖感知的在线应用动态扩缩容方法，其特征在于：所述服务链路跟踪方式为服务网格方式获取或日志打点方式，所述服务网格工具为Istio或ZipKin、pinpoint调用链监控工具。

3.如权利要求2所述的一种基于微服务调用依赖感知的在线应用动态扩缩容方法，其特征在于：所述指定时间间隔和指标统计方式包括avg、p90或p95等。

4.如权利要求3所述的一种基于微服务调用依赖感知的在线应用动态扩缩容方法，其特征在于：所述时间间隔为30s。