一种任务调度方法、装置、设备和存储介质

技术领域

本申请涉及任务调度技术领域，具体涉及一种任务调度方法、装置、设备和存储介质。

背景技术

在单纯的任务调度场景下，对任务进行处理的服务单元会受限于有限不变的资源，任务调度与资源管理的关系是割裂的，导致服务时常因达到资源使用上限，且无法直接调整资源，从而满足不了突发的客户端请求。针对这种问题，现有的做法是通过额外的定时任务来提前调整服务资源大小，从而满足客户端需求。

但是这种方式只能应对有强规律性的场景，满足不了任务调度所需要的多业务指标进行资源扩缩容的场景，会出现资源分配不合理，利用率低的情况。

发明内容

有鉴于此，本申请提供了一种任务调度方法、装置、设备和存储介质，用于解决现有的任务调度方式只能应对有强规律性的场景，满足不了任务调度所需要的多业务指标进行资源扩缩容的场景，会出现资源分配不合理，利用率低的情况。

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

第一方面，一种任务调度方法，包括：

响应于用户进行任务调度的请求指令，获取与所述请求指令对应的任务信息；

根据所述任务信息，确定与所述任务信息对应的目标任务；

获取所述目标任务的任务类型，并基于所述任务类型确定与所述目标任务对应的服务列表；

获取所述服务列表中的各个服务的处理能力；

若各个服务的处理能力均不小于预设阈值，且各个服务均不属于预设的空闲服务类型，则对所述服务列表进行扩容计算，得到第一结果；

判断所述第一结果是否满足预设的扩容条件，若是，则在所述服务列表中增加服务副本，并将已建立的第二任务分配给所述服务副本，以供该服务副本对所述第二任务进行执行，以完成任务的调度过程。

优选地，所述根据所述任务信息，确定与所述任务信息对应的目标任务，包括：

获取所述任务信息中的第一任务，并判断所述第一任务是否包含子任务；

若是，则获取与所述第一任务对应的执行模式，并利用所述执行模式对所述子任务进行模式处理，得到目标任务；

若否，则将所述第一任务作为目标任务。

优选地，所述对所述服务列表进行扩容计算，得到第一结果，包括：

获取所述服务列表的全局扩容优先级数和全局缩容优先级数；

将所述全局扩容优先级数减去所述全局缩容优先级数，得到所述服务列表的第一优先级差值；

将所述第二优先级差值作为第一结果。

优选地，所述判断所述第一结果是否满足预设的扩容条件，包括：

判断所述第一结果是否大于零；

若所述第一结果大于零，则判断所述第一结果是否大于第一预设阈值；

若所述第一结果大于第一预设阈值，则所述第一结果满足预设的扩容条件；

若所述第一结果不大于所述第一预设阈值，则获取所述服务列表的扩容冷却时间；

若所述扩容冷却时间大于冷却时间阈值，则所述第一结果满足预设的扩容条件。

优选地，还包括：

将增加所述服务副本的服务列表作为目标列表，并判断所述目标列表是否满足缩容条件；

若是，则获取所述目标列表的中的各个目标服务，从各个所述目标服务中确定各个空闲服务；

获取当前时间以及各个所述空闲服务的创建时间；

将所述当前时间与创建时间之间的时间间隔大于第一预设时间间隔的各个空闲服务作为各个待删除服务；

将各个所述待删除服务从所述目标列表中删除。

优选地，所述判断所述目标列表是否满足缩容条件，包括：

获取所述目标列表的全局扩容优先级数和全局缩容优先级数；

将所述全局缩容优先级数减去所述全局扩容优先级数，得到所述目标列表的第二优先级差值；

若所述第二优先级差值大于第二预设阈值，则获取与所述目标列表对应的内存占用值以及处理器占用值；

将所述第二优先级差值、内存占用值以及处理器占用值进行组合计算，得到该目标列表的缩容系数；

若所述缩容系数大于预设的缩容阈值，则所述目标列表满足缩容条件。

优选地，还包括：

将处理能力小于所述预设阈值的各个服务作为各个可处理服务；

获取当前时间以及各个所述可处理服务的创建时间；

将所述当前时间与创建时间之间的时间间隔大于第二预设时间间隔的各个可处理服务作为各个待分配服务；

将已建立的第二任务分配给各个所述待分配服务，以供各个所述待分配服务对所述第二任务进行执行，以完成任务的调度过程。

第二方面，一种任务调度装置，包括：

任务信息获取模块，用于响应于用户进行任务调度的请求指令，获取与所述请求指令对应的任务信息；

目标任务确定模块，用于根据所述任务信息，确定与所述任务信息对应的目标任务；

服务列表确定模块，用于获取所述目标任务的任务类型，并基于所述任务类型确定与所述目标任务对应的服务列表；

处理能力获取模块，用于获取所述服务列表中的各个服务的处理能力；

扩容计算模块，用于若各个服务的处理能力均不小于预设阈值，且各个服务均不属于预设的空闲服务类型，则对各个服务进行扩容计算，得到第一结果；

服务副本增加模块，用于判断所述第一结果是否满足预设的扩容条件，若是，则在所述服务列表中增加服务副本，并将已建立的第二任务分配给所述服务副本，以供该服务副本对所述第二任务进行执行，以完成任务的调度过程。

第三方面，一种任务调度设备，包括存储器和处理器；

所述存储器，用于存储程序；

所述处理器，用于执行所述程序，实现如第一方面所述的任务调度方法的各个步骤。

第四方面，一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时，实现如第一方面所述的任务调度方法的各个步骤。

从上述技术方案可以看出，本申请通过响应于用户进行任务调度的请求指令，获取与所述请求指令对应的任务信息；根据所述任务信息，确定与所述任务信息对应的目标任务；获取所述目标任务的任务类型，并基于所述任务类型确定与所述目标任务对应的服务列表；获取所述服务列表中的各个服务的处理能力；若各个服务的处理能力均不小于预设阈值，且各个服务均不属于预设的空闲服务类型，则对所述服务列表进行扩容计算，得到第一结果；判断所述第一结果是否满足预设的扩容条件，若是，则在所述服务列表中增加服务副本，并将已建立的第二任务分配给所述服务副本，以供该服务副本对所述第二任务进行执行，以完成任务的调度过程。该方案通过获取各个服务的处理能力来判断是否需要对服务列表进行扩容的操作，从而实现对多业务指标资源的合理分配，最大限度的提高服务资源的利用率。

附图说明

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

图1为本申请实施例提供的调度器和任务处理服务之间的通信过程示意图；

图2为本申请实施例提供的一种任务调度方法的可选流程图；

图3为本申请实施例提供的各模块之间的交互过程示意图；

图4为本申请实施例提供的一种任务调度装置的结构示意图；

图5为本申请实施例提供的一种任务调度设备的结构示意图。

具体实施方式

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

随着社会的发展和进步，互联网发展进入了一个新时代，业务场景日趋复杂。为了解决业务问题，技术设计上往往需要用到定时任务，批量数据处理和服务解耦的方式，而任务调度就是实现上述方式的重要并且常见的手段。不过，在单纯的任务调度场景下，对任务进行处理的服务单元会受限于有限不变的资源，任务调度与资源管理的关系是割裂的，导致服务时常因达到资源使用上限，且无法直接调整资源，从而满足不了突发的客户端请求。针对这种问题，现有的做法是通过额外的定时任务来提前调整服务资源大小，从而满足客户端需求。

而到了云原生的时代，K8s逐渐得到了应用，K8s是一个用于自动化部署、扩展和管理容器化应用的开源容器编排器技术，它使得部署和管理微服务架构应用程序变得很简单。K8s提供的HPA和VPA实现了按照Pod资源使用策略触发扩缩容，但是使用这种方式只能根据CPU和内存的配置来实现服务资源的弹性扩缩容，无法感知到业务指标，满足不了任务调度所需要的多业务指标进行资源扩缩容的场景，会出现资源分配不合理，利用率低的情况。

不过，业界上也有基于K8s的operator扩展扩缩容策略实现的开源通用组件，开箱即用，也确实达到了灵活兼容各项动态指标的要求，但是无法根据任务调度的需求实现Pod的定向缩容，由于其不感知业务操作，会出现误删工作中的Pod导致任务丢失的情况，无法实现在任务调度中对资源合理的掌控，实现合理高效持续的服务交付。

为了解决上述缺陷，本申请提供一个任务调度系统，该系统包括资源调度模块、任务调度模块和任务构建模块(任务解析模块)。

其中，资源调度模块支持配置多类型扩缩容指标，根据任务处理服务的扩缩容指标项，计算扩缩容指数，对资源进行分配管理，执行扩缩容操作。任务调度模块负责任务的发送和任务结果的回收，提供异常处理，包括任务重发和失败任务的清理。任务构建模块用于子任务的构建和任务请求数据解析。该系统的部署包括调度器、任务处理服务、redis和etcd。

具体地，调度器以集群模式进行部署，其启动时注册自身信息到etcd中，通过etcd实现主控制单元(leader)的选举，调度器的自身信息结构如下表1所示：

表1

其中，调度器所对应的value的具体数据结构如下2所示：

表2

任务处理服务通过etcd注册存活信息，其中存活信息的结构如下表3所示：

表3

其中，任务处理服务所对应的value的具体数据结构如表4所示：

表4

ScalerOption的类型包括：capacity(任务处理能力，意思是能处理的任务总数)，cpu，memory(内存)等，这些类型可以动态变化。

主调度器通过etcd的watch机制感知任务处理服务的注册动作，并将任务处理服务分配到各个从调度器分区中，具体实现方式是将分区信息存储在redis hash结构中，如下表5所示：

表5

其中，主调度器所对应的具体的数据结构如下表6所示：

表6

任务处理服务通过redis上报自身相关的信息，调度器通过redis获取任务处理服务信息，任务处理服务的信息结构如下表7所示：

表7

调度器和任务处理服务通过redis保存任务信息，防止任务分发时由于异常而导致丢失，相关数据结构如下表8和表9所示，表8展示了调度任务Job的数据结构，表9展示了服务任务Task的数据结构。

表8

表9

另外，调度器和任务处理服务通过RPC方式进行通信，通信过程可以如图1所示。

本发明实施例提供一种任务调度方法，该方法可以应用在各种计算机终端或是智能终端中，其执行主体可以为计算机终端或是智能终端的处理器或服务器，所述方法的方法流程图如图2所示，具体包括：

S1：响应于用户进行任务调度的请求指令，获取与请求指令对应的任务信息。

本步骤可以应用于业务服务单元，在本申请中，业务服务单元构建任务，通过RPC方式发送任务调度请求到调度器。调度器接受业务服务单元的请求指令，获取请求信息，由任务构建模块从所述请求信息中提取任务信息。

S2：根据任务信息，确定与任务信息对应的目标任务。

在步骤S1中获取到任务信息(Job)后，调度器可以根据任务信息确定与任务信息对应的目标任务，然后将目标任务发送至任务调度模块。

S3：获取目标任务的任务类型，并基于任务类型确定与目标任务对应的服务列表。

任务调度模块接收到调度器发送的目标任务后，获取目标任务的任务类型，然后根据任务类型可以确定与目标任务对应的服务列表。在一个示例中，目标任务的任务类型为转码任务，那么这个任务类型所对应的服务是专门做转码的服务，服务所携带的标志可以包括：服务名称、服务IP、服务端口、服务处理能力和服务创建时间。由一个或多个服务可以组成服务列表，本实施例对此不做限制。

S4：获取服务列表中的各个服务的处理能力。

S5：若各个服务的处理能力均不小于预设阈值，且各个服务均不属于预设的空闲服务类型，则对服务列表进行扩容计算，得到第一结果。

任务调度模块获取服务列表中各个服务的处理能力，并预先设置一个阈值，分别将各个服务的处理能力与预设阈值进行比较，若每一个服务的处理能力均不小于预设阈值，并且各个服务均不属于预设的空闲服务类型(可以理解的是，空闲服务类型指的是当前不包含处理任务的服务的类型)，则说明此时该服务列表可能满足进行扩容的条件，但是还需要进行扩容计算才确定是否要进行扩容。

那么任务调度模块对服务列表进行扩容计算后，得到第一结果，基于第一结果才能确定服务列表是否需要进行扩容。

扩容可以理解为增加服务副本，比如，现有的一个服务列表中包括服务1、服务2和服务3，若要对该服务列表进行扩容，则可以增加一个服务4或更多服务。

S6：判断第一结果是否满足预设的扩容条件，若是，则在服务列表中增加服务副本，并将已建立的第二任务分配给服务副本，以供该服务副本对第二任务进行执行，以完成任务的调度过程。

具体地，判断第一结果是否满足预设的扩容条件，若是，则增加服务副本，可以增加一个或多个，然后将这一个或多个新增的服务副本划分到调度器之下，并记录新增的服务副本的名称。然后任务调度模块通过RPC调用任务下发接口，分配第二任务给新增的服务副本，以供服务副本对第二任务进行执行，从而完成任务的调度过程。各个模块之间的交互过程可以如图3所示。

在获取各个服务的处理能力后，本方法还可以包括：

将处理能力小于所述预设阈值的各个服务作为各个可处理服务；获取当前时间以及各个所述可处理服务的创建时间；将所述当前时间与创建时间之间的时间间隔大于第二预设时间间隔的各个可处理服务作为各个待分配服务；将已建立的第二任务分配给各个所述待分配服务，以供各个所述待分配服务对所述第二任务进行执行，以完成任务的调度过程。

本发明实施例提供的方法中，所述根据所述任务信息，确定与所述任务信息对应的目标任务的过程，具体说明如下所述：

获取所述任务信息中的第一任务，并判断所述第一任务是否包含子任务；若是，则获取与所述第一任务对应的执行模式，并利用所述执行模式对所述子任务进行模式处理，得到目标任务；若否，则将所述第一任务作为目标任务。

具体地，调度器从任务信息中提取第一任务(rootTask)，也可以称之为调度任务，然后判断第一任务中是否存在子任务(subTask)。如果存在子任务，则获取与第一任务对应的执行模式，并利用执行模式对子任务进行模式处理，得到目标任务，并将目标任务发送至任务调度模块。其中，执行模式包括并行和串行，可以由业务服务构建指定，本实施例对此不作限制。若第一任务中不存在子任务，则直接将第一任务发送至任务调度模块。

上述实施例对本申请根据所述任务信息，确定与所述任务信息对应的目标任务的过程进行了说明，下面对本申请提供的对所述服务列表进行扩容计算，得到第一结果，并判断所述第一结果是否满足预设的扩容条件的过程进行具体说明。

获取所述服务列表的全局扩容优先级数和全局缩容优先级数，将所述全局扩容优先级数减去所述全局缩容优先级数，得到所述服务列表的第一优先级差值，将所述第二优先级差值作为第一结果。

判断所述第一结果是否大于零；若所述第一结果大于零，则判断所述第一结果是否大于第一预设阈值；

若所述第一结果大于第一预设阈值，则所述第一结果满足预设的扩容条件；

若所述第一结果不大于所述第一预设阈值，则获取所述服务列表的扩容冷却时间；若所述扩容冷却时间大于冷却时间阈值，则所述第一结果满足预设的扩容条件。

在上述方案中，可以从redis中获取服务列表中各个服务的处理能力，并且遍历所有的服务，若各个服务的处理能力均不小于预设阈值，且各个服务均不属于预设的空闲服务类型，则触发扩容计算。获取服务列表的全局扩容优先级数和全局缩容优先级数，将全局扩容优先级数减去全局缩容优先级数，得到服务列表的第一优先级差值，将第一优先级差值作为第一结果。其中，全局扩容优先级数和全局缩容优先级数的满级可以设置为10级。

若第一结果大于第一预设阈值，则第一结果满足扩容条件，那么对服务列表进行扩容，扩容后将服务列表的全局扩容优先级数降低一级，将全局缩容优先级数升高一级，并记录扩容时间。需要注意的是，此时有一个扩容冷却时间也需要记录，扩容冷却时间指的是在对服务列表进行扩容后，会设置一个扩容冷却时间，在这个扩容冷却时间内，不能再进行扩容操作，以防止短时间内的频繁扩容造成服务列表的容量过大，导致资源浪费的问题。在一个示例中，对服务列表进行扩容的时间为10：00，若扩容冷却时间为5分钟，则在10：00～10：05的时间段内，不能再次对服务列表进行扩容，10：05分之后才可以再次进行扩容。根据不同的服务列表可以设定不同的扩容冷却时间，本实施例对此不作限制。

可以理解的是，扩容之后升高全局缩容优先级数可以使短时间内造成的扩容在短时间内又能缩回去。因此可以通过多优先级的整合计算，得到合理的扩容频率。

在上述方案中，任务调度模块会优先分配任务到创建较久且仍有处理能力的服务身上，在资源匮乏时可以防止分配不均出现浪费，在资源盈余时集中任务分配到对应新增的服务副本上。

在本申请提供的一个实施例中，可以将扩容后的服务列表作为目标列表，并判断目标列表是否满足缩容条件。需要注意的是，在触发判断目标列表是否满足缩容条件的操作时，需要先判断当前目标列表是否处于扩容冷却时间内，若不处于，则可以对目标列表进行是否满足扩容条件的判断。

具体地，对于支持多指标的目标列表，通过CRD资源获取到目标列表的配置表达式，然后调用prometheus server获取到对应指标的历史监控数据(Prometheus有配置不同的监控指标的表达式，指标项指的是各种指标)。从各个所述目标服务中确定各个空闲服务；获取当前时间以及各个所述空闲服务的创建时间；将所述当前时间与创建时间之间的时间间隔大于第一预设时间间隔的各个空闲服务作为各个待删除服务；将各个所述待删除服务从所述目标列表中删除。另外，也可以只关注服务上报的任务处理数值而不关注其他指标的服务，并根据服务类型确定空闲服务，然后获取各个空闲服务的创建时间，按照创建时间的早晚对各个空闲服务进行排序，然后将满足缩容条件且创建时间较长的空闲服务进行清理或删除，同时记录目标列表的缩容冷却时间，缩容冷却时间与扩容冷却时间本质相同，此处不再赘述。最后将目标列表的全局扩容优先级数升高一级，将全局缩容优先级数降低一级，从而实现了定向缩容，顺应了K8s的特性，同时在这个模式下服务资源会适应业务场景而逐渐处于动态平衡的状态，最大化提高了服务资源利用率。

具体地，判断所述目标列表是否满足缩容条件的过程，可以包括：

获取所述目标列表的全局扩容优先级数和全局缩容优先级数；将所述全局缩容优先级数减去所述全局扩容优先级数，得到所述目标列表的第二优先级差值；若所述第二优先级差值大于第二预设阈值，则获取与所述目标列表对应的内存占用值以及处理器占用值；将所述第二优先级差值、内存占用值以及处理器占用值进行组合计算，得到该目标列表的缩容系数；若所述缩容系数大于预设的缩容阈值，则所述目标列表满足缩容条件。

在上述方案中，本申请通过调度器来执行调度操作，调度器通过集群模式，利用etcd来选主，由选举出来的主调度器对资源进行初始化分区和后续的平衡工作，分区提高了调度效率，集群模式提升了整体服务系统的健壮性和可用性。在调度器中，任务调度模块下发任务时感知对应服务集群的处理能力，获取服务列表，根据其处理情况发送资源请求到资源调度模块，由资源调度模块在其管控的分区下构建新的副本服务，以满足该批次任务调度的需求，实现在任务调度中对资源合理的掌控，达到合理高效的服务交付能力。任务调度模块对服务的处理能力设置合理的触发阀值，可以防止在资源极限的情况下出现大量任务堆积。

与图1所述的方法相对应，本发明实施例还提供了一种任务调度装置，用于对图1中方法的具体实现，本发明实施例提供的任务调度装置可以在计算机终端或各种移动设备中，结合图4，对任务调度装置进行介绍，如图4所示，该装置可以包括：

任务信息获取模块10，用于响应于用户进行任务调度的请求指令，获取与所述请求指令对应的任务信息；

目标任务确定模块20，用于根据所述任务信息，确定与所述任务信息对应的目标任务；

服务列表确定模块30，用于获取所述目标任务的任务类型，并基于所述任务类型确定与所述目标任务对应的服务列表；

处理能力获取模块40，用于获取所述服务列表中的各个服务的处理能力；

扩容计算模块50，用于若各个服务的处理能力均不小于预设阈值，且各个服务均不属于预设的空闲服务类型，则对各个服务进行扩容计算，得到第一结果；

服务副本增加模块60，用于判断所述第一结果是否满足预设的扩容条件，若是，则在所述服务列表中增加服务副本，并将已建立的第二任务分配给所述服务副本，以供该服务副本对所述第二任务进行执行，以完成任务的调度过程。

从上述技术方案可以看出，本申请通过响应于用户进行任务调度的请求指令，获取与所述请求指令对应的任务信息；根据所述任务信息，确定与所述任务信息对应的目标任务；获取所述目标任务的任务类型，并基于所述任务类型确定与所述目标任务对应的服务列表；获取所述服务列表中的各个服务的处理能力；若各个服务的处理能力均不小于预设阈值，且各个服务均不属于预设的空闲服务类型，则对所述服务列表进行扩容计算，得到第一结果；判断所述第一结果是否满足预设的扩容条件，若是，则在所述服务列表中增加服务副本，并将已建立的第二任务分配给所述服务副本，以供该服务副本对所述第二任务进行执行，以完成任务的调度过程。该方案通过获取各个服务的处理能力来判断是否需要对服务列表进行扩容的操作，从而实现对多业务指标资源的合理分配，最大限度的提高服务资源的利用率。

在一个示例中，所述目标任务确定模块20可以包括：

子任务包含确定模块，用于获取所述任务信息中的第一任务，并判断所述第一任务是否包含子任务；

模式处理模块，用于若是，则获取与所述第一任务对应的执行模式，并利用所述执行模式对所述子任务进行模式处理，得到目标任务；

目标任务最终确定模块，用于若否，则将所述第一任务作为目标任务。

在一个示例中，所述扩容计算模块50可以包括：

优先级获取模块，用于获取所述服务列表的全局扩容优先级数和全局缩容优先级数；

第一优先级差值计算模块，用于将所述全局扩容优先级数减去所述全局缩容优先级数，得到所述服务列表的第一优先级差值；

第一结果得到模块，用于将所述第二优先级差值作为第一结果。

在一个示例中，所述服务副本增加模块60可以包括：

第一判断模块，用于判断所述第一结果是否大于零；

第二判断模块，用于若所述第一结果大于零，则判断所述第一结果是否大于第一预设阈值；

第一满足模块，用于若所述第一结果大于第一预设阈值，则所述第一结果满足预设的扩容条件；

冷却时间获取模块，用于若所述第一结果不大于所述第一预设阈值，则获取所述服务列表的扩容冷却时间；

第二满足模块，用于若所述扩容冷却时间大于冷却时间阈值，则所述第一结果满足预设的扩容条件。

在一个示例中，所述装置还可以包括：

缩容判定模块，用于将增加所述服务副本的服务列表作为目标列表，并判断所述目标列表是否满足缩容条件；

空闲服务确定模块，用于若是，则获取所述目标列表的中的各个目标服务，从各个所述目标服务中确定各个空闲服务；

时间获取模块，用于获取当前时间以及各个所述空闲服务的创建时间；

待删除服务确定模块，用于将所述当前时间与创建时间之间的时间间隔大于第一预设时间间隔的各个空闲服务作为各个待删除服务；

删除模块，用于将各个所述待删除服务从所述目标列表中删除。

在一个示例中，所述缩容判定模块可以包括：

优先级获取模块，用于获取所述目标列表的全局扩容优先级数和全局缩容优先级数；

第二优先级差值计算模块，用于将所述全局缩容优先级数减去所述全局扩容优先级数，得到所述目标列表的第二优先级差值；

参数获取模块，用于若所述第二优先级差值大于第二预设阈值，则获取与所述目标列表对应的内存占用值以及处理器占用值；

组合计算模块，用于将所述第二优先级差值、内存占用值以及处理器占用值进行组合计算，得到该目标列表的缩容系数；

比较模块，用于若所述缩容系数大于预设的缩容阈值，则所述目标列表满足缩容条件。

在一个示例中，所述装置还可以包括：

将处理能力小于所述预设阈值的各个服务作为各个可处理服务；

获取当前时间以及各个所述可处理服务的创建时间；

将所述当前时间与创建时间之间的时间间隔大于第二预设时间间隔的各个可处理服务作为各个待分配服务；

将已建立的第二任务分配给各个所述待分配服务，以供各个所述待分配服务对所述第二任务进行执行，以完成任务的调度过程。

更进一步地，本申请实施例提供了一种任务调度设备。可选的，图5示出了任务调度设备的硬件结构框图，参照图5，任务调度设备的硬件结构可以包括：至少一个处理器01，至少一个通信接口02，至少一个存储器03和至少一个通信总线04。

在本申请实施例中，处理器01、通信接口02、存储器03、通信总线04的数量为至少一个，且处理器01、通信接口02、存储器03通过通信总线04完成相互间的通信。

处理器01可以是一个中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本发明实施例的一个或多个集成电路等。

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

其中，存储器存储有程序，处理器可调用存储器存储的程序，程序用于执行下述任务调度方法，包括：

响应于用户进行任务调度的请求指令，获取与所述请求指令对应的任务信息；

根据所述任务信息，确定与所述任务信息对应的目标任务；

获取所述目标任务的任务类型，并基于所述任务类型确定与所述目标任务对应的服务列表；

获取所述服务列表中的各个服务的处理能力；

若各个服务的处理能力均不小于预设阈值，且各个服务均不属于预设的空闲服务类型，则对各个服务进行扩容计算，得到第一结果；

判断所述第一结果是否满足预设的扩容条件，若是，则在所述服务列表中增加服务副本，并将已建立的第二任务分配给所述服务副本，以供该服务副本对所述第二任务进行执行，以完成任务的调度过程。

可选的，程序的细化功能和扩展功能可参照方法实施例中的任务调度方法的描述。

本申请实施例还提供一种存储介质，该存储介质可存储有适于处理器执行的程序，在所述程序运行时控制所述存储介质所在的设备执行下述任务调度方法，包括：

响应于用户进行任务调度的请求指令，获取与所述请求指令对应的任务信息；

根据所述任务信息，确定与所述任务信息对应的目标任务；

获取所述目标任务的任务类型，并基于所述任务类型确定与所述目标任务对应的服务列表；

获取所述服务列表中的各个服务的处理能力；

若各个服务的处理能力均不小于预设阈值，且各个服务均不属于预设的空闲服务类型，则对各个服务进行扩容计算，得到第一结果；

判断所述第一结果是否满足预设的扩容条件，若是，则在所述服务列表中增加服务副本，并将已建立的第二任务分配给所述服务副本，以供该服务副本对所述第二任务进行执行，以完成任务的调度过程。

具体地，该存储介质可以是一种计算机可读存储介质，计算机可读存储介质可以是诸如闪存、EEPROM(电可擦除可编程只读存储器)、EPROM、硬盘或者ROM之类的电子存储器。

可选的，程序的细化功能和扩展功能可参照方法实施例中的任务调度方法的描述。

另外，在本公开各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，直播设备，或者网络设备等)执行本公开各个实施例方法的全部或部分步骤。

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

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

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