任务调度系统建设迭代计划（二）

这是学习笔记的第 1830篇文章

关于任务调度的设计，完成了整体的设计和快速迭代的一个版本，我们需要考虑分布式的方案。

其中对于任务调度的功能拆分是基本的边界，调度是一个很纯粹的执行方式，调度器的执行方式支持异步和定时。

在这个基础上，如果要更加通用需要考虑的就是如何对接和如何把整个定时任务的流程跑通。

这个过程其实是需要一个循序渐进的迭代过程。所以从最开始我所提到的两个步调，先接入异步，然后再稳定定时任务。

第一个步骤是基本的步骤，就是任何一个系统要对接到任务调度平台，是通过API的方式来对接的，这里我们把任务调度平台简称为taskops,数据库运维平台简称为dbops,在这里taskops需要开放一个接入的API,使得任何第三方的系统，异构系统都可以正常的接入任务配置。注意这里仅仅是任务的配置，而不是一个可执行的任务。任务的接入方式都是RESTful API,格式是JSON.

在第1步的基础上，我们开始执行一个基本的任务，任务需要执行，是有一个执行对象的方式，比如这个任务是基于数据库实例维度，对象级别就是实例，即IP+端口，如果是系统主机，对象级别就是主机，即IP，类似这样的方式，当然这个地方是一种提倡的规范，可以根据业务需求做适当的调整。总之在这一步需要执行一个任务，任务的细节是在dbops端提供的API，在taskops端触发。

第3步是我们需要支持一个很常见的场景，比如要安装一个数据库服务，这个动作的触发是在dbops端完成，taskops是完全不需要关注的，那么这个任务要通过dbops能够下推到taskops,则需要通过异步执行的方式推送过来，同时在dbops端可以查看任务的执行结果。这样也就完成了异步任务的对接，任务的执行逻辑还是控制在业务端，任务系统只是一个执行器而已，而要把这个流程跑通，第1步的接入是必须的。所以有了基础的铺垫，我们就可以把需要的任务推送到taskops端，能够被正常识别，也能够看到任务的执行结果。

最后一步是定时任务的接入，这个阶段的接入是在taskops端触发，对于定时任务的触发，其实执行对象是相对确定的方式，需要在taskops端不光做任务的属性配置，还需要做任务执行的配置。

taskops端关注任务的时间属性，而任务的执行细节则是在dbops端负责提供对接，最终任务的执行结果可以通过taskops端来查看。

以上是一个任务调度迭代的过程，也是多系统任务接入的一个参考方式。