资源分配方法、装置、系统、设备和介质

摘要

一种资源分配方法、装置、系统、设备和介质，所述方法包括：接收资源分配请求，所述资源分配请求包括业务类型和资源类型；根据所述业务类型和所述资源类型，确定资源阈值；将剩余资源率大于所述资源阈值的服务器作为候选服务器；在所述候选服务器中确定一个或多个目标服务器，以使所述目标服务器基于所述资源分配请求分配资源。采用本发明实施例后，能够提高服务器资源分配的均衡性和避免资源争抢。

权利要求

1.一种资源分配方法，包括：

接收资源分配请求，所述资源分配请求包括业务类型和资源类型；

根据所述业务类型和所述资源类型，确定资源阈值；

将剩余资源率大于所述资源阈值的服务器作为候选服务器；

在所述候选服务器中确定一个或多个目标服务器，以使所述目标服务器基于所述资源分配请求分配资源。

2.根据权利要求1所述资源分配方法，其中，所述业务类型包括独占业务和/或共享业务；

所述资源类型包括内存资源、CPU资源、MAC地址资源和IP地址资源中的至少一种。

3.根据权利要求1所述资源分配方法，其中，所述将剩余资源率大于所述资源阈值的服务器作为候选服务器，包括：将每一种资源类型的剩余资源率均大于相应的资源阈值的服务器，作为所述候选服务器。

4.根据权利要求1所述资源分配方法，其中，所述资源分配请求还包括资源需求量；

所述将剩余资源大于所述资源阈值的服务器作为候选服务器，包括：将剩余资源率大于所述资源阈值，且剩余资源量大于或等于所述资源需求量的服务器作为候选服务器。

5.根据权利要求1所述资源分配方法，其中，所述剩余资源率为剩余资源量与服务器的总资源量的比值，所述剩余资源量为所述服务器的总资源量与所述服务器的已占用资源量的差，所述服务器的已占用资源量为每一种业务类型的已占用资源量之和，所述业务类型以业务标识区分。

6.根据权利要求1所述资源分配方法，其中，还包括：预测目标资源需求量和资源消耗量，所述目标资源需求量为目标时间段内客户端的资源需求总量，所述资源消耗量为当前时间段的终点到所述目标时间段的起点时间内所有服务器减少的剩余资源量，所述当前时间段的终点到所述目标时间段的起点的时长为预设的资源补充周期；

当当前时间段所有服务器的剩余资源量之和小于所述目标资源需求量与所述资源消耗量之和时，对资源进行补充以增加服务器的剩余资源。

7.根据权利要求6所述资源分配方法，其中，所述资源需求总量为各客户端在目标时间段内的资源需求量之和与预设系数的乘积。

8.一种资源分配方法，包括：

向中心服务器上报剩余资源率；

接收所述中心服务器发送的资源分配指令，所述资源分配指令基于客户端发送的资源分配请求而发出；

基于所述资源分配指令，为所述客户端分配资源。

9.根据权利要求8所述资源分配方法，其中，所述资源分配请求包括业务类型和资源类型，所述业务类型包括独占业务和/或共享业务；

所述资源类型包括内存资源、CPU资源、MAC地址资源和IP地址资源中的至少一种。

10.根据权利要求9所述资源分配方法，其中，所述资源分配请求还包括资源需求量；

所述方法还包括：

向所述中心服务器上报剩余资源量。

11.根据权利要求8所述资源分配方法，其中，所述剩余资源率为剩余资源量与服务器的总资源量的比值，所述剩余资源量为所述服务器的总资源量与所述服务器的已占用资源量的差，所述服务器的已占用资源为每一种业务类型的已占用资源量之和，所述业务类型以业务标识区分。

12.一种资源分配装置，包括：

接收模块，用于接收资源分配请求，所述资源分配请求包括业务类型和资源类型；

确定模块，用于所述业务类型和所述资源类型，确定资源阈值；

候选模块，用于将剩余资源率大于所述资源阈值的服务器作为候选服务器；

目标模块，用于在所述候选服务器中确定一个或多个目标服务器，以使所述目标服务器基于所述资源分配请求分配资源。

13.一种资源分配装置，包括：

上报模块，用于上报剩余资源率；

接收模块，用于接收所述中心服务器发送的资源分配指令，所述资源分配指令基于客户端发送的资源分配请求而发出；

分配模块，用于基于所述资源分配指令，为所述客户端分配资源。

14.一种资源分配系统，包括如权利要求12所述资源分配装置和如权利要求13所述资源分配装置。

15.一种计算设备，包括：

存储器，用于存储程序；

处理器，用于运行所述存储器中存储的所述程序，以执行如权利要求1-7任一所述资源分配方法，或如权利要求8-11任一所述资源分配方法。

16.一种计算机可读存储介质，其上存储有计算机程序指令，当所述计算机程序指令被处理器执行时实现如权利要求1-7中任一项所述资源分配方法，或如权利要求8-11任一所述资源分配方法。

说明书

资源分配方法、装置、系统、设备和介质

技术领域

[0001] 本发明涉及计算机领域，尤其涉及一种资源分配方法、装置、系统、设备和计算机存储介质。

背景技术

[0002] 弹性计算服务(Elastic Compute Service，ECS)为用户提供一个根据需求动态运行的虚拟机环境，虚拟机创建于ECS的云服务器上。对于ECS提供的虚拟机，用户可以像使用一台物理机器一样进行各种操作。ECS允许用户根据自己的需要，租用多个虚拟机来完成各种任务，这多个虚拟机可以位于同一个云服务器上，也可以位于不同的云服务器上。在运行的过程中，用户也可以根据计算资源的需要动态增加或减少虚拟机的数量。

[0003] ECS可以向用户提供多种业务类型的云服务器产品，用户可以根据自身需求来进行选择。例如，业务类型可以包括“包年包月”和“按量付费”。“包年包月”要求用户每次最少购买一个月，到期可以自动续费，属于生命周期比较稳定的云服务器产品。“按量付费”按照使用时长付费，不用可立即释放，属于非稳定生命周期的产品。其收费形式按照云服务器生命周期划分：对应分钟付费收费方式、小时收费方式、天收费方式、月收费方式以及年收费方式。对于上述两种业务类型的云服务器产品，在实际生产过程中，遵循相同的流程：选择地域－选择可用区－选择集群－选择云服务器，最后在特定的云服务器(server)上创建虚拟机，为用户提供计算服务。

[0004] 现有技术中通常人工设定集群的云服务器产品的售卖数量上限，以调控云服务器的资源分配。人工设定上限的资源分配方式存在以下问题：1)没有考虑用户的业务类型和服务器的运行状态，难以实现云服务器的资源分配平衡。2)库存资源量(即服务器上的剩余资源量)更新不及时，可能会将同一资源分配给多个用户，造成资源争抢。

发明内容

[0005] 本发明实施例提供了一种资源分配方法、装置、系统、设备和计算机存储介质，能够提高服务器资源分配的均衡性和解决资源争抢。

[0006] 一种资源分配方法，包括：

[0007] 接收资源分配请求，所述资源分配请求包括业务类型和资源类型；

[0008] 根据所述业务类型和所述资源类型，确定资源阈值；

[0009] 将剩余资源率大于所述资源阈值的服务器作为候选服务器；

[0010] 在所述候选服务器中确定一个或多个目标服务器，以使所述目标服务器基于所述资源分配请求分配资源。

[0011] 所述业务类型包括独占业务和/或共享业务；

[0012] 所述资源类型包括内存资源、CPU资源、MAC地址资源和IP地址资源中的至少一种。

[0013] 所述将剩余资源率大于所述资源阈值的服务器作为候选服务器，包括：

[0014] 将每一种资源类型的剩余资源率均大于相应的资源阈值的服务器，作为所述候选服务器。

[0015] 所述资源分配请求还包括资源需求量；

[0016] 所述将剩余资源大于所述资源阈值的服务器作为候选服务器，包括：

[0017] 将剩余资源率大于所述资源阈值，且剩余资源量大于或等于所述资源需求量的服务器作为候选服务器。

[0018] 所述剩余资源率为剩余资源量与服务器的总资源量的比值，所述剩余资源量为所述服务器的总资源量与所述服务器的已占用资源量的差，所述服务器的已占用资源量为每一种业务类型的已占用资源量之和，所述业务类型以业务标识区分。

[0019] 还包括：

[0020] 预测目标资源需求量和资源消耗量，所述目标资源需求量为目标时间段内客户端的资源需求总量，所述资源消耗量为当前时间段的终点到所述目标时间段的起点时间内所有服务器减少的剩余资源量，所述当前时间段的终点到所述目标时间段的起点的时长为预设的资源补充周期；

[0021] 当当前时间段所有服务器的剩余资源量之和小于所述目标资源需求量与所述资源消耗量之和时，对资源进行补充以增加服务器的剩余资源。

[0022] 所述资源需求总量为各客户端在目标时间段内的资源需求量之和与预设系数的乘积。

[0023] 一种资源分配方法，包括：

[0024] 向中心服务器上报剩余资源率；

[0025] 接收所述中心服务器发送的资源分配指令，所述资源分配指令基于客户端发送的资源分配请求而发出；

[0026] 基于所述资源分配指令，为所述客户端分配资源。

[0027] 所述资源分配请求包括业务类型和资源类型，所述业务类型包括独占业务和/或共享业务；

[0028] 所述资源类型包括内存资源、CPU资源、MAC地址资源和IP地址资源中的至少一种。

[0029] 所述资源分配请求还包括资源需求量；

[0030] 所述方法还包括：

[0031] 向所述中心服务器上报剩余资源量。

[0032] 所述剩余资源率为剩余资源量与服务器的总资源量的比值，所述剩余资源量为所述服务器的总资源量与所述服务器的已占用资源量的差，所述服务器的已占用资源为每一种业务类型的已占用资源量之和，所述业务类型以业务标识区分。

[0033] 一种资源分配装置，包括：

[0034] 接收模块，用于接收资源分配请求，所述资源分配请求包括业务类型和资源类型；

[0035] 确定模块，用于所述业务类型和所述资源类型，确定资源阈值；

[0036] 候选模块，用于将剩余资源率大于所述资源阈值的服务器作为候选服务器；

[0037] 目标模块，用于在所述候选服务器中确定一个或多个目标服务器，以使所述目标服务器基于所述资源分配请求分配资源。

[0038] 一种资源分配装置，包括：

[0039] 上报模块，用于上报剩余资源率；

[0040] 接收模块，用于接收所述中心服务器发送的资源分配指令，所述资源分配指令基于客户端发送的资源分配请求而发出；

[0041] 分配模块，用于基于所述资源分配指令，为所述客户端分配资源。

[0042] 一种资源分配系统，包括如上述资源分配装置。

[0043] 一种计算设备，包括：存储器，用于存储程序；

[0044] 处理器，用于运行所述存储器中存储的所述程序，以执行如上述资源分配方法。

[0045] 一种计算机可读存储介质，其上存储有计算机程序指令，当所述计算机程序指令被处理器执行时实现如上述资源分配方法。

[0046] 从上述技术方案中可以看出，根据接收的资源分配请求中业务类型和资源类型，确定资源阈值。然后，可以基于资源阈值筛选出候选服务器。并非每个候选服务器可以服务于客户端。而是需要在候选服务器中确定一个或多个目标服务器，以使目标服务器基于资源分配请求分配资源。目标服务器的剩余资源率需要满足资源阈值，进而能够提高服务器资源分配的均衡性。

附图说明

[0047] 从下面结合附图对本发明的具体实施方式的描述中可以更好地理解本发明其中，相同或相似的附图标记表示相同或相似的特征。

[0048] 图1是本发明实施例中资源分配系统的结构示意图；

[0049] 图2是本发明实施例资源分配方法的流程示意图；

[0050] 图3是本发明另一个实施例资源分配方法的流程示意图；

[0051] 图4是本发明实施例资源分配装置的结构示意图；

[0052] 图5是本发明另一个实施例资源分配装置的结构示意图；

[0053] 图6是本发明实施例资源分配系统的结构示意图；

[0054] 图7是本发明实施例资源分配方法和装置的计算设备的示例性硬件架构的结构图。

具体实施方式

[0055] 为使本发明的目的、技术方案和优点表达得更加清楚明白，下面结合附图及具体实施例对本发明再作进一步详细的说明。

[0056] 下面将详细描述本申请的各个方面的特征和示例性实施例，为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细描述。应理解，此处所描述的具体实施例仅被配置为解释本申请，并不被配置为限定本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。

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

[0058] 在云计算环境中，不同客户端业务在不同时期对于资源的需求是不同的，ECS可以根据用户的业务需求调整其使用的计算资源，从而实现在业务高峰时增加计算资源，以及在业务需求下降时减少计算资源以节约成本。

[0059] 在实际生产过程中，通过选择地域、可用区、集群和云服务器，用户的业务需求在特定的云服务器上的虚拟机，得到计算服务。

[0060] 人工设定集群的云服务器产品的售卖数量上限，以调控云服务器的资源分配。一方面，存在云服务器的资源分配失衡的问题；另一方面，可能会将同一资源分配给多个用户，造成资源争抢的问题。

[0061] 参见图1，图1是本发明实施例中资源分配系统的结构示意图，具体包括客户端、服务节点和中心节点。其中，服务节点与中心节点耦合。

[0062] 在本发明实施例中，中心节点在资源分配系统中管理服务节点的资源。服务节点和中心节点可以是服务器。也就是说，服务节点是服务器，中心节点也是服务器，作为一个示例，服务器可以是云服务器。

[0063] 中心节点在资源分配系统中管理服务节点的资源。具体来说，服务节点向中心节点上报自身的剩余资源的信息。其中，上报自身的剩余资源的信息可以是周期性上报或定时上报。作为一个示例，服务节点向中心节点周期性上报自身的剩余资源的信息，剩余资源的信息包括剩余CPU核数、剩余内存容量和剩余IP地址数量。中心节点接收到每个服务节点上报的剩余资源的信息，存储上报的剩余资源的信息。可知，中心节点中存储有下属服务节点的剩余资源的信息。

[0064] 用户通过客户端可以向中心节点发送资源分配请求。客户端发送资源分配请求的目的在于，在服务节点中获取可以向客户端提供资源的目标服务器。

[0065] 在本发明的一个实施例中，客户端向中心节点发送的资源分配请求中包括业务类型和资源类型。业务类型是客户端所请求业务的种类。资源类型是客户端所请求的资源种类。

[0066] 作为一个示例，业务类型包括独占业务和/或共享业务。独占业务为服务器面向特定的客户端，独立占用进行相应的资源生产。共享业务为当服务器的资源足够的时候，可以将独占后剩余资源用于其他业务的生产。换言之，独占业务的优先级高于共享业务。服务器优先为独占业务提供服务；只有当服务器满足了独占业务的生产需求之后，若仍有足够的剩余资源，才用于向共享业务提供服务。应当指出，上述独占业务、共享业务的二级业务类型划分仅为一个示例，在其他的实施例中，也可以将业务类型设置为包括第一业务、第二业务、…第N业务的N级划分，不同的业务类型有不同的优先级。服务器按照优先级来为各业务提供服务，即，服务器优先为优先级最高的业务来提供服务。

[0067] 作为另一个示例，客户端根据不同的业务需求，向中心节点发送的资源分配请求包括不同的资源类型。资源类型可以包括下属资源中的至少一种，内存资源、CPU资源、MAC地址资源和IP地址资源。也就是说，客户端所请求的资源类型，不仅可以包括一种资源还可以包括其他类型的资源。

[0068] 业务类型的不同，所使用的资源类型也是不同的。不同的业务，所需的资源类型是不同的。考虑到业务类型的不同，对资源需求量也并非相同。作为一个示例，业务类型是独占业务，该独占业务的计算量比较大，对于CPU资源和内存资源要求较高。那么，客户端向中心节点发送的资源分配请求中还可以包括资源需求量。资源需求量为客户端所请求资源类型的数量。例如，资源需求量包括2核CPU和4G内存。

[0069] 中心节点接收客户端发送的资源分配请求，并从管理的服务节点中为客户端分配提供资源的目标服务器。中心节点可以是独立服务器，也可以是与服务节点共用服务器。

[0070] 在本发明的一个实施例中，中心节点接收到客户端发送的资源分配请求，资源分配请求包括业务类型和资源类型。

[0071] 中心节点可以根据业务类型和资源类型，确定资源阈值。资源阈值是服务节点向客户端提供可用资源的参数。资源阈值由业务类型和资源类型确定。需要说明的是，资源阈值是预先基于业务类型和资源类型设置。作为一个示例，可以按照业务类型的种类和资源类型的种类，设置业务类型、资源类型与资源阈值的关联列表。通过查找上述关联列表，即可确定某一业务类型和某一资源类型所对应的资源阈值。

[0072] 在本发明的一个实施例中，由于独占业务的优先级高于共享业务，因此，针对同一种资源类型，独占业务对应的资源阈值小于共享业务对应的资源阈值。例如，对于CPU资源而言，独占业务对应的资源阈值为0.1，共享业务对应的资源阈值为0.7。这样，当服务器的CPU剩余资源率较少(0.10.7)时，该服务器才可以为共享业务提供服务(当然这时候服务器也是可以为独占业务提供服务的)。而当服务器的CPU剩余资源率很少(CPU剩余资源率≤0.1)时，服务器不对新来的业务提供服务，即，既不向新的独占业务提供服务，也不为新的共享业务提供服务，服务器上的剩余资源仅用于维护服务器上的现有业务的正常运行。

[0073] 作为一个示例，业务类型是共享业务，资源类型包括CPU资源，共享业务、CPU资源所对应的资源阈值可以为0.7。也就是说，若服务节点的CPU剩余资源率大于资源阈值0.7，则可以确定该服务节点为候选服务器。候选服务器是可能为客户端提供资源的服务器。服务节点的剩余资源率等于服务节点的剩余资源与服务节点的总资源的比值。

[0074] 在本发明的一个实施例中，资源类型可以包括多种。每一种资源类型均有相应的资源阈值。那么，可以将每一种资源类型的剩余资源率均大于相应的资源阈值的服务器，作为候选服务器。

[0075] 作为一个示例，业务类型是共享业务，资源类型包括CPU资源和内存资源，独占业务、CPU资源对应的资源阈值为0.7，独占业务、内存资源对应的资源阈值是0.6。那么，若服务节点的剩余CPU资源率大于CPU资源的资源阈值0.7，且服务节点的剩余内存资源率大于内存资源的资源阈值0.6，则可以确定该服务节点为候选服务器。

[0076] 在本发明的一个实施例中，中心节点接收到客户端发送的资源分配请求，资源分配请求包括业务类型、资源类型和资源需求量。即资源分配请求在包括业务类型和资源类型的基础上，还包括资源需求量。

[0077] 中心节点在确定候选服务器的过程中，不仅考虑服务器的剩余资源率，而且还需要考虑服务器的剩余资源量。可以将剩余资源率大于资源阈值，且剩余资源量大于或等于资源需求量的服务器作为候选服务器。

[0078] 作为一个示例，中心节点接收到客户端发送的资源分配请求，资源分配请求包括业务类型、资源类型和资源需求量。业务类型是共享业务，资源类型是内存资源，以及资源需求量是4G内存。独占业务、内存资源所对应的资源阈值是0.6。在服务节点对应的服务器中，将内存剩余资源率大于0.6，且内存剩余资源量大于或等于4G的服务器作为候选服务器。

[0079] 需要说明的是，剩余资源量为服务器的总资源量与服务器的已占用资源量的差。服务器的已占用资源为每一种业务类型的已占用资源量之和。作为一个示例，服务器的已占用资源包括两个业务类型的占用资源，即独占业务占用资源和共享业务占用资源。那么服务器的已占用资源等于独占业务占用资源和共享业务占用资源的和。此外，可以以业务标识区分业务类型。作为一个示例，独占业务的业务标识为第一业务标识；共享业务的业务标识为第二业务标识。剩余资源率为剩余资源量与服务器的总资源量的比值。

[0080] 作为一个示例，标记第一业务标识的业务类型占用内存资源量为10G内存，标记第二业务标识的业务类型占用内存资源量为4G内存。服务器所有的内存资源为16G，剩余资源量等于16G–10G–4G＝2G，剩余资源率等于2G/16G＝0.125。

[0081] 在从服务节点对应的服务器中，基于资源阈值和服务器的剩余资源率筛选得到候选服务器。并非将筛选得到的所有候选服务器用于处理资源分配请求，而是在候选服务器中确定目标服务器。

[0082] 在候选服务器中可以基于资源分配请求的来源区域，确定目标服务器。来源区域是客户端所处的地理位置和/或网络位置，来源区域可以以IP地址等参数标识。

[0083] 在同一个来源区域中，客户端与目标服务器之间的网络时延更小。但由于客户端与目标服务器在同一个来源区域，在该来源区域发生断电等灾难情况，目标服务器有可能难以向客户端提供资源。那么，也可以选择与客户端不属于同一来源区域的目标服务器为客户端提供服务，从而提高容灾能力。

[0084] 为了确保能够及时为客户端提供服务，还可以选择多个目标服务器。其中，多个目标服务器中的一个目标服务器，可以与客户端在同一个来源区域；多个目标服务器中的另一个目标服务器，可以与客户端不在同一个来源区域。这样，与客户端在同一个来源区域的目标服务器，以及与客户端不在同一个来源区域的目标服务器，可以同时为客户端提供服务。进而在降低网络时延的基础上，提高容灾能力。

[0085] 本发明的上述实施例，可以根据业务类型和资源类型来确定资源阈值，进而根据资源阈值来选择服务器，使得剩余资源较少的服务器(对应的资源阈值较小)仅为优先级较高的业务类型提供服务，剩余资源较多的服务器(对应的资源阈值较大)才能为优先级较低的业务类型提供服务。上述实施例在为客户端分配资源时综合考虑了客户端请求的业务类型和服务器的资源状态(剩余资源率)，提高了服务器资源分配的均衡性。

[0086] 本发明的上述实施例用于实现对集群中现有的服务器的剩余资源均衡分配。在本发明的一个实施例中，还可以进行集群资源的动态补充，即，当预测到服务器的剩余资源量无法满足未来某一时间段的客户端需求时，对资源进行补充。

[0087] 需要说明的是，本发明的资源动态补充的实施例与前述现有资源均衡分配的实施例可以合并实施，也可以单独实施而不依赖于前者。

[0088] 在本发明的一个实施例中，资源动态补充的方案单独实施，与前述资源均衡分配的方案没有依赖关系。

[0089] 中心服务器预测目标资源需求量和资源消耗量，当当前时间段所有服务器的剩余资源量之和小于目标资源需求量与资源消耗量之和时，对资源进行补充以增加服务器的剩余资源。资源的补充方式有多种，例如，可以通过增加服务器的方式来补充资源，或者，可以通过向现有的服务器中增加硬件设备(例如内存条、硬盘、网卡等)的方式来补充资源，本发明对资源的具体补充方式不做限制。

[0090] 目标资源需求量为目标时间段内客户端的资源需求总量。目标时间段为距离当前时间段的时长为预设的资源补充周期的未来的时间段，目标时间段与当前时间段的时长相同。例如，时间段的长度均为1天，当前时间段为3月20日，资源补充周期为5天，则目标时间段为3月26日。目标资源需求量即为3月26日一天内客户端的资源需求总量。

[0091] 资源需求总量是各客户端在目标时间段内的资源需求量的总和。若满足全部客户端的需求，则需要服务器在目标时间段内的剩余资源量大于所有客户端的资源需求量的总和。在实际的场景中，可以根据预设系数确定需要满足客户端的需求。也就是说，资源需求总量为各客户端在目标时间段内的资源需求量之和与预设系数的乘积。例如，预设系数为0.9，则将在目标时间段内客户端的资源需求量之和与0.9的乘积作为资源需求总量，该资源需求总量即能够满足未来90％的客户端的需求。预设系数的具体取值可以由本领域技术人员基于实际情况和经验来设置，本发明对此不做限制。

[0092] 资源消耗量为当前时间段的终点到目标时间段的起点时间内所有服务器减少的剩余资源量。例如，资源补充周期为5天，当前时间段为3月20日，目标时间段为3月26日，则资源消耗量为3月20日24：00(即3月21日0：00)至3月26日0：00期间服务器减少的剩余资源量。

[0093] 需要说明的是，本发明对预测目标资源需求量和资源消耗量的具体算法不做限制。在一个实施例中，可以采用机器学习算法(例如线性回归、逻辑回归、神经网络等算法)来预测目标资源需求量和资源消耗量，即，通过资源需求量的历史数据来训练资源需求量模型，以预测未来某一时间段的资源需求量；通过资源消耗量的历史数据来训练资源消耗量模型，以预测未来某一时长内的资源消耗量。

[0094] 在本发明的另一个实施例中，资源动态补充的方案与前述资源均衡分配的方案合并实施。

[0095] 中心节点接收到每个服务节点上报的剩余资源的信息，进而可以获知当前所有服务节点即当前所有服务器的剩余资源总量。中心节点不断接收到客户端发送的资源分配请求，然后基于资源分配请求在服务器中确定目标服务器，目标服务器基于资源分配请求分配资源。当前所有服务节点即服务器的剩余资源总量会随着接收的资源分配请求的增加而变化，那么为了满足客户端的资源分配请求，当前所有服务器的剩余资源总量在难以满足客户端的需求时，则需要扩容，即增加剩余资源。

[0096] 需要说明的是，服务器利用剩余资源主要服务于客户端和服务器自身。

[0097] 对于客户端而言，当服务器作为目标服务器的情况下，该目标服务器基于资源分配请求分配资源。可以以目标资源需求量衡量客户端的资源需求。目标资源需求量为目标时间段内客户端的资源需求总量。

[0098] 作为一个示例，目标时间段时长为1天，则目标资源需求量为1天内客户端的资源需求总量。

[0099] 资源需求总量是各客户端在目标时间段内的资源需求量的总和。若满足全部客户端的需求，则需要服务器在目标时间段内的剩余资源量大于所有客户端的资源需求量的总和。在实际的场景中，可以根据预设系数确定需要满足客户端的需求。也就是说，资源需求总量为各客户端在目标时间段内的资源需求量之和与预设系数的乘积。

[0100] 作为一个示例，预设系数为0.9，则将在目标时间段内满足90％客户端的资源需求量之和作为资源需求总量。

[0101] 对于服务器而言，服务器自身需要预留一定的物理资源，用于保障现有用户的基本功能需求。作为一个示例，预留的物理资源可以用于用户的资源升级等。作为另一个示例，预留的物理资源可以用于服务器的迁移。

[0102] 那么，可以以资源消耗量衡量服务器减少的资源量。资源消耗量为一段时间段内所有服务器减少的剩余资源量。作为一个示例，总时间段包括当前时间段和目标时间段，当前时间段与目标时间段的时长相同。当前时间段是当前时间起点至当前时间终点之间的时间段。目标时间段是目标时间起点至目标时间终点之间的时间段。那么，资源消耗量为当前时间段的终点到目标时间段的起点时间内所有服务器减少的剩余资源量。其中，当前时间段的终点到目标时间段的时长为预设的资源补充周期。资源补充周期为增加服务器的资源所消耗的时间。作为一个示例，通过增加服务器的数量增加服务器的资源。增加服务器需要申请、审批、采购和交付四个过程，那么资源补充周期包括上述四个过程所消耗的时间。

[0103] 作为一个示例，资源补充周期为5天，当前时间段是3月20日，目标时间段是3月26日，则资源消耗量为3月20日24：00(即3月21日0：00)至3月26日0：00期间服务器减少的剩余资源量。

[0104] 在本发明的一个实施例中，基于资源消耗量的历史值，可以预估未来的资源消耗量。其中，预估可以采用机器学习。

[0105] 机器学习是使用算法来解析数据、从中学习，然后做出预测。机器学习是用大量的数据来“训练”，通过各种算法从数据中学习如何完成任务。具体来说，机器学习可以包括线性回归、逻辑回归、决策树和神经网络等，其中，神经网络具体可以是深度学习。

[0106] 在本发明的实施例中，利用机器学习的目的在于预测资源消耗量。为了预测未来某一时间段的资源消耗量，需要先基于资源消耗量的历史数据进行学习。

[0107] 作为一个示例，可以基于实际的资源消耗量和预估的资源消耗量进行机器学习，进而得到资源消耗量预测模型。也就是说，利用实际的资源消耗量和预估的单周期资源消耗量作为数据进行学习，得到可以预测资源消耗量的资源消耗量预测模型。

[0108] 当前时间段所有服务器的剩余资源量需要大于目标资源需求量与资源消耗量之和，才能满足客户端的需求。否则就会出现无法满足客户端需求的情况。也就是说，在当前时间段所有服务器的剩余资源量之和小于目标资源需求量与资源消耗量之和的情况下，对资源进行补充以增加服务器的剩余资源。

[0109] 在本发明的一个实施例中，首先，服务节点向中心节点上报剩余资源率。目的在于，中心节点能够及时获知服务节点的剩余资源的信息。其次，中心节点确定由服务节点为客户端分配资源，则中心节点向服务节点发送资源分配请求。也就是说，资源分配请求是根据客户端发送的资源分配请求而发出的。最后，中心节点根据资源分配指令，为客户端分配资源。这样，服务节点可以基于上报的剩余资源率，接收中心节点的资源分配指令，在中心节点的统一调度下为客户端分配资源，这样就会实现资源分配平衡，不会将同一资源分配给多个用户，造成资源争抢。

[0110] 参见图2，图2是本发明实施例资源分配方法的流程示意图，图2中各步骤的执行主体可以是中心节点，具体包括：

[0111] S201、接收资源分配请求，资源分配请求包括业务类型和资源类型。

[0112] 中心节点与服务节点相耦合，中心节点和服务节点都可以是服务器。

[0113] 一方面，中心节点管理服务节点的资源。中心节点接收服务节点发送的剩余资源的信息。

[0114] 另一方面，客户端需要获取服务器的资源，那么客户端向中心节点发送资源分配请求。中心节点接收客户端发送的资源分配请求。

[0115] 资源分配请求中包括业务类型和资源类型。业务类型是客户端所请求业务的种类。资源类型是客户端所请求的资源种类。作为一个示例，业务类型包括独占业务和/或共享业务。作为另一个示例，资源类型可以包括下属四种资源中的至少一种，内存资源、CPU资源、MAC地址资源和IP地址资源。

[0116] S202、根据业务类型和资源类型，确定资源阈值。

[0117] 中心节点接收客户端发送的资源分配请求，资源分配请求包括业务类型和资源类型。中心节点可以根据业务类型和资源类型，确定资源阈值。

[0118] 资源阈值为表征提供资源的服务器的最小剩余资源率。资源阈值与业务类型和资源类型相关。可以预先基于业务类型和资源类型设置资源阈值。

[0119] S203、将剩余资源率大于资源阈值的服务器作为候选服务器。

[0120] 中心节点利用接收的客户端发送的资源分配请求，在服务节点及服务器中选择候选服务器。剩余资源率为表征服务器空闲资源的参数。

[0121] 并非存在剩余资源的服务节点都可以作为候选服务器。考虑到，不确定存在剩余资源的服务节点的剩余资源是否可以满足客户端的实际需求。因此，需要根据客户端的实际需求，判断存在剩余资源的服务节点是否可以满足。

[0122] 在本发明的一个实施例中，利用剩余资源率度量服务节点的剩余资源。剩余资源率为剩余资源量与服务器的总资源量的比值。剩余资源量为服务器的总资源量与服务器的已占用资源量的差。服务器的已占用资源量为每一种业务类型的已占用资源量之和。

[0123] 通过剩余资源率可以迅速获知服务节点即服务器的剩余资源，进而可以基于剩余资源率，在服务节点中筛选出候选服务器。

[0124] 在本发明的一个实施例中，可以以业务标识区分不同的业务类型。进而，中心节点依据收到的资源分配请求中业务类型的业务标识，能够及时获知业务类型。

[0125] S204、在候选服务器中确定一个或多个目标服务器，以使目标服务器基于资源分配请求分配资源。

[0126] 在候选服务器中，可以确定一个或多个目标服务器。所确定的目标服务器可以根据资源分配请求为客户端分配资源。

[0127] 在候选服务器中确定一个目标服务器，则由该目标服务器根据资源分配请求为客户端分配资源。

[0128] 在候选服务器中确定多个目标服务器，则由多个目标服务器根据资源分配请求为客户端分配资源。多个目标服务器可以按照目标服务器所在的地理位置/网络位置和客户端所在的地理位置/网络位置，分别为客户端分配资源。

[0129] 在本发明实施例中，首先，接收资源分配请求，根据客户端的资源分配请求中业务类型和资源类型，确定资源阈值。然后，基于服务器的剩余资源率和资源阈值筛选候选服务器。最后，在候选服务器中确定目标服务器，由目标服务器基于资源分配请求分配资源。可知，确定目标服务器的过程中，不仅考虑到客户端的资源分配请求，还考虑到服务器的剩余资源，以及目标服务器的数目。因此，一方面能够提高服务器资源分配的均衡性和解决资源争抢，另一方面确定目标服务器向客户端提供资源的可靠性。

[0130] 在本发明的一个实施例中，从整体的角度考虑当前所有服务器的剩余资源。当前所有服务器需要为所有客户端提供资源。若在一个时间段内，无法满足所有客户端的需求，则会出现资源分配失败的问题。

[0131] 那么，为了满足所有客户端的需求，当当前时间段所有服务器的剩余资源量之和小于目标资源需求量与资源消耗量之和时，对资源进行补充以增加服务器的剩余资源。

[0132] 目标资源需求量为目标时间段内客户端的资源需求总量。资源消耗量为一段时间段内所有服务器减少的剩余资源量。

[0133] 这样，采用上述技术方案，能够基于目标资源需求量和资源消耗量及时扩容，以满足所有客户端的需求。

[0134] 在本发明实施例中，资源需求总量为各客户端在目标时间段内的资源需求量之和与预设系数的乘积。

[0135] 可以根据预设系数及时调整资源需求总量，平衡客户端的需求与服务器的剩余资源率之前的关系。

[0136] 参见图3，图3是本发明另一个实施例资源分配方法的流程示意图，图3中各步骤的执行主体可以是服务节点，具体包括：

[0137] S301、向中心节点上报剩余资源率。

[0138] 服务节点与中心节点相耦合。服务节点具体可以是服务器。服务节点可以周期性的向中心节点上报剩余资源，使得中心节点能够及时获知服务节点的剩余资源。

[0139] 作为一个示例，可以以剩余资源率进行上报。剩余资源率为剩余资源量与服务器的总资源量的比值，剩余资源量为服务器的总资源量与服务器的已占用资源量的差，服务器的已占用资源为每一种业务类型的已占用资源量之和，业务类型以业务标识区分。

[0140] 需要说明的是，所上报的剩余资源率大于资源阈值的情况下，服务节点有可能为客户端分配资源。具体来说，资源阈值是由客户端的资源分配请求中业务类型和资源类型确定的参数。

[0141] 在一个实施例中，业务类型包括独占业务和/或共享业务；资源类型包括内存资源、CPU资源、MAC地址资源和IP地址资源中的至少一种。

[0142] 此外，服务节点向中心节点上报的多种剩余资源率。即，每种一种资源类型对应一种剩余资源率。当有多种资源类型的情况下，则服务节点向中心节点上报多种剩余资源率。所上报的每一种剩余资源率均大于相应的资源阈值的情况下，服务节点有可能为客户端分配资源。

[0143] 作为一个示例，服务节点向中心节点上报两种剩余资源率，即CPU剩余资源率和内存剩余资源率。当CPU剩余资源率大于CPU的资源阈值，且内存剩余资源率大于内存的资源阈值，则服务节点有可能为客户端分配资源。

[0144] 在本发明的一个实施例中，客户端的资源分配请求还包括资源需求量。那么，为了便于中心节点确定剩余资源，服务节点还需要上报剩余资源量。在上报的剩余资源量大于或等于客户端的资源需求量的情况下，服务节点有可能为客户端分配资源。

[0145] S302、接收中心节点发送的资源分配指令，资源分配指令基于客户端发送的资源分配请求而发出。

[0146] 中心节点向服务节点发送资源分配指令的目的在于，为客户端分配资源。也就是说，客户端向中心节点发送资源分配请求。之后，中心节点基于前述步骤S201～S204，将服务节点确定为用于向客户端分配资源的目标服务节点，随后，中心节点基于客户端发送的资源分配请求向该服务节点发送资源分配指令。其中，资源分配请求可以包括客户端的业务类型和资源类型。

[0147] S303、基于资源分配指令，为客户端分配资源。

[0148] 当服务节点被确定为用于为客户端分配资源的目标服务节点后，则可以基于资源分配指令中的业务类型和资源类型，针对客户端分配剩余资源率对应的剩余资源。

[0149] 在本发明实施例中，服务节点需要上报剩余资源的情况至中心节点，当中心节点确定服务节点为客户端分配资源，则发送资源分配指令，从而提高服务节点为客户端服务的质量。

[0150] 参见图4，图4是本发明实施例资源分配装置的结构示意图，资源分配装置与资源分配方法相对应，资源分配装置具体包括：

[0151] 接收模块401，用于接收资源分配请求，资源分配请求包括业务类型和资源类型。

[0152] 确定模块402，用于根据业务类型和资源类型，确定资源阈值。

[0153] 候选模块403，用于将剩余资源率大于资源阈值的服务器作为候选服务器。

[0154] 目标模块404，用于在候选服务器中确定一个或多个目标服务器，以使目标服务器基于资源分配请求分配资源。

[0155] 在本发明的一个实施例中，业务类型包括独占业务和/或共享业务；

[0156] 资源类型包括内存资源、CPU资源、MAC地址资源和IP地址资源中的至少一种。

[0157] 在本发明的一个实施例中，候选模块403，具体用于将每一种资源类型的剩余资源率均大于相应的资源阈值的服务器，作为候选服务器。

[0158] 在本发明的一个实施例中，资源分配请求还包括资源需求量；候选模块403，具体用于将剩余资源率大于资源阈值，且剩余资源量大于或等于资源需求量的服务器作为候选服务器。

[0159] 在本发明的一个实施例中，剩余资源率为剩余资源量与服务器的总资源量的比值，剩余资源量为服务器的总资源量与服务器的已占用资源量的差，服务器的已占用资源量为每一种业务类型的已占用资源量之和，业务类型以业务标识区分。

[0160] 在本发明的一个实施例中，资源分配装置还包括控制模块(图中未示出)，用于预测目标资源需求量和资源消耗量，目标资源需求量为目标时间段内客户端的资源需求总量，资源消耗量为当前时间段的终点到目标时间段的起点时间内所有服务器减少的剩余资源量，当前时间段的终点到目标时间段的起点的时长为预设的资源补充周期；

[0161] 当当前时间段所有服务器的剩余资源量之和小于目标资源需求量与资源消耗量之和时，对资源进行补充以增加服务器的剩余资源。。

[0162] 在本发明的一个实施例中，资源需求总量为各客户端在目标时间段内的资源需求量之和与预设系数的乘积。

[0163] 参见图5，图5是本发明另一个实施例资源分配装置的结构示意图，资源分配装置与资源分配方法相对应，资源分配装置具体包括：

[0164] 上报模块501，用于向中心节点上报剩余资源率。

[0165] 接收模块502，用于接收中心节点发送的资源分配指令，资源分配指令基于客户端发送的资源分配请求而发出。

[0166] 分配模块503，用于基于资源分配指令，为所述客户端分配资源。

[0167] 在本发明的一个实施例中，业务类型包括独占业务和/或共享业务；

[0168] 资源类型包括内存资源、CPU资源、MAC地址资源和IP地址资源中的至少一种。

[0169] 在本发明的一个实施例中，剩余资源率包括多种剩余资源率；每一种资源类型的剩余资源率均大于相应的资源阈值。

[0170] 在本发明的一个实施例中，资源分配请求还包括资源需求量；上报模块501，还用于向中心节点上报剩余资源量。

[0171] 在本发明的一个实施例中，剩余资源率为剩余资源量与服务器的总资源量的比值，剩余资源量为服务器的总资源量与服务器的已占用资源量的差，服务器的已占用资源为每一种业务类型的已占用资源量之和，业务类型以业务标识区分。

[0172] 参见图6，图6是本发明实施例资源分配系统的结构示意图。资源分配系统具体包括：图4中的资源分配装置和图5中的资源分配装置。

[0173] 其中，图4中的资源分配装置和图5中的资源分配装置相耦合。

[0174] 图7是示出能够实现根据本发明实施例资源分配方法和装置的计算设备的示例性硬件架构的结构图。

[0175] 如图7所示，计算设备700包括输入设备701、输入接口702、中央处理器703、存储器704、输出接口705、以及输出设备706。其中，输入接口702、中央处理器703、存储器704、以及输出接口705通过总线710相互连接，输入设备701和输出设备706分别通过输入接口702和输出接口705与总线710连接，进而与计算设备700的其他组件连接。

[0176] 具体地，输入设备701接收来自外部的输入信息，并通过输入接口702将输入信息传送到中央处理器703；中央处理器703基于存储器704中存储的计算机可执行指令对输入信息进行处理以生成输出信息，将输出信息临时或者永久地存储在存储器704中，然后通过输出接口705将输出信息传送到输出设备706；输出设备706将输出信息输出到计算设备700的外部供客户端使用。

[0177] 也就是说，图7所示的计算设备也可以被实现为包括：存储有计算机可执行指令的存储器；以及处理器，该处理器在执行计算机可执行指令时可以实现结合图1至图6描述的资源分配方法和装置。

[0178] 最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使对应技术方案的本质脱离本发明各实施例技术方案的范围。