一种通用调度平台的设计思路

根据笔者的工作经历，这里总结一种通用调度平台的设计思路。

这里会分三部分介绍：

1、相关概念。明确调度平台中常用的术语，避免歧义。

2、设计思路。分模块介绍各个模块的设计思路。

3、一些问题的处理方法。

1、相关概念

调度平台顾名思义就是调度任务的平台，在说调度平台之前需要先明确一下任务的概念。

工作流：有的同学认为执行一个脚本就是执行一个任务，而有的同学则是将多个脚本组装的流称为任务。本文采用后者的思路，为了避免歧义，则会将任务流称为工作流。

实例：工作流每次调度的记录则是一个实例。比如说工作流A每小时执行一次，那么3点钟的执行记录是一个实例，4点钟的执行记录也是一个实例。

节点：一个工作流包含多个需要调度的脚本，每个脚本称为一个节点。

调度器（Master）：调度工作流的模块叫调度器。

执行器（Executor）：执行工作流中节点的模块。

整个架构如下所示：

调度平台

2、设计思路

2.1、工作流的存储、转换思路

工作流包含四部分内容：

工作流的基本配置信息，比如说名字，开始执行时间，调度间隔，执行队列，执行超时时间，超时是否告警，管理员等

工作流中节点的依赖信息：比如说节点A的父节点是任务B和任务C，任务B和任务C都只有一个子节点任务A

工作流中节点的配置信息：比如说节点A是一个filter节点，需要配置filter的条件，filter的字段以及filter的值

工作流间的依赖信息：当前工作流可以依赖于另外一个工作流，也可以只依赖于其中一个节点。比如说工作流A是一个天任务，工作流B是一个小时任务，工作流A依赖于工作流B的24个实例。

存储层：

思路一：

四部分单独存储，存为四张表。使用时组装即可。

思路二：

以工作流为核心，内部组件存储在一起，依赖另外存储。也就是说前三部分存一个表，第四部分存一个表。依赖部分和节点的配置信息分别用json存储。

适配层：

适配层提供了一个规整后的工作流，包含基本信息，节点配置，节点依赖，工作流依赖等，并且提供任务流到指定调度引擎任务的转换。其目的主要是为了适配不同的调度引擎。比如说当前的调度引擎用的是airflow，用了一段时间后发现问题特别多，自己写了一套调度逻辑，此时适配层的作用就体现出来了。同时也解决了多个调度器同时运行的问题。

2.2、调度器的设计思路

调度器可以用现有开源的组件，比如说airflow。也可以自己写一套调度逻辑，这里则是介绍如果自己设计调度器，需要从那些角度考虑。

调度器包含实例生成、调度两个模块。

实例生成模块：

实例生成模块包含实例生成和依赖检测两个部分。

实例生成不用管任务的依赖，只需要根据任务配置的调度周期生成实例即可，但生成的实例状态不是待执行状态，而是依赖检测状态。调度器不会调度依赖检测状态的实例。

依赖检测则是选择依赖检测状态的实例，检测它们的依赖的实例或者节点是否都已全部执行成功，如果满足则将实例的状态置为待执行。调度器会调度待执行状态的实例。

调度模块

调度模块包含从数据库取出待执行实例，解析节点DAG关系，对外提供服务三个部分。

取出待执行实例部分的逻辑比较简单，如果当前正在执行的实例个数小于阀值，则以某种优先级取出实例即可。这里可能还涉及到队列限制等。

解析节点DAG部分则是根据节点的DAG关系进行解析，将满足依赖的节点放到内存队列中。

对外提供服务部分则是对外提供http或者rpc服务，供执行器从队列中拉节点执行，以及接收执行器的执行结果。

2.3、节点的管理思路

节点是一个传入参数就可以执行的脚本。

节点脚本存储

首先面临的一个问题是节点的脚本存在哪？有三种方案：

第一种是节点的脚本放在调度器，执行器执行时从调度器拉脚本。

第二种是节点的脚本放在执行器，执行器执行时直接从本地读文件执行即可。

第三种是构建一个节点平台，节点平台管理所有的节点，执行器执行时从节点平台拉脚本执行。

第一种方案的弊端是调度器耦合了节点的管理逻辑，当节点频繁更新时，可能会影响调度器的执行；第二种方案的弊端是更新节点的脚本比较麻烦，需要手动下发；第三种方案的弊端是管理比较复杂。这里的方案根据特点自己选择即可。

节点执行时，执行器直接impor节点执行即可。

3、常见问题的处理方法

3.1、节点是push or pull？

如果选用push，那么调度器需要做三件事，挑选节点，挑选执行器，把节点配置信息推到执行器。挑选执行器这块会比较复杂，可能需要根据执行器执行的任务个数，执行器当前的资源来决定。

如果选用pull，调度器需要做两件事，挑选节点，向执行器返回节点的配置信息。

下面的问题都是基于节点是以pull的方式讨论的。

3.2、如何保证高可用和高扩展？

调度器采用主备的方式（ZK实现），同一时间点只有一个调度器可用。

执行器属于对等的方式，各类执行器保持一致，需要添加机器时直接增加即可，无需重启集群。

调度器监控执行器，当执行器丢失时，重置执行器上面正在执行的任务；

执行器监控调度器，当调度器丢失时，从zk上面获取新的调度器ip。

3.3、调度器丢失时，如何保证数据的一致性？

方案一：备调度器检测到主调度器丢失时，直接将正在执行的任务全部重置，自己变为主调度器；执行器检测到master丢失时，直接丢掉所有正在执行的节点；

所有正在执行的任务都是从刚正在执行的节点开始执行，数据不会错乱。

方案二：备调度器检测到主调度器丢失时，自己变为主调度器，将正在执行的任务和节点恢复到内存中；执行器检测到master丢失时，继续执行节点，向master返回节点执行的结果时，如果发现master不可用，将节点的执行结果写到本地，每隔段时间重试一次，直至master恢复。

3.4、如何规避调度器和执行器的假死？

假设一执行器所在的机器负载特别高，丢失了zk连接，导致调度器认为执行器挂掉，调度器将节点调度到其他机器执行，过了一段时间后，执行器恢复，向调度器返回节点的执行结果。有如下的影响：

1、同一节点被执行了两次，且数据不一致。不讨论节点执行返回的结果是否幂等，节点的统计信息也会有异常。比如说任务A 3点钟由执行器a开始执行，3点半时执行器a假死，任务A被执行器b开始执行，此时任务A的起始执行时间为3点半，但过会后执行器a恢复，继续执行任务A，4点钟向调度器返回结果，如果没有一些限制措施，则会更新任务A的结束执行时间为4点。此时任务A的起始时间时执行器b的开始时间，结束时间时任务b的结束时间。

2、执行器恢复后未向zk注册，导致调度器未监控到该执行器，如果该执行器再次挂掉，会导致节点假死处于一直被执行的状态。

如果是调度器假死后恢复，对数据的影响不大，但内存中记录的正在执行的节点会一直保留，产生误告警之类的信息。

解决方案：

节点被两个执行器更新的问题：执行器拉取的节点加一个标记位，只有标记位相同的结果才能更新。

执行器假死的问题：执行器有个线程定时监测自己的zk是否存在，如果不存在，创建。

调度器假死的问题：调度器有个线程定时监测主调度器的ip是否是自己的ip，如果不是，自动转换为备调度器。

3.5、隔离计算密集型节点和IO密集型节点

业务场景越多，节点也就越多。根据节点的计算逻辑，可以将节点分为计算密集型节点和IO密集型节点。针对于节点不同的特性，可以将执行器分为多种类型，比如说IO密集型执行器和计算密集型执行器，每种类型的执行器可以通过配置决定自己能执行什么类型的任务。