具体实施方式

下面将参照附图更详细地描述本发明的示例性实施例。虽然附图中显示了本发明的示例性实施例，然而应当理解，可以以各种形式实现本发明而不应被这里阐述的实施例所限制。

目前的扩容方法一般是通过预先设定内存使用率容器管理阈值和请求率容器管理阈值，当监控到集群的内存使用率超过内存使用率容器管理阈值、并且集群的请求率超过请求率容器管理阈值，则触发容器管理动作。内存使用率是由业务逻辑复杂度和资源调用复杂度决定的，而集群的请求率与瞬时的业务调用量相关，使用预先指定的阈值，难以适应系统的实时变化，而使得扩容准确率较低，而无效的扩容会造成资源浪费。并且，生产系统的架构、部署、代码、业务量等都处于动态变化中，每个功能模块的业务特性的也不同，预先指定的阈值需要根据系统变化对各个功能模块的阈值及时作出调整，而使得维护工作量很大。

基于此，本发明实施例提供了一种容器管理方法、装置及计算设备，提高扩容准确率。

具体地，下面结合附图，对本发明实施例作进一步阐述。

其中，应当理解的是，本发明提供的下述实施例之间，只要不冲突，均可相互结合以形成新的实施方式。

图1示出了发明实施例提供的容器管理方法的流程示意图。该方法可以应用于计算设备。如图1所示，该方法包括：

步骤110、获取集群在历史预设时间的历史性能数据。

其中，集群可以为生产系统中的一个功能模块。生产系统可以包括多个功能模块，即生产系统可以包括多个集群。集群可以包括若干个相同或者不同的容器。因此，可以分别对各个集群执行容器管理方法，以实现各个集群的容器管理。

其中，历史预设时间可以为预先设置的一个时间段，例如，历史预设时间可以为当前时刻的前24小时，还可以为当前日期的前一天。历史预设时间可以分成若干个单位时间，例如，单位时间为1小时，历史预设时间为当前日期的前一天，则历史预设时间包括24个单位时间。

其中，历史性能数据可以包括历史预设时间内的各单位时间的历史处理请求数、历史成功率、历史响应时间。例如，对历史预设时间内的n个单位时间分别进行统计(n为正整数)，将第i个单位时间的性能数据记为历史处理请求数r_i、历史成功率s_i、历史响应时间t_i，则得到的历史性能数据为r₁、r₂……r_i……r_n、s₁、s₂……s_i……s_n、t₁、t₂……t_i……t_n。

其中，历史处理请求数是指单位时间内集群处理的请求的总数，历史成功率是指单位时间内集群服务的成功率，历史响应时间是指单位时间内集群的服务的响应时间。

步骤120、根据历史性能数据，确定标杆性能数据，并确定与标杆性能数据对应的标杆容器数量。

其中，标杆性能数据用于反映集群的最佳处理能力。如图2a和2b所示，当集群的容量充裕时，随着请求数的增加，成功率和响应时间基本保持不变；当集群的容量达到饱和后，成功率和响应时间就会明显恶化。集群的最佳处理能力，即性能拐点，为Min(Q_A，Q_B)，Q_A为A点处的请求数，Q_B为B点处的请求数。当集群所使用的容器规格、部署环境和代码业务逻辑等不发生变化时，可认为集群的性能拐点是固定的。但由于生产环境的动态变化，拐点也处于不断变化中，因此，本实施例通过历史性能数据确定标杆性能数据，从而动态寻找接近性能拐点的最大值。

其中，该方法还包括：根据预设时间间隔，重新获取历史性能数据；根据重新获取的历史性能数据，更新标杆性能数据以及标杆容器数量。其中，预设时间间隔是预先设置的用于更新历史性能数据的时间间隔。例如，假设预设时间间隔为10小时，历史预设时间为当前时刻的前24小时，当前时刻为6点，则在6点获取前24小时的历史性能数据，在16点重新获取前24小时的历史性能数据。又例如，假设预设时间间隔为24小时，历史预设时间为当前时刻的前24小时，当前时刻为0点，则在0点获取前24小时的历史性能数据，在24点(即第二天0点)重新获取前24小时的历史性能数据。并根据重新获取的历史性能数据，重新确定标杆性能数据以及标杆容器数量，从而使得标杆性能数据能够随着环境变化而变化，从而能够反映最实时的系统处理能力。

其中，标杆性能数据可以包括标杆请求总数R、标杆成功率S、标杆响应时间T。与标杆性能数据对应的标杆容器数量N是指当采集到被确定为标杆性能数据的历史性能数据时，集群中的容器数量。可以在获取历史性能数据时一并获取各单位时间的容器数量，得到历史性能数据对应的历史容器数量，从而当某个单位时间的历史性能数据被确定为标杆性能数据时，将该单位时间的容器数量确定为标杆容器数量。

具体地，步骤120可以包括：

步骤121、根据各单位时间的历史处理请求数、历史成功率、历史响应时间，分别计算各单位时间的单位请求总数；

步骤122、将各单位请求总数中最大的单位请求总数确定为标杆请求总数；

步骤123、将最大的单位请求总数对应的历史成功率确定为标杆成功率；

步骤124、将最大的单位请求总数对应的历史响应时间确定为标杆响应时间。

在步骤121中，可以根据以下公式计算单位请求总数：

其中，R_i为第i个单位时间的单位请求总数，r_i为第i个单位时间的历史处理请求数，s_i为第i个单位时间的历史成功率，t_i为第i个单位时间的历史响应时间。

在步骤122中，计算得到各个单位时间的单位请求总数R₁、R₂……R_i……R_n后，确定R₁、R₂……R_i……R_n中的最大值，将最大的单位请求总数确定为标杆请求总数R，即R＝Max(R₁，R₂……R_i……R_n)。R为集群在统计周期内接近最佳处理能力的最大值，即R≈Min(Q_A,Q_B)。

在步骤123中，假设第j个单位时间的单位请求总数R_j为最大的单位请求总数，则将最大的单位请求总数对应的历史成功率s_j确定为标杆成功率S。

在步骤124中，假设第j个单位时间的单位请求总数R_j为最大的单位请求总数，则将最大的单位请求总数对应的历史响应时间t_j确定为标杆响应时间T。

步骤130、获取集群在当前时间的当前性能数据以及与当前性能数据对应的当前容器数量。

其中，当前时间是指对集群执行容器管理方法的时间，则当前性能数据为对集群实时采集的性能数据。当前性能数据可以包括当前请求总数R'、当前成功率S'、当前响应时间T'。例如，当前请求总数R'可以为最近一分钟内机器的请求总数，当前成功率S'可以为当前时间的集群的成功率，当前响应时间T'可以为连续五个一分钟内的集群的响应时间的最小值。当前性能数据对应的当前容器数量是指当前时间的集群的容器数量。

步骤140、根据标杆性能数据、标杆容器数量、当前性能数据、当前容器数量，确定是否对集群进行扩容。

其中，请一并参阅图2a和2b，当满足以下任一条件时，则表明集群容量不足，需要进行扩容：条件一、集群的请求数上升，并且服务的成功率下降；条件二、集群的请求数上升，并且服务的平均响应时间增加。因此，虽然标杆性能数据只是接近最佳处理能力的一个近似值，仍然可以准确地评估集群的当前容量是否充裕，从而可以根据标杆性能数据、标杆容器数量、当前性能数据、当前容器数量，确定是否对集群进行扩容。

具体地，步骤140可以包括：

步骤141、根据标杆请求总数和标杆容器数量，计算集群的标杆平均请求数；

步骤142、根据当前请求总数和当前容器数量，计算集群的当前平均请求数；

步骤143、若标杆平均请求数大于当前平均请求数，并且标杆响应时间大于当前响应时间或者标杆成功率小于当前成功率，则确定对集群进行扩容。

其中，将标杆请求总数除以标杆容器数量，得到标杆平均请求数；将当前请求总数除以当前容器数量，得到当前平均请求数。若当前性能数据的统计单位为分钟，而标杆性能数据的统计单位为小时，则在比较标杆平均请求数和当前平均请求数之前，需要先统一为相同单位再进行比较。例如，根据以下公式计算当前平均请求数和标杆平均请求数

其中，R'为当前请求总数，N'为当前容器数量，λ为矫正参数(例如可以取0.9)，R为标杆请求总数，N为标杆容器数量。

在步骤143中，当且(T'＞T或者S'＜S)，则确定对集群进行扩容。

步骤150、若确定对集群进行扩容，则根据标杆性能数据和当前性能数据，计算扩容容器的数量。

其中，为了避免瞬时抖动引起大量容器扩容造成资源浪费的情况，采用调和级数来计算扩容容器数量，以进行少量多次扩容。例如，可以根据以下公式计算扩容容器的数量：

其中，Y为扩容容器的数量，γ为欧拉常数(可以取0.5772)，x为影响扩容的因素，例如成功率、响应时间等。

具体地，步骤150可以包括：

步骤151、获取集群的最小容器数量和最大容器数量；

步骤152、根据最小容器数量、当前容器数量、标杆成功率、当前成功率、标杆响应时间、当前响应时间，计算计划扩容数量；

步骤153、根据最大容器数量和当前容器数量，计算剩余可扩容器数量；

步骤154、若计划扩容数量小于或者等于剩余可扩容器数量，则将计划扩容数量确定为扩容容器的数量；

步骤155、若计划扩容数量大于剩余可扩容器数量，则将剩余可扩容器数量确定为扩容容器的数量。

其中，最小容器数量F是指集群中容纳的容器数量的最小值，最大容器数量C是指集群中容纳的容器数量的最大值。最小容器数量F和最大容器数量C可以在集群初始时进行配置。

其中，由于容量不足首先会体现在响应时间上，即响应时间先上升，等响应时间上升到一定程度时，成功率开始下降。因此，成功率相比响应时间增加是一个更加严重的信号，需要扩展更多的容器。另外，扩容容器的效果跟集群当前已存在的容器数量有关，当集群中已有容器的数量较多时，需要扩展更多的容器才能达到预期的效果。在步骤152中，可以根据以下公式计算计划扩容数量：

其中，M为计划扩容数量，F为最小容器数量，N'为当前容器数量，S为标杆成功率，S'为当前成功率，T为标杆响应时间，T'为当前响应时间，γ为欧拉常数。

其中，由于扩容数量还需要取决于剩余可扩容的容器数量，则在步骤153中，将最大容器数量F减去当前容器数量N'，计算得到剩余可扩容器数量(F-N')。在步骤154和步骤155中，M≤(F-N')，则扩容容器的数量Y＝M；若M＞(F-N')，则扩容容器的数量Y＝(F-N')。

步骤160、根据标杆性能数据和当前性能数据，计算扩容容器的生存时间。

其中，扩容容器的生存时间与标杆成功率S、当前成功率S'、标杆响应时间T、当前响应时间T'有关，则步骤160具体可以包括：

步骤161、获取扩容容器的最小生存时间；

步骤162、根据标杆成功率、当前成功率、标杆响应时间、当前响应时间、最小生存时间，计算扩容容器的生存时间。

其中，扩容容器的最小生存时间t是指扩展的容器能够生存的最短时间。最小生存时间t也可以在集群初始时进行配置。可以根据以下公式计算扩容容器的生存时间t'：

其中，S为标杆成功率，S'为当前成功率，T为标杆响应时间，T'为当前响应时间，t为最小生存时间。

在本实施例中，通过设定扩容容器的生存时间，可以有效应对业务量回落的情况，从而及时回收容器，提高资源利用率。

步骤170、根据扩容容器的数量和扩容容器的生存时间，对集群进行扩容。

其中，在计算得到扩容容器的数量和扩容容器的生存时间后，可以将扩容容器的数量、扩容容器的生存时间以及集群标识发送给调度模块，以使调度模块根据扩容容器的数量、扩容容器的生存时间、集群标识，调度容器管理平台，对与集群标识对应的集群进行扩容。

本发明实施例通过获取集群在历史预设时间的历史性能数据，根据历史性能数据，确定标杆性能数据，并确定与标杆性能数据对应的标杆容器数量，获取集群在当前时间的当前性能数据以及与当前性能数据对应的当前容器数量，根据标杆性能数据、标杆容器数量、当前性能数据、当前容器数量，确定是否对集群进行扩容，若确定对集群进行扩容，则根据标杆性能数据和当前性能数据，计算扩容容器的数量，根据标杆性能数据和当前性能数据，计算扩容容器的生存时间，根据扩容容器的数量和扩容容器的生存时间，对集群进行扩容，能够随着环境变化，动态确定标杆性能数据，以动态获取集群点的最佳处理能力近似值，从而提高了扩容准确率，无需人为干预，减少了工作量，并且，还依据集群当前性能相对于标杆性能的恶化程度以及集群的当前容器数量来计算扩容数量，规避了瞬时大量扩容造成的资源浪费，另外，不仅规划了扩容数量，还确定了扩容容器的存活时间，不仅在面对突发性瞬时业务高峰时可快速扩容，还可在业务回落时迅速释放多余资源。

图3示出了本发明实施例提供的容器管理装置的结构示意图。该装置可以应用于计算设备。如图3所示，该装置200包括：数据获取模块210、标杆管理模块220、容量管控模块230和调度模块240。

其中，数据获取模块210与生产系统400连接，标杆管理模块220分别与数据获取模块210、容量管控模块230连接，容量管控模块230与数据获取模块210连接，调度模块240与容量管控模块230连接，容器管理平台500分别与调度模块240、生产系统400连接。其中，生产系统400可以包括至少一个集群，容器管理平台500用于在生产系统400中增加或者回收容器。

其中，数据获取模块210用于获取集群在历史预设时间的历史性能数据，并获取所述集群在当前时间的当前性能数据以及与所述当前性能数据对应的当前容器数量；标杆管理模块220用于根据所述历史性能数据，确定标杆性能数据，并确定与所述标杆性能数据对应的标杆容器数量，以及，根据所述标杆性能数据、所述标杆容器数量、所述当前性能数据、所述当前容器数量，确定是否对所述集群进行扩容；容量管控模块230用于若确定对所述集群进行扩容，则根据所述标杆性能数据和所述当前性能数据，计算扩容容器的数量，以及，根据所述标杆性能数据和所述当前性能数据，计算扩容容器的生存时间；调度模块240用于根据所述扩容容器的数量和所述扩容容器的生存时间，对所述集群进行扩容。

在一种可选的方式中，所述历史性能数据包括所述历史预设时间内的各单位时间的历史处理请求数、历史成功率、历史响应时间，所述标杆性能数据包括标杆请求总数、标杆成功率、标杆响应时间。标杆管理模块220具体用于：根据所述各单位时间的历史处理请求数、历史成功率、历史响应时间，分别计算所述各单位时间的单位请求总数；将各所述单位请求总数中最大的单位请求总数确定为所述标杆请求总数；将所述最大的单位请求总数对应的历史成功率确定为所述标杆成功率；将所述最大的单位请求总数对应的历史响应时间确定为所述标杆响应时间。

在一种可选的方式中，所述当前性能数据包括当前请求总数、当前成功率、当前响应时间。标杆管理模块220具体用于：根据所述标杆请求总数和所述标杆容器数量，计算所述集群的标杆平均请求数；根据所述当前请求总数和所述当前容器数量，计算所述集群的当前平均请求数；若所述标杆平均请求数大于所述当前平均请求数，并且所述标杆响应时间大于所述当前响应时间或者所述标杆成功率小于所述当前成功率，则确定对所述集群进行扩容。

在一种可选的方式中，容量管控模块230具体用于：获取所述集群的最小容器数量和最大容器数量；根据所述最小容器数量、所述当前容器数量、所述标杆成功率、所述当前成功率、所述标杆响应时间、所述当前响应时间，计算计划扩容数量；根据所述最大容器数量和所述当前容器数量，计算剩余可扩容器数量；若所述计划扩容数量小于或者等于所述剩余可扩容器数量，则将所述计划扩容数量确定为所述扩容容器的数量；若所述计划扩容数量大于所述剩余可扩容器数量，则将所述剩余可扩容器数量确定为所述扩容容器的数量。

在一种可选的方式中，容量管控模块230具体用于：根据以下公式计算所述计划扩容数量：

其中，M为所述计划扩容数量，F为所述最小容器数量，N'为所述当前容器数量，S为所述标杆成功率，S'为所述当前成功率，T为所述标杆响应时间，T'为所述当前响应时间，γ为常数。

在一种可选的方式中，容量管控模块230具体还用于：获取扩容容器的最小生存时间；根据所述标杆成功率、所述当前成功率、所述标杆响应时间、所述当前响应时间、所述最小生存时间，计算所述扩容容器的生存时间。

在一种可选的方式中，数据获取模块210还用于：根据预设时间间隔，重新获取所述历史性能数据；标杆管理模块220还用于：根据重新获取的历史性能数据，更新所述标杆性能数据以及所述标杆容器数量。

需要说明的是，本发明实施例提供容器管理装置是能够执行上述容器管理方法的装置，则上述容器管理方法的所有实施例均适用于该装置，且均能达到相同或相似的有益效果。

本发明实施例通过获取集群在历史预设时间的历史性能数据，根据历史性能数据，确定标杆性能数据，并确定与标杆性能数据对应的标杆容器数量，获取集群在当前时间的当前性能数据以及与当前性能数据对应的当前容器数量，根据标杆性能数据、标杆容器数量、当前性能数据、当前容器数量，确定是否对集群进行扩容，若确定对集群进行扩容，则根据标杆性能数据和当前性能数据，计算扩容容器的数量，根据标杆性能数据和当前性能数据，计算扩容容器的生存时间，根据扩容容器的数量和扩容容器的生存时间，对集群进行扩容，能够随着环境变化，动态确定标杆性能数据，以动态获取集群点的最佳处理能力近似值，从而提高了扩容准确率，无需人为干预，减少了工作量，并且，还依据集群当前性能相对于标杆性能的恶化程度以及集群的当前容器数量来计算扩容数量，规避了瞬时大量扩容造成的资源浪费，另外，不仅规划了扩容数量，还确定了扩容容器的存活时间，不仅在面对突发性瞬时业务高峰时可快速扩容，还可在业务回落时迅速释放多余资源。

图4示出了本发明实施例提供的计算设备的结构示意图，本发明具体实施例并不对计算设备的具体实现做限定。

如图4所示，该计算设备可以包括：处理器(processor)302、通信接口(Communications Interface)304、存储器(memory)306、以及通信总线308。

其中：处理器302、通信接口304、以及存储器306通过通信总线308完成相互间的通信。通信接口304，用于与其它设备比如客户端或其它服务器等的网元通信。处理器302，用于执行程序310，具体可以执行上述用于容器管理方法实施例中的相关步骤。

具体地，程序310可以包括程序代码，该程序代码包括计算机可执行指令。

处理器302可能是中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本发明实施例的一个或多个集成电路。内容传输网络包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。

存储器306，用于存放程序310。存储器306可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

程序310具体可以被处理器302调用使计算设备执行上述实施例中的容器管理方法中的操作。

本发明实施例通过获取集群在历史预设时间的历史性能数据，根据历史性能数据，确定标杆性能数据，并确定与标杆性能数据对应的标杆容器数量，获取集群在当前时间的当前性能数据以及与当前性能数据对应的当前容器数量，根据标杆性能数据、标杆容器数量、当前性能数据、当前容器数量，确定是否对集群进行扩容，若确定对集群进行扩容，则根据标杆性能数据和当前性能数据，计算扩容容器的数量，根据标杆性能数据和当前性能数据，计算扩容容器的生存时间，根据扩容容器的数量和扩容容器的生存时间，对集群进行扩容，能够随着环境变化，动态确定标杆性能数据，以动态获取集群点的最佳处理能力近似值，从而提高了扩容准确率，无需人为干预，减少了工作量。

本发明实施例提供了一种计算机可读存储介质，所述存储介质存储有至少一可执行指令，该可执行指令在内容传输网络设备上运行时，使得容器管理装置/设备执行上述任意方法实施例中的容器管理方法。可执行指令具体可以用于使得内容传输网络设备执行上述实施例中的容器管理方法中的操作。

本发明实施例通过获取集群在历史预设时间的历史性能数据，根据历史性能数据，确定标杆性能数据，并确定与标杆性能数据对应的标杆容器数量，获取集群在当前时间的当前性能数据以及与当前性能数据对应的当前容器数量，根据标杆性能数据、标杆容器数量、当前性能数据、当前容器数量，确定是否对集群进行扩容，若确定对集群进行扩容，则根据标杆性能数据和当前性能数据，计算扩容容器的数量，根据标杆性能数据和当前性能数据，计算扩容容器的生存时间，根据扩容容器的数量和扩容容器的生存时间，对集群进行扩容，能够随着环境变化，动态确定标杆性能数据，以动态获取集群点的最佳处理能力近似值，从而提高了扩容准确率，无需人为干预，减少了工作量。

本发明实施例提供一种容器管理装置，用于执行上述容器管理方法。

本发明实施例提供了一种计算机程序，所述计算机程序可被处理器调用使计算设备执行上述任意方法实施例中的容器管理方法。

本发明实施例提供了一种计算机程序产品，计算机程序产品包括存储在计算机可读存储介质上的计算机程序，计算机程序包括程序指令，当程序指令在计算机上运行时，使得所述计算机执行上述任意方法实施例中的容器管理方法。

在此提供的算法或显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明实施例也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本发明并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明实施例的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。上述实施例中的步骤，除有特殊说明外，不应理解为对执行顺序的限定。