一种资源配置方法及装置与流程

本申请涉及互联网技术领域，更具体地说，涉及一种资源配置方法及装置。

背景技术：

随着互联网的发展，各种类型的应用也如雨后春笋般出现，为用户提供了多样化的网络业务，如视频业务、游戏业务、网络直播业务等等，极大的丰富了用户的生活。

对于某一业务而言，随着业务的运营以及时间变化，业务所需的资源配置会产生变化。如一款新上线的业务，随着业务发展其在线用户数量会逐渐上升，导致业务所需的资源配置会增加，此时需要重新调整业务所在容器的资源配置。现有技术中，需要人工依据经验决定是否需要对业务所在容器的资源配置进行调整，以及人工确定调整后的目标资源配置。

显然，现有技术人工决定是否调整资源配置以及确定调整后目标资源配置的方式存在准确度低、浪费人工成本的问题。

技术实现要素：

有鉴于此，本申请提供了一种资源配置方法及装置，用于解决现有技术人工决定是否调整资源配置以及确定调整后目标资源配置的方式存在准确度低、浪费人工成本的问题。

为了实现上述目的，现提出的方案如下：

一种资源配置方法，包括：

获取目标业务程序所在容器的资源占用率信息；

根据所述资源占用率信息以及所述目标业务程序的运营策划数据，确定是否需要调整所述目标业务程序所在容器的资源配置；

若是，利用所述资源占用率信息以及所述目标业务程序的运营策划数据，确定所要调整至的目标资源配置；

将所述目标业务程序所在容器的资源配置调整至所述目标资源配置。

一种资源配置装置，包括：

资源占用信息获取单元，用于获取目标业务程序所在容器的资源占用率信息；

调整判断单元，用于根据所述资源占用率信息以及所述目标业务程序的运营策划数据，确定是否需要调整所述目标业务程序所在容器的资源配置；

目标资源配置确定单元，用于在所述调整判断单元的判断结果为是时，利用所述资源占用率信息以及所述目标业务程序的运营策划数据，确定所要调整至的目标资源配置；

资源配置调整单元，用于将所述目标业务程序所在容器的资源配置调整至所述目标资源配置。

本申请实施例提供的资源配置方法，获取目标业务程序所在容器的资源占用率信息；根据所述资源占用率信息以及所述目标业务程序的运营策划数据，确定是否需要调整所述目标业务程序所在容器的资源配置；若是，利用所述资源占用率信息以及所述目标业务程序的运营策划数据，确定所要调整至的目标资源配置；将所述目标业务程序所在容器的资源配置调整至所述目标资源配置。本申请通过监控获取目标业务程序所在容器的资源占用率信息，结合运营策划数据，能够确定是否需要调整目标业务程序所在容器的资源配置，并在确定为是时利用资源占用率信息以及运营策划数据确定所要调整至的目标资源配置，相比于人工依据经验进行判断的方式其准确度得到了很大的提升，且节省了大量的人力成本。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例公开的一种硬件架构示意图；

图2为本申请实施例公开的一种资源配置方法流程图；

图3为本申请示例的客户端与Cgroup交互示意图；

图4为本申请实施例公开的另一种资源配置方法流程图；

图5为本申请示例的一种容器缩容过程示意图；

图6为本申请实施例公开的又一种资源配置方法流程图；

图7为本申请实施例公开的一种资源配置装置结构示意图；

图8为本申请实施例公开的一种控制中心硬件结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在介绍本申请方案之前，首先对业务程序的运行过程进行简单介绍。

业务程序运行在容器中，一个业务程序可以对应一个或多个容器。容器位于容器集群中，一个容器集群包括众多业务程序的容器。集群对应一资源池，为其内各个容器提供资源。一般性的，在生成业务程序之后，即为业务程序所在的各个容器配置资源标准，举例如，为一个业务程序所在的每一个容器均配置10核CPU、50G内存等。在对业务程序所在容器的资源配置进行调整时，即调整业务程序所在每一容器的资源配置，举例如，将某一业务程序所在的每一容器的内存下调50％。

首先介绍本申请方案的实施硬件架构，参见图1，图1为本申请实施例公开的一种硬件架构示意图，如图1所示，包括：

控制中心1和集群性能监控模块2，其中：

集群性能监控设备2用于对集群内各容器进行监控，监控数据可以包括资源占用率信息等。

集群性能监控设备2将监控到的数据发送给控制中心1，由控制中心1根据监控数据以及业务运营策划数据，确定是否需要调整业务的资源配置，并在确定需要调整业务的资源配置时，按照计算出的目标资源配置进行调整。

其中，集群性能监控模块2可以是进程组资源管理系统Cgroup，其能够对集群中各个业务的容器进行实时监控。

控制中心1可以是一台服务器，或者是多台服务器组成的服务器集群。

接下来，本申请从控制中心的角度对本申请的资源配置方法进行介绍，参见图2。如图2所示，该方法包括：

步骤S200、获取目标业务程序所在容器的资源占用率信息；

具体地，随着业务发展以及运营策略的变化，目标业务的在线访问数量会产生变化，导致目标业务程序所在容器的资源占用情况会发生变化。本步骤中，获取目标业务程序所在容器的资源占用信息。具体的获取策略可以是实时获取，也可以是每隔设定时间获取一次。获取的资源占用率信息可以包括目标业务程序所在容器的历史资源占用率信息以及当前时刻的资源占用率信息。

步骤S210、根据所述资源占用率信息以及所述目标业务程序的运营策划数据，确定是否需要调整所述目标业务程序所在容器的资源配置；若是，执行步骤S220；

具体地，目标业务程序的运营策划数据可以包括目标业务程序的近期活动，如在线时间满足条件即赠送业务内虚拟资源等。运行策划数据可以用于预测目标业务程序的在线访问数量。

具体地，可以预先设置资源调整条件，如分别设置资源扩容条件和资源缩容条件，根据目标业务程序所在容器的资源占用率信息以及运营策划数据，确定是否满足设定的资源调整条件，在确定满足时，即认定需要调整所述目标业务程序所在容器的资源配置，否则，认定不需要调整所述目标业务程序所在容器的资源配置。

步骤S220、利用所述资源占用率信息以及所述目标业务程序的运营策划数据，确定所要调整至的目标资源配置；

具体地，本申请可以预先设定资源配置调整策略，如针对不同的资源设置不同的调整策略，进而根据资源调整策略，以及所述资源占用率信息、所述目标业务程序的运营策划数据，确定所要调整至的目标资源配置。

其中可选的，资源配置可以包括CPU占用情况、内存占用情况、磁盘空间占用情况等。

步骤S230、将所述目标业务程序所在容器的资源配置调整至所述目标资源配置。

具体地，本申请可以在不需要目标业务程序暂停服务的情况下，实现在线对容器资源配置进行调整，避免业务停服给用户带来的负面影响。

本申请实施例提供的资源配置方法，获取目标业务程序所在容器的资源占用率信息；根据所述资源占用率信息以及所述目标业务程序的运营策划数据，确定是否需要调整所述目标业务程序所在容器的资源配置；若是，利用所述资源占用率信息以及所述目标业务程序的运营策划数据，确定所要调整至的目标资源配置；将所述目标业务程序所在容器的资源配置调整至所述目标资源配置。本申请通过监控获取目标业务程序所在容器的资源占用率信息，结合运营策划数据，能够确定是否需要调整目标业务程序所在容器的资源配置，并在确定为是时利用资源占用率信息以及运营策划数据确定所要调整至的目标资源配置，相比于人工依据经验进行判断的方式其准确度得到了很大的提升，且节省了大量的人力成本。

可选的，本申请获取目标业务程序所在容器的资源占用率信息的过程，以及调整目标目标业务程序所在容器的资源配置的过程，均可以通过进程组资源管理系统Cgroup实现。

参见图3，图3为本申请示例的客户端与Cgroup交互示意图。

其中，客户端为控制中心1的客户端，Docker API为容器引擎接口，通过Docker API可以访问Cgroup。Cgroup能够实时对集群中各个容器的性能进行监控。

本申请获取目标业务程序所在容器的资源占用率信息的过程可以包括：

客户端调用Docker API访问Cgroup，以读取所述Cgroup对所述目标业务程序所在容器的监控数据，所述监控数据可以包括资源占用率信息。

本申请将所述目标业务程序所在容器的资源配置调整至所述目标资源配置的过程可以包括：

客户端调用Docker API访问Cgroup，以通过所述Cgroup将所述目标业务程序所在容器的资源配置更改为所述目标资源配置。

本申请通过Cgroup实现容器的资源配置在线更改，不影响业务的正常服务。

在本申请的另一个实施例中，介绍另一种资源配置方法，参见图4。

如图4所示，该方法包括：

步骤S400、获取目标业务程序所在容器的资源占用率信息；

步骤S410、根据所述资源占用率信息以及所述目标业务程序的运营策划数据，确定是否满足设定的资源调整条件；若是，执行步骤S420；

具体地，本申请可以预先设定资源调整条件，如设置资源扩容条件和资源缩容条件。在根据所述资源占用率信息以及所述目标业务程序的运营策划数据，确定满足资源扩容条件或资源缩容条件时，确定需要调整目标业务程序所在容器的资源配置，否则，确定不需要调整所述目标业务程序所在容器的资源配置。

可以理解的是，若确定满足资源扩容条件，则需要上调目标业务程序所在容器的资源配置；若确定满足资源缩容条件，则需要下调目标业务程序所在容器的资源配置。

步骤S420、根据所述目标业务程序的运营策划数据，预测所述目标业务程序的在线访问数量；

具体地，通过目标业务程序的运营策划数据可以预测未来一段时间内目标业务程序的在线访问数量。举例如，目标业务程序为一款游戏，游戏运营商策划了一个游戏活动：国庆七天假期内，每天在线5小时以上奖励游戏内道具。则基于该运营策划数据可以预测，国庆七天假期内游戏在线访问数量将会得到提升，并基于游戏当前的在线访问数量，可以预测游戏在国庆七天假期内的在线访问数量。

步骤S430、根据所述目标业务程序当前的在线访问数量、所述目标业务程序当前的资源占用率信息以及预测得到的在线访问数量，计算目标资源配置；

具体地，在预测得到目标业务程序的在线访问数量之后，根据目标业务程序当前的在线访问数量、目标业务程序当前的资源占用率信息以及预测得到的在线访问数量，可以计算出目标资源配置，该目标资源配置为与预测得到的目标业务程序的在线访问数量对应的资源配置量。

以一个简单的例子进行说明：

游戏A当前的在线访问数量为1万，游戏A的容器内存分配大小为5G，且当前内存占用率为50％，结合游戏A的运营策略数据预测得到未来一段时间内游戏A的在线访问数量将会达到2万，为了保证游戏A的容器内存占用率始终不超过50％，则可以将游戏A的容器内存分配大小增加一倍，即目标内存大小为10G。

步骤S440、将所述目标业务程序所在容器的资源配置调整至所述目标资源配置。

可选的，若上述步骤S410中确定满足资源扩容条件，则在步骤S430计算得到目标资源配置之后，该方法还可以进一步增加：

判断所述目标业务程序所在容器所位于的目标容器集群的剩余资源量，是否满足所述目标资源配置，若是，则执行步骤S440。

其中，容器以集群形式存在，一个集群中设置有多个不同业务程序的容器。容器的总资源量是固定的，在确定满足资源扩容条件时，若目标业务程序所在容器所位于的目标容器集群的剩余资源量不满足所述目标资源配置，也即剩余资源量不够目标资源配置，则无法进行扩容。

进一步可选的，在上述实施例的基础上，本申请还可以增加校验机制，即在步骤S440，将所述目标业务程序所在容器的资源配置调整至所述目标资源配置之后，增加如下步骤：

获取所述目标业务程序所在容器的最新资源配置；

利用所述目标资源配置对所述最新资源配置进行校验。

具体地，在对目标业务程序所在容器的资源配置进行调整之后，为了检测是否成功进行调整，本申请可以进一步获取目标业务程序所在容器的最新资源配置，并判断该最新资源配置是否与目标资源配置相同，如果相同，则代表校验通过，否则，代表校验不通过。

通过增加校验机制，保证资源调整顺利执行。

在本申请的又一个实施例中，以容器缩容过程为实例，对方案进行介绍。

参照图5进行说明：

其中，集群A中包含众多的容器，图5中示例的两列容器A1对应目标业务1所在的容器。针对目标业务1的每一容器的CPU占用量、内存MEM占用量、磁盘DISK占用量三个指标进行实时监控。

某一时刻确定目标业务1所在的每一容器的资源配置情况如下：CPU占用X(core颗)、内存MEM占用Y(G)、磁盘DISK占用Z(G)。根据资源配置情况，以及通过目标业务1的运营策划数据预测出的在线访问数量，判断满足资源缩容条件，并计算缩容后的目标资源配置为当前资源配置的一半。调用容器引擎接口Docker API访问进程组资源管理系统Cgroup，以通过所述Cgroup对容器A1的资源配置进行调整，调整后资源配置情况如下：CPU占用X/2(core颗)、内存MEM占用Y/2(G)、磁盘DISK占用Z/2(G)。

为了保证调整成功，可以增加校验过程，即获取调整后容器A1的资源配置，并与目标资源配置进行对比。

按照本实施例的调整方案，在确定目标业务满足资源缩容条件时可以在线调整目标业务所在容器的资源配置，缩容得出的资源可以供该集群A中其它业务使用。

接下来，本申请分别对内存、CPU、磁盘三种资源的调整过程进行介绍。

第一、内存调整策略

在介绍内存调整之前首先介绍Cgroup关于内存的几个统计参数：

(1)、cache缓存：包括了file cache文件缓存和shm共享内存

(2)、anon_LRU：对应Cgroup中的inactive_anon\active_anon，包括了anon匿名页和shm共享内存

(3)、file_LRU：对应Cgroup中的inactive_file\active_file，包括file cache

(4)、rss：包括anon匿名页

(5)、swap交换空间内存

其中，cache+rss＝anon_LRU+file_LRU。

anon+shm+swap这部分内存代表了正在使用，不能被释放。而file cache，如果在内存足够情况下，这部分内存不会释放，但可以被回收，所以降内存只能针对这部分。

基于此，上述步骤S430，根据所述目标业务程序当前的在线访问数量、所述目标业务程序当前的资源占用率信息以及预测得到的在线访问数量，计算目标资源配置的过程可以包括：

根据所述目标业务程序当前的在线访问数量、所述目标业务程序当前的内存占用率信息以及预测得到的在线访问数量，计算扩/缩容比例；

将非活动文档内存inactive_file与所述扩/缩容比例的乘积、活动匿名页内存active_anon、非活动匿名页内存inactive_anon、交换空间内存swap、活动文档内存active_file的和值确定为目标内存大小，即目标内存大小：

target_value＝inactive_anon+active_anon+swap+active_file+inactive_file*X％

其中X％为扩/缩容比例。举例如，X可以是30，对应缩容比例。

第二、CPU调整策略

CPU扩缩容以物理核为单位，CPU缩容过程比较简单，在计算出目标CPU核数之后，将目标业务程序所在容器的CPU占用数量减少至目标CPU核数即可。本实施例中重点介绍CPU扩容过程。

在CPU扩容过程中，需要考虑CPU的NUMA((Non Uniform Memory Access Architecture))分布，尽量保证同一业务程序所在容器占用的CPU在同一NUMA节点。

基于此，在确定满足扩容条件并计算得到目标CPU核数之后，步骤S440，将所述目标业务程序所在容器的资源配置调整至所述目标资源配置的过程可以包括：

S1、根据所述目标CPU核数以及所述目标业务程序所在容器当前占用的CPU核数，计算二者的差值；

S2、获取每个NUMA节点中空闲CPU的下标和个数；

S3、判断所述目标业务程序所在容器当前占用的CPU所在的节点中空闲CPU个数是否不小于所述差值；若是，执行步骤S4；

S4、在所述目标业务程序所在容器当前占用的CPU所在的节点中的空闲CPU中，为所述目标业务程序所在容器增加分配所述差值个数的CPU。

为了便于理解，通过下述实例进行说明：

假设共存在2个node节点，每个node有12个物理核，支持超线程，所以存在24个逻辑核。其中CPU 0-11，24-35在node0，CPU 12-23,36-47在node1。且CPU0-6已经被目标业务程序所在容器占用。

假设目标CPU为12核，目标业务程序所在容器当前占用的CPU核数为6，且该6核CPU分别为CPU0-6。

计算差值12-6＝6，代表还需要额外为目标业务程序所在容器分配6核CPU。

按照上述分配原则，在node0上查找6个空闲CPU：7-11，24。则为目标业务程序增加分配的CPU的下标为：7-11和24。

第三、磁盘调整策略

磁盘的扩缩容相比于CPU和内存要简单，通过系统提供的xfs的project quota功能可动态调整磁盘的限制空间。

这里需要注意的是，如果是判断满足资源缩容条件，则在计算出目标磁盘大小之后可以进一步计算目标业务程序所在容器的当前磁盘占用量与目标磁盘大小的比例，并判断该比例是否超过设定比例阈值，如70％，若判断超过，则可以将目标磁盘大小调大，以保证该比例不超过设定比例阈值。

通过这种机制，可以保证磁盘缩容之后仍存在足够的剩余磁盘空间，以应对目标业务程序突发的磁盘占用。

基于上述各实施例介绍的资源配置过程以及内存、CPU、磁盘调整策略，本申请实施例提供了一种完整的资源配置方法，参见图6，图6为本申请实施例公开的又一种资源配置方法流程图。

如图6所示，该方法包括：

步骤S600、获取目标业务程序在线扩缩容需求；

步骤S610、判断需要扩容或缩容；在确定需要进行缩容时，执行步骤S620-S660，在确定需要进行扩容时，执行步骤S670-S680。

具体地，根据目标业务程序所在容器的资源占用率信息，以及目标业务程序的运营策划数据，判断出需要对目标业务程序所在容器进行扩容或缩容。

步骤S620、按照CPU调整策略计算目标CPU大小；

步骤S630、按照内存调整策略计算目标内存大小；

步骤S640、按照磁盘调整策略计算目标磁盘大小；

其中，步骤S620-S640的执行顺序并不限定，可以相互颠倒或同时执行。具体调整策略可以参照上文相关介绍。

步骤S650、执行在线缩容；

具体地，按照计算出的目标CPU大小、目标内存大小、目标磁盘大小，对目标业务程序所在容器的资源配置进行缩容调整。

步骤S660、结果校验；

在缩容调整之后进行结果校验，校验过程可以参照上文相关介绍。

步骤S670、判断集群剩余资源是否足够，若是，执行步骤S680；

具体地，在执行该步骤时也需要先计算出扩容后的目标CPU大小、目标内存大小、目标磁盘大小，并判断集群剩余资源是否支持扩容需求。

步骤S680、执行在线扩容，并进一步执行步骤S660。

下面对本申请实施例提供的资源配置装置进行描述，下文描述的资源配置装置与上文描述的资源配置方法可相互对应参照。

参见图7，图7为本申请实施例公开的一种资源配置装置结构示意图。

如图7所示，该装置包括：

资源占用信息获取单元11，用于获取目标业务程序所在容器的资源占用率信息；

调整判断单元12，用于根据所述资源占用率信息以及所述目标业务程序的运营策划数据，确定是否需要调整所述目标业务程序所在容器的资源配置；

目标资源配置确定单元13，用于在所述调整判断单元的判断结果为是时，利用所述资源占用率信息以及所述目标业务程序的运营策划数据，确定所要调整至的目标资源配置；

资源配置调整单元14，用于将所述目标业务程序所在容器的资源配置调整至所述目标资源配置。

本申请通过监控获取目标业务程序所在容器的资源占用率信息，结合运营策划数据，能够确定是否需要调整目标业务程序所在容器的资源配置，并在确定为是时利用资源占用率信息以及运营策划数据确定所要调整至的目标资源配置，相比于人工依据经验进行判断的方式其准确度得到了很大的提升，且节省了大量的人力成本。

可选的，所述资源占用信息获取单元具体可以用于，调用容器引擎接口Docker API访问进程组资源管理系统Cgroup，以读取所述Cgroup对所述目标业务程序所在容器的监控数据，所述监控数据包括资源占用率信息。

可选的，所述资源配置调整单元具体可以用于，调用容器引擎接口Docker API访问进程组资源管理系统Cgroup，以通过所述Cgroup将所述目标业务程序所在容器的资源配置更改为所述目标资源配置。

可选的，所述调整判断单元可以包括：

条件判断单元，用于根据所述资源占用率信息以及所述目标业务程序的运营策划数据，确定是否满足设定的资源调整条件；

判断结果确定单元，用于在所述条件判断单元判断为是时，确定需要调整所述目标业务程序所在容器的资源配置，判断为否时，确定不需要调整所述目标业务程序所在容器的资源配置。

可选的，所述资源调整条件可以包括资源扩容条件和资源缩容条件，该装置还可以包括：

集群剩余资源量判断单元，用于在所述条件判断单元确定满足所述资源扩容条件时，判断所述目标业务程序所在容器所位于的目标容器集群的剩余资源量，是否满足所述目标资源配置，并在判断为是时，执行所述资源配置调整单元。

可选的，所述目标资源配置可以包括目标CPU核数，该目标CPU核数为在确定满足资源扩容条件下确定的。基于此，所述资源配置调整单元可以包括：

差值计算单元，用于根据所述目标CPU核数以及所述目标业务程序所在容器当前占用的CPU核数，计算二者的差值；

空闲CPU确定单元，用于获取每个NUMA节点中空闲CPU的下标和个数；

差值判断单元，用于判断所述目标业务程序所在容器当前占用的CPU所在的节点中空闲CPU个数是否不小于所述差值；

CPU分配单元，用于在所述差值判断单元判断为是时，在所述目标业务程序所在容器当前占用的CPU所在的节点中的空闲CPU中，为所述目标业务程序所在容器增加分配所述差值个数的CPU。

可选的，所述目标资源配置确定单元可以包括：

在线访问数量预测单元，用于根据所述目标业务程序的运营策划数据，预测所述目标业务程序的在线访问数量；

目标资源配置计算单元，用于根据所述目标业务程序当前的在线访问数量、所述目标业务程序当前的资源占用率信息以及预测得到的在线访问数量，计算目标资源配置。

可选的，所述目标业务程序所在容器的资源配置可以包括内存配置。基于此，所述目标资源配置计算单元可以包括：

比例计算单元，用于根据所述目标业务程序当前的在线访问数量、所述目标业务程序当前的内存占用率信息以及预测得到的在线访问数量，计算扩/缩容比例；

目标内存大小计算单元，用于将非活动文档内存与所述扩/缩容比例的乘积、活动和非活动匿名页内存、交换空间内存、活动文档内存的和值确定为目标内存大小。

可选的，本申请的装置还可以包括：

校验单元，用于在所述资源配置调整单元之后，获取所述目标业务程序所在容器的最新资源配置；利用所述目标资源配置对所述最新资源配置进行校验。

本申请实施例提供的资源配置装置应用于控制中心，该控制中心的硬件结构可以是电脑、笔记本等处理设备，参见图8，图8为本申请实施例公开的一种控制中心硬件结构示意图。如图8所示，该控制中心可以包括：

处理器1，通信接口2，存储器3，通信总线4，和显示屏5；

其中处理器1、通信接口2、存储器3和显示屏5通过通信总线4完成相互间的通信；

可选的，通信接口2可以为通信模块的接口，如GSM模块的接口；

处理器1，用于执行程序；

存储器3，用于存放程序；

程序可以包括程序代码，所述程序代码包括处理器的操作指令。

处理器1可能是一个中央处理器CPU，或者是特定集成电路ASIC(Application Specific Integrated Circuit)，或者是被配置成实施本申请实施例的一个或多个集成电路。

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

其中，程序具体可以用于：

获取目标业务程序所在容器的资源占用率信息；

根据所述资源占用率信息以及所述目标业务程序的运营策划数据，确定是否需要调整所述目标业务程序所在容器的资源配置；

若是，利用所述资源占用率信息以及所述目标业务程序的运营策划数据，确定所要调整至的目标资源配置；

将所述目标业务程序所在容器的资源配置调整至所述目标资源配置。

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

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。