CN113568706A - 针对业务的容器调整方法、装置、电子设备和存储介质 - Google Patents

Abstract

本公开提供了一种针对业务的容器调整方法，涉及计算机领域，尤其涉及扩缩容领域。具体实现方案为：根据业务数据的时效性指标，计算针对业务的原有容器的扩容需求；根据扩容需求，调整原有容器内执行的进程数，得到第一目标容器；响应于扩容需求符合第一预设条件，新增至少一个第一目标容器，得到多个第二目标容器；以及响应于扩容需求符合第二预设条件，调整每个第二目标容器内执行的进程数。本公开还提供了一种针对业务的容器调整装置、电子设备和存储介质。

Description

针对业务的容器调整方法、装置、电子设备和存储介质

技术领域

本公开涉及计算机技术领域，尤其涉及扩缩容技术。更具体地，本公开提供了一种针对业务的容器调整方法、装置、电子设备和存储介质。

背景技术

目前，内容业务需求快速增长，例如新闻、天气、商品等内容数据高速迭代，内容数据生效的时效性要求越来越高。因此，针对业务的扩缩容的时效性要求也越来越高。

发明内容

本公开提供了一种针对业务的容器调整方法、装置、电子设备以及存储介质。

根据第一方面，提供了一种针对业务的容器调整方法，该方法包括：根据业务数据的时效性指标，计算针对业务的原有容器的扩容需求；根据扩容需求，调整原有容器内执行的进程数，得到第一目标容器；响应于扩容需求符合第一预设条件，新增至少一个第一目标容器，得到多个第二目标容器；以及响应于扩容需求符合第二预设条件，调整每个第二目标容器内执行的进程数。

根据第二方面，提供了一种针对业务的容器调整装置，该装置包括：计算模块，用于根据业务数据的时效性指标，计算针对业务的原有容器的扩容需求；第一调整模块，用于根据扩容需求，调整原有容器内执行的进程数，得到第一目标容器；新增模块，用于响应于扩容需求符合第一预设条件，新增至少一个第一目标容器，得到多个第二目标容器；以及第二调整模块，用于响应于扩容需求符合第二预设条件，调整每个第二目标容器内执行的进程数。

根据第三方面，提供了一种电子设备，包括：至少一个处理器；以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行根据本公开提供的方法。

根据第四方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，该计算机指令用于使计算机执行根据本公开提供的方法。

根据第五方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据本公开提供的方法。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1是根据本公开的一个实施例的可以应用针对业务的容器调整方法和装置的示例性业务框架示意图；

图2是根据本公开的一个实施例的针对业务的容器调整方法的流程图；

图3是根据本公开的一个实施例针对业务的容器调整方法的示意图；

图4是根据本公开的一个实施例的计算扩容需求的方法的流程图；

图5是根据本公开的另一个实施例的可以应用针对业务的容器调整方法和装置的示例性业务框架示意图；

图6是根据本公开的一个实施例的针对业务的容器调整装置的框图；以及

图7是根据本公开的一个实施例的针对业务的容器调整方法的电子设备的框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

由于计算机程序的部署从物理机器逐渐转到虚拟化部署，因此，针对业务的应用程序通常作为微服务进程封装在虚拟容器内。

目前搜索引擎、推荐引擎的内容数据，例如新闻、天气、商品等内容数据，在分发的过程中，都需要大量复杂的策略内容计算，从而不可避免的使用为在线计算提供充足的容量以便实现以策略计算为驱动的内容分发。

随着内容业务需求的快速增长，传统的分布式内容处理或者MR(Map Reduce，映射-归纳)类型的任务处理已经不能完全满足快速发展并且复杂多变的业务需求，针对于数据生效的实时性和可控制性的要求越来越高。一方面，业务需要对数据进行流式的快速生效，新到来的数据需要很高的实时性，例如从原始数据产生到最终数据生效需要在10秒以内，另一方面，策略越来越复杂，变更频繁，当其中一部分计算结果不符合预期的时候，需要对这部分数据进行数据调整后，重新进行数据计算。因此，为适用在复杂业务高速迭代模式下，业务数据快速迭代，数据高效生效的场景，针对业务的扩缩容的时效性要求也越来越高。

目前普遍采取根据业务数据堆积量触发新增容器来进行扩容的方式。但是新增容器需要寻找合适的机器分配容器以及运行环境的初始化(包括代码库下载)的过程，在一般离线环境中，由于离线机器磁盘IO不稳定、网络有抖动等情况，上述过程一般需要20分钟左右的时间才能完成，延迟较高。

为了降低延迟，可以预先将容器的镜像下载下来，以便在有业务需要扩容时可以直接启动容器，省去下载数据包的过程。也可以预先完成容器的初始化，并为可能需要扩容的业务分配好已完成初始化的容器，哪个业务需要扩容，则在对应的容器中启动业务。但是，这两种方式都需要深入到基础环境容器层的优化，涉及到容器层分发、下载等一系列过程，仍不可避免地产生延迟。

本公开的技术方案中，所涉及的用户个人信息的获取，存储和应用等，均符合相关法律法规的规定，且不违背公序良俗。

图1是根据本公开一个实施例的可以应用针对业务的容器调整方法和装置的示例性业务框架示意图。需要注意的是，图1所示仅为可以应用本公开实施例的业务***架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、***、环境或场景。

如图1所示，根据该实施例的业务框架100可以包括数据接入层110和数据生效层120。数据接入层110用于将容器外部的业务数据流接入到容器内。数据生效层120包括数据处理模块121和数据分发模块122。数据处理模块121可以包括用于对业务数据进行处理的业务算子，具体用于从数据接入层110获取数据流，并对数据流进行参数解析、数据过滤、策略计算、数据融合等一系列处理后，产生业务处理结果。数据分发模块122用于通过预设的接口函数将业务处理结果分发给用户。

可以理解的是，针对业务的容器内所执行的进程是基于上述业务框架100的。针对业务的容器可以有多个，每个容器内所执行的进程均基于上述业务框架100进行业务数据流的处理，实现业务数据的生效。

图2是根据本公开的一个实施例的针对业务的容器调整方法的流程图。

如图2所示，该针对业务的容器调整方法200可以包括操作S210～操作S240。

在操作S210，根据业务数据的时效性指标，计算针对业务的原有容器的扩容需求。

例如，业务可以是新闻、天气或商品等内容数据的发布。可以将针对上述业务的应用程序改造成微服务进程封装在虚拟容器内，实现计算机程序的虚拟化部署。针对上述每个业务，所部署的容器可以称为原有容器，原有容器可以有一个或多个。

业务数据的时效性指标可以包括针对业务的原有容器处理该业务的数据流所需要的时长。例如，原有容器处理该业务的数据流所需要的时长可以是业务数据从接入到生效的时长，可以称为生效时长或数据更新时长。

内容业务的时效性要求较高，如果业务数据突然出现流量高峰，原有容器内的进程处理压力变大，则业务数据的实际生效时长与业务***所期望的生效时长之间会存在一定差异，当差异大于或等于阈值(例如，50％)时，则可以触发扩容计算。例如，业务***所期望的生效时长是在3分钟以内，而当前业务数据的实际生效时长达到了6分钟，则确定需要扩容，触发扩容计算，生成扩容需求。

在操作S220，根据扩容需求，调整原有容器内执行的进程数，得到第一目标容器。

例如，原有容器内可以封装有一个进程来进行业务处理。响应于扩容需求，可以为原有容器分配更多的资源来支持多个(例如10个)进程进行业务处理，同时将原有容器的资源调整为支持10进程的大小。例如，将原有容器的CPU和内存资源调整为支持10进程的大小。这一过程可以称为原有容器的纵向扩容，纵向扩容后的原有容器可以称为第一目标容器。

可以理解，第一目标容器内支持多个(例如10个)进程进行业务处理，则第一目标容器处理业务数据的速度相比于原有容器处理业务数据的速度成倍(例如10倍)增长，从而可以缩短业务数据的生效时长，避免业务数据堆积，达到扩容效果。

根据本公开的实施例，相比于通过新增容器的横向扩容方式，增加原有容器内的进程数的纵向扩容方式能够省去容器部署和启动的时间，时效性更高。对于内容分发业务等时效性要求较高的场景，能够实现数据高效生效，提高用户体验。

在操作S230，响应于扩容需求符合第一预设条件，新增至少一个第一目标容器，得到多个第二目标容器。

例如，上述对原有容器进行纵向扩容的过程可以称为第一阶段的扩容。第一预设条件可以包括：第一阶段的扩容后，扩容需求仍在持续且持续了较长时间(例如超过了10分钟还没有结束)；或者，第一阶段的扩容后，扩容需求没有被满足。例如，响应于扩容需求，原有容器应将进程数调整为10个，然而由于为该容器分配的资源不能支持10个进程，仅能支持7个或5个进程的情况，则第一阶段的扩容需求没有被满足。

如果符合上述第一预设条件，可以进行第二阶段的扩容。例如，针对第一阶段扩容后得到的第一目标容器，新增至少一个该第一目标容器，得到多个第二目标容器。例如，第一目标容器内执行的进程数为10，新增9个第一目标容器，得到10个第一目标容器作为第二目标容器，该10个第二目标容器中的每个第二目标容器内执行的进程数均为10。

如果不符合上述第一预设条件，例如，第一阶段的扩容后，业务数据流量高峰退去，又恢复到高峰前的流量水平，扩容需求消失，则不进行第二阶段的扩容。

在操作S240，响应于扩容需求符合第二预设条件，调整每个第二目标容器内执行的进程数。

例如，第二预设条件可以包括在第二阶段扩容完成后(例如得到10个第二目标容器之后)，扩容需求仍在维持但是没有上涨，如波动范围小于5％。

如果符合上述第二预设条件，可以将每个第二目标容器内的进程数调整回原来的个数。例如，将每个第二目标容器内的进程数10个调整为1个，同时将每个第二目标容器的容量(CPU和内存资源)调整回支持1个进程的大小。这个过程可以称为第二阶段的缩容。

如果不符合上述第二预设条件，可以根据扩容需求的实际上涨情况或下降情况来计算每个第二目标容器需要调整的进程数。

可以理解，每个第二目标容器内的进程数调整回原来的1个，可以避免资源利用率过高，造成容量超用风险，且在第二预设条件下，扩容需求没有上涨，每个第二目标容器执行1个进程也能够满足扩容需求。

根据本公开的实施例，根据业务数据的时效性指标触发扩容需求，并根据扩容需求优先调整原有容器内执行的进程数，相比于直接增加新容器的方式省去新容器的部署和启动时间，时效性更好。

图3是根据本公开的一个实施例的针对业务的容器调整方法的示意图。

如图3所示，例如，针对预设业务，该业务的消息队列中有一个两跳的数据流A→B，针对该预设业务部署有原有容器310和原有容器320，原有容器310和原有容器320内各有1个进程分别用于处理数据流A和数据流B。原有容器310和原有容器320处理业务数据的速度(或访问业务数据的速度)均是10QPS。

根据业务数据的时效性指标，确定该预设业务需要扩容，并且计算出了具体的扩容需求。例如，扩容需求为扩容后的原有容器310和原有容器320处理业务数据的速度需要达到100QPS(即处理流量达到100QPS)。响应于扩容需求(处理流量达到100QPS)，可以进行第一阶段的扩容。

第一阶段的扩容可以将原有容器310的CPU和内存资源调整为满足10进程的大小，并将原有容器310内的进程数调整为10，得到第一目标容器311，第一目标容器311处理业务数据的速度为10*10＝100QPS。并且，将原有容器320的CPU和内存资源调整为满足10个进程的大小，并将原有容器320内的进程数调整为10，得到第一目标容器321，第一目标容器321处理业务数据的速度为10*10＝100QPS。

此时，如果原有容器310和原有容器320所在机器的资源充足，均完成了10进程的扩容，满足了扩容需求，则判断扩容需求是否持续。例如，如果业务数据流量高峰仅持续了较短时长(例如5分钟)，便迅速下降了，业务数据流量恢复成初始值(10QPS)，扩容需求消失，则可以进行第一阶段的缩容。

第一阶段的缩容可以将第一目标容器311和第一目标容器321的资源参数和进程数调整回初始值。例如，将第一目标容器311和第一目标容器321的容量调整回满足1进程的大小，并将第一目标容器311和第一目标容器321内的进程数调整回1。能够避免资源利用率过高，造成容量超用风险。

如果扩容需求(处理流量达到100QPS)满足第一预设条件，即在第一阶段扩容后，扩容需求仍在持续且持续了较长时间(例如超过了10分钟还没有结束)，或者第一阶段的扩容没有满足扩容需求，例如原有容器310和原有容器320中的至少之一没有被分配足够的资源来支持10进程，仅扩容出了7进程或5进程的情况。则开始进入第二阶段的扩容。

第二阶段的扩容可以将第一目标容器311的数量增至10个，得到的10个第二目标容器(分别是第二目标容器312-1、第二目标容器312-2......第二目标容器312-10)，第二目标容器312-1、第二目标容器312-2......第二目标容器312-10中的每个的容量和进程数与第一目标容器311相同。并且，将第二目标容器321的数量增至10个，得到的10个第二目标容器(分别是第二目标容器322-1、第二目标容器322-2......第二目标容器322-10)，第二目标容器322-1、第二目标容器322-2......第二目标容器322-10中的每个的容量和进程数与第一目标容器321相同。

如果扩容需求(处理流量达到100QPS)满足第二预设条件，即在第二阶段扩容完成后，扩容需求仍在维持但是没有上涨，如波动范围小于5％。则可以进行第二阶段的缩容。

第二阶段的缩容可以将第二目标容器312-1、第二目标容器312-2......第二目标容器312-10中的每个的容量调整回支持1进程的大小，进程数调整回1，得到10个第三目标容器(分别是第三目标容器313-1、第二目标容器313-2......第二目标容器313-10)。并且，将第二目标容器322-1、第二目标容器322-2......第二目标容器322-10中的每个的容量调整回支持1进程的大小，进程数调整回1，得到10个第三目标容器(分别是第三目标容器323-1、第三目标容器323-2......第三目标容器323-10)。

根据本公开的实施例，通过多阶段的扩缩容不仅能够满足时效性要求，并且能够避免资源利用率过高，造成容量超用风险。

图4是根据本公开的一个实施例的计算扩容需求的方法的流程图。

如图4所示，该方法包括操作S401～S403。

在操作S401，获取针对业务的原有容器处理业务数据的实际时效性信息和预期时效性信息。

例如，可以通过监控原有容器的运行情况获取原有容器处理业务数据的实际时效性信息，实际时效性信息可以包括原有容器处理业务数据的实际时长，该实际时长可以是业务数据从接入到生效的时长，可以称为生效时长或数据更新时长。

例如，可以通过获取用户平台的配置信息得到用户期望的预期时效性信息，即原有容器处理业务数据的预期时长。

在操作S402，根据实际时效性信息和预期时效性信息，判断是否需要扩容，如果是，则执行操作S403。否则返回操作S401。

例如，实际时效性信息和预期时效性信息之间的差异大于或等于预设阈值(例如，50％)，则执行操作S403。否则返回操作S401继续获取时效性信息。

在操作S403，根据原有容器处理业务数据的原有速度以及业务数据的下发速度，计算扩容需求。

例如，原有容器处理业务数据的原有速度是10QPS，业务数据的下发速度是20QPS，数据的初始堆积量是2000。扩容需要时间，例如，扩容时长为5分钟，预期10分钟之内完全消费堆积，则在10分钟之内数据的预估堆积量是20*10*60＝12000，加上初始堆积量2000，则10分钟之内的总体堆积量是14000。由于预计在10分钟之内完全消费堆积，则在10分钟之内消费的数据量应等于10分钟之内的总体堆积量。

如果扩容完成后处理业务数据的预期速度是X，则在10分钟之内消费的数据量等于前5分钟按照原有速度的消费的数据量(即10*5*60＝3000)加上后5分钟按预期速度消费的数据量(即X*5*60＝300X)。则可以得到等式3000+300X＝14000，则求得扩容完成后处理业务数据的预期速度X约为36QPS，则扩容需求可以是扩容完成后处理业务数据的预期速度达到36QPS。

由于是预期速度约是原有速度的4倍，可以将原有容器内执行的进程数由1个调整为4，则能够满足扩容需求。

根据本公开的实施例，根据时效性指标触发扩容需求，相比于仅根据业务数据堆积情况触发扩容需求的方式，能够更直观地反映出业务所需要的时效性。

图5是根据本公开的另一个实施例的可以应用针对业务的容器调整方法和装置的示例性业务框架示意图。

如图5所示，该业务框架500包括数据接入层510、中间处理层520以及数据生效层530。

数据接入层510用于将容器外部的业务数据流接入到容器内。

中间处理层520包括伴生服务模块521和多进程调用模块522。多进程调用模块522用于通过预设的调用方式(例如RPC调用方式)将业务请求分发给容器内的多个进程。为便于理解，可以将用于分发业务请求的进程称为主进程，将容器内执行的多个进程称为子进程，则通过RPC方式来进行多进程调用，具体是通过主进程将业务请求分发给多个子进程，并且RPC方式可以根据多个子进程的负荷量，有选择地将业务请求优先发送给低负荷的进程。伴生服务模块521可以包括进程管理子模块、服务管理子模块、预处理子模块和优化模。进程管理子模块用于对容器内的多个子进程进行启动、维护和销毁等进行管理。服务管理子模块用于配置用户参数(例如访问参数)、监控参数变化等。预处理子模块用于进行业务方与用户方之间的协议转化。优化子模块用于通过批量获取的方式获取数据流，以及并发处理数据流。

数据生效层530包括多个进程处理子层，分别对应容器内执行的多个子进程。每个进程处理子层包括数据处理模块531和数据分发模块532。数据处理模块531用于通过RPC调度方式接收主进程发送过来的服务请求，并对服务请求中的数据流进行参数解析、数据校验、策略计算、数据融合等处理，产生业务处理结果。数据分发模块532用于通过预设的接口函数将业务处理结果分发给用户。

根据本公开的实施例，通过RPC调度方式进行多进程调用，实现容器内多个进程进行业务处理，能够实现容器的纵向扩容，扩容时效性更好。

图6是根据本公开的一个实施例的针对业务的容器调整装置的框图。

如图6所示，该针对业务的容器调整装置600可以包括计算模块601、第一调整模块602、新增模块603和第二调整模块604。

计算模块601用于根据业务数据的时效性指标，计算针对业务的原有容器的扩容需求。

第一调整模块602用于根据扩容需求，调整原有容器内执行的进程数，得到第一目标容器。

新增模块603用于响应于扩容需求符合第一预设条件，新增至少一个第一目标容器，得到多个第二目标容器。

第二调整模块604用于响应于扩容需求符合第二预设条件，调整每个第二目标容器内执行的进程数。

根据本公开的实施例，计算模块601包括第一确定模块和第二确定模块。

第一确定模块用于根据原有容器处理业务数据的实际时长与预期时长之间的差异，确定是否需要扩容。

第二确定模块用于在确定需要扩容的情况下，根据原有容器处理业务数据的原有速度以及业务数据的下发速度，确定第一目标容器处理业务数据的预期速度，作为扩容需求。

根据本公开的实施例，第一调整模块用于根据原有速度与预期速度之间的差异，将原有容器内执行的进程数由第一数量调整为第二数量。

根据本公开的实施例，第二预设条件包括在得到多个第二目标容器之后，扩容需求的波动维持在预设范围；第二调整模块用于将每个第二目标容器内执行的进程数由第二数量调整回第一数量。

根据本公开的实施例，第一调整模块还用于根据调整的原有容器内执行的进程数，调整原有容器的容量，得到第一目标容器。

根据本公开的实施例，第一调整模块还用于根据调整的每个第二目标容器内执行的进程数，调整每个第二目标容器的容量。

根据本公开的实施例，第一预设条件包括：在得到第一目标容器之后，扩容需求仍在持续且持续时长大于预设阈值，或者扩容需求没有被满足。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

图7示出了可以用来实施本公开的实施例的示例电子设备700的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图7所示，设备700包括计算单元701，其可以根据存储在只读存储器(ROM)702中的计算机程序或者从存储单元708加载到随机访问存储器(RAM)703中的计算机程序，来执行各种适当的动作和处理。在RAM 703中，还可存储设备700操作所需的各种程序和数据。计算单元701、ROM 702以及RAM 703通过总线704彼此相连。输入/输出(I/O)接口705也连接至总线704。

设备700中的多个部件连接至I/O接口705，包括：输入单元706，例如键盘、鼠标等；输出单元707，例如各种类型的显示器、扬声器等；存储单元708，例如磁盘、光盘等；以及通信单元709，例如网卡、调制解调器、无线通信收发机等。通信单元709允许设备700通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元701可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元701的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元701执行上文所描述的各个方法和处理，例如针对业务的容器调整方法。例如，在一些实施例中，针对业务的容器调整方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元708。在一些实施例中，计算机程序的部分或者全部可以经由ROM 702和/或通信单元709而被载入和/或安装到设备700上。当计算机程序加载到RAM 703并由计算单元701执行时，可以执行上文描述的针对业务的容器调整方法的一个或多个步骤。备选地，在其他实施例中，计算单元701可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行针对业务的容器调整方法。

本文中以上描述的***和技术的各种实施方式可以在数字电子电路***、集成电路***、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上***的***(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程***上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储***、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储***、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行***、装置或设备使用或与指令执行***、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体***、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的***和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的***和技术实施在包括后台部件的计算***(例如，作为数据服务器)、或者包括中间件部件的计算***(例如，应用服务器)、或者包括前端部件的计算***(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的***和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算***中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将***的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机***可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (17)

1.一种针对业务的容器调整方法，包括：

根据业务数据的时效性指标，计算针对所述业务的原有容器的扩容需求；

根据所述扩容需求，调整所述原有容器内执行的进程数，得到第一目标容器；

响应于所述扩容需求符合第一预设条件，新增至少一个所述第一目标容器，得到多个第二目标容器；以及

响应于所述扩容需求符合第二预设条件，调整每个第二目标容器内执行的进程数。

2.根据权利要求1所述的方法，其中，所述根据业务数据的时效性指标，计算针对所述业务的原有容器的扩容需求包括：

根据所述原有容器处理所述业务数据的实际时长与预期时长之间的差异，确定是否需要扩容；以及

在确定需要扩容的情况下，根据所述原有容器处理所述业务数据的原有速度以及所述业务数据的下发速度，确定所述第一目标容器处理所述业务数据的预期速度，作为所述扩容需求。

3.根据权利要求2所述的方法，其中，所述根据所述扩容需求，调整所述原有容器内执行的进程数包括：

根据所述原有速度与所述预期速度之间的差异，将所述原有容器内执行的进程数由第一数量调整为第二数量。

4.根据权利要求3所述的方法，其中，所述第二预设条件包括在得到多个第二目标容器之后，所述扩容需求的波动维持在预设范围；所述调整每个第二目标容器内执行的进程数包括：

将每个所述第二目标容器内执行的进程数由所述第二数量调整回所述第一数量。

5.根据权利要求1所述的方法，还包括：

根据调整的所述原有容器内执行的进程数，调整所述原有容器的容量，得到所述第一目标容器。

6.根据权利要求1所述的方法，还包括：

根据调整的所述每个第二目标容器内执行的进程数，调整所述每个第二目标容器的容量。

7.根据权利要求1所述的方法，其中，所述第一预设条件包括：在得到所述第一目标容器之后，所述扩容需求仍在持续且持续时长大于预设阈值，或者所述扩容需求没有被满足。

8.一种针对业务的容器调整装置，包括：

计算模块，用于根据业务数据的时效性指标，计算针对所述业务的原有容器的扩容需求；

第一调整模块，用于根据所述扩容需求，调整所述原有容器内执行的进程数，得到第一目标容器；

新增模块，用于响应于所述扩容需求符合第一预设条件，新增至少一个所述第一目标容器，得到多个第二目标容器；以及

第二调整模块，用于响应于所述扩容需求符合第二预设条件，调整每个第二目标容器内执行的进程数。

9.根据权利要求8所述的装置，其中，所述计算模块包括：

第一确定模块，用于根据所述原有容器处理所述业务数据的实际时长与预期时长之间的差异，确定是否需要扩容；以及

第二确定模块，用于在确定需要扩容的情况下，根据所述原有容器处理所述业务数据的原有速度以及所述业务数据的下发速度，确定所述第一目标容器处理所述业务数据的预期速度，作为所述扩容需求。

10.根据权利要求9所述的装置，其中，所述第一调整模块用于根据所述原有速度与所述预期速度之间的差异，将所述原有容器内执行的进程数由第一数量调整为第二数量。

11.根据权利要求10所述的装置，其中，所述第二预设条件包括在得到多个第二目标容器之后，所述扩容需求的波动维持在预设范围；所述第二调整模块用于将每个所述第二目标容器内执行的进程数由所述第二数量调整回所述第一数量。

12.根据权利要求8所述的装置，所述第一调整模块还用于根据调整的所述原有容器内执行的进程数，调整所述原有容器的容量，得到所述第一目标容器。

13.根据权利要求8所述的装置，所述第二调整模块还用于根据调整的所述每个第二目标容器内执行的进程数，调整所述每个第二目标容器的容量。

14.根据权利要求8所述的装置，其中，所述第一预设条件包括：在得到所述第一目标容器之后，所述扩容需求仍在持续且持续时长大于预设阈值，或者所述扩容需求没有被满足。

15.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1至7中任一项所述的方法。

16.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据权利要求1至7中任一项所述的方法。

17.一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据权利要求1至7中任一项所述的方法。

Images