一种容器管理方法及装置与流程

本发明涉及计算机应用技术领域，特别是涉及一种容器管理方法及装置。

背景技术：

docker是一个开源的应用容器引擎，能够让开发者打包他们的应用以及依赖包到一个可移植的容器中实现虚拟化。docker所在的服务器通过docker创建容器后可以在创建的容器中运行应用，并且通过容器运行应用能让更多数量的应用在同一服务器上运行。

但是容器中运行应用时其处理能力是一定的，因此在实际应用过程中上述服务器需要根据某一应用的待处理的请求量的大小来调节运行该应用的容器的数量，例如：需要根据接收到的搜索应用的搜索请求量大小，来实时调节运行搜索应用的容器数量，再例如需要根据接收到的多媒体应用的播放请求量的大小，来实时调节运行多媒体应用的容器数量。现有方法一般是在发现请求量增长过快，即当前时刻请求量较上一时刻请求量的增长率超过预设的阈值后，服务器才开始增加容器的数量；或是发现服务请求量减少过快，服务器才开始减少容器的数量。

然而，发明人在实现本发明的过程中发现，现有技术至少存在如下问题：当发现请求量增长过快时才去增加容器的数量容易导致请求处理不及时，当发现请求量减少过快时才去减少容器的数量容易导致容器被闲置，造成资源浪费。即现有技术存在严重的滞后性。

技术实现要素：

本发明实施例的目的在于提供一种容器管理方法，以实现根据历史服务请求数量智能的调节容器的数量，减少资源浪费。具体技术方案如下：

本发明实施的一方面提供了一种容器管理方法，所述方法包括：

确定目标时间段，所述目标时间段用于计算目标应用的待预测服务请求数量；

根据所述目标应用的历史服务请求数量，计算所述目标应用在所述目标时间段内预计接收到的服务请求的数量；

根据计算得到的服务请求的数量，调整用于运行所述目标应用的容器的数量。

可选的，所述根据所述目标应用的历史服务请求数量，计算所述目标应用在所述目标时间段内预计接收到的服务请求的数量的步骤，包括：

获得第一时间段内所述目标应用接收到的服务请求的数量，作为第一历史服务请求数量，其中，所述第一时间段为：与所述目标时间段相邻且时长相同的上一时间段；

根据历史参考单位内所述目标应用接收到的服务请求数量，计算第一数量相较于第二数量的预计增长率，其中，所述第一数量为：所述目标应用在所述目标时间段内预计接收到的服务请求数量，所述第二数量为：所述目标应用在所述第一时间段内接收到的服务请求数量；

根据所述第一历史服务请求数量和所述预计增长率，确定所述目标时间段内预计接收到的服务请求的数量。

可选的，所述根据历史参考单位内所述目标应用接收到的服务请求数量，计算第一数量相较于第二数量的预计增长率的步骤，包括：

获得第二时间段内所述目标应用接收到的服务请求的数量，作为第二历史服务请求数量，其中，所述第二时间段为：历史参考单位内与所述目标时间段的起始时刻、终止时刻相同的时间段；

获得第三时间段内所述目标应用接收到的服务请求的数量，作为第三历史服务请求数量，其中，所述第三时间段为：与所述第二时间段相邻且时长相同的上一时间段；

根据所述第二历史服务请求数量和所述第三历史服务请求数量，计算第一数量相较于第二数量的预计增长率。

可选的，所述历史参考单位为以下信息中的一种：

当前日期的前一天；

当前日期的前一周中的至少一天；

当前日期的前一月中的至少一天；

当前日期的前一年中的至少一天。

可选的，所述根据计算得到的服务请求的数量，调整用于运行所述目标应用的容器的数量的步骤，包括：

计算所述预计接收到的服务请求的数量与所述第一历史服务请求数量的差值；

当所述差值为正且大于第三数量时，则相应地增加运行所述目标应用的容器的数量；其中，所述第三数量为：当前运行所述目标应用的容器中具有剩余服务请求数量的容器所能处理的服务请求的数量；

当所述差值为负且所述差值的绝对值大于第四数量时，则相应地减少运行所述目标应用的容器的数量；其中，所述第四数量为：当前运行所述目标应用的容器中具有剩余服务请求数量的容器的服务请求的数量。

本发明实施的又一方面还提供了一种容器管理装置，所述装置包括：

确定模块，用于确定目标时间段，所述目标时间段用于计算目标应用的待预测服务请求数量；

计算模块，用于根据所述目标应用的历史服务请求数量，计算所述目标应用在所述目标时间段内预计接收到的服务请求的数量；

调整模块，用于根据计算得到的服务请求的数量，调整用于运行所述目标应用的容器的数量。

可选的，所述计算模块包括：

获得子模块，用于获得第一时间段内所述目标应用接收到的服务请求的数量，作为第一历史服务请求数量，其中，所述第一时间段为：与所述目标时间段相邻且时长相同的上一时间段；

计算子模块，用于根据历史参考单位内所述目标应用接收到的服务请求数量，计算第一数量相较于第二数量的预计增长率，其中，所述第一数量为：所述目标应用在所述目标时间段内预计接收到的服务请求数量，所述第二数量为：所述目标应用在所述第一时间段内接收到的服务请求数量；

确定子模块，用于根据所述第一历史服务请求量和所述预计增长率，确定所述目标时间段内预计接收到的服务请求的数量。

可选的，所述计算子模块具体用于，

获得第二时间段内所述目标应用接收到的服务请求的数量，作为第二历史服务请求数量，其中，所述第二时间段为：历史参考单位内与所述目标时间段的起始时刻、终止时刻相同的时间段；

获得第三时间段内所述目标应用接收到的服务请求的数量，作为第三历史服务请求数量，其中，所述第三时间段为：与所述第二时间段相邻且时长相同的上一时间段；

根据所述第二历史服务请求数量和所述第三历史服务请求数量，计算第一数量相较于第二数量的预计增长率。

可选的，所述历史参考单位为以下信息中的一种：

当前日期的前一天；

当前日期的前一周中的至少一天；

当前日期的前一月中的至少一天；

当前日期的前一年中的至少一天。

可选的，所述调整模块具体用于，

计算所述预计接收到的服务请求的数量与所述第一历史服务请求数量的差值；

当所述差值为正且大于第三数量时，则相应地增加运行所述目标应用的容器的数量；其中，所述第三数量为：当前运行所述目标应用的容器中具有剩余服务请求数量的容器所能处理的服务请求的数量；

当所述差值为负且所述差值的绝对值大于第四数量时，则相应地减少运行所述目标应用的容器的数量；其中，所述第四数量为：当前运行所述目标应用的容器中具有剩余服务请求数量的容器的服务请求的数量。

在本发明实施的又一方面，还提供了一种电子设备，其特征在于，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；

存储器，用于存放计算机程序；

处理器，用于执行存储器上所存放的程序时，实现上述任一所述的容器管理方法。

在本发明实施的又一方面，还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述任一所述的容器管理方法。

在本发明实施的又一方面，本发明实施例还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述任一所述的容器管理方法。

本发明实施例提供的容器管理方法及装置，可以根据历史服务请求数量来预计服务请求数量的增长和降低情况，然后根据预计的情况对运行目标应用的容器的数量进行调整，根据历史服务请求数量进行预计得到的结果更符合目标应用实际接收到的服务请求数量的情况，避免了服务请求的数量增长过快导致请求不能及时处理，和服务请求的数量减少过快导致容器闲置造成资源浪费的问题。当然，实施本发明的任一产品或方法必不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。

图1为本发明实施例提供的一种容器管理方法的流程示意图；

图2为本发明实施例提供的预计接收到的服务请求的数量的步骤示意图；

图3为本发明实施例提供的预计增长率的步骤示意图；

图4为本发明实施例提供的一种容器管理装置的结构示意图；

图5为本发明实施例提供的一种电子设备的结构示意图。

具体实施方式

现有的容器管理方法现有方法一般是在发现请求量增长过快，即当前时刻请求量较上一时刻请求量的增长率超过预设的阈值后，服务器才开始增加容器的数量，容易导致请求处理不及时；或是发现服务请求量减少过快，服务器才开始减少容器的数量，容易导致容器被闲置，造成资源浪费。针对以上问题本发明实施例提供了一种容器管理方法，包括：确定目标应用的待预测服务请求数量的目标时间段；根据所述目标应用的历史服务请求数量，计算所述目标应用在所述目标时间段内预计接收到的服务请求的数量；根据计算得到的服务请求的数量，调整用于运行所述目标应用的容器的数量。通过本发明实施例提供的方案可以根据历史服务请求数量来预计目标应用服务请求数量的变化情况，然后根据预计的情况对运行目标应用的容器的数量进行调整，根据历史服务请求数量预计得到的结果更符合目标应用实际接收到的服务请求数量的情况，避免了服务请求的数量增长过快请求不能及时处理，和服务请求的数量减少过快容器被闲置造成资源浪费的问题。

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行描述。

参照图1，示出了本发明实施例提供的一种容器管理方法的流程示意图，该方法具体包括：

s100，确定目标时间段，所述目标时间段用于计算目标应用的待预测服务请求数量。

一种实现方式中，目标时间段可以理解为当前时刻向后推特定的时长，时长可以为10分钟、15分钟、30分钟等。例如当前时刻为pm8:00，时长为10分钟，那么目标时间段则为pm8:00-8:10。当然，上述目标时间段也可以是固定的时间段，例如，晚上8点到10点等等。

具体的，上述时长可以是固定值，也可以是非固定值。如，发明人通过对大量样本数据进行统计分析，发现在互联网应用中每个应用的服务请求数量通常具有周期性，例如，爱奇艺视频播放应用通常在晚上八点到十点的黄金时期是视频播放请求数量的高峰，而在凌晨是视频播放请求数量的低谷。基于此可以根据目标应用在实际应用中接收到的服务请求数量的情况来实时改变上述时长。例如，在服务请求数量高峰阶段设置上述时长为5分钟，在服务请求数量低谷阶段设置上述时长为30分钟。在高峰阶段服务请求数量变化快，减少预测时长即增加单位时间内预测的次数从而能够避免在高峰时期服务请求数量增长过快而处理不过来；在低谷时期服务请求数量趋于平缓，增加预测时长即减少单位时间内预测的次数来降低服务器计算资源消耗。上述单位时间可以理解为1小时，5小时，10小时，一天等这都是可以的。

s200，根据所述目标应用的历史服务请求数量，计算所述目标应用在所述目标时间段内预计接收到的服务请求的数量。

目标应用的历史服务请求数量是指：在目标时间段之前的一个时间段内，目标应用接收到的服务请求数量，其中，目标时间段之前的一个时间段的时长可以与目标时间段的时长相等，也可以不相等。例如，目标时间段为pm8:00-pm9:00，即时长为1小时，相应的，目标时间段之前的一个时间段的时长可以取1小时，也可以取1天、1周、1月等。

本发明实施例一种实现方式中，确定目标应用的待预测服务请求数量的目标时间段之后，可以根据该目标应用的历史服务请求数量中与目标时间段起始时刻、终止时刻相同的时间段内的历史服务请求数量来预计目标应用在目标时间段内接收到的服务请求的数量。具体的，确定目标应用的待预测服务请求数量的目标时间段为pm8:00-8:10之后，可以先获取当前日期前30天的每一天中在pm8:00-8:10这一时间段内接收到的历史服务请求数量；然后根据获取到的各个历史服务请求数量计算得到一平均值作为该目标应用在目标时间段内预计接收到的服务请求的数量。

本发明实施的一种方式中，还可以对目标应用的历史服务请求数量中与目标时间段起始时刻、终止时刻相同的时间段内的历史服务请求数量进行加权相加来预计目标时间段内接收到的服务请求的数量。具体的，确定目标应用的待预测服务请求数量的目标时间段为星期五pm8:00-8:10之后，可以先获取当前日期前一周的每一天中在pm8:00-8:10这一时间段内接收到的历史服务请求数量，然后为每一天在pm8:00-8:10这一时间段内接收到的历史服务请求数量分配一权值，如，距离当前日期接近日期的即前一天分配的权值最高，然后依次递减上周五分配的权值最小，最后加权相加来预计目标时间段内接收到的服务请求的数量。由于当前日期的前一天与当前日期时间间隔短，这两天的服务请求数量的变化趋势比较类似，所以服务请求数量与当前日期会比较接近，因而可以为当前日期的前一天所对应的历史服务请求数量设置的权值高于其他日期内所对应的历史服务请求数量的权值。使得最终预计得到的计目标时间段内接收到的服务请求的数量更符合实际变化情况。

s300，根据计算得到的服务请求的数量，调整用于运行所述目标应用的容器的数量。

一种实现方式中，可以根据计算得到的服务请求的数量与用于运行目标应用的容器的最大请求处理数量的比值，预计需要运行该目标应用的容器的数量，然后与当前运行该目标应用的容器的数量进行比较来调节容器的数量。

例如，计算得到的服务请求的数量为12345，运行目标应用的容器的最大请求处理数量为1000，12345/1000＝12.345表明目标时间段内需要13个容器，如果当前容器的数量为10个，那就需要增加3个容器；如果当前容器的数量为15个则相应的减少2个容器。

通过本发明实施例提供的容器管理方法可以根据历史服务请求数量来预计服务请求数量的增长和降低情况，然后根据预计的情况对运行目标应用的容器的数量进行调整，根据历史服务请求数量进行预计得到的结果更符合目标应用实际接收到的服务请求数量的情况，避免了服务请求的数量增长过快导致请求不能及时处理，和服务请求的数量减少过快导致容器闲置造成资源浪费的问题。

参照图2示出了本发明实施例一种实现方式中，s200根据所述目标应用的历史服务请求数量，计算所述目标应用在所述目标时间段内预计接收到的服务请求的数量，具体可以包括：

s210，获得第一时间段内所述目标应用接收到的服务请求的数量，作为第一历史服务请求数量，其中，所述第一时间段为：与所述目标时间段相邻且时长相同的上一时间段。

第一时间段为与目标时间段相邻且时长相同的上一时间段，例如目标时间段为pm8:00-8:10则第一时间段为pm7:50-8:00。

s220，根据历史参考单位内所述目标应用接收到的服务请求数量，计算第一数量相较于第二数量的预计增长率，其中，所述第一数量为：所述目标应用在所述目标时间段内预计接收到的服务请求数量，所述第二数量为：所述目标应用在所述第一时间段内接收到的服务请求数量。

上述历史参考单位可以理解为：当前日期之前的一段时间，一段时间可以为当前日期之前的日期中至少一天。

本发明实施例一种实现方式中，历史参考单位可以为当前日期的前一天；当前日期的前一周中的至少一天；当前日期的前一月中的至少一天；当前日期的前一年中的至少一天。例如，今天是7月28日星期五，则相应地参考单位可以取前一天星期四、当前日期的前一周中与当前日期对应相同的一天，即上个星期五和当前日期的前一年中与当前日期对应相同的一天，即去年7月28日。

本发明实施例一种实现方式中，可以根据当前日期前一个月的每一天中与目标时间段对应起始时刻、终止时刻相同的时间段内接收到的服务请求数量，和与第一时间段对应起始时刻、终止时刻相同的时间段内接收到的服务请求数量，计算得到多个增长率，然后将根据计算得到的多个增长率取平均值作为第一数量相较于第二数量的预计增长率。例如，确定待预测目标应用服务请求数量的目标时间段为pm8:00-8:10，相应地第一时间段为pm7:50-8:00，根据当前日期前一个月的每一天中在pm8:00-8:10接收到的服务请求数量相比pm7:50-8:00接收到的服务请求数量的增长率，然后将计算得到的各个增长率求和再除以30得到一平均增长率，作为第一数量相较于第二数量的预计增长率。

本发明实施例一种实现方式中，还可以根据当前日期前一个月的每一天中与目标时间段对应起始时刻、终止时刻相同的时间段内接收到的服务请求数量，和与第一时间段对应起始时刻、终止时刻相同的时间段内接收到的服务请求数量，计算得到多个增长率，然后对计算得到的多个增长率进行加权相加得到第一数量相较于第二数量的预计增长率。具体的，可以为每一天中所对应的增长率分配不同的权值，如当前日期为7与28日，相应的7月27日对应的增长率分配的权值最大，其他日期对应的增长率的权值依次递减，6与28日对应的增长率分配的权值最小。

s230，根据所述第一历史服务请求数量和所述预计增长率，确定所述目标时间段内预计接收到的服务请求的数量。

一种实现方式中，将该目标应用在与目标时间段相邻且时长相同的上一时间段内接收到的历史服务请求数量乘以预计增长率得到的值，作为该目标应用在目标时间段内预计接收到的服务请求的数量。

本发明实施例可以根据历史服务请求数量来预计目标时间段内服务请求的数量，使得预计得到的结果更符合目标应用实际接收到的服务请求数量的情况。

参照图3示出了本发明实施例s220，根据历史参考单位内所述目标应用接收到的服务请求数量，计算第一数量相较于第二数量的预计增长率，其中，所述第一数量为：所述目标应用在所述目标时间段内预计接收到的服务请求数量，所述第二数量为：所述目标应用在所述第一时间段内接收到的服务请求数量。具体可以包括：

s221，获得第二时间段内所述目标应用接收到的服务请求的数量，作为第二历史服务请求数量，其中，所述第二时间段为：历史参考单位内与所述目标时间段的起始时刻、终止时刻相同的时间段；

s222，获得第三时间段内所述目标应用接收到的服务请求的数量，作为第三历史服务请求数量，其中，所述第三时间段为：与所述第二时间段相邻且时长相同的上一时间段；

s223，根据所述第二历史服务请求数量和所述第三历史服务请求数量，计算第一数量相较于第二数量的预计增长率。

上述第二时间段为历史参考单位内与所述目标时间段的起始时刻、终止时刻相同的时间段。例如，今天为7月28日，历史参考单位取7月27日和6月28日，目标时间段为pm8:00-pm8:10，则相应的第二时间段则为7月27日pm8:00-pm8:10和6月28日pm8:00-pm8:10。

上述第三时间段是与第二时间段相邻且时长相同的上一时间段，相应于对第二时间段的举例，相应地第三时间段则分别为7月27日pm7:50-pm8:00和6月28日7:50-pm8:00。

相应于上述对第二时间段和第三时间段的举例，本发明实施例在根据所述第二历史服务请求数量和所述第三历史服务请求数量，计算第一数量相较于第二数量的预计增长率的过程中，可以先计算出7月27日中pm8:00-pm8:10相对于pm7:50-pm8:00的历史服务请求数量的增长率，然后在计算出6月28日中pm8:00-pm8:10相对于pm7:50-pm8:00的历史服务请求数量的增长率，最后可以根据计算得到的两个增长率取平均值，来得到第一数量相较于第二数量的预计增长率。

本发明实施例一种实现方式中，在计算第一数量相较于第二数量的预计增长率的过程中，首先利用当前日期的前一天中与目标时间段起始时刻、终止时刻相同的时间段内接收到的服务请求数量除以上述目标时间段相邻且时长相同的时间段内接收到的服务请求数量得到一增长率；然后同理计算得到当前日期的前一周中和当前日期的前一年中分别与当前日期对应相同的一天中相同时间段内的增长率；最后进行加权相加得到一最终增长率作为第一数量相较于第二数量的预计增长率。

在上述加权相加的过程中，由于当前日期的前一天与当前日期时间间隔短，这两天的服务请求数量的变化趋势比较类似，服务请求数量与当前日期会比较接近，因而可以为当前日期的前一天所对应的增长率设置的权值高于其他历史参考单位内所对应的增长率。例如，当前日期的前一天所对应的增长率的权值可以设为0.5，当前日期的前一周所对应的增长率的权值可以设为0.3，当前日期的前一年所对应的增长率的权值可以设为0.2。

在上述加权相加的过程中，在为历史参考单位内所对应的增长率设置权值时，还可以根据服务请求的类型来确定各个历史参考单位内所对应的增长率的权值。例如，针对视频播放请求，周六观看视频的人数会比工作日期间观看视频的人数多，因而在计算周六中的目标时间段内预计接收到的服务请求的数量时，可以为当前日期的前一周所对应的增长率设置的权值高于其他历史参考单位内所对应的增长率。

以下以本发明一个具体实施例来对根据目标应用的历史服务请求数量，计算该目标应用在目标时间段内预计接收到的服务请求的数量的步骤进行说明：

当前时刻为7月28日星期五pm8:00，确定待预测目标应用服务请求数量的目标时间段为pm8:00-8:10，历史参考单位取当前日期的前一天星期四、当前日期的前一周中的星期五和当前日期的前一年中的7月28日；

根据历史服务请求数量首先获取该目标应用在当前日期pm7:50-8:00这段时间内的服务请求数量为15000；然后获取该目标应用在去年7月28日pm7:50-8:00这段时间内的服务请求数量为13000，在去年7月28日pm8:00-8:10这段时间内的服务请求数量为14000；获取上周五pm7:50-8:00这段时间内的服务请求数量为12000，pm8:00-8:10这段时间内的服务请求数量为13500；获取昨天pm7:50-8:00这段时间内的服务请求数量为14000，pm8:00-8:10这段时间内的服务请求数量为16000；

接着计算去年7月28日pm8:00-8:10相比pm7:50-8:00服务请求数量的增长率为(14000/13000)*100％＝107.69％；上星期五pm8:00-8:10相比pm7:50-8:00服务请求数量的增长率(13500/1200)*100％＝112.5％；昨天pm8:00-8:10相比pm7:50-8:00服务请求数量的增长率(16000/14000)*100％＝114.29％；然后进行加权相加107.69％*0.2+112.5％*0.3+114.29％*0.5＝112.443％；

最后用15000乘以112.443％得到16866即为该目标应用在目标时间段内预计接收到的服务请求数量。

本发明实施例还可以针对特定的某一天的历史服务请求数量来预计服务请求数量的增长和降低情况，例如每年的双十一，使得预计得到的结果更接近目标应用实际接收到的服务请求数量的情况。

本发明实施例一种实现方式中，s300，根据计算得到的服务请求的数量，调整用于运行所述目标应用的容器的数量。具体还可以包括以下步骤：

计算所述预计接收到的服务请求的数量与所述第一历史服务请求数量的差值；

当所述差值为正且大于当前运行所述目标应用的容器中具有剩余服务请求数量的容器所能处理的服务请求的数量时，表明目标时间段内目标应用的服务请求数量的增加，会超出当前运行目标应用的容器的服务请求的剩余处理能力，则相应地增加运行所述目标应用的容器的数量；

当所述差值为负且所述差值的绝对值大于当前运行所述目标应用的容器中具有剩余服务请求数量的容器的服务请求的数量时，则表明目标时间段内目标应用的服务请求数量的减少，会导致当前具有剩余服务请求数量的容器被闲置，则相应地减少运行所述目标应用的容器的数量。

例如，预计接收到的服务请求的数量为12300，第一历史服务请求数量为10000，运行目标应用的容器的最大请求处理数量为1000，当前具有剩余服务请求数量的容器所能处理的服务请求的数量为400，预计接收到的服务请求的数量与第一历史服务请求数量的差值为2300，2300-400＝1900则表明需要增加容器的数量，进一步地根据1900/1000＝1.9，确定需要增加2个容器。

当预计接收到的服务请求的数量为10000，第一历史服务请求数量为12300，运行目标应用的容器的最大请求处理数量为1000，当前运行所述目标应用的容器中具有剩余服务请求数量的容器的服务请求的数量为700，预计接收到的服务请求的数量与第一历史服务请求数量的差值为-2300，绝对值为2300，2300大于700则表明需要减少容器的数量，首先服务请求的数量减少700相应的减少一个容器，然后(2300-700)/1000＝1.6还需要进一步减少一个容器，最终确定需要减少2个容器。

通过本发明实施例提供的容器管理方法可以根据历史服务请求数量来预计服务请求数量的增长和降低情况，然后根据预计的情况对运行目标应用的容器的数量进行调整，根据历史服务请求数量进行预计得到的结果更符合目标应用实际接收到的服务请求数量的情况，避免了服务请求的数量增长过快导致请求不能及时处理，和服务请求的数量减少过快导致容器闲置造成资源浪费的问题。

参照图4，示出了本发明实施例提供的一种容器管理装置的结构示意图，该装置具体包括：

确定模块400，用于确定目标时间段，所述目标时间段用于计算目标应用的待预测服务请求数量；

计算模块410，用于根据所述目标应用的历史服务请求数量，计算所述目标应用在所述目标时间段内预计接收到的服务请求的数量；

调整模块420，用于根据计算得到的服务请求的数量，调整用于运行所述目标应用的容器的数量。

本发明实施例提供的容器管理装置，可以根据历史服务请求数量来预计服务请求数量的增长和降低情况，然后根据预计的情况对运行目标应用的容器的数量进行调整，根据历史服务请求数量进行预计得到的结果更符合目标应用实际接收到的服务请求数量的情况，避免了服务请求的数量增长过快导致请求不能及时处理，和服务请求的数量减少过快导致容器闲置造成资源浪费的问题。

本发明实施例一种实现方式中，上述计算模块包括：

获得子模块，用于获得第一时间段内所述目标应用接收到的服务请求的数量，作为第一历史服务请求数量，其中，所述第一时间段为：与所述目标时间段相邻且时长相同的上一时间段；

计算子模块，用于根据历史参考单位内所述目标应用接收到的服务请求数量，计算第一数量相较于第二数量的预计增长率，其中，所述第一数量为：所述目标应用在所述目标时间段内预计接收到的服务请求数量，所述第二数量为：所述目标应用在所述第一时间段内接收到的服务请求数量；

确定子模块，用于根据所述第一历史服务请求量和所述预计增长率，确定所述目标时间段内预计接收到的服务请求的数量。

本发明实施例一种实现方式中，上述计算子模块具体用于，

获得第二时间段内所述目标应用接收到的服务请求的数量，作为第二历史服务请求数量，其中，所述第二时间段为：历史参考单位内与所述目标时间段的起始时刻、终止时刻相同的时间段；

获得第三时间段内所述目标应用接收到的服务请求的数量，作为第三历史服务请求数量，其中，所述第三时间段为：与所述第二时间段相邻且时长相同的上一时间段；

根据所述第二历史服务请求数量和所述第三历史服务请求数量，计算第一数量相较于第二数量的预计增长率。

本发明实施例一种实现方式中，上述历史参考单位为以下信息中的一种：

当前日期的前一天；

当前日期的前一周中的至少一天；

当前日期的前一月中的至少一天；

当前日期的前一年中的至少一天。

本发明实施例一种实现方式中，上述调整模块具体用于，

计算所述预计接收到的服务请求的数量与所述第一历史服务请求数量的差值；

当所述差值为正且大于第三数量时，则相应地增加运行所述目标应用的容器的数量；其中，所述第三数量为当前运行所述目标应用的容器中具有剩余服务请求数量的容器所能处理的服务请求的数量；

当所述差值为负且所述差值的绝对值大于第四数量时，则相应地减少运行所述目标应用的容器的数量；其中，所述第四数量为当前运行所述目标应用的容器中具有剩余服务请求数量的容器的服务请求的数量。

本发明实施例提供的容器管理装置，可以根据历史服务请求数量来预计服务请求数量的增长和降低情况，然后根据预计的情况对运行目标应用的容器的数量进行调整，根据历史服务请求数量进行预计得到的结果更符合目标应用实际接收到的服务请求数量的情况，避免了服务请求的数量增长过快导致请求不能及时处理，和服务请求的数量减少过快导致容器闲置造成资源浪费的问题。

本发明实施例还提供了一种电子设备，如图5所示，包括处理器001、通信接口002、存储器003和通信总线004，其中，处理器001，通信接口002，存储器003通过通信总线004完成相互间的通信，

存储器003，用于存放计算机程序；

处理器001，用于执行存储器003上所存放的程序时，实现本发明实施例所述的容器管理方法。

具体的，上述容器管理方法，包括：

确定目标时间段，所述目标时间段用于计算目标应用的待预测服务请求数量；

根据所述目标应用的历史服务请求数量，计算所述目标应用在所述目标时间段内预计接收到的服务请求的数量；

根据计算得到的服务请求的数量，调整用于运行所述目标应用的容器的数量。

需要说明的是，上述处理器001执行存储器003上所存放的程序实现容器管理方法的其他实施例，与前述方法实施例部分提供的实施例相同，这里不再赘述。

本发明实施例提供的电子设备，可以根据历史服务请求数量来预计服务请求数量的增长和降低情况，然后根据预计的情况对运行目标应用的容器的数量进行调整，根据历史服务请求数量进行预计得到的结果更符合目标应用实际接收到的服务请求数量的情况，避免了服务请求的数量增长过快导致请求不能及时处理，和服务请求的数量减少过快导致容器闲置造成资源浪费的问题。

上述电子设备提到的通信总线可以是外设部件互连标准(peripheralpomponentinterconnect，简称pci)总线或扩展工业标准结构(extendedindustrystandardarchitecture，简称eisa)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通信接口用于上述电子设备与其他设备之间的通信。

存储器可以包括随机存取存储器(randomaccessmemory，简称ram)，也可以包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器可以是通用处理器，包括中央处理器(centralprocessingunit，简称cpu)、网络处理器(networkprocessor，简称np)等；还可以是数字信号处理器(digitalsignalprocessing，简称dsp)、专用集成电路(applicationspecificintegratedcircuit，简称asic)、现场可编程门阵列(field－programmablegatearray，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

在本发明提供的又一实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机实现本发明实施例所述的容器管理方法。

具体的，上述容器管理方法，包括：

确定目标时间段，所述目标时间段用于计算目标应用的待预测服务请求数量；

根据所述目标应用的历史服务请求数量，计算所述目标应用在所述目标时间段内预计接收到的服务请求的数量；

根据计算得到的服务请求的数量，调整用于运行所述目标应用的容器的数量。

需要说明的是，通过上述计算机可读存储介质实现容器管理方法的其他实施例，与前述方法实施例部分提供的实施例相同，这里不再赘述。

本发明实施例提供的计算机可读存储介质，可以根据历史服务请求数量来预计服务请求数量的增长和降低情况，然后根据预计的情况对运行目标应用的容器的数量进行调整，根据历史服务请求数量进行预计得到的结果更符合目标应用实际接收到的服务请求数量的情况，避免了服务请求的数量增长过快导致请求不能及时处理，和服务请求的数量减少过快导致容器闲置造成资源浪费的问题。

在本发明提供的又一实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机实现本发明实施例所述的容器管理方法。

具体的，上述容器管理方法，包括：

确定目标时间段，所述目标时间段用于计算目标应用的待预测服务请求数量；

根据所述目标应用的历史服务请求数量，计算所述目标应用在所述目标时间段内预计接收到的服务请求的数量；

根据计算得到的服务请求的数量，调整用于运行所述目标应用的容器的数量。

需要说明的是，通过上述计算机程序产品实现容器管理方法的其他实施例，与前述方法实施例部提供的实施例相同，这里不再赘述。

本发明实施例提供的计算机程序产品，可以根据历史服务请求数量来预计服务请求数量的增长和降低情况，然后根据预计的情况对运行目标应用的容器的数量进行调整，根据历史服务请求数量进行预计得到的结果更符合目标应用实际接收到的服务请求数量的情况，避免了服务请求的数量增长过快导致请求不能及时处理，和服务请求的数量减少过快导致容器闲置造成资源浪费的问题。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solidstatedisk(ssd))等。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、电子设备、计算机程序产品、计算机可读存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。