具体实施方式

下面将参考若干示例性实施方式来描述本公开的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本公开的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

根据本公开的实施方式，提出了一种负载均衡方法、介质、装置和计算设备。

在本文中，需要理解的是，所涉及的术语表示。此外，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

下面参考本公开的若干代表性实施方式，详细阐释本公开的原理和精神。

应用场景总览

请参见图1，图1为本公开示出的一种采用三级处理器缓存架构的计算设备的示意图。

如图1所示，上述计算设备可以搭载多个物理CPU(中央处理器)，该多个物理CPU共同访问同一个物理内存。其中，上述物理CPU是指上述计算设备的主板上实际插入的CPU硬件。而上述计算设备搭载的物理CPU的数量，则是指上述计算设备的主板上实际插入的CPU硬件的数量。上述计算设备搭载的每一个物理CPU，都可以是多核CPU，可以包括多个CPU内核(如图1示出的cpu core)。进一步的，为了提高各个CPU内核对内存的访问效率，可以为每个CPU内核分别设置多级缓存。

上述多级缓存，是指位于CPU和内存之间的临时存储器。一般而言，上述多级缓存通常包括三级缓存，分别为L1 cache(第一级缓存)、L2cache(第二级缓存)和L3cache(第三级缓存)。

其中，上述L1 cache，通常设置在CPU内核内部的，由该CPU内核独享的缓存，用于存储CPU需要访问的数据和需要执行的指令；在实际应用中，L1 cache又可以进一步划分为用于存储数据的L1 D-Cache和用于存储指令的L1 I-Cache。

上述L2 cache，通常也是设置在CPU内核内部的，由该CPU内核独享的缓存，用于存储CPU需要访问的数据。

需要说明的是，在实际应用中，L2 cache也可以是设置在CPU内核的外部，由多个CPU内核共享的缓存，在本说明书中不进行特别限定。例如，图1示出的L2 cache为设置在CPU内核的内部，由该CPU内核独享的缓存。而在实际应用中，图1示出的L2 cache也可以如L3 cache一样，设置在CPU内核的外部，由多个CPU内核共享。

上述L3 cache，通常是设置在CPU内核的外部，由多个CPU内核共享的缓存，用于存储CPU需要访问的数据。

在图1示出的三级处理器缓存架构，由于各个物理CPU共同访问同一个物理内存，因此如果物理CPU的CPU内核数量过多，会使各个物理CPU面临性能瓶颈。

请参见图2，图2为本公开示出的一种采用NUMA(Non Uniform Memory Access，非统一内存访问)架构的计算设备的示意图。

NUMA架构，是在图1示出的三级处理器缓存架构的基础上，衍生出的一种处理器架构。其中，在NUMA架构下，可以为各个物理CPU分别设置独享的内存，从而相对于图1示出的架构，可以缓解由于物理CPU的CPU内核数量过多而引起的各个物理CPU的性能瓶颈。

如图2所示，在NUMA架构下，可以将计算设备搭载的CPU划分成多个NUMA node。

例如，如图2所示，在NUMA架构下，可以将计算设备搭载的各个物理CPU分别作为一个独立的NUMA node；比如，假设计算设备搭载了N个物理CPU，则可以将该N个物理CPU分别划分为N个NUMA node，每一个NUMA node对应一个独立的物理CPU。

其中，如图2所示，各个NUMA node内部的CPU内核之间共享L3cache；而各个NUMAnode中的CPU内核，与其它NUMA node中的CPU内核之间，则并不共享L3 cache。

在NUMA架构下，在将计算设备搭载的CPU划分成多个NUMA node之后，还可以为每个NUMA node分配独享的内存。

例如，在实际应用中，可以按照NUMA node的总数量，将计算设备搭载的内存，平均分配到各个NUMA node；比如，假设采用NUMA机构的计算设备一共有N个NUMA node，计算设备搭载的内存的容量为M，则每一个NUMA node分配搭配的独享的内存的容量为N/M。

请继续参见图2，在采用NUMA架构的计算设备中，各个NUMA node之间可以通过NUMA互联模块来实现互联。其中，各个NUMA node通过NUMA互联模块来实现互联的具体技术细节，在本说明书中不再赘述。

一方面，NUMA node可以通过内部通道(比如IO总线)来访问独享的内存(称之为Local Access)；另一方面，也可以通过NUMA互联模块来远程访问其它NUMA node独享的内存(称之为Remote Access)。

其中，为NUMA node分配的独享的内存，可以称之为该NUMA node的本地内存；而为其它NUMA node分配的内存，则可以称之该NUMA node的远程内存。

在实际应用中，NUMA node在通过内部通道来访问本地内存时，通常可以直接基于该本地内存的内存地址，快速访问到对应的数据。而NUMA node在访问其它NUMA node的内存时，由于需要通过NUMA互联模块来远程访问，因此相较于访问本地内存而言，通常具有较低的访问速度。

需要补充说明的是，计算设备搭载的CPU的数量，通常是指计算设备搭载的逻辑CPU的数量。

在实际应用中，图1和图2中示出的每一个物理CPU上的每一个CPU内核，均可以采用超线程技术(Hyper-Threading)，将其进一步模拟成一对逻辑CPU。

在这种情况下，计算设备搭载的CPU的数量，则取决于该计算设备搭载的物理CPU的数量以及每一个物理CPU所包含的CPU内核的数量。

例如，假设一个计算设备搭载了N个物理CPU，每一个物理CPU又包括M个CPU内核；而每一个CPU内核又可以基于超线程技术，进一步模拟成一对逻辑CPU。则该计算设备搭载的逻辑CPU的数量为N*M*2。举例而言，假设上述计算设备搭载2个物理CPU，每个物理CPU均为4CPU内核的多核CPU的话，此时N的取值为2，M的取值为4，则该计算设备搭载的逻辑CPU的数量为16个。

如图2示出的计算设备，可以用于承担至少两类不同的业务对应的处理任务。例如，在一个例子中，可以将在线业务和离线业务，混合部署在上述计算设备上。

除此之外，在将至少两类不同的业务混合部署到上述计算设备时，为了让计算设备所承担的处理任务，能够在其搭载的各逻辑CPU之间均衡的进行调度，通常可以在计算设备的操作系统内核中，将其搭载的各逻辑CPU划分成为若干调度域。

其中，在计算设备的操作系统内核中，对其搭载的各逻辑CPU划分调度域时，通常可以将计算设备搭载的所有逻辑CPU，划分为一个调度域。再进一步将计算设备搭载的所有逻辑CPU中共享L3 cache的CPU，分别划分至同一个调度组。也即，划分出的每一个调度组中的CPU均共享L3 cache。

如图2所示，如前所述，由于各物理CPU所包含的各逻辑CPU之间是共享L3 cache的；因此，通过以上描述的调度组的划分方式，相当于是将计算设备搭载的各物理CPU所包含的各个逻辑CPU，分别划分至同一个调度组。最终划分出的调度组的数量，与计算设备搭载的物理CPU的数量相同。

例如，请参见图2，对于采用NUMA架构的计算设备，由于各个物理CPU将分别作为一个独立的NUMA node；因此，在按照以上描述的方式划分调度组时，可以将计算设备搭载的所有逻辑CPU划分为一个大的调度域，再将各个物理CPU对应的NUMA node所包含的逻辑CPU，划分为一个独立的调度组。

在这种情况下，假设该计算设备包括N个NUMA node，则每一个NUMA node中所包含的逻辑CPU将共同构成一个独立的调度组，此时上述调度域中一共可以包括与各NUMA node对应的N个调度组。

在实际应用中，为了避免混合部署的不同类型的业务之间相互影响，通常还可以对计算设备承担的不同类型的业务进行业务隔离。

其中，目前对业务进行隔离的一种通用的解决方案是cpuset方案。所谓cpuset方案，是指通过将业务对应的业务处理进程与特定的一个或者多个CPU内核进行绑定的方式，将该业务对应的业务处理进程的执行，限制到特定的一个或者多个CPU内核之中进行运行，以实现业务隔离的方案。由于cpuset方案易于实现，并且隔离性好，因此是目前应用较为广泛的通用隔离方案。

在采用cpuset方案进行业务隔离时，由于此前已经在计算设备的操作系统内核中，对计算设备搭载的各逻辑CPU划分了调度域和调度组；因此，可以将计算设备搭载的不同类型的业务，分别部署到不同的调度组中，并将不同类型的业务分别与其对应的调度组进行绑定，来实现业务的隔离。

以在上述计算设备上混合部署在线业务和离线业务为例，进行举例说明。

假设计算设备一共包括两个NUMA node，分别记为NUMA nodeA和NUMA nodeB。NUMAnodeA与划分出的第一调度组对应；NUMA nodeB与划分出的第二调度组对应。

在这种情况下，可以将在线业务部署到第一调度组，由该第一调度组中的CPU来承担在线业务对应的处理任务；相应的，还可以将离线业务部署到第二调度组，由该第二调度组中的CPU来承担离线业务对应的处理任务。

同时，为了实现在线业务和离线业务的隔离，可以采用以上描述的cpuset方案，将在线业务与第一调度组绑定，将离线业务与第二调度组绑定。

在将在线业务部署到第一调度组，并且将在线业务与第一调度组绑定之后，后续计算设备可以基于负载均衡策略，将该第一调度组中的各个CPU承担的在线业务对应的处理任务，在第一调度组中的各个CPU之间进行负载均衡处理，以使第一调度组中的各个CPU承担的与在线业务对应的处理任务，能够达到一个负载平衡的状态。

相应的，在将离线业务部署到第二调度组，并且将离线业务与第二调度组绑定之后，后续计算设备也可以基于负载均衡策略，将该第二调度组中的各个CPU承担的离线业务对应的处理任务，在第二调度组中的各个CPU之间进行负载均衡处理，以使第二调度组中的各个CPU承担的离线业务对应的处理任务，也能够达到一个负载平衡的状态。

进一步的，在实际应用中，当上述第一调度组或者上述第二调度组中的某一个调度组承担的处理任务负载过重(比如承担的处理任务进程的数量达到阈值)，此时可能需要对该调度组进行扩容，从其它的调度组分配新的CPU来承担处理任务。

例如，假设与在线业务绑定的NUMA nodeA(即第一调度组)中承担的任务负载过重，则可以从NUMA nodeB(即第二调度组)中为NUMA nodeA分配若干CPU，来承担在线业务对应的处理任务。

然而，在对某一个调度组进行扩容时，从其它的调度组为该调度组分配的新的CPU，为其绑定的业务类型，与该被扩容的调度组绑定的业务类型通常并不一致；因此，这种绑定的业务类型的不一致，可能会对处理任务在各个调度组之间的负载均衡调度造成一定的限制，进而可能导致各个调度组承担的处理任务无法达到负载平衡。

例如，假设与在线业务绑定的NUMA nodeA中承担的任务负载过重，在从NUMAnodeB中为NUMA nodeA分配若干CPU之后，分配的这些CPU是与离线业务绑定的。而计算设备所采用的负载均衡调度策略，优先在与同一类业务绑定的业务调度组之间进行业务调度的策略。

这就可能导致，即便从NUMA nodeB中为NUMA nodeA分配了若干CPU，但由于分配的这些CPU并没有与在线业务绑定，而是仍然与离线业务绑定的；因此，计算设备在NUMAnodeA中的CPU进行负载均衡处理时，仍然无法将NUMA nodeA中的CPU超负荷承担的在线业务的处理任务，调度至新分配的这些CPU进行处理。

这样，就会导致分配的这些CPU的处理资源无法被充分的利用，新分配的这些CPU与NUMA nodeA中的CPU承担的处理任务始终处于无法达到负载平衡。比如，可能会出现NUMAnodeA中的CPU仍然负载过重，而从NUMA nodeB中为NUMA nodeA分配的若干CPU承担的在线业务的业务负载仍然较低甚至完全空载的情况。

可见，在计算设备混合部署多种业务，并且通过Cpuset方案实现多种业务的业务隔离的场景下，一旦涉及跨调度组的CPU扩容，可能会出现扩容出的CPU的处理资源，无法被充分利用的问题。

发明概述

如前所述，在采用如图1或图2示出的架构的计算设备上混合部署多种业务，并且通过Cpuset方案实现多种业务的业务隔离的场景下，一旦涉及跨调度组的CPU扩容，通常会出现扩容出的CPU的处理资源，无法被充分利用的问题。

有鉴于此，本说明书提供一种在计算设备混合部署多种业务，并且通过Cpuset方案实现多种业务的业务隔离的场景下，如何在进行跨调度组的CPU扩容时，充分利用扩容出的CPU的处理资源，使扩容出的CPU和已有的CPU达到负载平衡的负载均衡方法。

本说明书的核心技术构思在于：

开放针对计算设备的各个调度组中的CPU与业务的绑定关系的修改权限，使得与计算设备的第一调度组绑定的第一类业务在满足扩容条件时，可以从与第二类业务绑定的第二调度组中为该第一类业务分配若干CPU，并通过修改这些CPU与业务的绑定的关系的方式，将这些CPU与第一类业务进行绑定，再基于与第一类业务绑定的这些CPU创建扩容调度组，来分担第一调度组承担的第一类业务的负载压力。

通过这种方式，由于计算设备在对第一类业务进行负载均衡处理时，通常需要将与该第一类业务对应的处理任务，在与该第一类业务绑定的多个调度组之间进行负载均衡调度；因此，在已经存在了与第一类业务绑定的第一调度组的基础上，再基于从第二调度组中分配的与第一类业务绑定的若干处理器创建一个扩容调度组，可以使计算设备基于搭载的负载均衡策略，将第一类业务对应的处理任务，在该第一调度组和扩容调度组之间进行负载均衡处理，将第一调度组承载的第一类业务的处理任务，调度至上述扩容调度组，从而来缓解第一调度组的负载压力；

而且，由于上述扩容调度组中的处理器，可以不再与第二类业务进行绑定，而是与第一类业务进行绑定；因此，还可以避免在将第一类业务对应的处理任务，在该第一调度组和扩容调度组之间进行负载均衡处理的过程中，由于第一调度组和扩容调度组绑定的业务类型不一致，无法将第一调度组承载的第一类业务的处理任务，调度至上述扩容调度组，而导致的第一调度组和扩容调度组承载的处理任务出现不均衡的问题，从而可以充分利用扩容调度组中的处理器的处理资源，避免扩容调度组中的处理器的处理资源无法得到充分利用。

示例性方法

下面将通过具体的实施例对本说明书的技术构思进行详细描述。

请参见图3，图3是一示例性实施例提供的一种负载均衡方法的流程图。所述方法应用于计算设备上。

其中，在所述计算设备中，可以包括多个处理器；所述多个处理器可以均采用图1示出的三级缓存架构；所述多个处理器至少被划分为第一调度组和第二调度组；第一调度组中的至少部分处理器与第一类业务绑定；第二调度组中的至少部分处理器与第二类业务绑定；所述计算设备开放了用于对处理器与业务的绑定关系进行修改的接口；第一调度组中的处理器之间共享L3 cache，所述第二调度组中的处理器之间共享L3cache；所述第一调度组中的处理器和所述第二调度组中的处理器之间不共享L3 cache；所述方法执行以下步骤：

步骤301，接收针对所述第一类业务的扩容指令；其中，所述扩容指令包括所述第二调度组的标识信息；

上述计算设备，可以是任意形式的能够混合部署多类业务的硬件设备；例如，在一个例子中，上述计算设备可以是云计算平台中用于承担计算任务的计算设备；在另一个例子中，上述计算设备也可以面向用户提供各类实时或者非实时服务的服务器。

上述第一类业务和第二类业务的具体业务类型，在本说明书中不进行特别限定，在实际应用中，可以包括任意类型的能够混合部署在同一台计算设备上的业务；

在一个例子中，上述第一类业务可以是在线业务，上述第二类业务可以是离线业务；或者，上述第一类业务可以是离线业务；上述第二类业务可以是在线业务。其中，需要解释的是，在线业务可以是实时性比较高的业务；相反，离线业务可以是对实时性要求不高的业务；

例如，以上述计算设备为云计算平台中承担计算任务的计算设备为例，在这种场景下，上述在线业务可以是实时的云计算任务；而上述离线业务则可以是在后台中离线执行的离线计算任务；

又如，以上述计算设备为面向用户提供各类实时或者离线服务的音乐播放类APP的服务器为例，在这种场景下，上述在线业务可以是面向用户提供的在线播放服务；而上述离线业务则可以是面向用户提供的离线音乐下载的服务。

在另一个例子中，上述第一类业务和第二类业务除了可以是在线业务或者离线业务以外，也可以是其他类型的业务；

例如，以上述计算设备为某音乐播放类APP的服务器为例，在这种场景下，上述第一类业务可以是面向普通用户提供的音乐版权购买业务；而上述第二类业务则可以是面向专业的音乐人提供的音乐版权分成业务。上述计算设备可以搭载多个物理CPU，每一个物理CPU都可以是包括多个CPU内核的多核CPU；当上述计算设备支持超线程技术的话，每一个CPU内核，还可以被进一步模拟成一对逻辑CPU。在这种情况下，该计算设备搭载的CPU的数量，通常是指计算设备搭载的逻辑CPU的数量，该逻辑CPU的数量则取决于该计算设备搭载的物理CPU的数量以及每一个物理CPU所包含的CPU内核的数量。

例如，在一个例子中，假设上述计算设备搭载2个物理CPU，每个物理CPU均为4CPU内核的多核CPU，并且每个的CPU内核采用超线程技术又被进一步模拟成一对逻辑CPU的话，则该计算设备搭载的逻辑CPU的数量为4*2*2＝16个。

上述计算设备搭载的CPU，可以被划分为若干调度域，每一个调度与可以被进步划分为若干调度组。

其中，在将第一类业务和第二类业务混合部署在计算设备上的应用场景下，被划分出的若干调度组可以包括；用于承担第一类业务的处理任务的第一调度组；以及，用于承担第二类业务的处理任务的第二调度组。

例如，在实现时，可以将计算设备搭载的所有逻辑CPU，划分为一个调度域。进一步的，由于每一个物理CPU下的逻辑CPU共享L3 cach；则可以将计算设备搭载的各物理CPU，分别划分至不同的调度组。在这种情况下，上述第一调度组和上述第二调度组，将分别对应不同的物理CPU。

在示出的一种实施方式中，上述计算设备具体可以采用如图2所示的NUMA架构。当上述计算设备采用NUMA架构，上述计算设备可以包括多个NUMA node；比如，至少可以包括第一NUMA node和第二NUMA node。在这种情况下，可以将NUMA架构下的所有逻辑CPU划分为一个调度域；再将第一NUMA node划分为上述第一调度域，将第一NUMA node划分为上述第二调度域。

对于划分出的上述第一调度域和上述第二调度域，仍然可以采用前述的cpuset的方案，将上述第一类业务与上述第一调度域绑定，将上述第二类业务与上述第二类业务绑定，以实现在计算设备上混合部署第一类业务和第二类业务的情况下，第一类业务和第二类业务之间的业务隔离。

在本说明书中，当上述第一类业务或者第二类业务满足了扩容条件时，还可以通过触发扩容指令的方式，来为第一类业务或者第二类业务进行扩容。

其中，上述扩容条件，可以基于实际的扩容需求由用户进行灵活定制；例如，上述扩容条件，可以包括承担上述第一类业务或者第二类业务的处理任务的CPU的利用率达到阈值；上述第一类业务或者第二类业务对应处理任务的数量达到阈值(比如业务进程数量达到阈值)，等等，在本说明书中不再进行一一列举。

在一个例子中，上述扩容指令，具体可以是计算设备在上述第一类业务或者第二类业务满足扩容条件时，由计算设备自动触发创建的扩容指令。在另一个例子中，上述计算设备具体可以面向用户(比如业务管理人员)提供与业务相关的命令行工具；比如，该命令行工具可以是一个面向用户提供指令输入服务的客户端软件。在这种情况下，上述扩容指令可以是用户在上述第一类业务或者第二类业务满足扩容条件时，通过命令行工具手动输入的扩容指令。

在本说明书中，假设上述第一类业务满足了扩容条件，此时需要从与第二类业务绑定的第二调度组中，为第一类业务扩容出用于承担第一类业务的处理任务的若干CPU。

在这种情况下，该第一类业务满足了扩容条件时触发的扩容指令中，具体可以包括上述第二调度组的标识。上述计算设备可以接收上述扩容指令，对该扩容指令进行处理，为第一类业务进行扩容。

步骤302，响应于所述扩容指令，从与所述标识信息对应的第二调度组中为所述第一类业务分配若干处理器，并调用所述接口，修改所述若干处理器与业务的绑定关系，将所述若干处理器与所述第一类业务进行绑定，并基于与所述第一类业务绑定的所述若干处理器创建扩容调度组；

上述计算设备在收到上述扩容指令时，可以响应该扩容指令，从第二调度组中为该第一类业务分配若干CPU

在示出的一种实施方式中，在上述第二调度组中，可以预留若干未与第二类业务进行绑定的CPU，用于承担与第一类业务对应的处理任务的CPU集合；其中，该CPU集合中的预留CPU的数量，可以基于计算设备实际包含的CPU总数来进行灵活设置。

在这种情况下，在从第二调度组中为需要扩容的第一类业务分配CPU时，具体可以从上述预留的CPU集合中，为所述第一类业务分配CPU。

当然，在上述第一调度组中，也可以预留若干未与第一类业务进行绑定的CPU，用于承担与第二类业务对应的处理任务的CPU集合。当第二类业务满足扩容条件，也可以从上述CPU集合中为第二类业务分配CPU。

在示出的一种实施方式中，在上述扩容指令中，具体也可以包括从上述第二调度组中为第一类业务分配的若干CPU的标识信息。例如，该扩容指令具体可以是用户通过命令行工具手动输入的扩容指令，此时该扩容指令中具体可以包含由用户指定的需要从上述第二调度组中为第一类业务分配的若干CPU的标识信息。

在这种情况下，在这种情况下，在从第二调度组中为需要扩容的第一类业务分配CPU时，具体可以将上述第二调度组中与该扩容指令中包括的上述标识信息对应的若干CPU，分配给第一类业务。

在本说明书中，从第二调度组中为第一类业务分配的若干CPU默认可能与第二类业务进行了绑定；因此，为了避免这种绑定关系，对后续的负载均衡处理过程造成限制，上述计算设备可以通过开放一个用于对处理器与业务的绑定关系进行修改的接口的方式，将cpuset方案下各个调度组中的CPU与业务的绑定关系的修改权限开放给用户。

在这种情况下，当从第二调度组中为第一类业务分配了若干CPU之后，可以进一步调用上述接口，对分配的这些CPU与业务的绑定关系进行修改，将分配的这些CPU与第一类业务进行绑定，再基于分配的这些与第一类业务绑定的CPU创建扩容调度组。

在示出的一种实施方式中，在调用上述接口，对分配的这些CPU与业务的绑定关系进行修改时，具体可以采用动态热修改的方式，即时的对第二调度组中的CPU与业务的绑定关系进行调整，将这些CPU与与第一类业务进行绑定。

通过采用动态热修改的方式，可以使从第二调度组中为该第一类业务分配的若干CPU与第一类业务的绑定关系，能够即时生效，而无需重新启动计算设备。

当然，在实际应用中，除了采用这种动态热修改的方式，也仍然可以采用设备需要重启后修改才能生效的传统的冷修改的方式，在本说明书中不进行特别限定。

在示出的一种实施方式中，上述计算设备搭载的操作系统的内核，通常会根据设备搭载的物理CPU的物理拓扑结构，来如实的描述调度域和调度组，通常会在操作系统的内核维护一个用于描述上述第一调度域和上述第二调度组所隶属的调度域的拓扑结构的拓扑数据；例如，在实际应用中，该拓扑数据通常是操作系统内核中维护的一个结构体；比如，该结构体通常为操作系统内核中维护的一个名为struct sched_domain_topology_level的结构体文件。

而在该拓扑数据中，还会进一步包括一些用于描述该调度域中的各个调度组中的处理器与业务之间的绑定关系的描述信息；例如，在实际应用中，该拓扑数据通常是操作系统内核中维护的一个结构体；比如，该结构体通常为操作系统内核中维护的一个名为sched_domain_mask_fmask的变量。

在相关技术中，由于操作系统的内核，通常会根据设备搭载的物理CPU的物理拓扑结构，来如实的描述调度域和调度组；因此，一般而言，上述结构体和描述信息，描述的是计算设备搭载的物理CPU的真实的物理拓扑结构。

在本说明书中，为了使两个在物理上相互隔离的调度组之间，能够灵活的互相扩容CPU，可以开放针对上述结构体中的上述描述信息的修改权限，使得用户可以基于实际的扩容需求，灵活的对调度组中的CPU与业务的绑定关系进行调整，而不受计算设备搭载的物理CPU本身的物理拓扑结构的限制。

其中，需要说明的是，如前所述，针对上述描述信息的修改，具体也可以是一种动态热修改，以确保针对该描述信息的修改，可以即时生效而不需要重新启动上述计算设备。

在示出的一种实施方式中，上述计算设备开放的用于对处理器与业务的绑定关系进行修改的接口，具体可以是一个用于对操作系统的内核中维护的上述描述信息进行修改的用户态接口；比如，该用户态接口可以是一个用于开放上述描述信息的修改权限的API接口。

在这种情况下，当计算设备从第二调度组中为该第一类业务分配若干CPU之后，可以进一步调用上述用户态接口，对与上述第二调度组对应的上述描述信息进行修改，为分配的若干CPU创建与第一类业务的绑定关系。

例如，在一个例子中，假设为该第一类业务分配的若干CPU，为上述预留的CPU集合中的CPU，此时这些CPU与第二类业务并没有进行绑定；则可以直接在与上述第二调度组对应的上述描述信息中，新增这些CPU与第一类业务的绑定关系即可。

在另一个例子中，假设为该第一类业务分配的若干CPU，不是上述预留的CPU集合中的CPU，预先与第二类业务进行了绑定；则可以对与上述第二调度组对应的上述描述信息进行修改，将该描述信息中维护的上述若干CPU与第二类业务的绑定关系，重新修改为上述若干CPU与第一类业务的绑定关系。

其中，在一种实现方式中，在为分配的若干CPU创建与第一类业务的绑定关系时，具体可以将分配的若干CPU与第一类业务对应的业务处理进程进行绑定，在上述描述信息中创建分配的若干CPU与第一类业务对应的业务处理进程之间的绑定关系。

需要说明的是，与第一类业务对应的业务处理进程与CPU之间的绑定关系，通常是指业务处理进程与CPU之间的亲和性关系。而业务处理进程与某个CPU之间具有亲和性关系，通常是指该业务处理进程需要在该CPU上尽量长时间地运行，而不被迁移到其他CPU。

进一步的，在通过调用上述用户态接口，对上述第二调度组的描述信息进行修改，为分配的若干CPU创建与第一类业务的绑定关系之后，此时可以基于分配的这些CPU创建一个扩容调度组，以触发对上述第二调度组进行重建，从上述第二调度组中划分出一个与第一类业务绑定的扩容调度组。

此时重建之后的第二调度组包括两个调度组，其中一个是与第一类业务绑定的扩容调度组，另一个是由剩余的CPU组成的与第二类业务绑定的调度组。

步骤303，采用负载均衡策略针对所述第一调度组和所述扩容调度组进行负载均衡处理，以将所述第一调度组承担的所述第一类业务中的至少部分的处理任务，调度至所述扩容调度组。

在本说明书中，当计算设备响应于上述扩容指令，从第二调度组中为第一类业务分配若干CPU，并基于分配的若干CPU创建了与第一类业务绑定的扩容调度组之后，后续计算设备可以基于负载均衡策略，对上述第一调度组和上述扩容调度组进行负载均衡处理，以将第一调度组承担的第一类业务中的至少部分的处理任务，调度至该扩容调度组，以缓解第一调度组中的负载压力。

在示出的一种实施方式中，上述计算设备所采用的负载均衡策略，仍然可以是优先在与同一类业务绑定的业务调度组之间进行业务调度的策略。

由于新建的上述扩容调度组与业务的绑定关系，已经通过以上描述的方式修改为与第一类业务绑定；此时上述第一调度组和上述扩容调度组均与第一类业务绑定；因此，采用优先在与同一类业务绑定的业务调度组之间进行业务调度的策略，可以正常的将第一调度组承担的第一类业务中的至少部分的处理任务，调度至该扩容调度组。

需要说明的是，在实际应用中，计算设备采用负载均衡策略，对上述第一调度组和上述扩容调度组进行负载均衡处理时，通常是以上述第一调度组和上述扩容调度组中的各个CPU为单位的负载均衡处理过程。

在实现时，计算设备通常可以依次确定上述第一调度组和上述扩容调度组中的各个CPU是否满足负载均衡处理条件，当任一CPU满足了负载处理均衡条件，可以采用与上述负载均衡策略相关的负载均衡算法，对该CPU进行负载均衡处理。

其中，需要说明的是，上述计算设备所采用的与上述负载均衡策略对应的负载均衡算法的具体类型，在本说明书中不进行特别限定。

在示出的一种实施方式中，上述负载均衡算法具体可以是CFS(completely fairschedule，完全公平调度)算法。

请参见图4，图4是一示例性实施例提供的一种对第一调度组和上述扩容调度组进行负载均衡处理的流程图，包括以下步骤：

步骤401，当所述扩容调度组中任一目标处理器满足负载均衡处理条件时，确定所述第一调度组和所述扩容调度组中业务负载较大的调度组；

基于CFS算法，假设上述扩容调度组中任一目标CPU满足负载均衡条件时，可以确定上述第一调度组和上述扩容调度组中业务负载较大的调度组；比如，确定上述第一调度组和上述扩容调度组中承载的进程数较多的调度组。

步骤402，如果所述第一调度组的业务负载较大，进一步确认所述第一调度组中业务负载最高的处理器；以及，将确定出的所述业务负载最高的处理器承担的所述第一类业务中的至少部分的处理任务，调度至所述目标处理器。

如果上述第一调度组的业务负载较大，可以进一步确认上述第一调度组中业务负载最高的CPU，并将确定出的业务负载最高的CPU承担的第一类业务中的至少部分的处理任务，调度至该目标CPU；例如，将该业务负载最高的处理器承担的第一类业务中的至少部分的业务处理进程，迁移至上述目标CPU。

通过这种调度方式，可以逐渐将第一调度组中承担的处理任务，分担给新扩容出来的扩容调度组，以使第一调度组和扩容调度组中的CPU承担的处理任务，能够达到负载平衡的状态，进而缓解第一调度组的负载压力。

当然，如果一段时间后，上述第一调度组中除了上述目标CPU以外的其它任一CPU满足了负载均衡处理条件，此时针对该第一调度组和上述扩容调度组的负载均衡处理过程，与以上描述的类似，不再赘述。其中，需要补充说明的是，上述负载均衡处理条件，通常取决于计算设备所采用的负载均衡算法，在本说明书中不进行特别的限定；

例如，如果采用的负载均衡算法为CFS算法，则常见的负载均衡处理条件可以包括如下的几种情况：

在一种情况下，针对上述第一调度组和上述扩容调度组中的各个CPU，可以周期性的进行负载均衡处理；例如，可以由用户为各CPU分别配置一个固定的进行负载均衡处理的时刻；其中，不同的CPU的负载均衡处理的时刻可以不同。在这种情况下，对于某一个CPU而言，如果该CPU满足了周期性进行负载均衡处理的条件，也即当前的时刻到达为该CPU配置的进行负载均衡处理的时刻，则视为该CPU已经满足了负载均衡条件。

在另一种情况下，上述第一调度组和上述扩容调度组中的各个CPU的负载均衡条件，也可以是CPU承载的处理任务的数量低于阈值。在这种情况下，对于某一个CPU而言，如果该CPU承载的处理任务的数量低于阈值。则视为该CPU已经满足了负载均衡条件。

在以上实施例中，由于计算设备在对第一类业务进行负载均衡处理时，通常需要将与该第一类业务对应的处理任务，在与该第一类业务绑定的多个调度组之间进行负载均衡调度；因此，在已经存在了与第一类业务绑定的第一调度组的基础上，再基于从第二调度组中分配的与第一类业务绑定的若干处理器创建一个扩容调度组，可以使计算设备基于搭载的负载均衡策略，将第一类业务对应的处理任务，在该第一调度组和扩容调度组之间进行负载均衡处理，将第一调度组承载的第一类业务的处理任务，调度至上述扩容调度组，从而来缓解第一调度组的负载压力。

而且，由于上述扩容调度组中的处理器，可以不再与第二类业务进行绑定，而是与第一类业务进行绑定；因此，还可以避免在将第一类业务对应的处理任务，在该第一调度组和扩容调度组之间进行负载均衡处理的过程中，由于第一调度组和扩容调度组绑定的业务类型不一致，无法将第一调度组承载的第一类业务的处理任务，调度至上述扩容调度组，而导致的第一调度组和扩容调度组承载的处理任务出现不均衡的问题，从而可以充分利用扩容调度组中的处理器的处理资源，避免扩容调度组中的处理器的处理资源无法得到充分利用。

在本公开的示例性实施例中，还提供了一种能够实现上述方法的电子设备。

在本公开的示例性实施例中，还提供一种负载均衡装置。图5示出了上述负载均衡装置500的结构示意图，如图5所示，上述负载均衡装置500可以包括：接收模块510、创建模块520和调度模块530。其中：

接收模块510被配置为，接收针对所述第一类业务的扩容指令；其中，所述扩容指令包括所述第二调度组的标识信息；

创建模块520被配置为，响应于所述扩容指令，从与所述标识信息对应的第二调度组中为所述第一类业务分配若干处理器，并调用所述接口，修改所述若干处理器与业务的绑定关系，将所述若干处理器与所述第一类业务进行绑定，并基于与所述第一类业务绑定的所述若干处理器创建扩容调度组；

调度模块530被配置为，采用负载均衡策略针对所述第一调度组和所述扩容调度组进行负载均衡处理，以将所述第一调度组承担的所述第一类业务中的至少部分的处理任务，调度至所述扩容调度组。

上述负载均衡装置500的各个模块的具体细节已经在之前描述负载均衡方法流程中进行了详细的描述，因此此处不再赘述。

应当注意，尽管在上文详细描述中提及负载均衡装置500的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

在本公开的示例性实施例中，还提供了一种能够实现上述方法的电子设备。

下面参照图6来描述根据本公开的这种实施例的电子设备600。图6显示的电子设备600仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图6所示，电子设备600以通用计算设备的形式表现。电子设备600的组件可以包括但不限于：上述至少一个处理单元601、上述至少一个存储单元602、连接不同系统组件(包括存储单元602和处理单元601)的总线603。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元601执行，使得所述处理单元601执行本说明书上述各种实施例的步骤。

存储单元602可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)6021和/或高速缓存存储单元6022，还可以进一步包括只读存储单元(ROM)6023。

存储单元602还可以包括具有一组(至少一个)程序模块6025的程序/使用工具6024，这样的程序模块6025包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包含网络环境的现实。

总线603可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备600也可以与一个或多个外部设备604(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备600交互的设备通信，和/或与使得该电子设备600能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口605进行。并且，电子设备600还可以通过网络适配器606与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器606通过总线603与电子设备600的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备600使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施例的描述，本领域的技术人员易于理解，这里描述的示例实施例可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施例的方法。

在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施例中，本公开的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施例的步骤。

参考图7所示，描述了根据本公开的实施例的用于实现上述方法的程序产品70，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本公开的其他实施例。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由权利要求指出。

应当注意，尽管在上文详细描述中提及了装置的若干单元/模块或子单元/模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。

此外，尽管在附图中以特定顺序描述了本公开方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

虽然已经参考若干具体实施方式描述了本公开的精神和原理，但是应该理解，本公开并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本公开旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。