一种容器数量的调整方法、装置、设备和介质与流程
admin
2022-11-26 09:47:40
0次
该技术已申请专利。仅供学习研究，如用于商业用途，请联系技术所有人。
1.本技术涉及容器服务技术领域，特别是涉及一种容器数量的调整方法、装置、设备和计算机可读存储介质。
背景技术：
2.容器化技术不需要虚拟出整个操作系统，只需要虚拟一个小规模的环境即可，而且启动速度很快，除了运行其中应用以外，基本不消耗额外的系统资源。docker是应用最为广泛的容器技术，通过打包镜像，启动容器来创建一个服务。但是随着应用越来越复杂，容器的数量也越来越多，由此衍生了管理运维容器的重大问题，k8s(kubernetes)应运而生。k8s是为容器服务而生的一个可移植容器的编排管理工具。
3.目前k8s内置的hpa(horizontal pod autoscaler，水平自动缩放控制器)在控制容器的弹性伸缩时，往往依赖于单一类型的参数调整容器数量。例如，当cpu(central processing unit，中央处理器)使用量或者内存使用量很高时，为了降低后台服务的运行压力，可以对容器进行扩容，即增加容器个数。单一类型的指标并不能全面的反映后台服务的运行压力，导致调整后的容器数量并不符合实际服务需求。容器数量调整的较高时，会导致容器利用率偏低，造成资源浪费。容器数量调整的较低时，无法缓解后台的运行压力。
4.可见，如何及时准确的实现对容器数量的弹性伸缩，是本领域技术人员需要解决的问题。
技术实现要素：
5.本技术实施例的目的是提供一种容器数量的调整方法、装置、设备和计算机可读存储介质，可以及时准确的实现对容器数量的弹性伸缩。
6.为解决上述技术问题，本技术实施例提供一种容器数量的调整方法，包括：
7.获取全链路监控数据；其中，所述全链路监控数据包括容器运行参数和服务参数；所述服务参数用于表征服务调用情况；
8.依据所述容器运行参数和所述服务参数，构建关联参数；其中，所述关联参数用于表征容器数量与服务调用情况的相关性；
9.基于所述全链路监控数据以及所述关联参数预测容器数量，得到容器数量预估值；
10.根据所述容器数量预估值，调整系统的容器数量。
11.可选地，所述基于所述全链路监控数据以及所述关联参数预测容器数量，得到容器数量预估值包括：
12.将所述全链路监控数据和所述关联参数输入预测模型得到容器数量预估值。
13.可选地，所述预测模型为时间序列模型；
14.所述时间序列模型的训练过程包括：
15.获取满足周期性要求的历史全链路监控数据；其中，所述历史全链路监控数据包
括历史容器运行参数和历史服务参数；
16.依据所述历史容器运行参数和所述历史服务参数，构建历史关联参数；
17.利用所述历史全链路监控数据以及所述历史关联参数，对初始时间序列模型进行训练，以得到用于预测容器数量的时间序列模型。
18.可选地，所述基于所述全链路监控数据以及所述关联参数预测容器数量，得到容器数量预估值包括：
19.将所述全链路监控数据输入预测模型得到容器数据初始预估值；
20.基于设定的关联参数与容器数量调整比例的对应方式，确定出所述关联参数对应的目标容器数量调整比例；
21.依据所述目标容器数量调整比例，对所述容器数量初始预估值进行调整，得到容器数量预估值。
22.可选地，所述预测模型为时间序列模型；
23.所述时间序列模型的训练过程包括：
24.获取满足周期性要求的历史全链路监控数据；其中，所述历史全链路监控数据包括历史容器运行参数和历史服务参数；
25.利用所述历史全链路监控数据，对初始时间序列模型进行训练，以得到用于预测容器数量的时间序列模型。
26.可选地，所述获取全链路监控数据包括：
27.采集初始的全链路监控数据；
28.按照设定的数据清洗方式，对所述初始的全链路监控数据进行清洗，以得到全链路监控数据；其中，所述数据清洗方式包括剔除异常数据、补全缺失数据和参数归一化。
29.可选地，所述容器数量预估值包括多个时间段各自对应的容器数量预估值；所述根据所述容器数量预估值，调整系统的容器数量包括：
30.基于系统当前时间所属的目标时间段，将系统的容器数量调整为所述目标时间段对应的容器数量预估值；其中，所述目标时间段为所述多个时间段中的任意一个时间段。
31.本技术实施例还提供了一种容器数量的调整装置，包括获取单元、构建单元、预测单元和调整单元；
32.所述获取单元，用于获取全链路监控数据；其中，所述全链路监控数据包括容器运行参数和服务参数；所述服务参数用于表征服务调用情况；
33.所述构建单元，用于依据所述容器运行参数和所述服务参数，构建关联参数；其中，所述关联参数用于表征容器数量与服务调用情况的相关性；
34.所述预测单元，用于基于所述全链路监控数据以及所述关联参数预测容器数量，得到容器数量预估值；
35.所述调整单元，用于根据所述容器数量预估值，调整系统的容器数量。
36.可选地，所述预测单元用于将所述全链路监控数据和所述关联参数输入预测模型得到容器数量预估值。
37.可选地，所述预测模型为时间序列模型；针对于所述时间序列模型的训练过程，所述装置包括训练单元；
38.所述获取单元，用于获取满足周期性要求的历史全链路监控数据；其中，所述历史
全链路监控数据包括历史容器运行参数和历史服务参数；
39.所述构建单元，用于依据所述历史容器运行参数和所述历史服务参数，构建历史关联参数；
40.所述训练单元，用于利用所述历史全链路监控数据以及所述历史关联参数，对初始时间序列模型进行训练，以得到用于预测容器数量的时间序列模型。
41.可选地，所述预测单元包括预估子单元、确定子单元和得到子单元；
42.所述预估子单元，用于将所述全链路监控数据输入预测模型得到容器数据初始预估值；
43.所述确定子单元，用于基于设定的关联参数与容器数量调整比例的对应方式，确定出所述关联参数对应的目标容器数量调整比例；
44.所述得到子单元，用于依据所述目标容器数量调整比例，对所述容器数量初始预估值进行调整，得到容器数量预估值。
45.可选地，所述预测模型为时间序列模型；针对于所述时间序列模型的训练过程，所述装置包括训练单元；
46.所述获取单元，用于获取满足周期性要求的历史全链路监控数据；其中，所述历史全链路监控数据包括历史容器运行参数和历史服务参数；
47.所述训练单元，用于利用所述历史全链路监控数据，对初始时间序列模型进行训练，以得到用于预测容器数量的时间序列模型。
48.可选地，所述获取单元包括采集子单元和清洗子单元；
49.所述采集子单元，用于采集初始的全链路监控数据；
50.所述清洗子单元，用于按照设定的数据清洗方式，对所述初始的全链路监控数据进行清洗，以得到全链路监控数据；其中，所述数据清洗方式包括剔除异常数据、补全缺失数据和参数归一化。
51.可选地，所述容器数量预估值包括多个时间段各自对应的容器数量预估值；所述调整单元用于基于系统当前时间所属的目标时间段，将系统的容器数量调整为所述目标时间段对应的容器数量预估值；其中，所述目标时间段为所述多个时间段中的任意一个时间段。
52.本技术实施例还提供了一种容器数量的调整设备，包括：
53.存储器，用于存储计算机程序；
54.处理器，用于执行所述计算机程序以实现如上述容器数量的调整方法的步骤。
55.本技术实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述容器数量的调整方法的步骤。
56.由上述技术方案可以看出，获取全链路监控数据；其中，全链路监控数据包括容器运行参数和服务参数，服务参数可以用于表征服务调用情况。相比于单一类型的参数，全链路监控数据包含的参数类型更加全面。与容器相关的参数越全面，越能够准确的预测出服务所需的容器数量。为了充分挖掘各参数之间的关联性，可以依据容器运行参数和服务参数，构建关联参数；其中，关联参数用于表征容器数量与服务调用情况的相关性。基于全链路监控数据以及关联参数预测容器数量，可以得到容器数量预估值。根据容器数量预估值，
可以调整系统的容器数量。在该技术方案中，通过获取不同类型的参数，并且挖掘各参数之间的关联性得到关联参数，使得获取的参数较为全面，从而基于这些参数可以较为准确的得到符合服务需求的容器数量预估值。
附图说明
57.为了更清楚地说明本技术实施例，下面将对实施例中所需要使用的附图做简单的介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
58.图1为本技术实施例提供的一种调整容器数量的场景示意图；
59.图2为本技术实施例提供的一种容器数量的调整方法的流程图；
60.图3为本技术实施例提供的一种容器数量的调整装置的结构示意图；
61.图4为本技术实施例提供的一种容器数量的调整设备的结构图。
具体实施方式
62.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下，所获得的所有其他实施例，都属于本技术保护范围。
63.本技术的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及他们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可包括没有列出的步骤或单元。
64.为了使本技术领域的人员更好地理解本技术方案，下面结合附图和具体实施方式对本技术作进一步的详细说明。
65.传统方式中，对容器进行扩容往往是检测到后台服务器运行压力较大的情况下，通过增加容器个数，降低后台服务器的压力。但是这种方式属于事后扩容，是在后台服务器已经压力较大的情况下才会进行扩容，使得扩容之前的这段时间服务器存在响应过慢等问题。造成后台服务器压力较大的因素有多种，但是传统的扩容方式往往依赖于cpu或内存的使用量调整容器个数，会导致调整后的容器数量可能并不符合实际服务需求。
66.故此，本技术实施例提供了一种容器数量的调整方法、装置、设备和计算机可读存储介质，获取全链路监控数据；其中，全链路监控数据包括容器运行参数和服务参数，服务参数可以用于表征服务调用情况。依据容器运行参数和服务参数，构建关联参数；关联参数用于表征容器数量与服务调用情况的相关性。基于全链路监控数据以及关联参数预测容器数量，可以得到容器数量预估值，从而根据容器数量预估值，调整系统的容器数量，实现了对容器数量的提前预测。
67.本技术实施例所提供的容器数量的调整方案可以适用于pass平台，其中pass平台是指以k8s+docker为核心构建容器化具有编排能力的平台。其中容器(pod)是k8s中最小的调度单位，也是最小的，管理，创建的最小单元，k8s中pod的形式对外提供服务。
68.图1为本技术实施例提供的一种调整容器数量的场景示意图，可以将服务器所需执行的工作划分为三个模块，分别为全链路监控模块、预测模块(adaptor)和容器数量调整
模块(hpa模块)。其中，全链路监控模块可以获取全链路监控数据；其中，全链路监控数据包括容器运行参数和服务参数，服务参数可以用于表征服务调用情况。全链路监控模块可以采用prometheus组件实现。依据容器运行参数和服务参数，构建关联参数。相比于单一类型的参数，全链路监控数据包含的参数类型更加全面。与容器相关的参数越全面，越能够准确的预测出服务所需的容器数量。为了充分挖掘各参数之间的关联性，在全链路监控数据的基础上，增加了关联参数。
69.考虑到服务器上业务需求的变动往往具有周期性，因此预测模块可以结合不同时间范围内各参数与容器数量的相关性对全链路监控数据以及关联参数进行分析，从而得到容器数量预估值。容器数量调整模块根据容器数量预估值，可以调整系统的容器数量。通过获取不同类型的参数，并且挖掘各参数之间的关联性得到关联参数，使得获取的参数较为全面，从而基于这些参数可以较为准确的得到符合服务需求的容器数量预估值。
70.接下来，详细介绍本技术实施例所提供的一种容器数量的调整方法。图2为本技术实施例提供的一种容器数量的调整方法的流程图，该方法包括：
71.s201：获取全链路监控数据。
72.其中，全链路监控数据可以包括容器运行参数和服务参数。
73.为了更加全面的了解服务器的运行压力，容器运行参数和服务参数均可以包含多种类型的数据。
74.在具体实现中，容器运行参数可以包括当前cpu使用量c(t)，内存使用量m(t)，磁盘block io使用量b(t)，网卡数据量n(t)等。服务参数可以用于表征服务调用情况，可以包括每个服务对应每段时间内的调用次数，以及每次调用耗时，调用时间点等。
75.对于全链路监控数据的获取，可以通过监控平台对集群中所有容器每隔10分钟采集一次全链路监控数据。在后续确定容器数量预估值时，可以每隔1小时执行一次。
76.考虑到实际应用中，采集的数据可能会存在不规范的情况，例如，出现无效数据、异常数据或者数据不完成等情况。因此在本技术实施例中，可以采集初始的全链路监控数据；按照设定的数据清洗方式，对初始的全链路监控数据进行清洗，以得到全链路监控数据；其中，数据清洗方式包括剔除异常数据、补全缺失数据和参数归一化。
77.在具体实现中，针对于采集过程中出现的部分数据存在异常的情况，可以通过3sigma原则剔除异常数据。同时对于部分数据存在缺失的情况，可以采用k近邻插补法来补全缺失数据。由于采集的数据是多维度不同特征的数据，为了实现对数据的后续分析，需要将这些数据变成无量纲的归一化的数据，通过对全链路监控数据进行变换，把全链路监控数据映射到(0，1)之间。
78.数据归一化处理的方式较为常规，具体可以参见目前已有的技术，在此不再赘述。
79.s202：依据容器运行参数和服务参数，构建关联参数。
80.与容器相关的参数越全面，越能够准确的预测出服务所需的容器数量。在本技术实施例中，为了充分挖掘各参数之间的关联性，可以依据容器运行参数和服务参数，构建关联参数。
81.其中，关联参数用于表征容器数量与服务调用情况的相关性。
82.以上述介绍的当前cpu使用量c(t)，内存使用量m(t)，磁盘block io使用量b(t)，网卡数据量n(t)、每个服务对应每段时间内的调用次数，以及每次调用耗时，调用时间点这
7类数据为例，可以依次用x1(t)至x7(t)表示。
83.考虑到实际应用中，当前cpu使用量c(t)和每个服务对应每段时间内的调用次数存在一定的相关性，因此可以计算着这两个指标的互相关性，得到关联参数记为x8(t)，具体计算方法可以是计算这两个指标的协方差，具体公式为:
[0084][0085]
其中，x1(t)表示t时间下cpu使用量，x5(t)表示t时间下每个服务对应的调用次数，表示表示所有cpu对应的使用量的平均数，表示所有服务对应的调用次数的平均数，n表示cpu的个数。
[0086]
通过该协方差可估算服务是否为是cpu密集型。当协方差数值为正，说明该服务是cpu密集型，通过增加pod个数可以显著降低服务的响应时间，解决卡顿的问题。并且当该数值越大，说明增加pod数量越降低服务的影响时间。
[0087]
当协方差数值为负，说明该服务不是cpu密集型，通过增加pod个数一定程度上能提升响应时间，能缓解服务的卡顿问题，但效果不太明显，是因为该服务的瓶颈服务的i/o处理上，不在cpu上。
[0088]
s203：基于全链路监控数据以及关联参数预测容器数量，得到容器数量预估值。
[0089]
考虑到服务器上业务需求的变动往往具有周期性，因此在本技术实施例中，在基于全链路监控数据以及关联参数预测容器数量时可以结合不同时间范围内各参数与容器数量的相关性，对全链路监控数据以及关联参数进行分析，从而容器数量预估值。
[0090]
在具体实现中，可以通过模型训练的方式，得到能够反映不同时间范围内各参数与容器数量的相关性的预测模型，从而可以将全链路监控数据和关联参数输入预测模型得到容器数量预估值。
[0091]
预测模型可以采用时间序列模型。对于时间序列模型的训练过程，可以依赖于服务器的历史全链路监控数据进行训练得到。
[0092]
在具体实现中，可以获取满足周期性要求的历史全链路监控数据；其中，历史全链路监控数据可以包括历史容器运行参数和历史服务参数。依据历史容器运行参数和历史服务参数，构建历史关联参数。
[0093]
周期性要求可以是对历史全链路监控数据采集时间跨度的限定，时间跨度越长，采集的历史全链路监控数据的数据量越多，越有利于模型的训练。并且通过对历史全链路监控数据的时间跨度进行限定，可以采集最近一段时间内的历史全链路监控数据，从而使得训练得到的时间序列模型预测出的服务器运行压力的变化趋势，更加贴合当前服务器运行的实际情况。
[0094]
构建历史关联参数的实现方式可以参见s202的步骤，在此不再赘述。
[0095]
在获取到历史容器运行参数和历史服务参数，并且构建历史关联参数之后，可以利用历史全链路监控数据以及历史关联参数，对初始时间序列模型进行训练，以得到用于预测容器数量的时间序列模型。
[0096]
完成时间序列模型的训练之后，后续直接调用训练好的时间序列模型即可，无需每次执行容器数量的调整时都训练得到时间序列模型。
[0097]
s204：根据容器数量预估值，调整系统的容器数量。
[0098]
以时间序列模型为例，在训练得到时间序列模型时，可以对时间序列模型的输出形式进行限定，例如，向时间序列模型输入全链路监控数据以及关联参数，可以输出一个容器数量预估值。也可以向时间序列模型输入全链路监控数据以及关联参数，可以输出多个容器数量预估值，每个容器预估值有其适用的时间范围。
[0099]
以输出一个容器数量预估值为例，在实际应用中，直接以该容器数量预估值作为接下来一段时间内服务器系统的容器数量。
[0100]
以容器数量预估值包括多个时间段各自对应的容器数量预估值为例，在实际应用中，可以基于系统当前时间所属的目标时间段，将系统的容器数量调整为目标时间段对应的容器数量预估值。其中，目标时间段可以为多个时间段中的任意一个时间段。
[0101]
举例说明，假设当前时间为上午8点，通过上述操作得到的容器数量预估值为100和130，其中，100对应为上午8点至8点30分的时间段，130对应为上午8点30分至9点的时间段。在具体实现中，可以在上午8点的时刻，将系统的容器数量调整为100，在上午8点30分的时刻，将系统的容器数量调整为130。在达到上午9点的时刻，可按照上述s201至s204的操作，重新预测出下一个时间对应的容器数量预估值。
[0102]
为了便于描述，可以将容器运行参数、服务参数和关联参数统称为参数，在本技术实施例中，依赖于不同时间范围内各参数与容器数量的相关性对当前获取的参数进行分析，可以基于当前的参数预测接下来一段时间内服务所需的容器数量，实现了容器数量的提前预测，从而依赖于容器数量预估值及时准确的实现对容器数量的弹性伸缩。
[0103]
由上述技术方案可以看出，获取全链路监控数据；其中，全链路监控数据包括容器运行参数和服务参数，服务参数可以用于表征服务调用情况。相比于单一类型的参数，全链路监控数据包含的参数类型更加全面。与容器相关的参数越全面，越能够准确的预测出服务所需的容器数量。为了充分挖掘各参数之间的关联性，可以依据容器运行参数和服务参数，构建关联参数；其中，关联参数用于表征容器数量与服务调用情况的相关性。基于全链路监控数据以及关联参数预测容器数量，可以得到容器数量预估值。根据容器数量预估值，可以调整系统的容器数量。在该技术方案中，通过获取不同类型的参数，并且挖掘各参数之间的关联性得到关联参数，使得获取的参数较为全面，从而基于这些参数可以较为准确的得到符合服务需求的容器数量预估值。
[0104]
上述介绍中是以时间序列模型同时对全链路监控数据和关联参数进行分析，得到容器数量预估值。除此之外，在本技术实施例中，也可以将全链路监控数据输入预测模型得到容器数据初始预估值；基于设定的关联参数与容器数量调整比例的对应方式，确定出关联参数对应的目标容器数量调整比例；依据目标容器数量调整比例，对容器数量初始预估值进行调整，得到容器数量预估值。
[0105]
结合上述介绍可知，关联参数取值为正时，通过增加pod个数可以显著降低服务的响应时间；关联参数取值为负时，调整pod个数对降低服务响应时间不具有明显的效果。
[0106]
设定的关联参数与容器数量调整比例的对应方式可以包括不同取值范围各自对应的比例，其中，取值范围可以只包括关联参数取值为正的范围。在确定出关联参数的取值后，通过查询关联参数与容器数量调整比例的对应方式，可以得到关联参数匹配的容器数量调整比例，为了便于区分，可以将该容器数量调整比例称作目标容器数量调整比例。
[0107]
相适应的，为了使得时间序列模型更准确的对全链路监控数据进行分析，在执行时间序列模型的训练时，可以获取满足周期性要求的历史全链路监控数据；其中，历史全链路监控数据包括历史容器运行参数和历史服务参数。利用历史全链路监控数据，对初始时间序列模型进行训练，以得到用于预测容器数量的时间序列模型。
[0108]
在本技术实施例中，对于得到容器数量预估值的具体实现方式不做限定，既可以依据时间序列模型同时对全链路监控数据和关联参数进行分析，得到容器数量预估值，此时时间序列模型是依据历史全链路监控数据和历史关联参数训练得到。也可以依据时间序列模型先对全链路监控数据进行分析，得到容器数量初始预估值，然后依据关联参数对容器数量初始预估值进行调整，从而得到最终的容器数量预估值，此时时间序列模型是依据历史全链路监控数据训练得到。
[0109]
图3为本技术实施例提供的一种容器数量的调整装置的结构示意图，包括获取单元31、构建单元32、预测单元33和调整单元34；
[0110]
获取单元31，用于获取全链路监控数据；其中，全链路监控数据包括容器运行参数和服务参数；服务参数用于表征服务调用情况；
[0111]
构建单元32，用于依据容器运行参数和服务参数，构建关联参数；其中，关联参数用于表征容器数量与服务调用情况的相关性；
[0112]
预测单元33，用于基于全链路监控数据以及关联参数预测容器数量，得到容器数量预估值
[0113]
调整单元34，用于根据容器数量预估值，调整系统的容器数量。
[0114]
可选地，预测单元用于将全链路监控数据和关联参数输入预测模型得到容器数量预估值。
[0115]
可选地，预测模型为时间序列模型；针对于时间序列模型的训练过程，装置包括训练单元；
[0116]
获取单元，用于获取满足周期性要求的历史全链路监控数据；其中，历史全链路监控数据包括历史容器运行参数和历史服务参数；
[0117]
构建单元，用于依据历史容器运行参数和历史服务参数，构建历史关联参数；
[0118]
训练单元，用于利用历史全链路监控数据以及历史关联参数，对初始时间序列模型进行训练，以得到用于预测容器数量的时间序列模型。
[0119]
可选地，预测单元包括预估子单元、确定子单元和得到子单元；
[0120]
预估子单元，用于将全链路监控数据输入预测模型得到容器数据初始预估值；
[0121]
确定子单元，用于基于设定的关联参数与容器数量调整比例的对应方式，确定出关联参数对应的目标容器数量调整比例；
[0122]
得到子单元，用于依据目标容器数量调整比例，对容器数量初始预估值进行调整，得到容器数量预估值。
[0123]
可选地，预测模型为时间序列模型；
[0124]
针对于时间序列模型
[0125]
的训练过程，装置包括训练单元；
[0126]
获取单元，用于获取满足周期性要求的历史全链路监控数据；其中，历史全链路监控数据包括历史容器运行参数和历史服务参数；
[0127]
训练单元，用于利用历史全链路监控数据，对初始时间序列模型进行训练，以得到用于预测容器数量的时间序列模型。
[0128]
可选地，获取单元包括采集子单元和清洗子单元；
[0129]
采集子单元，用于采集初始的全链路监控数据；
[0130]
清洗子单元，用于按照设定的数据清洗方式，对初始的全链路监控数据进行清洗，以得到全链路监控数据；其中，数据清洗方式包括剔除异常数据、补全缺失数据和参数归一化。
[0131]
可选地，容器数量预估值包括多个时间段各自对应的容器数量预估值；调整单元用于基于系统当前时间所属的目标时间段，将系统的容器数量调整为目标时间段对应的容器数量预估值；其中，目标时间段为多个时间段中的任意一个时间段。
[0132]
图3所对应实施例中特征的说明可以参见图2所对应实施例的相关说明，这里不再一一赘述。
[0133]
由上述技术方案可以看出，获取全链路监控数据；其中，全链路监控数据包括容器运行参数和服务参数，服务参数可以用于表征服务调用情况。相比于单一类型的参数，全链路监控数据包含的参数类型更加全面。与容器相关的参数越全面，越能够准确的预测出服务所需的容器数量。为了充分挖掘各参数之间的关联性，可以依据容器运行参数和服务参数，构建关联参数；其中，关联参数用于表征容器数量与服务调用情况的相关性。基于全链路监控数据以及关联参数预测容器数量，可以得到容器数量预估值。根据容器数量预估值，可以调整系统的容器数量。在该技术方案中，通过获取不同类型的参数，并且挖掘各参数之间的关联性得到关联参数，使得获取的参数较为全面，从而基于这些参数可以较为准确的得到符合服务需求的容器数量预估值。
[0134]
图4为本技术实施例提供的一种容器数量的调整设备的结构图，如图4所示，容器数量的调整设备包括：存储器20，用于存储计算机程序；
[0135]
处理器21，用于执行计算机程序时实现如上述实施例容器数量的调整方法的步骤。
[0136]
本实施例提供的容器数量的调整设备可以包括但不限于智能手机、平板电脑、笔记本电脑或台式电脑等。
[0137]
其中，处理器21可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器21可以采用dsp(digital signal processing，数字信号处理)、fpga(field－programmable gate array，现场可编程门阵列)、pla(programmable logic array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器21也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称cpu(central processing unit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器21可以在集成有gpu(graphics processing unit，图像处理器)，gpu用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器21还可以包括ai(artificial intelligence，人工智能)处理器，该ai处理器用于处理有关机器学习的计算操作。
[0138]
存储器20可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器20还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多
个磁盘存储设备、闪存存储设备。本实施例中，存储器20至少用于存储以下计算机程序201，其中，该计算机程序被处理器21加载并执行之后，能够实现前述任一实施例公开的容器数量的调整方法的相关步骤。另外，存储器20所存储的资源还可以包括操作系统202和数据203等，存储方式可以是短暂存储或者永久存储。其中，操作系统202可以包括windows、unix、linux等。数据203可以包括但不限于不同时间范围内各参数与容器数量的相关性、全链路监控数据、用于表征容器数量与服务调用情况的相关性的关联参数等。
[0139]
在一些实施例中，容器数量的调整设备还可包括有显示屏22、输入输出接口23、通信接口24、电源25以及通信总线26。
[0140]
本领域技术人员可以理解，图4中示出的结构并不构成对容器数量的调整设备的限定，可以包括比图示更多或更少的组件。
[0141]
可以理解的是，如果上述实施例中的容器数量的调整方法以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，执行本技术各个实施例方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、磁碟或者光盘等各种可以存储程序代码的介质。
[0142]
基于此，本发明实施例还提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如上述容器数量的调整方法的步骤。
[0143]
本发明实施例所述计算机可读存储介质的各功能模块的功能可根据上述方法实施例中的方法具体实现，其具体实现过程可以参照上述方法实施例的相关描述，此处不再赘述。
[0144]
以上对本技术实施例所提供的一种容器数量的调整方法、装置、设备和计算机可读存储介质进行了详细介绍。说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
[0145]
专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
[0146]
以上对本技术所提供的一种容器数量的调整方法、装置、设备和计算机可读存储介质进行了详细介绍。本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以对本技术进行若干改进和
修饰，这些改进和修饰也落入本技术权利要求的保护范围内。
1.本技术涉及容器服务技术领域，特别是涉及一种容器数量的调整方法、装置、设备和计算机可读存储介质。
背景技术：
2.容器化技术不需要虚拟出整个操作系统，只需要虚拟一个小规模的环境即可，而且启动速度很快，除了运行其中应用以外，基本不消耗额外的系统资源。docker是应用最为广泛的容器技术，通过打包镜像，启动容器来创建一个服务。但是随着应用越来越复杂，容器的数量也越来越多，由此衍生了管理运维容器的重大问题，k8s(kubernetes)应运而生。k8s是为容器服务而生的一个可移植容器的编排管理工具。
3.目前k8s内置的hpa(horizontal pod autoscaler，水平自动缩放控制器)在控制容器的弹性伸缩时，往往依赖于单一类型的参数调整容器数量。例如，当cpu(central processing unit，中央处理器)使用量或者内存使用量很高时，为了降低后台服务的运行压力，可以对容器进行扩容，即增加容器个数。单一类型的指标并不能全面的反映后台服务的运行压力，导致调整后的容器数量并不符合实际服务需求。容器数量调整的较高时，会导致容器利用率偏低，造成资源浪费。容器数量调整的较低时，无法缓解后台的运行压力。
4.可见，如何及时准确的实现对容器数量的弹性伸缩，是本领域技术人员需要解决的问题。
技术实现要素：
5.本技术实施例的目的是提供一种容器数量的调整方法、装置、设备和计算机可读存储介质，可以及时准确的实现对容器数量的弹性伸缩。
6.为解决上述技术问题，本技术实施例提供一种容器数量的调整方法，包括：
7.获取全链路监控数据；其中，所述全链路监控数据包括容器运行参数和服务参数；所述服务参数用于表征服务调用情况；
8.依据所述容器运行参数和所述服务参数，构建关联参数；其中，所述关联参数用于表征容器数量与服务调用情况的相关性；
9.基于所述全链路监控数据以及所述关联参数预测容器数量，得到容器数量预估值；
10.根据所述容器数量预估值，调整系统的容器数量。
11.可选地，所述基于所述全链路监控数据以及所述关联参数预测容器数量，得到容器数量预估值包括：
12.将所述全链路监控数据和所述关联参数输入预测模型得到容器数量预估值。
13.可选地，所述预测模型为时间序列模型；
14.所述时间序列模型的训练过程包括：
15.获取满足周期性要求的历史全链路监控数据；其中，所述历史全链路监控数据包
括历史容器运行参数和历史服务参数；
16.依据所述历史容器运行参数和所述历史服务参数，构建历史关联参数；
17.利用所述历史全链路监控数据以及所述历史关联参数，对初始时间序列模型进行训练，以得到用于预测容器数量的时间序列模型。
18.可选地，所述基于所述全链路监控数据以及所述关联参数预测容器数量，得到容器数量预估值包括：
19.将所述全链路监控数据输入预测模型得到容器数据初始预估值；
20.基于设定的关联参数与容器数量调整比例的对应方式，确定出所述关联参数对应的目标容器数量调整比例；
21.依据所述目标容器数量调整比例，对所述容器数量初始预估值进行调整，得到容器数量预估值。
22.可选地，所述预测模型为时间序列模型；
23.所述时间序列模型的训练过程包括：
24.获取满足周期性要求的历史全链路监控数据；其中，所述历史全链路监控数据包括历史容器运行参数和历史服务参数；
25.利用所述历史全链路监控数据，对初始时间序列模型进行训练，以得到用于预测容器数量的时间序列模型。
26.可选地，所述获取全链路监控数据包括：
27.采集初始的全链路监控数据；
28.按照设定的数据清洗方式，对所述初始的全链路监控数据进行清洗，以得到全链路监控数据；其中，所述数据清洗方式包括剔除异常数据、补全缺失数据和参数归一化。
29.可选地，所述容器数量预估值包括多个时间段各自对应的容器数量预估值；所述根据所述容器数量预估值，调整系统的容器数量包括：
30.基于系统当前时间所属的目标时间段，将系统的容器数量调整为所述目标时间段对应的容器数量预估值；其中，所述目标时间段为所述多个时间段中的任意一个时间段。
31.本技术实施例还提供了一种容器数量的调整装置，包括获取单元、构建单元、预测单元和调整单元；
32.所述获取单元，用于获取全链路监控数据；其中，所述全链路监控数据包括容器运行参数和服务参数；所述服务参数用于表征服务调用情况；
33.所述构建单元，用于依据所述容器运行参数和所述服务参数，构建关联参数；其中，所述关联参数用于表征容器数量与服务调用情况的相关性；
34.所述预测单元，用于基于所述全链路监控数据以及所述关联参数预测容器数量，得到容器数量预估值；
35.所述调整单元，用于根据所述容器数量预估值，调整系统的容器数量。
36.可选地，所述预测单元用于将所述全链路监控数据和所述关联参数输入预测模型得到容器数量预估值。
37.可选地，所述预测模型为时间序列模型；针对于所述时间序列模型的训练过程，所述装置包括训练单元；
38.所述获取单元，用于获取满足周期性要求的历史全链路监控数据；其中，所述历史
全链路监控数据包括历史容器运行参数和历史服务参数；
39.所述构建单元，用于依据所述历史容器运行参数和所述历史服务参数，构建历史关联参数；
40.所述训练单元，用于利用所述历史全链路监控数据以及所述历史关联参数，对初始时间序列模型进行训练，以得到用于预测容器数量的时间序列模型。
41.可选地，所述预测单元包括预估子单元、确定子单元和得到子单元；
42.所述预估子单元，用于将所述全链路监控数据输入预测模型得到容器数据初始预估值；
43.所述确定子单元，用于基于设定的关联参数与容器数量调整比例的对应方式，确定出所述关联参数对应的目标容器数量调整比例；
44.所述得到子单元，用于依据所述目标容器数量调整比例，对所述容器数量初始预估值进行调整，得到容器数量预估值。
45.可选地，所述预测模型为时间序列模型；针对于所述时间序列模型的训练过程，所述装置包括训练单元；
46.所述获取单元，用于获取满足周期性要求的历史全链路监控数据；其中，所述历史全链路监控数据包括历史容器运行参数和历史服务参数；
47.所述训练单元，用于利用所述历史全链路监控数据，对初始时间序列模型进行训练，以得到用于预测容器数量的时间序列模型。
48.可选地，所述获取单元包括采集子单元和清洗子单元；
49.所述采集子单元，用于采集初始的全链路监控数据；
50.所述清洗子单元，用于按照设定的数据清洗方式，对所述初始的全链路监控数据进行清洗，以得到全链路监控数据；其中，所述数据清洗方式包括剔除异常数据、补全缺失数据和参数归一化。
51.可选地，所述容器数量预估值包括多个时间段各自对应的容器数量预估值；所述调整单元用于基于系统当前时间所属的目标时间段，将系统的容器数量调整为所述目标时间段对应的容器数量预估值；其中，所述目标时间段为所述多个时间段中的任意一个时间段。
52.本技术实施例还提供了一种容器数量的调整设备，包括：
53.存储器，用于存储计算机程序；
54.处理器，用于执行所述计算机程序以实现如上述容器数量的调整方法的步骤。
55.本技术实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述容器数量的调整方法的步骤。
56.由上述技术方案可以看出，获取全链路监控数据；其中，全链路监控数据包括容器运行参数和服务参数，服务参数可以用于表征服务调用情况。相比于单一类型的参数，全链路监控数据包含的参数类型更加全面。与容器相关的参数越全面，越能够准确的预测出服务所需的容器数量。为了充分挖掘各参数之间的关联性，可以依据容器运行参数和服务参数，构建关联参数；其中，关联参数用于表征容器数量与服务调用情况的相关性。基于全链路监控数据以及关联参数预测容器数量，可以得到容器数量预估值。根据容器数量预估值，
可以调整系统的容器数量。在该技术方案中，通过获取不同类型的参数，并且挖掘各参数之间的关联性得到关联参数，使得获取的参数较为全面，从而基于这些参数可以较为准确的得到符合服务需求的容器数量预估值。
附图说明
57.为了更清楚地说明本技术实施例，下面将对实施例中所需要使用的附图做简单的介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
58.图1为本技术实施例提供的一种调整容器数量的场景示意图；
59.图2为本技术实施例提供的一种容器数量的调整方法的流程图；
60.图3为本技术实施例提供的一种容器数量的调整装置的结构示意图；
61.图4为本技术实施例提供的一种容器数量的调整设备的结构图。
具体实施方式
62.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下，所获得的所有其他实施例，都属于本技术保护范围。
63.本技术的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及他们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可包括没有列出的步骤或单元。
64.为了使本技术领域的人员更好地理解本技术方案，下面结合附图和具体实施方式对本技术作进一步的详细说明。
65.传统方式中，对容器进行扩容往往是检测到后台服务器运行压力较大的情况下，通过增加容器个数，降低后台服务器的压力。但是这种方式属于事后扩容，是在后台服务器已经压力较大的情况下才会进行扩容，使得扩容之前的这段时间服务器存在响应过慢等问题。造成后台服务器压力较大的因素有多种，但是传统的扩容方式往往依赖于cpu或内存的使用量调整容器个数，会导致调整后的容器数量可能并不符合实际服务需求。
66.故此，本技术实施例提供了一种容器数量的调整方法、装置、设备和计算机可读存储介质，获取全链路监控数据；其中，全链路监控数据包括容器运行参数和服务参数，服务参数可以用于表征服务调用情况。依据容器运行参数和服务参数，构建关联参数；关联参数用于表征容器数量与服务调用情况的相关性。基于全链路监控数据以及关联参数预测容器数量，可以得到容器数量预估值，从而根据容器数量预估值，调整系统的容器数量，实现了对容器数量的提前预测。
67.本技术实施例所提供的容器数量的调整方案可以适用于pass平台，其中pass平台是指以k8s+docker为核心构建容器化具有编排能力的平台。其中容器(pod)是k8s中最小的调度单位，也是最小的，管理，创建的最小单元，k8s中pod的形式对外提供服务。
68.图1为本技术实施例提供的一种调整容器数量的场景示意图，可以将服务器所需执行的工作划分为三个模块，分别为全链路监控模块、预测模块(adaptor)和容器数量调整
模块(hpa模块)。其中，全链路监控模块可以获取全链路监控数据；其中，全链路监控数据包括容器运行参数和服务参数，服务参数可以用于表征服务调用情况。全链路监控模块可以采用prometheus组件实现。依据容器运行参数和服务参数，构建关联参数。相比于单一类型的参数，全链路监控数据包含的参数类型更加全面。与容器相关的参数越全面，越能够准确的预测出服务所需的容器数量。为了充分挖掘各参数之间的关联性，在全链路监控数据的基础上，增加了关联参数。
69.考虑到服务器上业务需求的变动往往具有周期性，因此预测模块可以结合不同时间范围内各参数与容器数量的相关性对全链路监控数据以及关联参数进行分析，从而得到容器数量预估值。容器数量调整模块根据容器数量预估值，可以调整系统的容器数量。通过获取不同类型的参数，并且挖掘各参数之间的关联性得到关联参数，使得获取的参数较为全面，从而基于这些参数可以较为准确的得到符合服务需求的容器数量预估值。
70.接下来，详细介绍本技术实施例所提供的一种容器数量的调整方法。图2为本技术实施例提供的一种容器数量的调整方法的流程图，该方法包括：
71.s201：获取全链路监控数据。
72.其中，全链路监控数据可以包括容器运行参数和服务参数。
73.为了更加全面的了解服务器的运行压力，容器运行参数和服务参数均可以包含多种类型的数据。
74.在具体实现中，容器运行参数可以包括当前cpu使用量c(t)，内存使用量m(t)，磁盘block io使用量b(t)，网卡数据量n(t)等。服务参数可以用于表征服务调用情况，可以包括每个服务对应每段时间内的调用次数，以及每次调用耗时，调用时间点等。
75.对于全链路监控数据的获取，可以通过监控平台对集群中所有容器每隔10分钟采集一次全链路监控数据。在后续确定容器数量预估值时，可以每隔1小时执行一次。
76.考虑到实际应用中，采集的数据可能会存在不规范的情况，例如，出现无效数据、异常数据或者数据不完成等情况。因此在本技术实施例中，可以采集初始的全链路监控数据；按照设定的数据清洗方式，对初始的全链路监控数据进行清洗，以得到全链路监控数据；其中，数据清洗方式包括剔除异常数据、补全缺失数据和参数归一化。
77.在具体实现中，针对于采集过程中出现的部分数据存在异常的情况，可以通过3sigma原则剔除异常数据。同时对于部分数据存在缺失的情况，可以采用k近邻插补法来补全缺失数据。由于采集的数据是多维度不同特征的数据，为了实现对数据的后续分析，需要将这些数据变成无量纲的归一化的数据，通过对全链路监控数据进行变换，把全链路监控数据映射到(0，1)之间。
78.数据归一化处理的方式较为常规，具体可以参见目前已有的技术，在此不再赘述。
79.s202：依据容器运行参数和服务参数，构建关联参数。
80.与容器相关的参数越全面，越能够准确的预测出服务所需的容器数量。在本技术实施例中，为了充分挖掘各参数之间的关联性，可以依据容器运行参数和服务参数，构建关联参数。
81.其中，关联参数用于表征容器数量与服务调用情况的相关性。
82.以上述介绍的当前cpu使用量c(t)，内存使用量m(t)，磁盘block io使用量b(t)，网卡数据量n(t)、每个服务对应每段时间内的调用次数，以及每次调用耗时，调用时间点这
7类数据为例，可以依次用x1(t)至x7(t)表示。
83.考虑到实际应用中，当前cpu使用量c(t)和每个服务对应每段时间内的调用次数存在一定的相关性，因此可以计算着这两个指标的互相关性，得到关联参数记为x8(t)，具体计算方法可以是计算这两个指标的协方差，具体公式为:
[0084][0085]
其中，x1(t)表示t时间下cpu使用量，x5(t)表示t时间下每个服务对应的调用次数，表示表示所有cpu对应的使用量的平均数，表示所有服务对应的调用次数的平均数，n表示cpu的个数。
[0086]
通过该协方差可估算服务是否为是cpu密集型。当协方差数值为正，说明该服务是cpu密集型，通过增加pod个数可以显著降低服务的响应时间，解决卡顿的问题。并且当该数值越大，说明增加pod数量越降低服务的影响时间。
[0087]
当协方差数值为负，说明该服务不是cpu密集型，通过增加pod个数一定程度上能提升响应时间，能缓解服务的卡顿问题，但效果不太明显，是因为该服务的瓶颈服务的i/o处理上，不在cpu上。
[0088]
s203：基于全链路监控数据以及关联参数预测容器数量，得到容器数量预估值。
[0089]
考虑到服务器上业务需求的变动往往具有周期性，因此在本技术实施例中，在基于全链路监控数据以及关联参数预测容器数量时可以结合不同时间范围内各参数与容器数量的相关性，对全链路监控数据以及关联参数进行分析，从而容器数量预估值。
[0090]
在具体实现中，可以通过模型训练的方式，得到能够反映不同时间范围内各参数与容器数量的相关性的预测模型，从而可以将全链路监控数据和关联参数输入预测模型得到容器数量预估值。
[0091]
预测模型可以采用时间序列模型。对于时间序列模型的训练过程，可以依赖于服务器的历史全链路监控数据进行训练得到。
[0092]
在具体实现中，可以获取满足周期性要求的历史全链路监控数据；其中，历史全链路监控数据可以包括历史容器运行参数和历史服务参数。依据历史容器运行参数和历史服务参数，构建历史关联参数。
[0093]
周期性要求可以是对历史全链路监控数据采集时间跨度的限定，时间跨度越长，采集的历史全链路监控数据的数据量越多，越有利于模型的训练。并且通过对历史全链路监控数据的时间跨度进行限定，可以采集最近一段时间内的历史全链路监控数据，从而使得训练得到的时间序列模型预测出的服务器运行压力的变化趋势，更加贴合当前服务器运行的实际情况。
[0094]
构建历史关联参数的实现方式可以参见s202的步骤，在此不再赘述。
[0095]
在获取到历史容器运行参数和历史服务参数，并且构建历史关联参数之后，可以利用历史全链路监控数据以及历史关联参数，对初始时间序列模型进行训练，以得到用于预测容器数量的时间序列模型。
[0096]
完成时间序列模型的训练之后，后续直接调用训练好的时间序列模型即可，无需每次执行容器数量的调整时都训练得到时间序列模型。
[0097]
s204：根据容器数量预估值，调整系统的容器数量。
[0098]
以时间序列模型为例，在训练得到时间序列模型时，可以对时间序列模型的输出形式进行限定，例如，向时间序列模型输入全链路监控数据以及关联参数，可以输出一个容器数量预估值。也可以向时间序列模型输入全链路监控数据以及关联参数，可以输出多个容器数量预估值，每个容器预估值有其适用的时间范围。
[0099]
以输出一个容器数量预估值为例，在实际应用中，直接以该容器数量预估值作为接下来一段时间内服务器系统的容器数量。
[0100]
以容器数量预估值包括多个时间段各自对应的容器数量预估值为例，在实际应用中，可以基于系统当前时间所属的目标时间段，将系统的容器数量调整为目标时间段对应的容器数量预估值。其中，目标时间段可以为多个时间段中的任意一个时间段。
[0101]
举例说明，假设当前时间为上午8点，通过上述操作得到的容器数量预估值为100和130，其中，100对应为上午8点至8点30分的时间段，130对应为上午8点30分至9点的时间段。在具体实现中，可以在上午8点的时刻，将系统的容器数量调整为100，在上午8点30分的时刻，将系统的容器数量调整为130。在达到上午9点的时刻，可按照上述s201至s204的操作，重新预测出下一个时间对应的容器数量预估值。
[0102]
为了便于描述，可以将容器运行参数、服务参数和关联参数统称为参数，在本技术实施例中，依赖于不同时间范围内各参数与容器数量的相关性对当前获取的参数进行分析，可以基于当前的参数预测接下来一段时间内服务所需的容器数量，实现了容器数量的提前预测，从而依赖于容器数量预估值及时准确的实现对容器数量的弹性伸缩。
[0103]
由上述技术方案可以看出，获取全链路监控数据；其中，全链路监控数据包括容器运行参数和服务参数，服务参数可以用于表征服务调用情况。相比于单一类型的参数，全链路监控数据包含的参数类型更加全面。与容器相关的参数越全面，越能够准确的预测出服务所需的容器数量。为了充分挖掘各参数之间的关联性，可以依据容器运行参数和服务参数，构建关联参数；其中，关联参数用于表征容器数量与服务调用情况的相关性。基于全链路监控数据以及关联参数预测容器数量，可以得到容器数量预估值。根据容器数量预估值，可以调整系统的容器数量。在该技术方案中，通过获取不同类型的参数，并且挖掘各参数之间的关联性得到关联参数，使得获取的参数较为全面，从而基于这些参数可以较为准确的得到符合服务需求的容器数量预估值。
[0104]
上述介绍中是以时间序列模型同时对全链路监控数据和关联参数进行分析，得到容器数量预估值。除此之外，在本技术实施例中，也可以将全链路监控数据输入预测模型得到容器数据初始预估值；基于设定的关联参数与容器数量调整比例的对应方式，确定出关联参数对应的目标容器数量调整比例；依据目标容器数量调整比例，对容器数量初始预估值进行调整，得到容器数量预估值。
[0105]
结合上述介绍可知，关联参数取值为正时，通过增加pod个数可以显著降低服务的响应时间；关联参数取值为负时，调整pod个数对降低服务响应时间不具有明显的效果。
[0106]
设定的关联参数与容器数量调整比例的对应方式可以包括不同取值范围各自对应的比例，其中，取值范围可以只包括关联参数取值为正的范围。在确定出关联参数的取值后，通过查询关联参数与容器数量调整比例的对应方式，可以得到关联参数匹配的容器数量调整比例，为了便于区分，可以将该容器数量调整比例称作目标容器数量调整比例。
[0107]
相适应的，为了使得时间序列模型更准确的对全链路监控数据进行分析，在执行时间序列模型的训练时，可以获取满足周期性要求的历史全链路监控数据；其中，历史全链路监控数据包括历史容器运行参数和历史服务参数。利用历史全链路监控数据，对初始时间序列模型进行训练，以得到用于预测容器数量的时间序列模型。
[0108]
在本技术实施例中，对于得到容器数量预估值的具体实现方式不做限定，既可以依据时间序列模型同时对全链路监控数据和关联参数进行分析，得到容器数量预估值，此时时间序列模型是依据历史全链路监控数据和历史关联参数训练得到。也可以依据时间序列模型先对全链路监控数据进行分析，得到容器数量初始预估值，然后依据关联参数对容器数量初始预估值进行调整，从而得到最终的容器数量预估值，此时时间序列模型是依据历史全链路监控数据训练得到。
[0109]
图3为本技术实施例提供的一种容器数量的调整装置的结构示意图，包括获取单元31、构建单元32、预测单元33和调整单元34；
[0110]
获取单元31，用于获取全链路监控数据；其中，全链路监控数据包括容器运行参数和服务参数；服务参数用于表征服务调用情况；
[0111]
构建单元32，用于依据容器运行参数和服务参数，构建关联参数；其中，关联参数用于表征容器数量与服务调用情况的相关性；
[0112]
预测单元33，用于基于全链路监控数据以及关联参数预测容器数量，得到容器数量预估值
[0113]
调整单元34，用于根据容器数量预估值，调整系统的容器数量。
[0114]
可选地，预测单元用于将全链路监控数据和关联参数输入预测模型得到容器数量预估值。
[0115]
可选地，预测模型为时间序列模型；针对于时间序列模型的训练过程，装置包括训练单元；
[0116]
获取单元，用于获取满足周期性要求的历史全链路监控数据；其中，历史全链路监控数据包括历史容器运行参数和历史服务参数；
[0117]
构建单元，用于依据历史容器运行参数和历史服务参数，构建历史关联参数；
[0118]
训练单元，用于利用历史全链路监控数据以及历史关联参数，对初始时间序列模型进行训练，以得到用于预测容器数量的时间序列模型。
[0119]
可选地，预测单元包括预估子单元、确定子单元和得到子单元；
[0120]
预估子单元，用于将全链路监控数据输入预测模型得到容器数据初始预估值；
[0121]
确定子单元，用于基于设定的关联参数与容器数量调整比例的对应方式，确定出关联参数对应的目标容器数量调整比例；
[0122]
得到子单元，用于依据目标容器数量调整比例，对容器数量初始预估值进行调整，得到容器数量预估值。
[0123]
可选地，预测模型为时间序列模型；
[0124]
针对于时间序列模型
[0125]
的训练过程，装置包括训练单元；
[0126]
获取单元，用于获取满足周期性要求的历史全链路监控数据；其中，历史全链路监控数据包括历史容器运行参数和历史服务参数；
[0127]
训练单元，用于利用历史全链路监控数据，对初始时间序列模型进行训练，以得到用于预测容器数量的时间序列模型。
[0128]
可选地，获取单元包括采集子单元和清洗子单元；
[0129]
采集子单元，用于采集初始的全链路监控数据；
[0130]
清洗子单元，用于按照设定的数据清洗方式，对初始的全链路监控数据进行清洗，以得到全链路监控数据；其中，数据清洗方式包括剔除异常数据、补全缺失数据和参数归一化。
[0131]
可选地，容器数量预估值包括多个时间段各自对应的容器数量预估值；调整单元用于基于系统当前时间所属的目标时间段，将系统的容器数量调整为目标时间段对应的容器数量预估值；其中，目标时间段为多个时间段中的任意一个时间段。
[0132]
图3所对应实施例中特征的说明可以参见图2所对应实施例的相关说明，这里不再一一赘述。
[0133]
由上述技术方案可以看出，获取全链路监控数据；其中，全链路监控数据包括容器运行参数和服务参数，服务参数可以用于表征服务调用情况。相比于单一类型的参数，全链路监控数据包含的参数类型更加全面。与容器相关的参数越全面，越能够准确的预测出服务所需的容器数量。为了充分挖掘各参数之间的关联性，可以依据容器运行参数和服务参数，构建关联参数；其中，关联参数用于表征容器数量与服务调用情况的相关性。基于全链路监控数据以及关联参数预测容器数量，可以得到容器数量预估值。根据容器数量预估值，可以调整系统的容器数量。在该技术方案中，通过获取不同类型的参数，并且挖掘各参数之间的关联性得到关联参数，使得获取的参数较为全面，从而基于这些参数可以较为准确的得到符合服务需求的容器数量预估值。
[0134]
图4为本技术实施例提供的一种容器数量的调整设备的结构图，如图4所示，容器数量的调整设备包括：存储器20，用于存储计算机程序；
[0135]
处理器21，用于执行计算机程序时实现如上述实施例容器数量的调整方法的步骤。
[0136]
本实施例提供的容器数量的调整设备可以包括但不限于智能手机、平板电脑、笔记本电脑或台式电脑等。
[0137]
其中，处理器21可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器21可以采用dsp(digital signal processing，数字信号处理)、fpga(field－programmable gate array，现场可编程门阵列)、pla(programmable logic array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器21也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称cpu(central processing unit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器21可以在集成有gpu(graphics processing unit，图像处理器)，gpu用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器21还可以包括ai(artificial intelligence，人工智能)处理器，该ai处理器用于处理有关机器学习的计算操作。
[0138]
存储器20可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器20还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多
个磁盘存储设备、闪存存储设备。本实施例中，存储器20至少用于存储以下计算机程序201，其中，该计算机程序被处理器21加载并执行之后，能够实现前述任一实施例公开的容器数量的调整方法的相关步骤。另外，存储器20所存储的资源还可以包括操作系统202和数据203等，存储方式可以是短暂存储或者永久存储。其中，操作系统202可以包括windows、unix、linux等。数据203可以包括但不限于不同时间范围内各参数与容器数量的相关性、全链路监控数据、用于表征容器数量与服务调用情况的相关性的关联参数等。
[0139]
在一些实施例中，容器数量的调整设备还可包括有显示屏22、输入输出接口23、通信接口24、电源25以及通信总线26。
[0140]
本领域技术人员可以理解，图4中示出的结构并不构成对容器数量的调整设备的限定，可以包括比图示更多或更少的组件。
[0141]
可以理解的是，如果上述实施例中的容器数量的调整方法以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，执行本技术各个实施例方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、磁碟或者光盘等各种可以存储程序代码的介质。
[0142]
基于此，本发明实施例还提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如上述容器数量的调整方法的步骤。
[0143]
本发明实施例所述计算机可读存储介质的各功能模块的功能可根据上述方法实施例中的方法具体实现，其具体实现过程可以参照上述方法实施例的相关描述，此处不再赘述。
[0144]
以上对本技术实施例所提供的一种容器数量的调整方法、装置、设备和计算机可读存储介质进行了详细介绍。说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
[0145]
专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
[0146]
以上对本技术所提供的一种容器数量的调整方法、装置、设备和计算机可读存储介质进行了详细介绍。本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以对本技术进行若干改进和
修饰，这些改进和修饰也落入本技术权利要求的保护范围内。
