CN110825535A - 一种作业调度的方法和系统 - Google Patents

Abstract

本发明公开了一种作业调度的方法和系统，涉及计算机技术领域。该方法的一具体实施方式包括：将接收的触发事件解析成作业的输入条件，并在作业的输入条件全部就绪后，将作业放入作业集合中；从作业集合中取出待派发作业并进行作业派发；从已派发的作业队列中获取作业实例信息并执行作业。该实施方式能够避免调度过程中常见的轮询，极大提升了调度性能；整个作业调度为“去中心化”设计，由多个单独的组件串起来执行，各组件的分工明确，彼此通过消息队列进行解耦，从而可以通过简单的增加实例进行系统扩容。

Description

一种作业调度的方法和系统

技术领域

本发明涉及计算机技术领域，尤其涉及一种作业调度的方法和系统。

背景技术

多租户环境下的作业调度面临着以下方面的挑战：一、随着租户的增多，每日运行的任务的量级可达到百万以上，且由于业务领域的不同，作业之间存在着复杂的依赖关系，不同作业有着不同的运行频度要求，甚至还存在着时区的差异；二、异构、多样化的计算平台(如Hadoop平台、流计算平台、大规模并行处理MPP平台等等)，异构的平台决定了调度作业类型的复杂，既有Shell、Python等脚本类作业，也有Spark、Hive等大数据任务，更有微服务框架下的容器类任务；三、复杂的资源管理，多租户环境下需要确保不同租户之间的作业互不干扰，且需要限制在租户申请的资源下运行。这些都对作业调度平台提出了严峻的挑战。

目前，常用的作业调度系统，例如：基于Control-m的调度系统、基于Airflow的调度系统、基于Azkaban的调度系统等，在进行作业调度时，都存在着以下几个方面的问题：

1、无法很好地支持复杂场景下的调度需求，比如跨作业流依赖、事件触发等；

2、无法直接支持多租户环境，且往往在调度量级达到百万甚至千万级别时出现调度瓶颈；

3、对调度资源的管理支持较弱。

发明内容

有鉴于此，本发明实施例提供一种作业调度的方法和系统，能够避免调度过程中常见的轮询，极大提升了调度性能；整个作业调度为“去中心化”设计，由多个单独的组件串起来执行，各组件的分工明确，彼此通过消息队列进行解耦，从而可以通过简单的增加实例进行系统扩容。

为实现上述目的，根据本发明实施例的一个方面，提供了一种作业调度的方法。

一种作业调度的方法，包括：将接收的触发事件解析成作业的输入条件，并在所述作业的输入条件全部就绪后，将所述作业放入作业集合中；从所述作业集合中取出待派发作业并进行作业派发；从已派发的作业队列中获取作业实例信息并执行作业。

可选地，将接收的触发事件解析成作业的输入条件包括：根据所述触发事件匹配使用所述触发事件的对象，获取所述对象所属的作业流信息，并判断所述作业流是否已完成实例化，所述对象包括作业和作业流；若所述作业流已完成实例化，且所述对象为作业，则直接将所述触发事件转换成作业的输入条件；若所述作业流未完成实例化，则进行所述作业流的实例化，然后将所述触发事件转换成作业的输入条件。

可选地，所述作业流的实例化的过程包括：确定所述作业流允许实例化，然后，生成所述作业流包括的作业的作业实例信息。

可选地，在进行作业派发之前，还包括：判断所述待派发作业是否为虚跑状态；若所述待派发作业为虚跑状态，则直接将所述待派发作业的状态设置为执行成功，且无需派发该作业。

可选地，进行作业派发的过程包括：获取当前作业的作业实例信息，并根据所述作业实例信息，获取所述当前作业需使用的逻辑资源；当获取的所述当前作业需使用的逻辑资源不为空时，为所述当前作业添加作业锁；若系统剩余的逻辑资源不存在资源不足锁，则对所述当前作业进行派发；否则，解除所述当前作业的作业锁，并获取下一作业进行作业派发。

可选地，进行作业派发的过程还包括：若获取的所述当前作业需使用的逻辑资源为空，则直接对所述当前作业进行派发；以及，若获取的所述当前作业需使用的逻辑资源不为空，其中，所述当前作业需使用的逻辑资源不少于一个，则判断所述需使用的逻辑资源之间的关系，当所述需使用的逻辑资源之间的关系为逻辑与时，若系统剩余的逻辑资源均不存在资源不足锁，且每个逻辑资源的申请量小于等于所述逻辑资源的剩余量，则对所述当前作业进行派发，否则将所述当前作业置为等待资源状态；当所述需使用的逻辑资源之间的关系为逻辑或时，若系统剩余的逻辑资源中的至少一个不存在资源不足锁且逻辑资源的申请量小于等于所述逻辑资源的剩余量，则对所述当前作业进行派发，否则将所述当前作业置为等待资源状态。

可选地，执行作业的过程包括：根据作业实例信息获取所述作业对应的执行命令；判断该作业是否为容器类作业，若是，则将所述执行命令发送给容器集群管理系统以执行所述作业；否则，直接执行所述执行命令以执行所述作业。

可选地，在执行作业完毕后，还包括：输出所述作业的返回码并根据所述返回码判断下一步操作。

可选地，根据所述返回码判断下一步操作包括：根据所述返回码获取所述作业的执行结果；若所述执行结果为作业被挂起，则无需执行下一步操作；否则，根据所述执行结果判断所述作业的状态；若所述作业的状态为执行成功，则生成作业完成事件，同时进行所在作业流的翻牌判断；若所述作业的状态为失败或异常，则直接返回；若所述作业的状态为重跑，则进行重跑条件的判断，并当满足重跑条件时，重新执行所述作业。

可选地，所述作业流的翻牌判断包括：若所述作业所属的作业流包括的作业已全部执行成功，则发送所述作业流的完成事件，并调用作业流翻牌以完成作业流的预实例化；若所述作业所属的作业流包括的作业未全部执行成功，则不进行所述作业流的翻牌。

可选地，所述触发事件包括租户信息，并且，在将接收的触发事件解析成作业输入条件之后，将所述作业输入条件放入所述触发事件对应的租户的作业条件队列中。

根据本发明实施例的另一方面，提供了一种作业调度的系统。

一种作业调度的系统，包括：事件接收组件、事件处理组件、作业管理组件、作业派发组件和作业执行组件，其中，所述事件接收组件，用于接收触发事件，根据所述触发事件匹配使用所述触发事件的对象，获取所述对象所属的作业流信息，并判断所述作业流是否已完成实例化，所述对象包括作业和作业流；若所述作业流已完成实例化，且所述对象为作业则将所述触发事件解析成作业的输入条件，并将所述作业的输入条件发送给所述作业管理组件；否则，将所述触发事件发送给所述事件处理组件；所述事件处理组件，用于判断所述作业所属的作业流是否满足实例化条件，若满足，则进行作业流实例化；然后将所述触发事件转换成作业的输入条件，并将所述作业流已经到达的所有作业的输入条件发送给所述作业管理组件；所述作业管理组件，用于在作业包括的输入条件全部就绪后，将所述作业放入作业集合中；所述作业派发组件，用于从所述作业集合中取出待派发作业并进行作业派发；所述作业执行组件，用于从已派发的作业队列中获取作业实例信息并执行作业。

根据本发明实施例的又一方面，提供了一种作业调度的电子设备。

一种作业调度的电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本发明实施例所提供的作业调度的方法。

根据本发明实施例的再一方面，提供了一种计算机可读介质。

一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现本发明实施例所提供的作业调度的方法。

上述发明中的一个实施例具有如下优点或有益效果：将接收的触发事件解析成作业的输入条件，并在作业的输入条件全部就绪后，将作业放入作业集合中，然后从作业集合中取出待派发作业并进行作业派发，之后从已派发的作业队列中获取作业信息并执行作业，可以通过将作业/作业流的所有条件全部抽象成事件，避免了调度过程中常见的轮询，极大提升了调度性能；整个作业调度为“去中心化”设计，由多个单独的组件串起来执行，各组件的分工明确，彼此通过消息队列进行解耦，从而可以通过简单的增加实例进行系统扩容。本发明的作业调度系统支持多租户，既可以用于公有云环境，也可以用于私有云环境，满足多种不同的调度场景；且既可以实现最基本的作业调度，也可以进行资源调度；通过缓存机制和队列机制，为实现海量作业调度提供了可能性。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是基于Control-m的调度系统的系统架构图；

图2是基于Airflow的调度系统的系统架构图；

图3是基于Azkaban的调度系统的系统架构图；

图4是本发明一个实施例的作业调度系统的系统架构图；

图5是根据本发明实施例的作业调度的方法的主要步骤示意图；

图6是本发明实施例的事件接收流程示意图；

图7是本发明实施例的事件处理流程示意图；

图8是本发明实施例的实例化子流程示意图；

图9是本发明实施例的作业条件检查子流程示意图；

图10是本发明实施例的作业返回码处理子流程示意图；

图11是本发明实施例的作业派发流程示意图；

图12是本发明实施例的作业派发子流程示意图；

图13是本发明实施例的作业执行流程示意图；

图14是本发明实施例可以应用于其中的示例性系统架构图；

图15是适于用来实现本发明实施例的终端设备或服务器的计算机系统的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

在本发明的实施例介绍中，出现的一些名词的释义如下：

租户：在公有云环境下可以理解为某个客户，多租户简单来讲是实现多个租户之间共享系统实例，又能确保各租户数据、资源等的隔离性；

作业流：作业组织的基本单元，一般来讲，将一组功能相近、频度相近或者有依赖关系的作业组合成一个作业流，作业流也是调度的基本单元；

作业：又称任务，作业流中的一个节点，即由用户定义的完成一定工作的逻辑单元。在作业调度模型中，作业(或任务)是最小执行单元；

事件：表述某个预设消息的产生，比如一个文件到达消息、一个作业完成消息或是某个作业依赖的时间点到达都可以看作事件，事件最终会转化成作业的输入条件；

作业流实例化：实例化主要是设置作业/作业流执行时需要的业务日期、批次。作业流实例化分为预实例化和实例化两个动作，预实例化生成作业流的实例信息和作业与事件的对照关系实例信息；实例化完成作业的实例化(包含作业参数)；

调度域：一套物理上独立部署的完整调度系统；

MQ：消息队列，如RabbitMQ、RocketMQ等开源消息软件；

DAG：有向无环图，一般调度以DAG的方式组织一个作业流，且只有一个连通分支。本文的作业流组织方式比较灵活，允许单个作业流存在多个连通分支；

QR：逻辑资源，用于控制某类作业的最大并发度，作业可以设置对不同类型QR的需求，只有在QR全部满足的条件下，才允许派发；

作业流翻牌：一个作业流执行结束后，根据策略生成该作业流后续一到多个业务日期/批次作业流实例及作业流/作业依赖信息的动作称为翻牌。

为了解决现有技术中存在的技术问题，需要对现有技术中常用的作业调度系统进行系统的研究和分析。下面结合附图介绍现有技术的作业调度系统的实现原理及其存在的缺点。

图1是基于Control-M的调度系统的系统架构图。如图1所示，基于Control-M的调度系统通过三层架构实现了管理、调度及作业执行三部分功能的分离。这三层架构及其功能实现分别是：管理节点Control-MEM，负责作业的定义/上传、运行监控等；管理节点Control-M Server，是整个调度的核心，承担了作业流的实例化、作业的调度、资源配置、作业运行管理等；执行节点Control-M Agent，是作业运行节点，负责运行由Server下发的作业，并保存作业运行状态，与Control-M/Server同步作业运行状态。

然而，基于Control-M的调度系统在进行作业调度时，存在的缺点主要表现在以下方面：

1、没有事件触发的机制，对外部文件到达的探测通过轮询实现，效率较低；

2、没有多租户的概念，所有作业的实例信息在同一个队列中；

3、扩容不便，扩容时需要同步扩展服务节点(Control-M Server)、执行节点(Control-M Agent)和配套数据库；

4、执行节点隶属于某个服务节点，执行节点无法为没有与之建立关系的服务节点提供执行服务，资源利用率较低；

5、各台服务节点彼此负责一部分作业实例的调度，信息不共享，当某台服务节点宕机时迁移十分困难。

图2是基于Airflow的调度系统的系统架构图。基于Airflow的调度系统包括了服务器WebServer、调度器Scheduler、工作者线程Worker。调度器通过轮询数据库中的DAG信息，当满足条件时产生一个DAG(作业流)实例信息并在作业条件全部就绪时推送到缓存介质(一般是采用消息队列RocketMQ实现，也可以用redis等)。Worker会监听消息队列，当消息队列中有消息时，则取出该任务进行执行。在调度资源的并发控制上，可以通过创建池pool进行简单的并发控制(作业指定所属pool)。

然而，基于Airflow的调度系统在进行作业调度时，存在的缺点主要表现在以下方面：

1、需要将有依赖关系的作业组织为同一个DAG(作业流)，无法支持跨DAG作业之间的依赖，不够灵活；

2、核心的Scheduler(调度器)模块当前只支持单节点，在作业到达一定量级时会存在瓶颈，扩展不便；

3、没有多租户的概念，所有作业统一进行调度。

图3是基于Azkaban的调度系统的系统架构图。基于Azkaban的调度系统提供了一种批量任务调度方法，主要由三个关键组件构成：管理服务器Azkaban WebServer、执行服务器Azkaban ExecutorServer、关系型数据库(MySQL)，架构如下图所示。AzkabanWebServer是整个作业流系统的主要管理者，负责项目管理、用户登录认证、定时执行工作流、跟踪作业流进度等一系列任务，同时提供了Web服务操作的接口，外部系统可通过这些接口与Azkaban进行交互。AzkabanExecutorServer主要负责具体的作业流的提交、执行，可以通过启动多个执行服务器扩展调度能力，ExecutorServer通过Mysql数据库来协调任务的执行。Azkaban使用关系型数据库(MySQL)存储大部分状态，Azkaban Webserver和Azkaban ExecutorServer都需要访问数据库。

然而，基于Azkaban的调度系统在进行作业调度时，存在的缺点主要表现在以下方面：

1、需要将有依赖关系的作业组织为同一个DAG(作业流)，无法支持跨DAG作业之间的依赖，不够灵活；

2、Webserver作为Web端既要承担对工作流(含实例)的管理，又要承担调度的功能，负载过重，不利于扩展；

3、Webserver根据一定的策略选择Executor Server进行作业流的下发，两者之间没有队列缓存机制，当作业量达到一定量级时容易出现性能瓶颈；

4、不支持调度资源并发控制；

5、没有多租户的概念，所有作业统一进行调度。

根据以上的分析，为了实现一种既能够适用于公有云平台多租户环境也能够适用于私有云环境，且支持海量作业的作业调度系统，本发明提供了一种作业调度的方法和系统，实现了在多租户环境下，支持海量作业的调度，包含事件接收(管理)、作业流实例化、作业派发、作业执行等一系列完整功能的调度，能够解决现有技术中存在的以下技术问题：

(1)传统的调度软件不能直接适用于多租户环境，一般是通过部署多套物理上隔离的调度系统来实现。本发明所提供的作业调度的方法和系统，能够实现在同一套物理环境上支持不同租户的作业调度，既能保证不同租户的作业按照优先级进行派发，又能共享底层的计算资源；

(2)传统的调度软件一般仅支持按照时间依赖的方式对作业流进行周期性的调度，对文件依赖、跨作业流依赖的支持较弱，且对文件依赖的支持一般通过轮询的方式实现，效率低下。本发明将作业流(作业)的所有依赖全部统一抽象成事件的方式(包含时间事件、文件到达事件、作业依赖事件、自定义事件等等)，并通过消息队列进行事件的流转，既能支持作业流(作业)上的各种复杂依赖配置，又避免了轮询，极大提高了调度效率；

(3)由于所有作业共享底层的计算资源，不同应用的作业需要有效地进行各类作业的并发控制，传统调度对这方面的支持较弱。本发明通过作业管理、作业派发和作业执行等几个流程对各类作业进行并发控制，可以使得底层计算资源的共享达到优化。

图4是本发明一个实施例的作业调度系统的系统架构图。如图4所示，本发明一个实施例的作业调度系统由事件接收、事件处理、作业管理、作业派发、作业执行几大组件构成。各个组件之间通过消息队列rabbitmq或redis进行解耦，通过异步的方式极大提升了整体调度性能。

整个作业调度系统的运行流程如下：第一步，各类型的外部事件(包括时间事件、文件到达事件、监控补发事件等)由事件接收组件进行接收后，放入事件接收组件的输入队列中，事件接收组件对各类型的事件进行识别、登记，匹配该事件所属的对象是作业还是作业流，然后获取该对象所属的作业流。如果对应的作业流已经完成实例化，则将事件转换为作业(或作业流)的输入条件，然后将输入条件发送到作业管理组件；如果对应的作业流未完成实例化，则将事件发送到事件处理组件；第二步，事件处理组件接收到事件接收组件发送的解析作业(或作业流)的事件后，根据作业流的实例化策略驱动作业流完成实例化，同时将之前已接收的作业(或作业流)的输入条件按照一定格式发送到作业管理组件的输入队列；第三步，作业管理组件从其输入队列中解析作业(或作业流)的输入条件，根据redis缓存信息判断作业(或作业流)的输入条件是否全部就绪，在作业(或作业流)的输入条件全部就绪时，按照设定的作业(或作业流)的优先级和所属租户信息放入该租户对应的redis集合；第四步，作业派发组件每次从租户的Redis队列中获取一定数量的作业，根据该作业所属的类型判断该类作业的并发度，在并发度未超过设定阈值的情况下，将该作业实例信息放入已派发队列；第五步，作业执行组件从已派发队列中取出作业信息，根据该作业的类型，可选择直接在作业执行节点或往kubernetes提交作业(针对容器类作业)。

下面结合具体实施例和附图介绍本发明的作业调度系统进行作业调度的实施过程。

图5是根据本发明实施例的作业调度的方法的主要步骤示意图。如图5所示，本发明实施例的作业调度的方法主要包括如下的步骤S501至步骤S503。

步骤S501：将接收的触发事件解析成作业的输入条件，，并在作业的输入条件全部就绪后，将作业放入作业集合中；

步骤S502：从作业集合中取出待派发作业并进行作业派发；

步骤S503：从已派发的作业队列中获取作业实例信息并执行作业。

根据本发明的技术方案，触发事件包括租户信息，并且，在将接收的触发事件解析成作业输入条件之后，将所述作业输入条件放入所述触发事件对应的租户的作业条件队列中。相应地，作业也会根据其所属的作业流对应的租户信息放入对应租户的作业集合中；且每个租户对应的待派发作业和已派发作业也保存在各自的队列中，从而实现了可以应用于多租户的作业调度系统。

根据本发明的一个实施例，在将接收的触发事件解析成作业的输入条件时，具体可以按照以下步骤执行：根据触发事件匹配使用该触发事件的对象，获取该对象所属的作业流信息，并判断作业流是否已完成实例化，对象包括作业和作业流；若所述作业流已完成实例化，且对象为作业，则直接将所述触发事件转换成作业的输入条件；若所述作业流未完成实例化，则进行所述作业流的实例化，然后将所述触发事件转换成作业的输入条件。

在该实施例中，结合图4所示的本发明实施例的作业调度系统的系统架构图可知，步骤S501具体可以是由事件接收组件、事件处理组件和作业管理组件一起结合实现。其中，事件接收组件，用于接收触发事件，根据触发事件获取对应作业流信息，并判断作业流是否已完成实例化；若作业流已完成实例化，则将触发事件解析成作业的输入条件，并将作业的输入条件发送给作业管理组件；否则，将触发事件发送给事件处理组件；事件处理组件，用于判断作业所在的作业流是否满足实例化条件，若满足，则进行作业流实例化；然后将触发事件转换成作业的输入条件，并将作业的输入条件发送给作业管理组件；作业管理组件，用于在作业包括的输入条件全部就绪后，将作业放入作业集合中。

图6是本发明实施例的事件接收流程示意图。事件接收组件主要包括事件接收登记、对可能触发作业流实例化的事件发送事件处理组件的接收队列MQ、对所属作业流已经完成实例化的事件转发至作业管理组件的接收队列MQ几大功能。如图6所示，事件接收组件的事件接收流程主要包括以下步骤：

步骤601：事件客户端通过统一的应用程序编程接口API(ApplicationProgramming Interface)将事件发送到事件接收组件的输入队列MQ；

步骤602：事件接收组件解析输入队列MQ中的消息报文，获得事件要素，事件要素例如包括：事件名、事件标识ID(Identity document)、租户ID、调度域ID、业务日期、批次、对象ID(作业ID或者作业流ID)。各要素具体含义如下：事件名主要用于外部系统直接推送文件(此时可把文件名理解成事件名)或者推送自定义事件名的方式来实现作业的输入条件依赖，事件名和事件ID不需要同时提供；事件ID适用于调度系统各组件内部的直接交互，如作业完成事件、作业流完成事件等；租户ID和调度域ID标识该事件的来源；通过事件的业务日期和批次可用于确定该事件对应的作业流实例；对象ID用于标识使用该事件的具体对象，一般情况下不指定(代表所有使用到该事件的对象集)；

步骤603：通过步骤602解析得到的事件要素，完成事件的校验：如果调度域ID为空，则代表本域事件；如果对象ID为空则代表针对所有作业或作业流；如果事件ID为空，则通过事件名解析事件ID；

步骤604：根据前面步骤601至603得到的事件要素及其校验结果，用事件ID、业务日期、批次去更新所有使用到该事件的作业或作业流的事件状态为已经到达；

步骤605：判断步骤604所关联到的作业流是否已完成实例化；

步骤606：如果步骤605解析到的作业流未完成实例化，则将该事件按照约定格式发送到事件处理组件的输入队列MQ；

步骤607：如果步骤605解析到的作业流状态为已经完成实例化，则将本事件解析成作业的输入条件，然后发送到作业管理组件的输入条件队列MQ。

图7是本发明实施例的事件处理流程示意图。事件处理组件主要完成作业流实例化的逻辑控制、作业流实例化(包含生成相关redis缓存表)操作、批量补齐已到达的作业的输入条件到作业管理组件输入队列MQ等几大功能。根据本发明的实施例，在进行作业流的实例化时，具体的过程例如包括：确定作业流允许实例化，然后，生成作业流包括的作业的作业实例信息。如图7所示，事件处理组件进行事件处理的流程主要如下：

步骤701：事件处理组件从其输入队列MQ中解析消息报文，获取的报文信息主要包括：事件ID、作业流ID、作业流业务日期、作业流批次等；

步骤702：判断该作业流的状态是否允许实例化，如果作业流状态处于预定义暂停或已经处于实例化，则不允许对该作业流进行实例化；

步骤703：若该作业流允许实例化，则判断作业流的输入事件是否全部到齐，作业流的实例化原则为：如果作业流上定义了输入事件(作业流上可以定义时间依赖事件、作业流依赖事件)，那么必须等作业流全部的输入事件到齐才允许实例化；如果作业流上没有定义输入事件，则任意的输入事件到达均可触发实例化。因此该步骤需要判断作业流的输入事件是否全部到齐；

步骤704：若作业流的输入事件已全部到齐，则调用实例化模块完成作业流的实例化。其中，实例化模块进行作业流的实例化的具体流程如图8所示。

图8是本发明实施例的实例化子流程示意图。如图8所示，实例化模块进行作业流的实例化主要包括如下的步骤：

步骤801：更新作业流状态为实例化中，若更新不成功，代表其他进程也在进行该作业流的实例化操作，则无需进行作业流实例化；若更新成功，则执行步骤802；

步骤802：生成作业实例信息(包含作业参数的实例)；

步骤803：生成redis缓存信息，主要是生成作业与事件的对应关系实例，该缓存可用于判断作业条件是否已就绪；

步骤804：当作业流的实例化完成后，更改作业流的状态为执行中；

步骤805：获取该作业流的所有输入事件并解析成输入条件，然后发送到作业管理组件的输入队列MQ，获取的事件主要包括以下几种：没有任何输入条件的作业，此时会生成一个空的输入条件；作业流未翻牌之前，提前到达的事件。

根据本发明的实施例，结合图8可知，本发明在进行作业流的实例化时，将作业流的实例化过程分成两个部分：预实例化(作业流翻牌时完成，完成作业流实例的生成和作业与事件关系实例信息的生成)和作业实例化(包含作业实例、作业参数实例等)，作业实例化只有在事件到达时才会完成，从而避免了在作业流翻牌时就提前将作业实例信息生成，大大减轻了数据库的压力。

作业管理组件主要用于进行作业条件检查(判断作业执行所需的全部条件是否已就绪)，并在作业就绪时发送指令给作业派发组件，由作业派发组件将作业按优先级派发至租户redis队列。另外，作业管理组件还在作业执行组件执行作业后，根据作业返回码进行解析处理，并判断是否需要进行失败重跑等。其中，作业返回码例如包括执行成功、异常、失败重跑等。当作业返回码为失败重跑时，需要对该作业进行重新执行，此时需要根据设定的重跑条件来判断是否可以进行重跑，例如：假设设定的重跑条件是“5分钟后重跑”，则可根据当前时间与执行失败时的时间相比较，来判断是否可以进行重跑。

下面结合图9和图10来介绍作业管理组件的实现流程。图9是本发明实施例的作业条件检查子流程示意图。如图9所示，作业条件检查的流程如下：

步骤901：事件接收组件(事件到达时，作业流已完成实例化，直接发送作业的输入条件)或事件处理组件(作业流完成实例化时，批量获取作业的输入条件)将作业的输入条件按指定格式(要素包括作业ID、事件ID、作业流实例ID)发送到作业管理组件的输入队列MQ；

步骤902：作业管理组件从其输入队列MQ中解析报文；

步骤903：作业管理组件根据redis缓存的作业与事件的对应关系实例信息判断作业的所有输入条件是否已经全部就绪；

步骤904：由于作业流允许将不同运行频度的作业组织在同一个作业流中，因此作业流翻牌时，可以提前算出作业在该业务日期是否运行，作业管理组件需要根据翻牌时算好的虚跑标志决定是否将作业派发到租户对应redis队列中。其中，虚跑指的是在一个作业流中，运行频度较低的作业无需执行的状态，例如：一个作业流中某作业的运行频度为每月一次，而其他作业的运行频度为每天一次，则在进行作业条件检查时，会根据作业频度判断该作业当天是否无需执行，即，当天是否要虚跑；

步骤905：对该业务日期需要实际运行的作业，作业管理组件会将作业派发到租户对应的redis队列中；

步骤906：对该业务日期不需要实际运行的作业，作业管理组件直接将该作业实例的状态置为成功(即：虚跑)，并将作业完成事件发送到事件接收组件。

根据本发明的一个实施例，在执行作业完毕后，还可以输出所述作业的返回码并根据所述返回码判断下一步操作。

在本发明的实施例中，根据所述返回码判断下一步操作具体可以包括：根据所述返回码获取所述作业的执行结果；若所述执行结果为作业被挂起，则无需执行下一步操作；否则，根据所述执行结果判断所述作业的状态；若所述作业的状态为执行成功，则生成作业完成事件，同时进行所在作业流的翻牌判断；若所述作业的状态为失败或异常，则直接返回；若所述作业的状态为重跑，则进行重跑条件的判断，并当满足重跑条件时，重新执行所述作业。

其中，在进行作业流的翻牌判断时，具体可以包括：若所述作业所属的作业流包括的作业已全部执行成功，则发送所述作业流的完成事件，并调用作业流翻牌以完成作业流的预实例化；若所述作业所属的作业流包括的作业未全部执行成功，则不进行所述作业流的翻牌。

图10是本发明实施例的作业返回码处理子流程示意图。在作业执行组件执行作业后，将生成作业返回码，并将作业返回码发送给作业管理组件，由作业管理组件根据作业返回码进行下一步操作。如图10所示，本发明实施例的作业返回码的处理子流程如下：

步骤1001：事件执行组件在作业运行完毕时将返回码发送到作业管理组件的输入队列MQ；

步骤1002：作业管理组件从其输入队列MQ中解析报文并获取返回码，返回码主要包括：挂起、成功、失败或异常、重跑，等等；

步骤1003：根据返回码更新作业实例的状态和运行信息；

步骤1004：判断作业是否被挂起(挂起代表不进行后续调度)，未被挂起执行步骤1005；

步骤1005：判断作业状态，若作业状态为成功，则执行步骤1006；若作业状态为失败或异常，则直接返回；若作业状态为重跑，则进行重跑条件的判断，例如：判断是否已到设定的重跑间隔时间，或者已满足设定的重跑条件；

步骤1006：发送作业完成事件到事件接收组件的输入队列MQ；

步骤1007：判断作业流是否完成，若完成则执行步骤1008；

步骤1008：发送作业流完成事件到事件接收组件的输入队列MQ，并完成作业流翻牌。

在该实施例中，利用消息队列MQ的消息确认机制，当对MQ中的消息处理异常中断(即：作业状态为失败或异常)时，消息不确认，从而确保消息不丢失。

下面介绍本发明实施例的作业派发组件进行作业派发的实现流程。根据本发明的一个实施例，在进行作业派发之前，还可以包括：判断所述待派发作业是否为虚跑状态；若所述待派发作业为虚跑状态，则直接将所述待派发作业的状态设置为执行成功，且无需派发该作业。

根据本发明实施例的技术方案，进行作业派发的过程例如是包括：获取当前作业的作业实例信息，并根据所述作业实例信息，获取所述当前作业需使用的逻辑资源；当获取的所述当前作业需使用的逻辑资源不为空时，为所述当前作业添加作业锁；若系统剩余的逻辑资源不存在资源不足锁，则对所述当前作业进行派发；否则，解除所述当前作业的作业锁，并获取下一作业进行作业派发。

根据本发明另一个实施例的技术方案，进行作业派发的过程例如还可以包括：若获取的所述当前作业需使用的逻辑资源为空，则直接对所述当前作业进行派发；以及，若获取的所述当前作业需使用的逻辑资源不为空，其中，所述当前作业需使用的逻辑资源不少于一个，则判断所述需使用的逻辑资源之间的关系，当所述需使用的逻辑资源之间的关系为逻辑与时，若系统剩余的逻辑资源均不存在资源不足锁，且每个逻辑资源的申请量小于等于所述逻辑资源的剩余量，则对所述当前作业进行派发，否则将所述当前作业置为等待资源状态；当所述需使用的逻辑资源之间的关系为逻辑或时，若系统剩余的逻辑资源中的至少一个不存在资源不足锁且逻辑资源的申请量小于等于所述逻辑资源的剩余量，则对所述当前作业进行派发，否则将所述当前作业置为等待资源状态。

图11是本发明实施例的作业派发流程示意图。在作业就绪时，作业管理组件会发送指令给作业派发组件，作业派发组件负责对就绪作业进行派发(当符合派发策略时)。派发策略支持作业的并发度、作业的逻辑资源(作业逻辑资源的数量代表了某类应用的最大并发度)是否满足等。其中，作业的并发度指的是一类作业可以并发执行的量，可根据需要进行设定。作业派发组件会通过多个派发实例(每个派发实例可通过一个线程来执行)进行作业派发，每个派发实例负责扫描一个或多个指定的租户，当扫描到其负责的租户集合中有就绪作业时，即进行作业派发，且还可以预先设置该派发实例对其负责的多个租户进行作业派发的优先级排序。并且，根据本发明的实施例，还可设置作业优先级的自动提升策略，当作业处于就绪队列时，会根据作业的等待时间自动对作业提升优先级(比如每30分钟提升一级)，避免低优先级作业长时间得不到调度而被“饿死”，从而使得作业的调度执行更为合理、均衡。

如图11所示，以一个派发实例进行作业派发为例，本发明实施例的作业派发流程如下：

步骤1101：作业管理组件将就绪作业放入该作业对应的租户的作业集合(可使用Redis Zset来实现)中；

步骤1102：判断该租户对应的派发实例是否被挂起，如果挂起则退出流程；否则执行步骤1103；

步骤1103：解析作业的实例信息，获取该作业需使用的逻辑资源QR，对该作业进行加锁，加锁主要是保证同一时刻单个作业只被某个派发实例派发；

步骤1104：若作业实例加锁失败则说明当前作业正在被其他派发实例派发，继续取下一作业实例进行派发处理，否则执行步骤1105；

步骤1105：判断该作业的QR是否存在资源不足锁(如果存在资源不足锁，则代表该资源已满，无法再并发处理更多的同类作业，该锁的作用是减少对QR的重复判断)；若存在，则同时解除作业锁，取下一作业实例进行派发处理；否则执行步骤1106；

步骤1106：对作业进行派发，详细流程见图12。

其中，在将就绪作业放入该作业对应的租户集合中时，通过使用Redis Zset来实现租户集合，可以充分利用redis的机制，将同一租户的不同作业信息保存到同一个Zset中，便于根据不同作业的优先级和更改时间来保证按照优先级进行有序派发。

图12是本发明实施例的作业派发子流程示意图。其中示出了在进行作业派发时的具体实现。如图12所示，本发明实施例的作业派发子流程主要包括以下步骤：

步骤1201：判断作业状态是否为“已就绪”，该状态为允许派发的唯一合法前序状态；

步骤1202：获取该作业用到的QR信息，QR之间的关系允许存在“逻辑或”或“逻辑与”的关系；

步骤1203：判断QR是否为空，为空代表不受资源限制，直接派发；不为空则执行步骤1204；

步骤1204：发送QR操作脚本到redis服务器，获取该作业所需的资源QR；

步骤1205：若获取QR失败，则加上对应资源的资源不足锁，并解除该作业锁；若获取QR成功，则执行步骤1206；

步骤1206：更改作业状态为“已派发”；

步骤1207：将作业打上标签(该标签代表了作业的类型)，并放入已派发队列；

步骤1208：删除租户优先级队列中对应的作业实例信息。

在本发明的实施例中，通过利用消息队列MQ的标签机制，对作业类型打标签，可以保证执行节点只订阅自己关心的作业类型，从而便于作业管理和调度。

在将作业派发完成后，将由派发给的作业执行组件来执行作业。根据本发明的技术方案，执行作业的过程例如可以包括：根据作业实例信息获取所述作业对应的执行命令；判断该作业是否为容器类作业，若是，则将所述执行命令发送给容器集群管理系统以执行所述作业；否则，直接执行所述执行命令以执行所述作业。其中，作业对应的执行命令例如是一句命令行代码，其中，包括了执行命令所需要的执行参数。作业执行组件通过执行该执行命令即可进行作业执行。

图13是本发明实施例的作业执行流程示意图。作业执行组件主要负责将作业在执行机上调起，包含了执行机硬件资源检查、作业插件调用(对作业统一做了一层封装，包含作业的前处理、作业的主体、作业的后处理等)、日志的捕获管理和作业运行返回码管理。作业执行流程如下：

步骤1301：作业派发组件在作业对应的资源满足时，将该作业实例信息放入已派发队列，并将作业实例信息发送到作业执行组件的输入队列MQ中；

步骤1302：作业执行组件先判断自身的硬件资源是否满足(主要是判断硬件的CPU、内存是否足够支撑作业运行)，在自身的硬件资源满足时从队列中取出消息进行处理，否则阻塞等待一段时间后，重试；

步骤1303：作业执行组件从其输入队列MQ中解析报文，得到报文的要素，包括：作业流实例ID、作业ID；

步骤1304：检查对应的执行用户在该机器上是否存在、检查作业插件对应的jar包是否存在，检查不通过则报错退出；检查通过则执行步骤1305；

步骤1305：创建新的进程，并切换到该执行用户；

步骤1306：判断该作业是否为容器类作业，如果不是容器类作业，则直接在执行机调起作业插件，如果是容器类作业，则可向K8S(Kubernetes，是Google开源的容器集群管理系统)或YARN(YetAnother Resource Negotiator，另一种资源协调者)提交该作业插件；在作业插件中将会依次调用作业的前处理、作业的主体、作业的后处理；

步骤1307：等待作业执行进程的退出；

步骤1308：当作业执行完毕时，捕获该作业的返回码和作业输出，保存作业的执行日志，并将返回码发送到返回码队列(作业管理组件会处理该返回码队列)。

在上述的实施例介绍中，事件接收组件、事件处理组件、作业管理组件、作业派发组件和作业执行组件均可以有多个实例，每个实例负责一定的租户，各个实例在地位上是均等的，故而可以通过简单的增加实例来方便地实现系统扩容。

根据本发明实施例的技术方案，将接收的触发事件解析成作业的输入条件，并在作业的输入条件全部就绪后，将作业放入作业集合中，然后从作业集合中取出待派发作业并进行作业派发，之后从已派发的作业队列中获取作业信息并执行作业，可以通过将作业/作业流的所有条件全部抽象成事件，避免了调度过程中常见的轮询，极大提升了调度性能；整个作业调度为“去中心化”设计，由多个单独的组件串起来执行，各组件的分工明确，彼此通过消息队列进行解耦，从而可以通过简单的增加实例进行系统扩容。本发明的作业调度系统支持多租户，既可以用于公有云环境，也可以用于私有云环境，满足多种不同的调度场景；且既可以实现最基本的作业调度，也可以进行资源调度；通过缓存机制和队列机制，为实现海量作业调度提供了可能性。

图14示出了可以应用本发明实施例的作业调度的方法或作业调度的系统的示例性系统架构1400。

如图14所示，系统架构1400可以包括终端设备1401、1402、1403，网络1404和服务器1405。网络1404用以在终端设备1401、1402、1403和服务器1405之间提供通信链路的介质。网络1404可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备1401、1402、1403通过网络1404与服务器1405交互，以接收或发送消息等。终端设备1401、1402、1403上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(示例)。

终端设备1401、1402、1403可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器1405可以是提供各种服务的服务器，例如对用户利用终端设备1401、1402、1403所浏览的购物类网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的产品信息查询请求等数据进行分析等处理，并将处理结果(例如目标推送信息、产品信息--仅为示例)反馈给终端设备。

需要说明的是，本发明实施例所提供的作业调度的方法一般由服务器1405执行，相应地，作业调度的系统一般设置于服务器1405中。

应该理解，图14中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

下面参考图15，其示出了适于用来实现本发明实施例的终端设备或服务器的计算机系统1500的结构示意图。图15示出的终端设备或服务器仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图15所示，计算机系统1500包括中央处理单元(CPU)1501，其可以根据存储在只读存储器(ROM)1502中的程序或者从存储部分1508加载到随机访问存储器(RAM)1503中的程序而执行各种适当的动作和处理。在RAM 1503中，还存储有系统1500操作所需的各种程序和数据。CPU 1501、ROM 1502以及RAM 1503通过总线1504彼此相连。输入/输出(I/O)接口1505也连接至总线1504。

以下部件连接至I/O接口1505：包括键盘、鼠标等的输入部分1506；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1507；包括硬盘等的存储部分1508；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1509。通信部分1509经由诸如因特网的网络执行通信处理。驱动器1510也根据需要连接至I/O接口1505。可拆卸介质1511，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1510上，以便于从其上读出的计算机程序根据需要被安装入存储部分1508。

特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1509从网络上被下载和安装，和/或从可拆卸介质1511被安装。在该计算机程序被中央处理单元(CPU)1501执行时，执行本发明的系统中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的单元或模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中，例如，一种处理器包括作业管理组件、作业派发组件和作业执行组件。其中，这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定，例如，发送单元还可以被描述为“用于将接收的触发事件解析成作业的输入条件并在所述作业的输入条件全部就绪后，将所述作业放入作业集合中的组件”。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：将接收的触发事件解析成作业的输入条件，并在所述作业的输入条件全部就绪后，将所述作业放入作业集合中；从所述作业集合中取出待派发作业并进行作业派发；从已派发的作业队列中获取作业信息并执行作业。

根据本发明实施例的技术方案，将接收的触发事件解析成作业的输入条件，并在作业的输入条件全部就绪后，将作业放入作业集合中，然后从作业集合中取出待派发作业并进行作业派发，之后从已派发的作业队列中获取作业信息并执行作业，可以通过将作业/作业流的所有条件全部抽象成事件，避免了调度过程中常见的轮询，极大提升了调度性能；整个作业调度为“去中心化”设计，由多个单独的组件串起来执行，各组件的分工明确，彼此通过消息队列进行解耦，从而可以通过简单的增加实例进行系统扩容。本发明的作业调度系统支持多租户，既可以用于公有云环境，也可以用于私有云环境，满足多种不同的调度场景；且既可以实现最基本的作业调度，也可以进行资源调度；通过缓存机制和队列机制，为实现海量作业调度提供了可能性。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (14)

1.一种作业调度的方法，其特征在于，包括：

将接收的触发事件解析成作业的输入条件，并在所述作业的输入条件全部就绪后，将所述作业放入作业集合中；

从所述作业集合中取出待派发作业并进行作业派发；

从已派发的作业队列中获取作业实例信息并执行作业。

2.根据权利要求1所述的方法，其特征在于，将接收的触发事件解析成作业的输入条件包括：

根据所述触发事件匹配使用所述触发事件的对象，获取所述对象所属的作业流信息，并判断所述作业流是否已完成实例化，所述对象包括作业和作业流；

若所述作业流已完成实例化，且所述对象为作业，则直接将所述触发事件转换成作业的输入条件；

若所述作业流未完成实例化，则进行所述作业流的实例化，然后将所述触发事件转换成作业的输入条件。

3.根据权利要求2所述的方法，其特征在于，所述作业流的实例化的过程包括：

确定所述作业流允许实例化，然后，生成所述作业流包括的作业的作业实例信息。

4.根据权利要求1所述的方法，其特征在于，在进行作业派发之前，还包括：

判断所述待派发作业是否为虚跑状态；

若所述待派发作业为虚跑状态，则直接将所述待派发作业的状态设置为执行成功，且无需派发该作业。

5.根据权利要求1所述的方法，其特征在于，进行作业派发的过程包括：

获取当前作业的作业实例信息，并根据所述作业实例信息，获取所述当前作业需使用的逻辑资源；

当获取的所述当前作业需使用的逻辑资源不为空时，为所述当前作业添加作业锁；

若系统剩余的逻辑资源不存在资源不足锁，则对所述当前作业进行派发；

否则，解除所述当前作业的作业锁，并获取下一作业进行作业派发。

6.根据权利要求5所述的方法，其特征在于，进行作业派发的过程还包括：

若获取的所述当前作业需使用的逻辑资源为空，则直接对所述当前作业进行派发；以及，

若获取的所述当前作业需使用的逻辑资源不为空，其中，所述当前作业需使用的逻辑资源不少于一个，则判断所述需使用的逻辑资源之间的关系，当所述需使用的逻辑资源之间的关系为逻辑与时，若系统剩余的逻辑资源均不存在资源不足锁，且每个逻辑资源的申请量小于等于所述逻辑资源的剩余量，则对所述当前作业进行派发，否则将所述当前作业置为等待资源状态；当所述需使用的逻辑资源之间的关系为逻辑或时，若系统剩余的逻辑资源中的至少一个不存在资源不足锁且逻辑资源的申请量小于等于所述逻辑资源的剩余量，则对所述当前作业进行派发，否则将所述当前作业置为等待资源状态。

7.根据权利要求1所述的方法，其特征在于，执行作业的过程包括：

根据作业实例信息获取所述作业对应的执行命令；

判断该作业是否为容器类作业，若是，则将所述执行命令发送给容器集群管理系统以执行所述作业；否则，直接执行所述执行命令以执行所述作业。

8.根据权利要求1所述的方法，其特征在于，在执行作业完毕后，还包括：

输出所述作业的返回码并根据所述返回码判断下一步操作。

9.根据权利要求8所述的方法，其特征在于，根据所述返回码判断下一步操作包括：

根据所述返回码获取所述作业的执行结果；

若所述执行结果为作业被挂起，则无需执行下一步操作；

否则，根据所述执行结果判断所述作业的状态；

若所述作业的状态为执行成功，则生成作业完成事件，同时进行所在作业流的翻牌判断；

若所述作业的状态为失败或异常，则直接返回；

若所述作业的状态为重跑，则进行重跑条件的判断，并当满足重跑条件时，重新执行所述作业。

10.根据权利要求9所述的方法，其特征在于，所述作业流的翻牌判断包括：

若所述作业所属的作业流包括的作业已全部执行成功，则发送所述作业流的完成事件，并调用作业流翻牌以完成作业流的预实例化；

若所述作业所属的作业流包括的作业未全部执行成功，则不进行所述作业流的翻牌。

11.根据权利要求1所述的方法，其特征在于，所述触发事件包括租户信息，并且，

在将接收的触发事件解析成作业输入条件之后，将所述作业输入条件放入所述触发事件对应的租户的作业条件队列中。

12.一种作业调度的系统，其特征在于，包括：事件接收组件、事件处理组件、作业管理组件、作业派发组件和作业执行组件，其中，

所述事件接收组件，用于接收触发事件，根据所述触发事件匹配使用所述触发事件的对象，获取所述对象所属的作业流信息，并判断所述作业流是否已完成实例化，所述对象包括作业和作业流；若所述作业流已完成实例化，且所述对象为作业则将所述触发事件解析成作业的输入条件，并将所述作业的输入条件发送给所述作业管理组件；否则，将所述触发事件发送给所述事件处理组件；

所述事件处理组件，用于判断所述作业所属的作业流是否满足实例化条件，若满足，则进行作业流实例化；然后将所述触发事件转换成作业的输入条件，并将所述作业流已经到达的所有作业的输入条件发送给所述作业管理组件；

所述作业管理组件，用于在作业包括的输入条件全部就绪后，将所述作业放入作业集合中；

所述作业派发组件，用于从所述作业集合中取出待派发作业并进行作业派发；

所述作业执行组件，用于从已派发的作业队列中获取作业实例信息并执行作业。

13.一种作业调度的电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-11中任一所述的方法。

14.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1-11中任一所述的方法。

Images