CN114416355A - 资源调度方法、装置、系统、电子设备及介质 - Google Patents

Abstract

本申请实施例提供了资源调度方法、装置、系统、电子设备及介质，旨在提高对服务器集群中资源的利用率，所述方法包括：在集群中的每个节点上创建多个资源池，其中，不同的资源池对应不同的业务属性，同一资源池用于响应属于同一业务属性的至少一种业务；基于每个资源池所对应的至少一种业务各自的实时负载，确定每个资源池对应的资源上限；其中，每个资源池对应的资源上限小于等于该资源池所对应的至少一种业务各自所需的最大资源之和；基于每个所述资源池的资源上限，为每个所述资源池配置所在节点上的可调用资源；其中，每个资源池对应的至少一种业务共享该资源池所被配置的可调用资源。

Description

资源调度方法、装置、系统、电子设备及介质

技术领域

本申请涉及服务器技术领域，特别是涉及一种资源调度方法、装置、电子设备及介质。

背景技术

随着计算机技术的发展，诞生了云服务，云服务是指基于互联网的相关服务的增加、使用和交互模式，通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源。其中，对云服务提供支持的是服务器，一般而言，对于业务量较大的云服务，是通过服务器集群实现支持的，服务器集群是由数量较大的服务器组成的集群，一个服务器可以看作是服务器集群中的一个节点。

其中，服务器属于计算机硬件资源，要创建一个服务器集群需要投入较高的成本，且服务器的更新换代也较为频繁，一般3～5年就需要购置新服务器，因此一般是尽量以少量的服务器提供云服务。在此种背景下，业界要求服务器集群中的服务器资源可以被充分利用，以降低购置成本、提高云服务质量。

相关技术中，是通过资源超售、动态调度的方式调度服务器资源，其中，资源超售是指按照一定的超售比放大节点的可用资源总量，以实现一个节点可以部署更多的业务，但是此种方式对服务的负载的监控准确度要求较高，超售比一旦过大，导致节点资源负载高，降低服务质量。其中，动态调度是根据监控到的节点实际负载确定其可部署的服务数，对低负载节点部署更多的服务来提高利用率。但是，此种方式对节点实际负载的监控精度也有很高的要求，且动态调度只能做到单节点的资源峰值利用率高，很难提高服务器集群的整体资源利用率。

因此，目前的资源调度方案存在对监控精确度要求高、资源利用不合理的问题。

发明内容

为了解决上述问题，本申请提供了一种资源调度方法、装置、电子设备及介质，旨在提高资源利用的合理性，并降低对监控精确度的要求。

本公开实施例的第一方面，提供了一种资源调度方法，所述方法包括：

在集群中的每个节点上创建多个资源池，其中，不同的资源池对应不同的业务属性，同一资源池用于响应属于同一业务属性的至少一种业务；

基于每个资源池所对应的至少一种业务各自的实时负载，确定每个资源池对应的资源上限；其中，每个资源池对应的资源上限小于等于该资源池所对应的至少一种业务各自所需的最大资源之和；

基于每个所述资源池的资源上限，为每个所述资源池配置所在节点上的可调用资源；其中，每个资源池对应的至少一种业务共享该资源池所被配置的可调用资源。

可选地，所述方法包括：

对到来的业务请求，基于所述业务请求所属的业务属性，从各个资源池中确定与所述业务请求对应的目标资源池；

从所述目标资源池被配置的可调用资源中调用部分或全部资源，以响应所述业务请求；

在响应所述业务请求结束时，将被调用的所述部分或全部资源释放。

可选地，所述方法还包括：

对所述集群中每个节点上每个资源池的资源利用率进行监控；其中，所述资源利用率表征资源池的可调用资源被使用的程度；

基于监控到的每个节点上每个资源池的资源利用率，确定每个节点上每个资源池的剩余可用资源，和/或，确定每个节点的总剩余可用资源；

所述基于所述业务请求的业务属性，从各个资源池中确定与所述业务请求对应的目标资源池，包括：

基于每个节点上每个资源池的剩余可用资源，和/或每个节点的总剩余可用资源，从所述集群中确定所述目标资源池。

可选地，所述业务属性为业务级别，所述业务级别用于表征业务的优先级；所述方法还包括：

对所述集群中每个节点上每个资源池的资源利用率进行监控；

在存在所述资源利用率达到第一预设资源利用率的过载资源池，且所述过载资源池不为业务级别最低的资源池的情况下，调用业务级别低于所述过载资源池的低级别资源池所配置的可调用资源，以响应到达所述过载资源池的业务请求。

可选地，调用业务级别低于所述过载资源池的低级别资源池所配置的可调用资源，以响应到达所述过载资源池的业务请求，包括：

确定业务级别低于所述过载资源池的低级别资源池的资源利用率；

基于所述低级别资源池的资源利用率，从所述低级别资源池中确定待资源占用的资源池；

调用所述待资源占用的资源池所配置的可调用资源，响应到达所述过载资源池的业务请求。

可选地，调用业务级别低于所述过载资源池的低级别资源池所配置的可调用资源，响应到达所述过载资源池的业务请求，包括：

基于所述低级别资源池的资源利用率，确定所述低级别资源池所配置的可调用资源是否全部为所述低级别资源池调用；

若是，则抢占所述低级别资源池所正在调用的资源，以通过抢占的资源响应到达所述过载资源池的业务请求；

若否，则从所述低级别资源池所配置的可调用资源中，调用未被所述低级别资源池所调用的资源，以响应到达所述过载资源池的业务请求。

可选地，基于每个资源池所对应的至少一种业务各自的实时负载，确定每个资源池对应的资源上限，包括：

获取每种业务对应的历史负载；

基于每种业务对应的实时负载和所述历史负载，确定每种业务的负载上限；

基于每个资源池所对应的至少一种业务各自的负载上限，确定每个资源池对应的资源上限。

可选地，所述方法还包括：

每间隔预设时间，基于每种业务对应的实时负载，对每个所述资源池对应的资源上限进行更新；

基于每个所述资源池的更新后的资源上限，更新每个所述资源池所配置的可调用资源。

可选地，所述方法还包括：

在每个节点上分别为所述多个资源池配置各自的父控制组，以及为每个所述资源池所对应的至少一种业务配置各自的子控制组；

对到达每个所述资源池的业务请求，通过所述业务请求所属的业务的子控制组调用该资源池所配置的可调用资源，以响应所述业务请求；

基于每个所述资源池的资源上限，为每个所述资源池配置所在节点上的可调用资源，包括：

基于每个所述资源池的资源上限，通过所述父控制组为每个所述资源池配置所在节点上的可调用资源。

可选地，所述业务属性为业务级别，所述业务级别用于表征业务的优先级，所述方法还包括：

对所述集群中每个节点上每个资源池的资源利用率进行监控；

在各个所述资源池的资源利用率均达到第一预设资源利用率的情况下，对最高业务级别的资源池所对应的部分业务进行业务级别降级，以利用业务级别低的资源池响应所述部分业务；和/或，将除最高业务级别外的其余资源池所处理的部分业务驱逐出所述其余资源池，以使所述最高业务级别的资源池抢占被驱逐的部分业务调用的资源；

在存在资源利用率小于第二预设资源利用率的低负载资源池时，降低所述低负载资源池的可调用资源；

其中，第二预设资源利用率小于所述第一预设资源利用率。

可选地，所述方法还包括：

在检测到各种业务中至少一个业务的业务属性变更时，获取所述各种业务的变更后业务属性；

基于所述各种业务的变更后业务属性，对所述多个资源池各自所响应的业务进行更新；

基于更新后的资源池所响应的业务的实时负载，调整所述更新后的资源池的可调用资源。

本申请实施例的第二方面，还提供了资源调度装置，所述装置包括：

资源池创建模块，用于在集群中的每个节点上创建多个资源池，其中，不同的资源池对应不同的业务属性，同一资源池用于响应属于同一业务属性的至少一种业务；

资源上限确定模块，用于基于每个资源池所对应的至少一种业务各自的实时负载，确定每个资源池对应的资源上限；其中，每个资源池对应的资源上限小于等于该资源池所对应的至少一种业务各自所需的最大资源之和；

资源配置模块，用于基于每个所述资源池的资源上限，为每个所述资源池配置所述节点上的可调用资源；其中，每个资源池对应的至少一种业务共享该资源池所被配置的可调用资源。

本申请实施例还提供一种资源调度系统，所述系统包括：策略计算组件以及业务响应组件；其中，所述业务响应组件，位于集群中的每个节点上；所述策略计算组件与所述集群中的每个节点通信链接；

所述业务响应组件，用于创建多个资源池，其中，不同的资源池对应不同的业务属性，同一资源池用于响应属于同一业务属性的至少一种业务；

所述业务响应组件，用于基于每个资源池所对应的至少一种业务各自的实时负载，确定每个资源池的资源上限；其中，每个资源池的资源上限小于等于该资源池所对应的至少一种业务各自所需的资源上限之和；

所述业务响应组件，还用于基于每个所述资源池的资源上限，为每个所述资源池配置所述节点上的可调用资源；其中，每个资源池对应的至少一种业务共享该资源池所被配置的可调用资源。

本公开实施例的第三方面，提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行时实现如的一方面所述的资源调度方法。

此外，本申请实施例还提供一种计算机可读存储介质，其存储的计算机程序使得处理器执行如第一方面所述的资源调度方法。

本申请中，可以在集群中的每个节点上创建多个资源池，不同的资源池对应不同的业务属性，同一资源池用于响应属于同一业务属性的至少一种业务；并基于每种业务对应的实时负载，确定每个资源池的资源上限；之后，基于每个资源池的资源上限，为每个资源池配置节点上的可调用资源；其中，每个资源池对应的至少一种业务共享该资源池所被配置的可调用资源。

采用本申请实施例的技术方案，至少具有以下优点：

一方面，可以提高对业务的响应速度、优化服务质量。由于同一资源池中的各种业务是共享该资源池的可调用资源，且资源池的资源上限小于等于该资源池所对应的至少一种业务各自所需的资源上限之和。如此，对于该资源池的每个业务而言，便会在超出自己负载上限的可调用资源中调用资源，使得响应速度得到提高，从而提高对每个业务的服务质量。

另一方面，可以降低对监控精确度的要求。由于按照业务的业务属性创建了与业务属性对应的资源池，同一个资源池可以响应属于同一业务属性的至少一种业务，且由于同一资源池中的各种业务是共享该资源池的可调用资源的，这样，即使监控到的业务所需的最高资源的结果与业务实际所需的最高资源有偏差(例如，监控到的业务所需的最高内存资源是3G，但是业务实际需要用到3.5G的内存资源)，由于该业务与其他种的业务共享资源池的可调度资源，该业务也可以调用与其他业务所共享的资源去响应业务，从而即使在监控精确度不够的情况下，也能保证业务的服务质量。

再一方面，由于同一个资源池可以响应属于同一业务属性的至少一种业务，这样，在某一种业务的业务量较大而另一种业务的业务量较小的情况下，在资源池的可调用资源中业务量较小的业务所调用的资源较少，这样，空出的资源便可以被业务量较大的业务调用，这样，可以使得资源池的可调用资源可以适应各业务的波峰和波谷，实现资源池的资源被错峰复用，即被合理且充分的利用，从而使得尽量以少量的服务器提供所需的云服务成为可能，以降低服务器购置成本。

附图说明

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

图1是本申请一实施例示出了本申请的技术构思示意图；

图2是本申请一实施例示出的一种资源调度方法的通信环境图；

图3是本申请一实施例示出的一种资源调度方法的步骤流程示意图；

图4是本申请一实施例示出的一个资源池内控制组的层级关系示意图；

图5是本申请一实施例示出的节点对资源池的可调用资源进行管理的步骤流程图；

图6是本申请一实施例示出的进行资源抢占的步骤流程图；

图7是本申请一实施例示出的资源调度方法的又一通信环境图；

图8是本申请一实施例示出的资源调度装置的框架示意图。

具体实施方式

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

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

相关技术中，是通过资源超售、动态调度的方式调度服务器资源。

其中，资源超售是目前比较普遍使用的解决资源利用率低的问题的方案。资源超售主要通过调低单容器的实际分配资源量和放大单节点实际资源供给总量的方式实现。在调低单容器的实际分配资源量中，比如业务申请8C16G(8个核的cpu和16G内存)资源，而实际为业务分配的资源可能只有4C8G，以此使得单个节点可以部署更多的其他业务来提升资源利用率；在放大单节点实际资源供给总量中，比如一个48C256G的服务器，在资源编排计算时，按照96C256G资源进行分配，也就是对资源进行超售，同样可以使得单个节点部署更多的业务来提升资源利用率。然而，这两种方式通常需要根据对业务的负载的监控数据和资源画像做出分析评估，确定具体超售比，对监控准确度有较高的要求。

其中，动态调度是根据服务器的实际负载确定其可部署的业务数，对低负载的节点部署更多的业务来提高利用率。动态调度对服务器的负载监控精度也有很高的要求，通用性比较差。而且业务对资源的使用具有时序性，动态调度可以做到单个节点的资源峰值利用率高，但很难做到不同业务对节点上的资源的错峰复用。

此外，为了提高服务器集群中服务器的资源的利用率，相关技术中还提供了混合部署和的方案，混合部署的目的是做到资源在业务间的错峰复用，提高整体资源利用率。但是其也对监控的准确度有较高的要求，再考虑到业务迭代导致资源使用的不可预测性，完全理想的业务间资源错峰复用很难做到。

有鉴于此，为了降低对监控的准确度的要求，同时保证业务的服务质量，本申请提出了以下技术构思：通过在每个节点上创建多个资源池，每个资源池对应同一业务属性的多种业务，多种业务共享资源池的可调用资源，实现同一业务属性的业务间的资源共享，使得每个业务都可以共享到其他业务的资源，从而降低对监控的准确度要求，保证服务质量。

参照图1所示，形象地示出了本申请的技术构思示意图，如图1所示，服务器集群中的每个服务器作为一个资源节点，服务器上的资源包括了网络、磁盘、内存、CPU等资源，本申请在每个节点上按照业务的业务属性，建立了多个资源池，每个资源池按照所需响应的业务，被指定了该服务器上可被该资源池调度的资源，从而实现对服务器资源进行池化管理。

示例地，如图1所示，服务器上的资源包括了网络、磁盘、内存、CPU等，则资源池1在响应业务的过程中，可以调用网络、磁盘、内存、CPU等资源，但是其一次所能调用的网络、磁盘、内存、CPU等资源的总量不超过资源池1的资源上限；资源池2在响应业务的过程中，也可以调用网络、磁盘、内存、CPU等资源，但是其一次所能调用的网络、磁盘、内存、CPU等资源不超过资源池2的资源上限。这样，使得一个服务器资源被多个资源池所分配管理。

本申请中，每个资源池可以对应一种或多种业务，一个资源池所需响应的一种或多种业务可以共享该资源池的可调用资源，例如，如图1所示，资源池1对应结算业务和下载业务，则结算业务可以调用磁盘、内存的资源，同样下载业务也可以调用磁盘和内存的资源。因而，对于结算业务和下载业务，其可调用的资源的大小是相同的，因此，与单个业务分配单个的资源相比，本申请的每个业务都可以调度到资源池的所有可调用资源，可以理解为每个业务可以占用同一业务属性的其他业务的资源。由此，可以对单个节点的负载、以及对业务的负载监控的准确度要求不高，同时又可以保证业务的服务质量。

参照图2所示，示出了本申请的通信环境图，如图2所示，包括N个服务器、调度系统以及M个客户端，调度系统与N个服务器进行通信，且调度系统与多个客户端通信，N个服务器构成服务器集群，每个服务器是该集群中的一个节点；其中N和M均为大于1的整数，当前实际中，M的数值要远大于N。如图1所示，当多个客户端上产生大量的业务时，会通过调度系统将业务调度到某个服务器上的资源池，以通过资源池的可调用资源响应该业务。

例如，如图2所示，客户端1上的业务可以通过调度系统调度到服务器1上的资源池进行响应，从而服务器1将业务响应结果反馈给客户端1。

结合图2所示的通信环境，对本申请的资源调度方法进行介绍，参照图3所示，示出了本申请的资源调度方法的步骤流程图，如图3所示，具体可以包括以下步骤：

步骤S301：在集群中的每个节点上创建多个资源池，其中，不同的资源池对应不同的业务属性，同一资源池用于响应属于同一业务属性的至少一种业务。

本实施例中，集群可以是指由N个服务器构成的服务器集群，其中，在该集群中的一个节点可以是一个服务器，实际中，可以依据当前的多种业务各自所属的业务属性，在每个节点上创建与各个业务属性各自对应的资源池，不同资源池对应不同的业务属性。

其中，业务属性可以用于描述业务的类别、优先级、繁忙时段等属性，在业务属性用于描述业务的类别的情况下，会为每个业务类别创建一个资源池。以网约车平台的线上业务为例，其包括的类别有支付、查询、轨迹跟踪，则属于支付的业务可以包括下单业务和结算业务，属于查询的业务可以包括历史订单查询业务，属于轨迹跟踪的业务可以包括司机端的轨迹跟踪业务和用户侧的轨迹跟踪业务。则可以创建2个资源池，其中一个资源池用于响应下单业务和结算业务，另一个资源池用于响应轨迹跟踪业务。

又以线上购物平台为例，其包括的类别有支付、查询、多媒体播放，则属于支付的业务可以包括下单业务和结算业务，属于查询的业务可以包括订单查询业务、商品搜索业务，属于多媒体播放的业务可以包括商品图片展示业务、商品视频播放业务，则可以创建2个资源池，其中一个资源池用于响应订单查询业务、商品搜索业务，另一个资源池用于响应商品图片展示业务、商品视频播放业务。

在业务属性用于描述业务的优先级的情况下，会为每个业务级别创建一个资源池。以网约车平台的线上业务为例，线上业务包括下单业务、结算业务、轨迹跟踪业务，则下单业务和结算业务均为高优先级，而轨迹跟踪业务为低优先级，则可以创建2个资源池，其中一个资源池用于响应下单业务和结算业务，另一个资源池用于响应轨迹跟踪业务。

此种情况下，又以线上购物平台为例，其包括下单业务、结算业务、订单查询业务、商品搜索业务和多媒体播放业务，其中，结算业务的优先级高于下单业务的优先级、下单业务的优先级高于商品搜索业务的优先级，商品搜索业务的优先级高于订单查询业务的优先级、其中，多媒体播放业务和订单查询业务属于同一优先级。如此，则可以创建4个资源池，不同资源池对应不同业务属性的业务。

本实施例中，可以基于业务的业务属性创建对应的资源池，使得资源池与业务属性挂钩，如此，可以实现对集群中的资源按照业务的业务属性进行资源调配。

步骤S302：基于每个资源池所对应的至少一种业务各自的实时负载，确定每个资源池对应的资源上限。

其中，每个资源池对应的资源上限小于等于该资源池所对应的至少一种业务各自所需的最大资源之和。

本实施例中，由于每个资源池对应同一业务属性的至少一种业务，如此，在确定每个资源池的可调用资源的大小时，可以基于每个资源池所需响应的至少一种业务各自的实时负载，确定每个资源池对应的资源上限，该资源上限可以是依据每种业务的实时负载，确定出的业务所需的最大资源确定的，且每个资源池对应的资源上限小于资源池所对应的至少一种业务各自所需的最大资源之和。

其中，每种业务的实时负载可以通过周期性监控每种业务的业务量确定，通过业务量可以确定出每种业务所需的资源，通过各个周期下每种业务所需的资源，可以确定出每种业务所需的资源的最大值，这个最大值即为每种业务所需资源的资源上限。

其中，每个资源池对应的资源上限可以表征该资源池可配置的各类型资源的最大值，例如，资源池对应的资源上限为7C12G，则表征该资源池最多可使用节点上7核的CPU资源和12G的内存资源，超过7核和12G的资源则不会配置到该资源池。当然，由于节点上的资源还可以包括磁盘、网络等资源，对于磁盘、网络等资源可同理配置，如，资源池对应的资源上限中网络资源上限是1Mb，则表示资源池可使用的网络资源的最大值是1Mb。

当然，在一些实施例中，每个资源池对应的资源上限还可以大于该资源池所对应的至少一种业务中所需资源最高的业务所对应的最大资源，如图1所示，资源池1对应结算业务和下载业务，其中，结算业务所需的最高资源是8C6G(8个核的CPU和6G内存)，而下载业务所需的最高资源是2C3G(2个核的CPU和3G内存)，则资源池1对应的资源上限可以是9C7G(9个核的CPU和7G内存)。

步骤S303：基于每个所述资源池的资源上限，为每个所述资源池配置所在节点上的可调用资源。

其中，每个资源池对应的至少一种业务共享该资源池所被配置的可调用资源。

本实施例中，由于资源池对应的资源上限可以表征该资源池可配置的资源的最大值，如此，可以基于每个资源池对应的资源上限，从节点配置的资源中为每个资源池分配其可调用的可调用资源，具体实施时，对每个节点上创建的多个资源池，可以将节点上配置的磁盘、网络和CPU等资源按照每个资源池对应的资源上限，分配给各个资源池。

示例地，如图1所示，资源池1对应的资源上限是6C7G，则资源池1所能使用的节点上的CPU资源上限是6C，而能使用的节点上的内存资源上限是7G。

在本实施例中，每个资源池对应的至少一种业务共享该资源池所被配置的可调用资源，也就是说，属于同一业务属性的业务可以共享同一资源池的可调用资源。示例地，如图1所示，资源池1对应的是结算业务和下载业务，资源上限是6C7G，则在实际运营中结算业务和下载业务共享6C7G的资源。

采用同一业务属性的业务可以共享同一资源池的可调用资源的方式，可以使得在其中一个业务处于低谷而另一业务处于业务高峰时，处于高峰的业务可以占用资源池的更多资源，例如可以占用到超出到自身所需资源上限的资源，从而实现资源的错峰复用。例如，如图1所示，对于资源池1而言，监测出结算业务所需的资源上限是9C76G，而在一个时段中，结算业务处于业务高峰，而下载业务处于业务低谷期，结算业务需要占用8C6G的资源，此时由于其和下载业务共享资源池1的资源，则其便会占用资源池1的8C6G资源，从而满足了结算业务的需求；而在另一时段中，结算业务处于业务低谷，而下载业务处于业务高峰期时，下载业务会占用资源池1更多的资源。

且采用同一业务属性的业务可以共享同一资源池的可调用资源的方式，对业务的实时负载的监控精度要求不高，例如，如图1所示，对于资源池1而言，对应结算业务和下载业务，则即使在某一时刻监测到的结算业务和下载的实时负载不精确，由于二者共享资源池1的可调用资源，可以实现在可调用资源的资源上限内，结算业务和下载业务动态调配资源，其也可以弥补监控精度不够所导致的误差，因而对实时负载监控不精确的容忍度较高，可以运用到多种调度系统中。

采用本申请实施例的技术方案，由于同一资源池中的各种业务是共享该资源池的可调用资源，且资源池的资源上限小于该资源池所对应的至少一种业务各自所需的资源上限之和。如此，对于该资源池的每个业务而言，便会在超出自己负载上限的可调用资源中调用资源，使得响应速度得到提高，从而提高对每个业务的服务质量。且，对于同一资源池所需响应的业务之间共享可调用资源，实现了业务之间的资源调用动态分配，从而保证了业务的服务质量，以及提高了对业务的实时负载监控不精确的容忍度。

其中，在一些实施例中，在每个节点上创建多个资源池时，可以为每个资源池配置各自的控制组，以实现各个资源池的资源隔离。具体地，可以在每个节点上分别为所述多个资源池配置各自的父控制组，以及为每个所述资源池所对应的至少一种业务配置各自的子控制组。

参照图4所示，示出了一个资源池内控制组的层级关系示意图，如图4所示，每个资源池配置一个父控制组，资源池内不同种的业务配置子控制组。父控制组用于为资源池配置可调用资源，并实现资源池与资源池间的资源隔离。其中，所述子控制组用于对同一资源池内的各种业务进行资源隔离，用于实现同一资源池内不同种业务的进程隔离和资源隔离。如此，每个资源池对应的至少一种业务共享该资源池所被配置的可调用资源，便可以理解为是同一资源池内的各个子控制组共享资源池的可调用资源。

具体地，对到达每个资源池的业务请求，可以通过业务请求所属的业务的子控制组调用该资源池所配置的可调用资源，以响应所述业务请求。

具体实施时，当每个资源池到来一种业务的业务请求时，可以确定该业务请求所属的具体业务，之后通过为该业务所配置的子控制组调用该资源池所配置的可调用资源，以响应业务请求。

当然，在步骤S303中，可以基于每个所述资源池的资源上限，通过所述父控制组为每个所述资源池配置所在节点上的可调用资源。

本实施例中，在为每个资源池配置可调用资源时，可以通过资源池对应的父控制组配置资源池的资源。

其中，父控制组和子控制组均可以通过Cgroups(Control groups，控制组群)技术实现，其中，Cgroups用于控制至少一种业务的响应进程对资源的使用，同时可以使得资源池之间相互隔离，在每个资源池所需响应的业务到来时，便可以通过子控制组调用该资源池的资源，去实现对业务的响应。

采用此实施方式时，由于每个资源池具有各自的控制组，则可以通过控制组实现对资源池的可调用资源的调度、管理和配置，并可以对各个资源池的资源进行相对隔离，从而通过资源隔离，降低资源池间的服务干扰。

在一种实施例中，对如何确定每个资源池的资源上限进行说明，其中，在确定每个资源池的资源上限时，可以根据该资源池对应的每种业务的历史负载和实时负载确定，每个资源池的资源上限可以大于该资源池对应的各种业务中资源需求量最大的业务所需的最高资源大小，小于该资源池对应的各种业务所需的资源大小之和。

其中，在一种具体的实施方式中，可以获取每种业务对应的历史负载；基于每种业务对应的实时负载和所述历史负载，确定每种业务的负载上限；基于每个资源池所对应的至少一种业务各自的负载上限，确定每个资源池对应的资源上限。

本实施例中，可以周期性获取每种业务的实时负载，历史负载可以是在每次获取业务的实时负载之前的各个历史时刻中业务的负载，其中，该负载可以是指业务的业务量，其可以反映业务所需的资源上限，例如，可以每个1分钟便获取一次业务的实时负载，则历史负载可以是前24小时内每分钟的实时负载。

本申请可以在每次获取到业务的实时负载时，根据该实时负载和历史负载确定业务所对应的负载上限，其中，业务所对应的负载上限可以是实时负载和各个历史负载的平均负载。进而，基于属于同一业务属性的每种业务的负载上限，可以确定属于同一业务属性的每种业务所需的资源上限，进而基于属于同一业务属性的每种业务的负载上限，可以确定该业务属性的资源池对应的资源上限。

具体而言，可以根据属于同一业务属性的各种业务所需的资源上限的最大值和同一业务属性的各种业务所需的资源上限之和，确定该业务属性的资源池对应的资源上限。

具体而言，一个资源池对应的资源上限，可以是根据属于同一业务属性的各种业务中所需资源上限的最大值，与除所需资源上限的最大值之外的其余资源上限之和所对应的权重，进行加权求和得到的。

其中，与除所需资源上限的最大值之外的其余资源上限之和所对应的权重，可以根据需求所设置，或者可以根据资源池运行一段时间内的资源利用率确定，例如，此种情况下，该权重可以是资源池运行一段时间内的平均资源利用率，该权重一般小于1。其中，资源利用率可以是资源池的可调用资源中被使用的资源的占比。

示例地，如图1所示，对于资源池1，其对应结算业务和下载业务，其中，结算业务当前的实时负载所需的资源上限是2C3G，而结算业务的历史负载所需的资源上限是8C8G，对内存资源而言，业务申请资源是8G，同样方法可以确定下载业务所需的资源上限是2C4G，对内存资源而言，下载业务所需申请的资源是4G，配置的权重为0.7，则该资源池对应的内存资源上限可以是8G+4G*0.7，资源池的资源配置上限为10.8G，小于两个业务的资源申请上限之和12G，以此类推，可以确定CPU类型的资源的资源上限。

采用此种实施方式时，由于基于业务的实时负载和历史负载，对业务的负载上限进行确定，因此其确定出的负载上限可以反映业务在一段时间内的平均最高负载，使用平均最高负载可以准确客观地反映业务的负载动态，且由于本申请的资源池中的各个业务是共享可调用资源的，因此，容忍业务实际使用资源超出其历史统计的峰值。比如上例中，资源池1实际配置的资源是10.8G，大于结算业务和下载业务各自申请的资源上限，所以对历史统计数据和监控数据的不准确相对容忍度更好。

此外，由于每个资源池的资源上限可以大于该资源池对应的各种业务中资源需求量最大的业务所需的最高资源大小，小于该资源池对应的各种业务所需的资源大小之和，这样，一个资源池的可调用资源可以保证满足资源需求量最高的业务，且又不至于导致资源的闲置，从而在保证服务质量的同时，充分提高了资源利用率。

相应地，可以对各种业务的负载变化进行实时监控，以实时调整资源池的可调用资源的上限。具体地，可以每间隔预设时间，基于每种业务对应的实时负载，对每个所述资源池对应的资源上限进行更新；并基于每个所述资源池的更新后的资源上限，更新每个所述资源池所配置的可调用资源。

本实施例中，由于可以周期性获取各种业务的实时负载和历史负载，如此，可以周期性确定每个资源池对应的资源上限，可以每次在确定出资源池对应的资源上限时，对每个资源池，在该资源池当前对应的资源上限与确定出的资源上限相同时，可以不更新该资源池对应的资源上限，在该资源池当前对应的资源上限与确定出的资源上限不同时，可以将确定出的资源上限作为该资源池的资源上限，从而根据更新后的资源池的资源上限，对该资源池的可调用资源进行调整。

示例地，在每隔一分钟便确定一次每个资源池对应的资源上限的情况下，假设第5分钟确定出的资源池1的资源上限是5C7G，而第6分钟确定出的资源池1的资源上限是5C8G,则会在第6分钟将资源池的资源上限确定为5C8G，并向资源池1增加1G的内存资源。若第6分钟确定出的资源池1的资源上限是6C7G，则会在第6分钟向资源池1中增加1核的CPU资源，即资源池1的可调用资源增加了。

当然，在一种实施例中，还可以根据多个节点上同一资源池在一段时间内的资源利用率的平均值，动态调整该同一资源池对应的资源上限。例如，多个节点上资源池1的资源使用率在10分钟内均过低，说明资源池1的资源配置过多，则会调低资源池1的资源上限，从而释放了部分资源出去供其它资源池使用；若多个节点上资源池1的资源使用率在10分钟内均过高，例如超过85％，说明资源池1的资源配置过少，会自动调高资源池1的资源上限，以为资源池1供给更多的资源。

其中，在对其中一个资源池的可调用资源进行重新调整时，可以尽量不对资源上限未发生更新的其他资源池的可调用资源进行调整，从而减轻服务器的控制组的工作负载。

采用此种实施方式时，由于可以周期性根据各种业务的负载上限，对每个资源池对应的资源上限进行更新，并根据更新后的资源上限，调整资源池的可调用资源，如此，可以使得资源池的资源配置可以根据业务的实际负载进行适时调整，从而保证了各个资源池的可调用资源是适配当下的业务的实际需求，保证了服务质量。

在一些实施例中，业务的业务属性也可以根据需求而变更，例如，在业务属性是优先级时，结算业务在一段时间内可以是级别较高的业务，而在另一段时间内可以是级别较低的业务。由于每个节点上的多个资源池是根据业务属性而创建的，因此，在业务的业务属性发生变更时，也可以对每个节点上的资源池进行更新，具体地，可以调整每个资源池所需响应的业务，以及每个资源池所配置的可调用资源。

具体实施时，可以采用以下过程进行：

首先，在检测到各种业务中至少一个业务的业务属性变更时，获取所述各种业务的变更后业务属性。

本实施例中，可以对每种业务的业务属性变化进行监控，在监控到存在业务属性变化的业务时，可以获取业务的被变化后的业务属性。需要说明的是，在一次业务属性变更时，可以是全部业务的业务属性均发生变化，也可以是部分业务的业务属性发生变化，在本申请实施例中，可以获取发生业务属性变化的业务，并获取发生业务属性变化的业务所变化后的业务属性，即本申请所述的变更后业务属性。

示例地，在业务属性是优先级的情况下，以线上购物平台为例，结算业务的优先级高于下单业务的优先级、下单业务的优先级高于商品搜索业务的优先级，商品搜索业务的优先级高于订单查询业务的优先级、其中，多媒体播放业务和订单查询业务属于同一优先级。在检测到业务属性变更后，其业务的变更后业务属性为：下单业务的优先级高于结算业务的优先级、结算业务的优先级高于商品搜索业务的优先级，其余业务的优先级不变，因此，可以发现，下单业务的优先级变高，而结算业务的优先级变低。

其次，基于所述各种业务的变更后业务属性，对所述多个资源池各自所响应的业务进行更新。

本实施例中，由于部分或全部业务的业务属性发生了变化，则可以基于业务的变更后业务属性，调整资源池所响应的业务，具体实施时，可以基于各个业务的变更后业务属性，对各个资源池所响应的业务进行调整。具体实施时，可以确定发生业务属性变更的业务在变更前所属的资源池，以及在变更后所属的资源池，从而将该业务从变更前所属的资源池挪到其更后所属的资源池中。

之后，基于更新后的资源池所响应的业务的实时负载，调整所述更新后的资源池的可调用资源。

本实施例中，在对资源池的可响应的业务进行调整后，可以基于资源池的更新后的所需响应的业务的实时负载，确定更新后的资源池的资源上限，进而根据更新后的资源池的资源上限，调整更新后的资源池的可调用资源。

其中，根据更新后的资源池的资源上限，调整更新后的资源池的可调用资源，可以根据上述实施例中步骤S303所述的过程即可，在此不再赘述。

采用本实施方式的技术方案，可以响应于业务的业务属性被变更的状态，对各个资源池所要响应的业务和各个资源池的可调用资源进行调整，从而可以使得资源池的可调用资源跟随业务的业务属性变化而变化，增强了本申请的资源调度方法的适用性。

在一种实施例中，业务属性可以为业务级别，该业务级别用于表征业务的优先级。由于每个资源池的可调用资源是具有资源上限的，即在限定的资源上限的情况下，调用该资源池的可调用资源。如此，在一些实施方式中，可以监控各资源池的负载，以及时反馈资源池的可调用资源使用情况，从而基于各个资源池的可调用资源使用情况，对业务的业务级别进行调整。

具体地，可以对每个所述节点上的每个资源池正在调用的资源进行监控。其中，在业务属性为业务级别的情况下，该业务级别可以理解为是上述实施例所述的业务的优先级，优先级最高的业务，其业务级别也越高。例如，优先级最高的业务，其业务级别可以为0，优先级次之的业务，其业务级别可以为1。

本实施方式中，可以对所述集群中每个节点上每个资源池的资源利用率进行监控，具体地，正在被调用的资源可以是正在使用的资源。

一方面，在各个所述资源池的资源利用率均达到第一预设资源利用率的情况下，对最高业务级别的资源池所对应的部分业务进行业务级别降级，以利用业务级别低的资源池响应所述部分业务，和/或，将除最高业务级别外的其余资源池所处理的部分业务驱逐出所述其余资源池，以使所述最高业务级别的资源池抢占被驱逐的部分业务调用的资源。

其中，第一预设资源利用率可以设置为98％或100％，表征资源池已经满负荷运转。每个资源池的资源利用率可以反映正在调用的资源占据可调用资源池的比例。

具体地，若节点上的每个资源的资源利用率均超过第一预设资源利用率时，例如，所有节点上每个资源池的可调用资源均被超额使用，则可以确定此种情况下，每种业务均具有较高的业务量，高业务级别的资源池无法从低业务级别的资源池抢占资源，如此，可以通过如下两种方式进行处理：

方式一：将最高业务级别的资源池所对应的部分业务进行业务级别降级，从而利用业务级别低的资源池响应业务级别被调低的部分业务。

其中，进行业务级别降级的业务可以根据需要进行确定，例如，如图1所示，对于资源池1而言，其是最高业务级别的资源池，可以将其中的下载业务进行降级，降级到其他资源池中进行执行，从而可以将原有的为下载服务提供服务的资源用于为结算业务进行服务，以优先满足高级别的业务的服务。

方式二：可以将除最高业务属性外的其余资源池所处理的业务驱逐出所述其余资源池，以使所述最高业务级别的资源池抢占被驱逐的部分业务调用的资源。

其中，对最高业务级别外的其余每个资源池，可以将该资源池的部分业务驱逐出去，这样驱逐业务后空出的资源便可以被最高业务级别的资源池所抢占，从而牺牲低级别的业务的服务质量，以优先满足高级别的业务的服务质量。具体实施时，可以将业务级别最低的资源池中的业务进行驱逐，以使得业务级别最高的资源池可以抢占业务级别最低的资源池所配置的可调用资源，从而响应最高业务级别的业务。

示例地，以线上购物平台为例，按照业务级别，创建了4个资源池，其中，资源池1对应结算业务、资源池2对应下单业务、资源池3对应商品搜索业务、资源池4对应订单查询业务和多媒体播放业务，如此，可以将资源池4的订单查询业务和多媒体播放业务驱除出资源池4，这样，被驱除订单查询业务和多媒体播放业务后空出的资源可以由资源池1抢占，以满足结算业务的服务。

在实际中，可以在方式一和方式二中择一种方式进行资源调配，也可以同时使用两种方式进行资源调配。

另一方面，在存在资源利用率小于第二预设资源利用率的低负载资源池时，降低所述低负载资源池的可调用资源。

其中，第二预设资源利用率可以设置为30％左右，具体可以根据需求设置即可。

本实施例中，若某一个资源池的资源利用率小于第二预设资源利用率，可以是指其正在调用的资源占该资源池的可调用资源的比例很小，则可以确定该资源池是低负载资源池。

在一种实施方式中，在降低低负载资源池的可调用资源时，可以对应降低该低负载资源池的资源上限。具体地，可以根据低负载资源池的资源利用率，确定降低后的可调用资源的大小，例如，资源利用率是0.4，则会将低负载资源池的可调用资源降低到原有可调用资源的0.4。当然，实际中，降低后的可调用资源可以在原有可调用资源的0.4上下浮动，在此不做限定。

其中，降低低负载资源池的可调用资源后，所释放出的资源可以被其他需要资源的资源池所使用。

采用此种实施方式时，一方面，在各个资源池都超负荷时，可以对最高业务级别的资源池所对应的部分业务进行业务级别降级，从而保证最重要的业务的服务质量。另一方面，也可以将业务级别较低的资源池的部分业务驱逐出去，以使得业务级别较低的资源池空出的资源可以被业务级别高的资源池抢占，如此，也可以保证高业务级别的业务的服务质量。再一方面，由于在存在低负载资源池时，可以降低低负载资源池的可调用资源，这样，从低负载资源池所释放出的资源可以被其他需要资源的资源池所使用，从而提高了资源利用率，实现了资源的合理调度。

在每个节点上创建多个资源池之后，可以利用资源池管理节点上的资源，去响应各种业务。下面，对如何基于创建的多个资源池，在业务到来时，调用节点上的资源进行响应的过程进行说明。

实际中，在每到来一个业务请求时，需要将该业务请求调度到集群中的一个节点上，通过该节点上与该业务对应的资源池的可调用资源去响应该业务。其中，每个资源池的可调用资源可以是与资源池相对解耦的，具体来说，资源池的可调用资源在需要响应业务时才被调用，在不需要响应业务时是处于释放的状态。

相应地，在一种实施方式中，对每个节点在执行业务响应过程中对资源的调用过程进行说明，参照图5所示，示出了节点对资源池的可调用资源进行管理的步骤流程图，如图5所示，具体可以包括以下步骤：

步骤S401：对到来的业务请求，基于所述业务请求所属的业务属性，从各个资源池中确定与所述业务请求对应的目标资源池。

本实施例中，每到来一个业务请求时，可以确定业务请求的业务所属的业务属性，并确定该业务属性对应的资源池，进而在集群拥有的该业务属性对应的全部资源池中确定与业务请求对应的目标资源池，即将业务请求调度到目标节点上的目标资源池。

其中，由于在每到来一个业务请求时，需要将该业务请求调度到集群中的一个节点上，实际中，在确定业务请求对应的目标资源池时，可以将业务请求调度到剩余资源较多的目标节点上的目标资源池，或者可以将业务请求调度到其可用资源满足该业务的业务请求数量的目标资源池。其中，剩余资源较多的目标节点上的目标资源池可以是指在该目标节点上，目标资源池的剩余可调用资源是最多的。

具体地，可以对所述集群中每个节点上每个资源池的资源利用率进行监控；并基于监控到的每个节点上每个资源池的资源利用率，确定每个节点上每个资源池的剩余可用资源，和/或，确定每个节点的总剩余可用资源。

其中，所述资源利用率表征资源池的可调用资源被使用的程度。

本实施例中，一种方式下，每个节点可以实时反馈自身的各个资源池的资源利用率，该资源利用率可以反映资源池的可调用资源被使用的程度，资源利用率越高，表征资源池的可调用资源被使用的越多。因此，可以基于每个节点实时反馈的各个资源池的资源利用率，以及各个资源池对应的可调用资源，确定每个节点上每个资源池的剩余可用资源。

另一方式下，每个节点可以实时反馈自身拥有的各类型资源的资源利用率，该资源利用率可以反映资源池所拥有的可调用资源被使用的程度，进而可以根据节点拥有的资源，确定节点的剩余可用资源。该剩余可用资源是指节点上未被调用的资源。示例地，资源池1的资源上限是9C7G，假设节点1上反映资源池1的资源利用率为20％CPU、30％内存，则资源池1上还剩余的可用资源为7.2C4.9G。

则相应地，可以基于每个节点上每个资源池的剩余可用资源，和/或每个节点的总剩余可用资源，从所述集群中确定所述目标资源池。

一方面，可以依据每个节点上每个资源池的剩余可用资源，从集群中的多个节点各自所拥有的与业务请求的业务属性对应的资源池中，将剩余可用资源最多的资源池所在的节点确定为目标节点，从而将目标节点上与业务请求的业务属性对应的资源池确定为目标资源池。例如，包括了10个节点，每个节点上拥有4个资源池，业务请求对应的业务属性为结算业务，属于资源池1，则会将10个节点上剩余可用资源最多的资源池1作为目标资源池。

另一方面，也可以依据每个节点所拥有的全部资源中还剩余的总剩余可用资源确定目标资源池，其中，节点上的总剩余可用资源可以基于节点上报的资源利用率确定，示例地，节点1上的全部资源为48C256G(48核CPU256G内存)，节点1上的资源利用率为50％CPU50％内存，则节点1上的总剩余可用资源为24C128G(24核CPU128G内存)。

具体地，可以将总剩余可用资源最多的节点作为目标节点，并将目标节点上的与业务请求对应的资源池确定为目标资源池。此种情况下，由于本申请的资源池的资源是动态调度的，即使用的时候再调度资源，使用完毕便会回退资源到节点，由此，总剩余可用资源最多，可以使得资源池可供调取的资源的基数较大，可以满足业务需求。

又一方面，可以根据节点上的总剩余可用资源以及与业务请求的业务属性对应的资源池的可调用资源，综合筛选出适合处理业务请求的目标资源池。具体地，可以从集群中的多个节点各自所拥有的与业务请求的业务属性对应的资源池中，将节点上总剩余可用资源最多、且与业务请求的业务属性对应的资源池的剩余可用资源最多的资源池作为目标资源池。示例地，包括了10个节点，每个节点上拥有4个资源池，业务请求对应的业务属性为结算业务，属于资源池1，则会将总剩余可用资源最多、且对应的资源池1的剩余可用资源最多的资源池的作为目标资源池。例如，节点2的总剩余可用资源最多且节点2上的资源池1的剩余可用资源也最多，则会将节点2的资源池1作为业务请求对应的目标资源池。

步骤S402：从所述目标资源池被配置的可调用资源中调用部分或全部资源，以响应所述目标业务属性的多个业务。

本实施例中，在确定出目标资源池后，便会将业务请求发送给目标资源池所在的目标节点，以从目标资源池所在的节点上，被配置给目标资源池的可调用资源中调用部分或全部资源，去响应业务请求。其中，响应业务请求可以是指对业务请求的具体请求进行处理。

其中，可以根据业务请求所对应的业务量，调用目标资源池的全部或部分可调用资源去响应业务请求。具体地，可以是从目标资源池的剩余未被调用的资源中调用的部分或全部资源去响应业务请求。

步骤S403：在响应所述业务请求结束时，将被调用的所述部分或全部资源释放。

本实施例中，在完成对业务请求的响应时，可以将目标资源池的被调用的部分或全部资源进行释放，从而该部分被释放的资源又可以响应到来的新的业务请求。

采用本实施方式的技术方案，一方面，由于可以将业务请求调度到剩余可用资源较多的目标资源池上进行响应，如此，可以确保响应业务请求的效率。另一方面，由于在响应业务请求结束时，将被调用的部分或全部资源释放，如此，可以使得资源池的可调用资源是跟随到来的业务进行动态使用的，其可以不用被资源池一直占用，一些情况下，被释放的资源可以被其他资源池所抢占，从而实现资源的动态调度。

其中，在一种实施方式中，在每个节点上可以创建剩余资源池，该剩余资源池用于管理节点上未被调用的资源。这样，在将资源池的被调用的部分或全部资源进行释放时，可以将释放的资源回退到剩余资源池；其中，剩余资源池还可以管理节点上未被配置给各个资源池的资源。例如，资源池1和资源池2释放的CPU和内存资源可以回退到剩余资源池进行管理，同时，节点上为配置给资源池1和资源池2的部分资源，如有1C5G的资源未配置出去，则也可以纳入到剩余资源池进行管理。

相应地，在上述实施例中，在业务级别较高的资源池的可调用资源不足时，可以优先从剩余资源池调用资源，当剩余资源池对应的可调用资源不足的情况下，再抢占比业务级别较低的资源池的可调用资源。总体来看，本申请的资源抢占过程如下：如上所示，在抢占比业务级别较低的资源池的可调用资源时，可以优先从业务级别最低的资源池抢占资源，若业务级别最低的资源池的资源不足，可以按照业务级别，逐级从上一业务级别的资源池抢占资源。若无法从各个资源池抢占资源，即各个资源池均是满载的，则可以选择将业务级别较低的资源池中的业务进行驱逐，以释放部分出资源响应业务。具体如下述实施例描述：

在一种实施例中，业务属性可以为业务级别，业务级别用于表征业务的优先级。实际中，对于每个节点，由于具有多个资源池，每个资源池配置有可调用资源，如上所述，在一种方式中，每个资源池与其配置的可调用资源可以是解耦的，这样，资源池之间的可调用资源便可以根据业务的繁忙状态进行资源抢占，具体的，业务级别高的资源池中的业务，可以抢占业务级别低的资源池所配置的可调用资源，以确保高级别的业务的服务。

具体实施时，可以对所述集群中每个节点上每个资源池的资源利用率进行监控；并在存在所述资源利用率达到第一预设资源利用率的过载资源池，且所述过载资源池不为业务级别最低的资源池的情况下，调用业务级别低于所述过载资源池的低级别资源池所配置的可调用资源，响应到达所述过载资源池的业务请求。

本实施例中，集群中的每个节点可以上报自身的各个资源池的资源利用率，该资源利用率可以表征正在调用的资源所占的比例，当监控到一个节点上资源池的资源利用率达到第一预设资源利用率时，表示资源池过载，该资源池可以称为过载资源池。例如，资源池1对应的资源上限是9C7G，假设节点1上的正在调用的资源已经达到9C7G，表征该资源池1已经出现过载状态，这样，当新的结算业务请求又到来时，资源池1便不足以进行快速响应。

此种情况下，可以抢占业务级别低于过载资源池的低级别资源池所配置的可调用资源，例如，资源池1可以抢占资源池2的可调用资源去响应新到来的结算业务请求。

其中，在业务级别低于过载资源池的低级别资源池有多个时，可以根据多个低级别资源池各自剩余的可用资源，抢占剩余的可用资源较多的低级别资源池的可调用资源，或者，可以抢占业务级别最低的资源池的可调用资源，或者，也可以从每个低级别资源池中抢占部分资源，以响应到来的业务请求。

具体地，如图6所示，示出了一种方式下的资源抢占的步骤流程图，如图6所示，具体可以包括以下步骤：

步骤S501：确定业务级别低于所述过载资源池的低级别资源池的资源利用率。

本实施例中，可以基于各个低级别资源池的资源利用率确定低级别资源池正在调用的资源占可调用资源的比例。

步骤S502：基于所述低级别资源池的资源利用率，从所述低级别资源池中确定待资源占用的资源池。

本实施例中，可以根据各个低级别资源池的资源利用率，确定各个低级别资源池的剩余可用资源，该剩余可用资源是资源上限与正在调用的资源之间的差值，正在调用的资源是资源上限与资源利用率的乘积。

其中，可以将剩余可用资源最多的低级别资源池作为待资源占用的资源池，在剩余可用资源最多的低级别资源池不止一个时，可以将任一剩余可用资源最多的低级别资源池作为待资源占用的资源池。

步骤S503：调用所述待资源占用的资源池所配置的可调用资源，响应到达所述过载资源池的业务请求。

本实施例中，可以从待资源占用的资源池所配置的可调用资源中调用部分资源，从而通过所调用的部分资源响应到达过载资源池的业务请求，从而实现过载资源池抢占业务级别较低的资源池的可调用资源，以优先满足高业务级别的业务请求。

采用此种实施方式，由于业务级别较低的资源池所响应的业务的级别较低、实际中其业务量也不大、对于平台来说，这部分业务级别低的业务并不是现阶段的重要业务，因此，业务级别较低的资源池的可调用资源被抢占后，由于业务级别较低的资源池的业务量不大、业务重要性不高，因此，对于整体的业务服务质量影响微弱，反而，由于优先满足了高业务级别的业务请求，从而使得业务量大、业务重要性高的业务的响应速度得到保证，从而整体上的业务服务质量是得到提高的。

其中，在又一种情况下，在业务级别高的资源池的可调用资源过载时，若业务级别低的低级别资源池的可调用资源也处于满载状态，则业务级别高的资源池可以抢占低业务级别的其他资源池正被调用的资源，以优先满足业务级别高的业务的服务。

具体实施时，可以基于所述低级别资源池的资源利用率，确定所述低级别资源池所配置的可调用资源是否全部为所述低级别资源池调用；若是，则抢占所述低级别资源池所正在调用的资源，以通过抢占的资源响应到达所述过载资源池的业务请求；若否，则从所述低级别资源池所配置的可调用资源中，调用未被所述低级别资源池所调用的资源，以响应到达所述过载资源池的业务请求。

本实施例中，无论是在低级别资源池为一个还是为多个的情况下，都可以确定各个低级别资源池的资源利用率，以确定其所配置的可调用资源是否全部被调用，其中，在存在未被全部调用的低级别资源池时，即低级别资源池的资源利用率小于第一预设资源利用率，表征该低级别资源池还有剩余可用资源，则可以按照上述实施方式所述的方法，从而还有剩余可用资源的低级别资源池中抢占未被低级别资源池调用的资源给过载资源池使用。

其中，在全部的低级别资源池所配置的可调用资源全部被调用的情况下，则如上述实施例所述的，节点上全部的资源池均以满负荷，此种情况下，可以将低级别资源池中的业务驱逐出去，这样低级别资源池正在调用的资源被抢占到过载资源池中，以通过抢占的资源响应过载资源池对应的业务请求，这样，低级别资源池因正在参与业务服务的资源被抢占，因此，低级别资源池的由被抢占的资源所服务的业务请求会暂停。

其中，在低级别资源池为多个的情况下，被资源抢占的资源池可以是业务级别最低的资源池。

示例地，资源池1和资源池2均满负荷了，此时，资源池1是过载资源池，资源池2是低级别资源池，则可以将资源池2正在被调用的资源抢占，以通过抢占到的资源响应资源池1的结算业务请求，这样，资源池2的下单业务会暂停，表现为客户端发送的下单请求的响应速度会降低，然而客户端发送的支付请求的响应速度会不受影响。

当然，由于每个资源池与其所配置的可调用资源是相对解耦的，这样，低级别资源池在结束部分业务请求时，则会通过因结束部分业务请求而空出的资源，响应其因资源抢占而被暂停的业务请求。

当然，在一些实施方式中，当检测到过载资源池正在被调用的资源未超过资源上限时，便会将抢占的资源恢复给被抢占的低级别资源池，从而使得低级别资源池可以通过被抢占的资源继续响应被暂停的业务请求。

采用此种实施方式时，由于在各个资源池都满载时，过载资源池可以通过资源抢占的方式，抢占低级别资源池的可调用资源，从而优先满足了业务级别较高的业务，又由于在过载资源池正在被调用的资源未超过资源上限时，可以将抢占的资源恢复给低级别资源池，从而又使低级别资源池仍然可以拥有自身的可调用资源，从而恢复业务级别低的业务的响应速度。如此，保证了资源池的可调用资源可以随着业务的实际负载而进行池间调度，从而保证了业务的整体服务质量。

本申请上述实施例的资源调度方法可以应用于现有的资源调度系统，如kubernetes(K8S)资源编排调度系统，但是并不限于该K8S调度系统。下面，以K8S系统对应的通信环境为例，对本申请的资源调度方法进行示例性说明。

参照图7所示，示出了本申请的又一通信环境示意图，如图7所示，包括服务器集群，以及与服务器集群中每个服务器通信链接的调度组件和策略计算组件；其中，策略计算组件可以与外部的监控服务和服务画像服务进行通信，监控服务用于监控各个业务的实时负载，而服务画像服务是基于各个业务的历史负载和实时负载为业务所需的资源进行确定。

S1、当前的业务有结算业务、下单业务、搜索业务和浏览业务。其中，结算业务和下单业务被设置为最高级别、业务级别为1，则搜索业务和浏览业务依次次之，其业务级别分别为2、3。

S2、在每个服务器上创建3个资源池，对应业务级别，分别是资源池1(结算业务和下单业务)、资源池2(搜索业务)、资源池3(浏览业务)。

S3、策略计算组件每1分钟监控结算业务、下单业务、搜索业务和浏览业务各自的实时负载，并根据监控到的实时负载和各业务的历史负载。

例如，当次确定出结算业务、下单业务、搜索业务和浏览业务各自所需的最高资源分别为：结算业务8C6G、下单业务6C7G、搜索业务1C2G、浏览业务1C1G。

S4、策略计算组件根据当次确定出的结算业务、下单业务、搜索业务和浏览业务各自所需的最高资源，确定出资源池1至资源池3各自的资源上限，假设分别为：资源池1为8C10G，资源池2为1C2G，资源池3为1C1G。

S5、策略计算组件将确定出的各个资源池的资源上限发送给各个服务器。

S6、服务器根据各个资源池的资源上限，通过每个控制组为每个资源池配置可调用资源。例如，在服务器1上，资源池1的可调用资源是8C10G，表征其可调配的CPU资源上限8核，内存资源上限是10G，以此可以类推其他资源池的可调用资源的配置。

S7、每个服务器向调度组件上报各个资源池的资源利用率，调度组件可以根据各个资源池的资源利用率，确定每个服务器上的每个资源池的剩余可用资源。

S8、调度组件在接收到客户端发送的业务请求时，可以确定业务请求的业务级别，以确定出执行业务请求的服务器和服务器上执行业务请求的资源池。如业务请求是结算业务，则业务级别是1，需要放到资源池1进行响应，假设，根据每个服务器上的资源池1的剩余可用资源，将结算业务请求发送到剩余可用资源最多的服务器上。

S9、每个服务器实时监控资源池1至资源池3的资源利用率，当检测到资源池1负载过高，其使用的资源已经达到8C10G时，便会从资源池2和资源池3中抢占资源。

具体来说，当资源池2和资源池3均还有剩余可用资源时，便会从剩余可用资源最多的资源池中抢占资源，假设资源池2的剩余可用资源最多，则会抢占资源池2的资源。

当资源池2和资源池3均没有剩余可用资源时，则会从级别最低的资源池3驱逐出部分业务，以抢占资源给资源池2使用。

S10、调度组件在检测到每个服务器上配置的三个资源池均没有剩余可用资源时，表征每种业务级别的业务量均非常大，此种是特殊情况，一方面，调度组件可以降低资源池1中下单业务的业务级别，使得下单业务对应到资源池2中，同时调整资源池2和资源池1的可调用资源。例如，为资源池2配置7C8G的资源，资源池1配置8C6G的资源，如此结算业务可以单独使用该资源池1的资源，而不用与下单业务共享。而下单业务可以共享资源池2的7C8G资源。

另一方面，调度组件可以从资源池2和资源池3中驱出部分业务，使得资源池2和资源池3空出部分资源，而空出的这部分资源可以被资源池1抢占。

采用本申请实施例的技术方案，具有以下优点：

第一，通过建立资源池，池内资源共享可调用资源来降低调整单个服务资源供给而对服务质量造成影响的风险，降低了对业务的实时负载的监控精度要求。

第二，通过进行不同资源池的业务级别定级，高业务级别的资源池可以抢占低业务级别的资源池的资源，从而实现依据业务需求，动态调整不同资源池之间的资源配置，达到对不同资源池的资源动态调度的目的，从而保障高优业务的服务。

第三，由于属于同一业务属性的业务共享资源池的资源，从而可以实现不同业务对资源池的资源的错峰复用，提升整体资源利用率。

第四，根据业务的业务属性，可以实时调整不同级别资源池的资源配置，优化资源使用，保障高优在线业务服务的服务质量的同时，提升整体资源利用率。

基于与上述实施例同一发明构思，本公开实施例的第二方面，提供了一种资源调度装置，参照图8所示，示出了该资源调度装置的结构示意图，如图8所示，所述装置具体可以包括以下模块：

资源池创建模块801，用于在集群中的每个节点上创建多个资源池，其中，不同的资源池对应不同的业务属性，同一资源池用于响应属于同一业务属性的至少一种业务；

资源上限确定模块802，用于基于每个资源池所对应的至少一种业务各自的实时负载，确定每个资源池对应的资源上限；其中，每个资源池对应的资源上限小于等于该资源池所对应的至少一种业务各自所需的最大资源之和；

资源配置模块803，用于基于每个所述资源池的资源上限，为每个所述资源池配置所述节点上的可调用资源；其中，每个资源池对应的至少一种业务共享该资源池所被配置的可调用资源。

可选地，所述装置还包括：

第一资源池确定模块，用于对到来的业务请求，基于所述业务请求所属的业务属性，从各个资源池中确定与所述业务请求对应的目标资源池；

资源调用模块，用于从所述目标资源池被配置的可调用资源中调用部分或全部资源，以响应所述业务请求；

资源释放模块，用于在响应所述业务请求结束时，将被调用的所述部分或全部资源释放。

可选地，所述装置还包括：

第一监控模块，用于对所述集群中每个节点上每个资源池的资源利用率进行监控；其中，所述资源利用率表征资源池的可调用资源被使用的程度；

剩余资源确定模块，用于基于监控到的每个节点上每个资源池的资源利用率，确定每个节点上每个资源池的剩余可用资源，和/或，确定每个节点的总剩余可用资源；

所述第一资源池确定模块，具体用于基于每个节点上每个资源池的剩余可用资源，和/或每个节点的总剩余可用资源，从所述集群中确定所述目标资源池。

可选地，所述业务属性为业务级别，所述业务级别用于表征业务的优先级；所述装置还包括：

第二监控模块，用于对所述集群中每个节点上每个资源池的资源利用率进行监控；

第一资源抢占模块，用于在存在所述资源利用率达到第一预设资源利用率的过载资源池，且所述过载资源池不为业务级别最低的资源池的情况下，调用业务级别低于所述过载资源池的低级别资源池所配置的可调用资源，以响应到达所述过载资源池的业务请求。

可选地，所述第一资源抢占模块，包括：

第一确定单元，用于确定业务级别低于所述过载资源池的低级别资源池的资源利用率；

第二确定单元，用于基于所述低级别资源池的资源利用率以及所述低级别资源池各自对应的资源上限，从所述低级别资源池中确定待资源占用的资源池；

调用单元，用于调用所述待资源占用的资源池所配置的可调用资源，响应到达所述过载资源池的业务请求。

可选地，所述第一资源抢占模块，包括：

第三确定单元，用于基于所述低级别资源池的资源利用率，确定所述低级别资源池所配置的可调用资源是否全部为所述低级别资源池调用；

第一调用单元，用于在所述低级别资源池所配置的可调用资源全部为所述低级别资源池调用的情况下，则抢占所述低级别资源池所正在调用的资源，以通过抢占的资源响应到达所述过载资源池的业务请求；

第二调用单元，用于在所述低级别资源池所配置的可调用资源未全部为所述低级别资源池调用的情况下则从所述低级别资源池所配置的可调用资源中，调用未被所述低级别资源池所调用的资源，以响应到达所述过载资源池的业务请求。

可选地，资源上限确定模块802，包括：

第一获取单元，用于获取每种业务对应的历史负载；

业务负载确定单元，用于基于每种业务对应的实时负载和所述历史负载，确定每种业务的负载上限；

资源上限确定单元，用于基于每个资源池所对应的至少一种业务各自的负载上限，确定每个资源池对应的资源上限。

可选地，所述装置还包括：

资源上限更新模块，用于每间隔预设时间，基于每种业务对应的实时负载，对每个所述资源池对应的资源上限进行更新；

可调用资源更新模块，用于基于每个所述资源池的更新后的资源上限，更新每个所述资源池所配置的可调用资源。

可选地，所述装置还包括：

控制组配置模块，用于在每个节点上分别为所述多个资源池配置各自的父控制组，以及为每个所述资源池所对应的至少一种业务配置各自的子控制组；

调用模块，用于对到达每个所述资源池的业务请求，通过所述业务请求所属的业务的子控制组调用该资源池所配置的可调用资源，以响应所述业务请求；

所述资源配置模块803，用于基于每个所述资源池的资源上限，通过所述父控制组为每个所述资源池配置所在节点上的可调用资源。

可选地，所述业务属性为业务级别，所述业务级别用于表征业务的优先级，所述装置还包括：

第三监控模块，用于对所述集群中每个节点上每个资源池的资源利用率进行监控；

第一处理模块，用于在各个所述资源池的资源利用率均达到第一预设资源利用率的情况下，对最高业务级别的资源池所对应的部分业务进行业务级别降级，以利用业务级别低的资源池响应所述部分业务；和/或，将除最高业务级别外的其余资源池所处理的部分业务驱逐出所述其余资源池，以使所述最高业务级别的资源池抢占被驱逐的部分业务调用的资源；

第二处理模块，用于在存在资源利用率小于第二预设资源利用率的低负载资源池时，降低所述低负载资源池的可调用资源；

其中，第二预设资源利用率小于所述第一预设资源利用率。

可选地，所述装置还包括：

业务属性检测模块，用于在检测到各种业务中至少一个业务的业务属性变更时，获取所述各种业务的变更后业务属性；

资源池更新模块，用于基于所述各种业务的变更后业务属性，对所述多个资源池各自所响应的业务进行更新；

可调用资源调整模块，用于基于更新后的资源池所响应的业务的实时负载，调整所述更新后的资源池的可调用资源。

本实施例还提供了一种资源调度系统，系统示意图可以参见图7所示的图，所述系统包括：策略计算组件以及业务响应组件；其中，所述业务响应组件，位于集群中的每个节点上；所述策略计算组件与所述集群中的每个节点通信链接；

所述业务响应组件，用于创建多个资源池，其中，不同的资源池对应不同的业务属性，同一资源池用于响应属于同一业务属性的至少一种业务；

所述策略计算组件，用于基于每个资源池所对应的至少一种业务各自的实时负载，确定每个资源池的资源上限；其中，每个资源池的资源上限小于该资源池所对应的至少一种业务各自所需的资源上限之和；

所述业务响应组件，还用于基于每个所述资源池的资源上限，为每个所述资源池配置所述节点上的可调用资源；其中，每个资源池对应的至少一种业务共享该资源池所被配置的可调用资源。

需要说明的是，装置实施例与方法实施例相近，故描述的较为简单，相关之处参见方法实施例即可。

本发明实施例还提供了一种电子设备，该电子设备可以包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器被配置为执行所述的资源调度方法。

本申请实施例还提供了一种非临时性计算机可读存储介质，当所述存储介质中的指令由处理器执行时，使得所述处理器能够执行一种以实现本申请上述的资源调度方法所执行的操作。

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

本领域内的技术人员应明白，本发明实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。

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

以上对本发明所提供的一种资源调度方法、装置、系统、电子设备及介质，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (15)

1.一种资源调度方法，其特征在于，所述方法包括：

在集群中的每个节点上创建多个资源池，其中，不同的资源池对应不同的业务属性，同一资源池用于响应属于同一业务属性的至少一种业务；

基于每个资源池所对应的至少一种业务各自的实时负载，确定每个资源池对应的资源上限；其中，每个资源池对应的资源上限小于等于该资源池所对应的至少一种业务各自所需的最大资源之和；

基于每个所述资源池的资源上限，为每个所述资源池配置所在节点上的可调用资源；其中，每个资源池对应的至少一种业务共享该资源池所被配置的可调用资源。

2.根据权利要求1所述的方法，其特征在于，所述方法包括：

对到来的业务请求，基于所述业务请求所属的业务属性，从各个资源池中确定与所述业务请求对应的目标资源池；

从所述目标资源池被配置的可调用资源中调用部分或全部资源，以响应所述业务请求；

在响应所述业务请求结束时，将被调用的所述部分或全部资源释放。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

对所述集群中每个节点上每个资源池的资源利用率进行监控；其中，所述资源利用率表征资源池的可调用资源被使用的程度，包括细粒度的资源分配调度统计；

基于监控到的每个节点上每个资源池的资源利用率，确定每个节点上每个资源池的剩余可用资源，和/或，确定每个节点的总剩余可用资源；

所述基于所述业务请求的业务属性，从各个资源池中确定与所述业务请求对应的目标资源池，包括：

基于每个节点上剩余可用资源，和/或每个资源池的属性，从所述集群中确定所述目标资源池。

资源池的属性包括资源池的优先级及具体的资源配置隔离策略等。

4.根据权利要求1-3任一所述的方法，其特征在于，所述业务属性为业务级别，所述业务级别用于表征业务的优先级；所述方法还包括：

对所述集群中每个节点上每个资源池的资源利用率进行监控；

在存在所述资源利用率达到第一预设资源利用率的过载资源池，且所述过载资源池不为业务级别最低的资源池的情况下，调用业务级别低于所述过载资源池的低级别资源池所配置的可调用资源，以响应到达所述过载资源池的业务请求。

5.根据权利要求4所述的方法，其特征在于，在所述低级别资源池为多个的情况下，调用业务级别低于所述过载资源池的低级别资源池所配置的可调用资源，以响应到达所述过载资源池的业务请求，包括：

基于各个所述低级别资源池的资源利用率，从各所述低级别资源池中确定待资源占用的资源池；

调用所述待资源占用的资源池所配置的可调用资源，响应到达所述过载资源池的业务请求。

6.根据权利要求4所述的方法，其特征在于，调用业务级别低于所述过载资源池的低级别资源池所配置的可调用资源，响应到达所述过载资源池的业务请求，包括：

基于所述低级别资源池的资源利用率，确定所述低级别资源池所配置的可调用资源是否全部为所述低级别资源池调用；

若是，则抢占所述低级别资源池所正在调用的资源，以通过抢占的资源响应到达所述过载资源池的业务请求；

若否，则从所述低级别资源池所配置的可调用资源中，调用未被所述低级别资源池所调用的资源，以响应到达所述过载资源池的业务请求。

7.根据权利要求1-3、5-6任一所述的方法，其特征在于，基于每个资源池所对应的至少一种业务各自的实时负载，确定每个资源池对应的资源上限，包括：

获取每种业务对应的历史负载；

基于每种业务对应的实时负载和所述历史负载，确定每种业务的负载上限；

基于每个资源池所对应的至少一种业务各自的负载上限，确定每个资源池对应的资源上限。

8.根据权利要求1-3、5-6任一所述的方法，其特征在于，所述方法还包括：

每间隔预设时间，基于每种业务对应的实时负载，对每个所述资源池对应的资源上限进行更新；

基于每个所述资源池的更新后的资源上限，更新每个所述资源池所配置的可调用资源。

9.根据权利要求1-3、5-6任一所述的方法，其特征在于，所述方法还包括：

在每个节点上分别为所述多个资源池配置各自的父控制组，以及为每个所述资源池所对应的至少一种业务配置各自的子控制组；

对到达每个所述资源池的业务请求，通过所述业务请求所属的业务的子控制组调用该资源池所配置的可调用资源，以响应所述业务请求；

基于每个所述资源池的资源上限，为每个所述资源池配置所在节点上的可调用资源，包括：

基于每个所述资源池的资源上限，通过所述父控制组为每个所述资源池配置所在节点上的可调用资源。

10.根据权利要求1所述的方法，其特征在于，所述业务属性为业务级别，所述业务级别用于表征业务的优先级，所述方法还包括：

对所述集群中每个节点上每个资源池的资源利用率进行监控；

在各个所述资源池的资源利用率均达到第一预设资源利用率的情况下，对最高业务级别的资源池所对应的部分业务进行业务级别降级，以利用业务级别低的资源池响应所述部分业务；和/或，将除最高业务级别外的其余资源池所处理的部分业务驱逐出所述其余资源池，以使所述最高业务级别的资源池抢占被驱逐的部分业务调用的资源；

在存在资源利用率小于第二预设资源利用率的低负载资源池时，降低所述低负载资源池的可调用资源；

其中，第二预设资源利用率小于所述第一预设资源利用率。

11.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在检测到各种业务中至少一个业务的业务属性变更时，获取所述各种业务的变更后业务属性；

基于所述各种业务的变更后业务属性，对所述多个资源池各自所响应的业务进行更新；

基于更新后的资源池所响应的业务的实时负载，调整所述更新后的资源池的可调用资源。

12.一种资源调度装置，其特征在于，所述装置包括：

资源池创建模块，用于在集群中的每个节点上创建多个资源池，其中，不同的资源池对应不同的业务属性，同一资源池用于响应属于同一业务属性的至少一种业务；

资源上限确定模块，用于基于每个资源池所对应的至少一种业务各自的实时负载，确定每个资源池对应的资源上限；其中，每个资源池对应的资源上限小于等于该资源池所对应的至少一种业务各自所需的最大资源之和；

资源配置模块，用于基于每个所述资源池的资源上限，为每个所述资源池配置所述节点上的可调用资源；其中，每个资源池对应的至少一种业务共享该资源池所被配置的可调用资源。

13.一种资源调度系统，其特征在于，所述系统包括：策略计算组件以及业务响应组件；其中，所述业务响应组件，位于集群中的每个节点上；所述策略计算组件与所述集群中的每个节点通信链接；

所述业务响应组件，用于创建多个资源池，其中，不同的资源池对应不同的业务属性，同一资源池用于响应属于同一业务属性的至少一种业务；

所述策略计算组件，用于基于每个资源池所对应的至少一种业务各自的实时负载，确定每个资源池的资源上限；其中，每个资源池的资源上限小于等于该资源池所对应的至少一种业务各自所需的资源上限之和；

所述业务响应组件，还用于基于每个所述资源池的资源上限，为每个所述资源池配置所述节点上的可调用资源；其中，每个资源池对应的至少一种业务共享该资源池所被配置的可调用资源。

14.一种电子设备，其特征在于，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行时实现如权利要求1-11任一项所述的资源调度方法。

15.一种计算机可读存储介质，其特征在于，其存储的计算机程序使得处理器执行如权利要求1-11任一项所述的资源调度方法。

Images