基于多集群的网络调度方法及装置

技术领域

本申请涉及数据处理技术领域，尤其涉及一种基于多集群的网络调度方法及装置。

背景技术

随着业务场景的拓展在一些高可用性能要求较高的场景下，多集群部署成为部署的必然选择。多集群部署是通过多集群多节点实现跨越多个不同服务区甚至地域和国家对外提供服务，是基于业务需求与架构稳定性需求的设计。

但是，目前的多集群场景需要在不同集群启动相应副本，容易导致集群资源的浪费，特别是调用较少的业务场景会造成极大的设备浪费。

发明内容

针对现有技术中的至少一个问题，本申请提出了一种基于多集群的网络调度方法及装置，能够在实现基于多集群的网络调度的基础上，减少资源浪费。

为了解决上述技术问题，本申请提供以下技术方案：

第一方面，本申请提供一种基于多集群的网络调度方法，包括：

接收目标业务类型的业务请求组，该业务请求组包括：多个业务请求；

根据预设的业务类型与执行器之间的对应关系，确定多个集群中所述目标业务类型对应的目标执行器，启动该目标执行器所在的服务器，每个集群包括：多个服务器，每个服务器设有至少一个执行器；

获取各个集群的剩余可用资源，根据所述业务请求组的资源需求量和各个集群的剩余可用资源，确定目标集群，每个集群的剩余可用资源为该集群中的各个目标执行器的剩余可用资源之和；

根据所述目标集群中的各个目标执行器的剩余可用资源，确定各个业务请求各自对应的目标执行器，将各个业务请求发送至各自对应的目标执行器，完成所述业务请求组对应的网络调度。

在一个实施例中，所述根据所述业务请求组的资源需求量和各个集群的剩余可用资源，确定目标集群，包括：

根据剩余可用资源从多到少对各个集群排序；

若前N位的集群的剩余可用资源之和大于等于所述业务请求组的资源需求量，并且前(N-1)位的集群的剩余可用资源之和小于所述业务请求组的资源需求量，则将前N位的各个集群均确定为所述目标集群。

在一个实施例中，所述的基于多集群的网络调度方法，还包括：

若前N位的集群的剩余可用资源之和大于等于所述业务请求组的资源需求量并且N为1，则将首位的集群确定为所述目标集群。

在一个实施例中，所述根据所述目标集群中的各个目标执行器的剩余可用资源，确定各个业务请求各自对应的目标执行器，包括：

根据所述目标集群中的各个目标执行器的剩余可用资源之间比例，确定各个业务请求各自对应的目标执行器。

在一个实施例中，所述根据所述业务请求组的资源需求量和各个集群的剩余可用资源，确定目标集群，包括：

若各个集群的剩余可用资源之和小于所述业务请求组的资源需求量，则进行执行器扩容操作，若扩容操作后的各个集群的剩余可用资源之和大于等于所述业务请求组的资源需求量，则根据所述业务请求组的资源需求量和扩容操作后的各个集群的剩余可用资源，确定目标集群。

在一个实施例中，所述进行执行器扩容操作，包括：

根据剩余可用资源由大到小对各个集群排序，将首位的集群确定为待扩容集群；

根据该待扩容集群中的各个服务器对应的剩余可用资源由大到少，对服务器进行排序，将首位的服务器确定为待扩容服务器，执行扩容步骤，每个服务器对应的剩余可用资源为该个服务器中的各个目标执行器的剩余可用资源之和；

所述扩容步骤包括：增加所述待扩容服务器中的目标执行器的数量，若增加目标执行器的数量之后，各个集群的剩余可用资源之和小于所述业务请求组的资源需求量，则增加所述待扩容集群的下一位服务器中的目标执行器数量，直至增加目标执行器数量之后，各个集群的剩余可用资源之和大于所述业务请求组的资源需求量。

在一个实施例中，在所述增加所述待扩容集群的下一位服务器中的目标执行器数量之后，还包括：

若所述待扩容集群中的各个服务器均增加目标执行器数量之后，各个集群的剩余可用资源之和小于所述业务请求组的资源需求量，则选取下一位的集群并确定为待扩容集群，返回执行所述扩容步骤。

第二方面，本申请提供一种基于多集群的网络调度装置，包括：

接收模块，用于接收目标业务类型的业务请求组，该业务请求组包括：多个业务请求；

启动模块，用于根据预设的业务类型与执行器之间的对应关系，确定多个集群中所述目标业务类型对应的目标执行器，启动该目标执行器所在的服务器，每个集群包括：多个服务器，每个服务器设有至少一个执行器；

确定模块，用于获取各个集群的剩余可用资源，根据所述业务请求组的资源需求量和各个集群的剩余可用资源，确定目标集群，每个集群的剩余可用资源为该集群中的各个目标执行器的剩余可用资源之和；

网络调度模块，用于根据所述目标集群中的各个目标执行器的剩余可用资源，确定各个业务请求各自对应的目标执行器，将各个业务请求发送至各自对应的目标执行器，完成所述业务请求组对应的网络调度。

在一个实施例中，所述确定模块包括：

排序单元，用于根据剩余可用资源从多到少对各个集群排序；

第一确定单元，用于若前N位的集群的剩余可用资源之和大于等于所述业务请求组的资源需求量，并且前(N-1)位的集群的剩余可用资源之和小于所述业务请求组的资源需求量，则将前N位的各个集群均确定为所述目标集群。

在一个实施例中，所述确定单元，还用于：

若前N位的集群的剩余可用资源之和大于等于所述业务请求组的资源需求量并且N为1，则将首位的集群确定为所述目标集群。

在一个实施例中，所述网络调度模块，包括：

第二确定单元，用于根据所述目标集群中的各个目标执行器的剩余可用资源之间比例，确定各个业务请求各自对应的目标执行器。

在一个实施例中，所述确定模块包括：

扩容单元，用于若各个集群的剩余可用资源之和小于所述业务请求组的资源需求量，则进行执行器扩容操作，若扩容操作后的各个集群的剩余可用资源之和大于等于所述业务请求组的资源需求量，则根据所述业务请求组的资源需求量和扩容操作后的各个集群的剩余可用资源，确定目标集群。

在一个实施例中，所述扩容单元还用于：

根据剩余可用资源由大到小对各个集群排序，将首位的集群确定为待扩容集群；

根据该待扩容集群中的各个服务器对应的剩余可用资源由大到少，对服务器进行排序，将首位的服务器确定为待扩容服务器，执行扩容步骤，每个服务器对应的剩余可用资源为该个服务器中的各个目标执行器的剩余可用资源之和；

所述扩容步骤包括：增加所述待扩容服务器中的目标执行器的数量，若增加目标执行器的数量之后，各个集群的剩余可用资源之和小于所述业务请求组的资源需求量，则增加所述待扩容集群的下一位服务器中的目标执行器数量，直至增加目标执行器数量之后，各个集群的剩余可用资源之和大于所述业务请求组的资源需求量。

在一个实施例中，所述扩容单元还用于：

若所述待扩容集群中的各个服务器均增加目标执行器数量之后，各个集群的剩余可用资源之和小于所述业务请求组的资源需求量，则选取下一位的集群并确定为待扩容集群，返回执行所述扩容步骤。

第三方面，本申请提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现所述的基于多集群的网络调度方法。

第四方面，本申请提供一种计算机可读存储介质，其上存储有计算机指令，所述指令被处理器执行时实现所述的基于多集群的网络调度方法。

由上述技术方案可知，本申请提供一种基于多集群的网络调度方法及装置。其中，该方法包括：接收目标业务类型的业务请求组，该业务请求组包括：多个业务请求；根据预设的业务类型与执行器之间的对应关系，确定多个集群中所述目标业务类型对应的目标执行器，启动该目标执行器所在的服务器，每个集群包括：多个服务器，每个服务器设有至少一个执行器；获取各个集群的剩余可用资源，根据所述业务请求组的资源需求量和各个集群的剩余可用资源，确定目标集群，每个集群的剩余可用资源为该集群中的各个目标执行器的剩余可用资源之和；根据所述目标集群中的各个目标执行器的剩余可用资源，确定各个业务请求各自对应的目标执行器，将各个业务请求发送至各自对应的目标执行器，完成所述业务请求组对应的网络调度，能够在实现基于多集群的网络调度的基础上，减少资源浪费；具体地，可以实现跨集群的服务调用的优化，建立统一跨集群调度控制器，针对网络调用的不同场景进行调度策略的优化；实现优化资源使用，提升服务能力。可以通过对逐级分配的多集群的网络负载进行管理，实现多集群中执行器状态可以保持最小状态，同时执行器数量可以根据业务请求动态调整执行器数量，优化集群的各类资源使用。通过各级存储资源的复用，减少资源重复创建与销毁。可以加快业务服务的相应时间同时避免资源的浪费与不必要的性能开销。

附图说明

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

图1是本申请实施例中的基于多集群的网络调度方法的第一流程示意图；

图2是本申请实施例中的基于多集群的网络调度方法的第二流程示意图；

图3是本申请实施例中的基于多集群的网络调度装置的结构示意图；

图4是本申请实施例中的确定模块的结构示意图；

图5是本申请一种举例中的基于多集群的网络调度方法的逻辑示意图；

图6是本申请实施例的电子设备的系统构成示意框图。

具体实施方式

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

为了便于对本方案的理解，首先对于本方案相关的技术术语进行说明。

Serverless：无服务技术，提供业务应用无需关心底层基础设施，根据调用量进行计费，是用户可以专注自身业务逻辑。

业务等级：用户根据自身需求对，业务请求设定相应等级。

执行器状态：执行器当前状态，可以分为启动中，运行中，繁忙，空闲，预销毁，资源回收。

并发度：指单个执行器可以接收的请求上限，由系统压测与用户指定相关数据。

集群资源：一般可以认为是集群中的各类资源如：计算资源包含有：执行器的CPU、内存与磁盘等；网络资源：用户的请求量，网络带宽，网络I/O等；以及一些用户指定的特殊场景，比如用户的业务序列等。

采用Serverless架构可有效的帮助开发效率的提升、构建与部署的简化、运维成本与复杂度的降低。Serverless采用按照调用进行实例创建并提供服务，因此资源的利用效率得到了明显的提高。但随着业务场景的拓展在一些高可用性能要求较高的场景下，多集群部署成为部署的必然选择。因此针对多集群部署架构下的Serverless服务网络调度优化成为影响业务的重要因素。目前亟需对现有Serverless架构的网络调用方案进行优化，实现在多个集群提供稳定高效的Serverless服务。

现有多集群部署方案一般通过在不同集群启动相应预留实例保证多集群情况下可以正常对外服务，网络请求按照一定的规则分配至对应集群中。举例来说，多集群包括集群A、B、C，集群A、C是集群B的副本，集群A、B、C均启动，业务请求组只能够在集群B调度，集群B故障，再将批量业务请求在集群A或C调度，存在资源浪费的问题。

首先多集群场景下需要在不同集群启动相应副本，使得针对大量调用较少的业务场景会造成极大的资源浪费。其次通过负载均衡通常由F5等设备层硬件或者nginx等工具实现，针对动态变化的业务场景难以实现快速实施调整流量策略。基于此，本方案提供一种基于多集群的网络调度方法及装置，实现跨集群调度，可以针对用户调用的不同场景进行调度策略的优化，通过按照集群进行调用分配，从而减少集群资源的浪费，实现优化资源使用，提升服务能力，同时提高针对异常场景的处理能力。

需要说明的是，本申请公开的基于多集群的网络调度方法及装置可用于金融技术领域，也可用于除金融技术领域之外的任意领域，本申请公开的基于多集群的网络调度方法及装置的应用领域不做限定。本申请各实施例的技术方案中对数据的获取、存储、使用、处理等均符合法律法规的相关规定。

具体通过下述各个实施例进行说明。

为了在实现基于多集群的网络调度的基础上，减少资源浪费，本实施例提供一种执行主体是基于多集群的网络调度装置的基于多集群的网络调度方法，该基于多集群的网络调度装置包括但不限于服务器，如图1所示，该方法具体包含有如下内容：

步骤100：接收目标业务类型的业务请求组，该业务请求组包括：多个业务请求。

具体地，所述目标业务类型可以包括：转账业务类型、支付业务类型和还款业务类型等。

步骤200：根据预设的业务类型与执行器之间的对应关系，确定多个集群中所述目标业务类型对应的目标执行器，启动该目标执行器所在的服务器，每个集群包括：多个服务器，每个服务器设有至少一个执行器。

具体地，所述业务类型与执行器之间的对应关系可以根据实际情况进行设置，本申请对此不作限制。所述预设的业务类型与执行器之间的对应关系可以预先存储在所述网络调度装置本地，将所述业务类型与执行器之间的对应关系中所述目标业务类型对应的执行器确定为所述目标执行器，可以仅启动目标执行器所在的服务器。执行器可以表示能够执行任务的组件或服务。所述目标执行器可以为所述执行器中的至少一个。举例来说，多集群包括集群A、B、C，集群A、C不是集群B的副本，若业务请求组对应的目标执行器为集群A中的服务器1和集群B中的服务器2内的执行器，那么仅启动服务器1和服务器2即可，无需启动其他服务器，可以减少资源消耗。

步骤300：获取各个集群的剩余可用资源，根据所述业务请求组的资源需求量和各个集群的剩余可用资源，确定目标集群，每个集群的剩余可用资源为该集群中的各个目标执行器的剩余可用资源之和。

具体地，执行器的剩余可用资源可以为该执行器的当前可用并发数，执行器M的当前可用并发数＝执行器M的并发度-执行器M已接收的业务请求数量。业务请求组的资源需求量可以为该业务请求组中的业务请求数量。执行器M已接收的业务请求数量可以为接收目标业务类型的业务请求组之前，执行器M接收到的业务请求数量。

步骤400：根据所述目标集群中的各个目标执行器的剩余可用资源，确定各个业务请求各自对应的目标执行器，将各个业务请求发送至各自对应的目标执行器，完成所述业务请求组对应的网络调度。

一般同一集群在相同机房，可以使用内网交换机，互联网带宽和网络带宽等资源更加充分。一般出于系统稳定的多活要求进行多集群部署，仅在主用园区出现故障时，进行切换。因此业务在主用园区进行相互调用可以减少跨园区的网络访问。相同集群进行部署有利于执行器的快速部署，利用现存执行器的服务器可以执行快速启动，通过利用磁盘IO，降低网络IO。基于此，为了在实现基于多集群的网络调度的基础上，尽可能减少业务请求调度时跨集群的数量，减少网络中带宽与I/O的压力，如图2所示，在本申请一个实施例中，步骤300所述的根据所述业务请求组的资源需求量和各个集群的剩余可用资源，确定目标集群，包括：

步骤301：根据剩余可用资源从多到少对各个集群排序。

步骤302：若前N位的集群的剩余可用资源之和大于等于所述业务请求组的资源需求量，并且前(N-1)位的集群的剩余可用资源之和小于所述业务请求组的资源需求量，则将前N位的各个集群均确定为所述目标集群。

举例来说，若集群A至F的剩余可用资源依次为100、98、90、88、80、70，业务请求组的资源需求量为260，则确定集群A、B、C均为目标集群。

为了在实现基于多集群的网络调度的基础上，尽可能减少业务请求调度时跨集群的数量，减少网络中带宽与I/O的压力，在本申请一个实施例中，步骤302还包括：若前N位的集群的剩余可用资源之和大于等于所述业务请求组的资源需求量并且N为1，则将首位的集群确定为所述目标集群。

为了提高资源利用率，在本申请一个实施例中，步骤400所述的根据所述目标集群中的各个目标执行器的剩余可用资源，确定各个业务请求各自对应的目标执行器，包括：根据所述目标集群中的各个目标执行器的剩余可用资源之间比例，确定各个业务请求各自对应的目标执行器。

具体地，用户无指定部署需求时，可以根据资源比例进行分配。举例来说，假设目标集群中包括：目标执行器A1和目标执行器A2；目标执行器A1和目标执行器A2的并发度上限均为100，目标执行器A1已接收业务请求数量为60，目标执行器A2已接收业务请求数量20，新接入的业务请求组包含有120个业务请求，则确定目标执行器A1和目标执行器A2的剩余可用资源之间比例为(100-60)：(100-20)＝1：2，可以按照1：2的比例，将40个业务请求分配至目标执行器A1，将80个业务请求分配至目标执行器A2。

为了提高确定目标集群的可靠性，在本申请一个实施例中，步骤300所述的根据所述业务请求组的资源需求量和各个集群的剩余可用资源，确定目标集群，包括：

若各个集群的剩余可用资源之和小于所述业务请求组的资源需求量，则进行执行器扩容操作，若扩容操作后的各个集群的剩余可用资源之和大于等于所述业务请求组的资源需求量，则根据所述业务请求组的资源需求量和扩容操作后的各个集群的剩余可用资源，确定目标集群。

为了提高扩容操作的可靠性，进而进一步减少业务请求调用时跨集群的数量，在本申请一个实施例中，所述进行执行器扩容操作，包括：

步骤311：根据剩余可用资源由大到小对各个集群排序，将首位的集群确定为待扩容集群。

步骤312：根据该待扩容集群中的各个服务器对应的剩余可用资源由大到少，对服务器进行排序，将首位的服务器确定为待扩容服务器，执行扩容步骤，每个服务器对应的剩余可用资源为该个服务器中的各个目标执行器的剩余可用资源之和。

步骤313：所述扩容步骤包括：增加所述待扩容服务器中的目标执行器的数量，若增加目标执行器的数量之后，各个集群的剩余可用资源之和小于所述业务请求组的资源需求量，则增加所述待扩容集群的下一位服务器中的目标执行器数量，直至增加目标执行器数量之后，各个集群的剩余可用资源之和大于所述业务请求组的资源需求量。

具体地，可以定时进行请求队列检查，设置堆积指数为Z，若累计出现在请求队列且待分配请求数目增加，则堆积指数加1。待分配请求D＝接收请求-已分配至执行器请求；执行器可接收请求K＝执行器数量×执行器设置并发阈值Y×1.2(超发参数，一般由用户通过测压数据进行指定)-已分配执行器请求。扩容执行器数量＝(D-K)×Y(1+Δ×Z)，其中，Δ表示设置的系统扩容速率，用户可以根据自身业务情况进行压测并设置。

为了进一步提高扩容操作的可靠性，在本申请一个实施例中，在步骤313所述的增加所述待扩容集群的下一位服务器中的目标执行器数量之后，还包括：

步骤314：若所述待扩容集群中的各个服务器均增加目标执行器数量之后，各个集群的剩余可用资源之和小于所述业务请求组的资源需求量，则选取下一位的集群并确定为待扩容集群，返回执行所述扩容步骤。

从软件层面来说，为了在提高基于多集群的网络调度效率的同时，减少资源浪费，本申请提供一种用于实现所述基于多集群的网络调度方法中全部或部分内容的基于多集群的网络调度装置的实施例，参见图3，所述基于多集群的网络调度装置具体包含有如下内容：

接收模块10，用于接收目标业务类型的业务请求组，该业务请求组包括：多个业务请求；

启动模块20，用于根据预设的业务类型与执行器之间的对应关系，确定多个集群中所述目标业务类型对应的目标执行器，启动该目标执行器所在的服务器，每个集群包括：多个服务器，每个服务器设有至少一个执行器；

确定模块30，用于获取各个集群的剩余可用资源，根据所述业务请求组的资源需求量和各个集群的剩余可用资源，确定目标集群，每个集群的剩余可用资源为该集群中的各个目标执行器的剩余可用资源之和；

网络调度模块40，用于根据所述目标集群中的各个目标执行器的剩余可用资源，确定各个业务请求各自对应的目标执行器，将各个业务请求发送至各自对应的目标执行器，完成所述业务请求组对应的网络调度。

如图4所示，在一个实施例中，所述确定模块30包括：

排序单元31，用于根据剩余可用资源从多到少对各个集群排序；

第一确定单元32，用于若前N位的集群的剩余可用资源之和大于等于所述业务请求组的资源需求量，并且前(N-1)位的集群的剩余可用资源之和小于所述业务请求组的资源需求量，则将前N位的各个集群均确定为所述目标集群。

在一个实施例中，所述确定单元，还用于：

若前N位的集群的剩余可用资源之和大于等于所述业务请求组的资源需求量并且N为1，则将首位的集群确定为所述目标集群。

在一个实施例中，所述网络调度模块，包括：

第二确定单元，用于根据所述目标集群中的各个目标执行器的剩余可用资源之间比例，确定各个业务请求各自对应的目标执行器。

在一个实施例中，所述确定模块包括：

扩容单元，用于若各个集群的剩余可用资源之和小于所述业务请求组的资源需求量，则进行执行器扩容操作，若扩容操作后的各个集群的剩余可用资源之和大于等于所述业务请求组的资源需求量，则根据所述业务请求组的资源需求量和扩容操作后的各个集群的剩余可用资源，确定目标集群。

在一个实施例中，所述扩容单元还用于：

根据剩余可用资源由大到小对各个集群排序，将首位的集群确定为待扩容集群；

根据该待扩容集群中的各个服务器对应的剩余可用资源由大到少，对服务器进行排序，将首位的服务器确定为待扩容服务器，执行扩容步骤，每个服务器对应的剩余可用资源为该个服务器中的各个目标执行器的剩余可用资源之和；

所述扩容步骤包括：增加所述待扩容服务器中的目标执行器的数量，若增加目标执行器的数量之后，各个集群的剩余可用资源之和小于所述业务请求组的资源需求量，则增加所述待扩容集群的下一位服务器中的目标执行器数量，直至增加目标执行器数量之后，各个集群的剩余可用资源之和大于所述业务请求组的资源需求量。

在一个实施例中，所述扩容单元还用于：

若所述待扩容集群中的各个服务器均增加目标执行器数量之后，各个集群的剩余可用资源之和小于所述业务请求组的资源需求量，则选取下一位的集群并确定为待扩容集群，返回执行所述扩容步骤。

本说明书提供的基于多集群的网络调度装置的实施例具体可以用于执行上述基于多集群的网络调度方法的实施例的处理流程，其功能在此不再赘述，可以参照上述基于多集群的网络调度方法实施例的详细描述。

为了进一步说明本方案，本申请提供一种基于多集群的网络调度装置的应用实例，在本应用实例中，该装置包括：

1)过滤模块：用于业务服务的请求接收与识别，实现业务请求与关联系统资源信息的识别与关联。过滤模块实现的功能可以相当于上述接收模块实现的功能。

2)流量监控模块：根据用户历史数据或用户设定，针对网络服务的请求数量，IO等网络负载信息进行记录，并与实际的服务的执行器进行关联，提供控制器各类执行器的负载情况，执行器可以用于响应业务请求。单个执行器可根据用户评估进行请求并发限制。同时可以针对执行器的计算资源使用进行配置。流量监控模块实现的功能可以相当于上述启动模块实现的功能。

3)控制器，根据资源管理器与业务请求监控为控制器提供的监控数据，对集群间的网络调度策略、执行器实际数量与集群冷备资源等进行管理。

4)集群间调度器：进行实际服务执行的数量的控制。

5)资源管理器：根据控制器发送的控制信息调整设备状态并对设备资源进行控制，提升资源使用效率。集群间调度器和资源管理器结合实现的功能可以相当于上述确定模块和网络调度模块结合实现的功能。

为了进一步说明本方案，结合上述网络调度装置的应用实例，本申请提供一种基于多集群的网络调度方法的应用实例，具体描述如下：

S01：接收各类业务应用的业务请求，进行权限校验，证书校验与参数校验等。

S02：业务请求接入后进行识别并统一进行处理关联对应执行器(其中每一类型执行器只能响应对应的请求)，并将识别后分类的请求信息发送至流量监控模块。

具体地，接收业务相关访问。业务请求通过请求过滤器进行识别，不同请求将配置至相关执行器进行处理，通过调度器将请求调度至对应Serverless集群暴露的对应服务,实现多集群间的业务快速调度，避免出现集群无资源需要冷启动的情况延长请求时间。每一类型执行器只能响应对应的请求，一台服务器可启动一个到多个执行器，一般在集群中随机选取一个进行部署，未实现快速部署，一般选择在已有服务器中进行资源扩容，减小网络压力。

S03：根据步骤S02中获取业务请求，按照执行器维度进行分类统计，得到针对请求量和网络I/O等指标的统计结果，将统计结果发送至控制器。

S04：负载调度器根据控制器控制策略配置业务请求。根据标记信息进行负载均衡策略的调整。首先根据各集群节点数量、并发度与请求进行计算，将请求调入目前空闲的执行器中。如未存在可用执行器，则根据集群执行器状态进行快速的创建并承接用户请求，实现网络负载的集群间调度，节点即集群内部部署相关服务的设备，如服务器。

具体地，可以对执行器的数量调整。执行器状态可以分为启动中，运行中(繁忙，空闲)预销毁，资源回收5类状态，其中运行中、繁忙与空闲均可对外提供服务。除资源回收状态，执行所需文件与执行程序包仍然保留，未进行销毁。控制器控制策略可以包括：

用户可以根据业务登记对运行中状态的时间进行设置，同时可以对执行器保留时间进行同步设置。避免频繁的资源回收造成资源浪费。

当业务请求接入时，优先调度至存在空闲的执行器的集群。

当业务请求接入时，优先调度到集群中已存在且未达到并发度上线的执行器中。

当业务请求接入时集群且已达到执行器上线，则跳过该集群查询其他具有该执行的集群，并发是否可用，直至查询到可用的执行器。

当请求接入时集群各执行器空闲均不可，完全承载请求流量。则按照集群可用执行器比例进行分配。如出现不足则在相应集群进行执行器扩容，提升集群可承载的流量，以应对流量高峰。

当业务请求接入且量超过全部集群现有资源情况时，即超出现有集群中现有执行可以提供的并发度时，在执行器所在服务器进行执行器扩容，提升执行器数量以应对相应请求。同时为应对流量洪峰，在监控到后续流量持续升高时(或可有用户设定的场景，如指定时刻，执行器内存持续升高等)基于同节点扩容无法满足的情况下，在集群中空闲节点进行执行器的扩容作为相应的热备节点。还可以根据控制器控制信息和实时资源信息，实现集群内执行器的CPU、内存与存储资源的调整。同时支持执行器状态调整至热备状态或将热备资源调整冷备状态，通过冷热备切换降低集群的运行成本。可以对集群间网络、集群内网络、执行器数量、服务器资源状态和集群物理资源调整。监控数据为CPU、内存、磁盘读写、网络带宽和网络连接时的网络负载等信息。执行策略支持用户设置负载均衡策略进行调整。

如出现集群资源不足时则可以跨多个集群进行执行器创建，并根据空闲执行器资源数量进行流量分配，集群间调度器根据集群中空闲执行器数量比例进行请求下发，资源不足可以为计算资源不足，如CPU或者内存不足，或者网络带宽、网络I/O不足。通过逐层升级的机制，尽量使用本地网络与集群内部网络，从而大大降低跨集群的网络开销，逐层升级的机制包括：请求优先在相同的集群节点上进行扩容，如无法满足则在集群内部进行扩容，利用集群间调度器进行请求的分发，如仍无法满足则进行跨集群节点扩容。

以最常见的网络请求数量超阈值情况为例，资源不足分为三个层级，跨集群级，集群级和服务器级。优先将服务在已启动的执行器中，随后在相同服务器中进行启动，随后是在同集群进行调度、最后采用跨集群启动的请求调度。通过尽可能的资源复用与本地存储利用减少网络中带宽与I/O的压力。

按照集群间各执行器仍有的节点剩余可执行请求的数量的比例进行分发，尽量实现各节点的负载均衡。

当业务请发接入时，执行器均为繁忙状态，则调度至启动中或者预销毁执行器中。由于存储资源未被释放，因此仅需重新启动即可。避免函数启动所需的复杂的环境准备工作。

当业务请求接入时执行器出现计算资源紧张时，资源管理模块发送相关信息至控制器，对执行器分配计算资源进行一定的扩容，暂时进行问题修复。同时激活空闲设备进行执行器的加载，进行执行器的同步扩容降低单个执行器的压力。

当重点业务接入时，所有节点均繁忙时。可从资源管理器中激活相应冷备节点中重点业务所需相关资源，加快重点业务的响应时间。

当业务请求接入量下降时进行执行器调整，首先降低跨集群节点数量。直到仅单集群运行，如资源仍充裕，则减少集群内部执行器数量。如仍资源充足，则缩减至单节点运行。直到无请求且到达销毁时间时进行执行器的回收。

S05：控制器根据请求监控数据与资源管理提供集群信息进行网络调度方案的配置与下发，实现将请求调度至所需的集群间调度器，并根据网络负载情况进行执行器的扩容与。

S06：在集群间的各节点进行服务请求调度，将请求分配至对应的执行器。

S07：接收集群间调度器发送的业务请求，利用存储器提供存储资源进行服务启停以便进行服务的实际相应。

S08：提供各类服务不同类型的存储服务。

图5为本申请一种举例中的基于多集群的网络调度方法的逻辑示意图，如图5所示，集群可抽象为集群网关、执行器与执行器所需的各类资源三部分；业务请求接入后为调用或创建相关执行器，控制器下发调度信息，当执行器启动完成并且计算资源与存储资源分配完成后，可以应用集群间调度器接收外部业务请求。

由上述描述可知，本应用实例提供的基于多集群的网络调度方法，通过跨集群的网络调度能力实现，资源的最大化利用；同时通过统一网关的建立实现针对业务大量突增，设备异常，网络异常等场景建立快速处理机制，同时建立应急专家库提升系统的异常处理能力，保障系统的高可用能力完善。

从硬件层面来说，为了在提高基于多集群的网络调度效率的同时，减少资源浪费，本申请提供一种用于实现所述基于多集群的网络调度方法中的全部或部分内容的电子设备的实施例所述电子设备具体包含有如下内容：

处理器(processor)、存储器(memory)、通信接口(Communications Interface)和总线；其中，所述处理器、存储器、通信接口通过所述总线完成相互间的通信；所述通信接口用于实现所述基于多集群的网络调度装置以及用户终端等相关设备之间的信息传输；该电子设备可以是台式计算机、平板电脑及移动终端等，本实施例不限于此。在本实施例中，该电子设备可以参照实施例用于实现所述基于多集群的网络调度方法的实施例及用于实现所述基于多集群的网络调度装置的实施例进行实施，其内容被合并于此，重复之处不再赘述。

图6为本申请实施例的电子设备9600的系统构成的示意框图。如图6所示，该电子设备9600可以包括中央处理器9100和存储器9140；存储器9140耦合到中央处理器9100。值得注意的是，该图6是示例性的；还可以使用其他类型的结构，来补充或代替该结构，以实现电信功能或其他功能。

在本申请一个或多个实施例中，基于多集群的网络调度功能可以被集成到中央处理器9100中。其中，中央处理器9100可以被配置为进行如下控制：

步骤100：接收目标业务类型的业务请求组，该业务请求组包括：多个业务请求；

步骤200：根据预设的业务类型与执行器之间的对应关系，确定多个集群中所述目标业务类型对应的目标执行器，启动该目标执行器所在的服务器，每个集群包括：多个服务器，每个服务器设有至少一个执行器；

步骤300：获取各个集群的剩余可用资源，根据所述业务请求组的资源需求量和各个集群的剩余可用资源，确定目标集群，每个集群的剩余可用资源为该集群中的各个目标执行器的剩余可用资源之和；

步骤400：根据所述目标集群中的各个目标执行器的剩余可用资源，确定各个业务请求各自对应的目标执行器，将各个业务请求发送至各自对应的目标执行器，完成所述业务请求组对应的网络调度。

从上述描述可知，本申请的实施例提供的电子设备，能够实现基于多集群的网络调度效率，减少资源浪费。

在另一个实施方式中，基于多集群的网络调度装置可以与中央处理器9100分开配置，例如可以将基于多集群的网络调度装置配置为与中央处理器9100连接的芯片，通过中央处理器的控制来实现基于多集群的网络调度功能。

如图6所示，该电子设备9600还可以包括：通信模块9110、输入单元9120、音频处理器9130、显示器9160、电源9170。值得注意的是，电子设备9600也并不是必须要包括图6中所示的所有部件；此外，电子设备9600还可以包括图6中没有示出的部件，可以参考现有技术。

如图6所示，中央处理器9100有时也称为控制器或操作控件，可以包括微处理器或其他处理器装置和/或逻辑装置，该中央处理器9100接收输入并控制电子设备9600的各个部件的操作。

其中，存储器9140，例如可以是缓存器、闪存、硬驱、可移动介质、易失性存储器、非易失性存储器或其它合适装置中的一种或更多种。可储存上述与失败有关的信息，此外还可存储执行有关信息的程序。并且中央处理器9100可执行该存储器9140存储的该程序，以实现信息存储或处理等。

输入单元9120向中央处理器9100提供输入。该输入单元9120例如为按键或触摸输入装置。电源9170用于向电子设备9600提供电力。显示器9160用于进行图像和文字等显示对象的显示。该显示器例如可为LCD显示器，但并不限于此。

该存储器9140可以是固态存储器，例如，只读存储器(ROM)、随机存取存储器(RAM)、SIM卡等。还可以是这样的存储器，其即使在断电时也保存信息，可被选择性地擦除且设有更多数据，该存储器的示例有时被称为EPROM等。存储器9140还可以是某种其它类型的装置。存储器9140包括缓冲存储器9141(有时被称为缓冲器)。存储器9140可以包括应用/功能存储部9142，该应用/功能存储部9142用于存储应用程序和功能程序或用于通过中央处理器9100执行电子设备9600的操作的流程。

存储器9140还可以包括数据存储部9143，该数据存储部9143用于存储数据，例如联系人、数字数据、图片、声音和/或任何其他由电子设备使用的数据。存储器9140的驱动程序存储部9144可以包括电子设备的用于通信功能和/或用于执行电子设备的其他功能(如消息传送应用、通讯录应用等)的各种驱动程序。

通信模块9110即为经由天线9111发送和接收信号的发送机/接收机9110。通信模块(发送机/接收机)9110耦合到中央处理器9100，以提供输入信号和接收输出信号，这可以和常规移动通信终端的情况相同。

基于不同的通信技术，在同一电子设备中，可以设置有多个通信模块9110，如蜂窝网络模块、蓝牙模块和/或无线局域网模块等。通信模块(发送机/接收机)9110还经由音频处理器9130耦合到扬声器9131和麦克风9132，以经由扬声器9131提供音频输出，并接收来自麦克风9132的音频输入，从而实现通常的电信功能。音频处理器9130可以包括任何合适的缓冲器、解码器、放大器等。另外，音频处理器9130还耦合到中央处理器9100，从而使得可以通过麦克风9132能够在本机上录音，且使得可以通过扬声器9131来播放本机上存储的声音。

上述描述可知，本申请的实施例提供的电子设备，能够实现基于多集群的网络调度效率，减少资源浪费。

本申请的实施例还提供能够实现上述实施例中的基于多集群的网络调度方法中全部步骤的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的基于多集群的网络调度方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：

步骤100：接收目标业务类型的业务请求组，该业务请求组包括：多个业务请求；

步骤200：根据预设的业务类型与执行器之间的对应关系，确定多个集群中所述目标业务类型对应的目标执行器，启动该目标执行器所在的服务器，每个集群包括：多个服务器，每个服务器设有至少一个执行器；

步骤300：获取各个集群的剩余可用资源，根据所述业务请求组的资源需求量和各个集群的剩余可用资源，确定目标集群，每个集群的剩余可用资源为该集群中的各个目标执行器的剩余可用资源之和；

步骤400：根据所述目标集群中的各个目标执行器的剩余可用资源，确定各个业务请求各自对应的目标执行器，将各个业务请求发送至各自对应的目标执行器，完成所述业务请求组对应的网络调度。

从上述描述可知，本申请实施例提供的计算机可读存储介质，能够实现基于多集群的网络调度效率，减少资源浪费。

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

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

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

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

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

本申请中应用了具体实施例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。