这是学习笔记的第 1828篇文章
近期在对接任务调度系统的时候，对整体系统的设计有了一个较为全面的认识，而原本的任务接入是更偏重于数据库方向的任务，而在后续要接入通用任务，这部分的工作和原来相比还是有较大的差异，但是换句话说，因为存在集成难度，所以一旦集成起来，对于任务接入来说，这算是任务调度通用模块的核心价值之一。
对于这部分的工作，还是按照迭代的步调来做，首先能让大家能够直接用到任务调度的一个直观印象就是有这么一个系统，现在不用考虑权限管理，菜单管理，脚本管理等，如果要想快速接入业务需求，得有一个基础的平台可支撑，所以从这个角度来说，借用已有的平台，然后平移过来，在原来的平台的基础上进行定制化的分支开发会是一个见效极快的方式。
从系统的迁移到数据迁移，到基础的环境搭建，基本两个小时就大体搞定了。
能让系统有了一个新的登录入口，同时可以支持基础的系统功能，这个迭代速度应该算是快的了。
目前的系统架构设计如下，我们使用了两台服务器，一台部署了任务调度系统，调度器celery和flower,还有一台服务器部署了数据库MySQL和任务队列Redis和调度器celery，其中celery采用这种方式混部主要是想让后续的调度器支持水平扩展，有了第2个调度器节点后续就可能会有第3个和更多，按照这种方式，从开始的时候就会让我们的调度任务设计就支持分布式的管理方式。
从任务调度系统的设计来说，目前是希望采用如下的方式来进行迭代改进。
首先需要接入的是异步任务，目前的目标是能够让数据库运维系统和任务调度系统能够集成起来，能够把数据库层的指定任务通过API的方式和任务系统对接起来，任务的执行细节还是数据库运维系统来支撑，而调度任务的执行触发则是通过任务系统来完成。
这个阶段的主要目标是：
1）通过API接入的方式能够最小化集成数据库方向的任务，让已有的任务系统先运行起来，先期验证分布式调度器的可行性，及时发现问题。
2）设计初版的业务接入页面，能够支持最基本的接入方式。
只要API接入的方式可行，那么就可以并行开始考虑其他系统的接入测试了。
这个阶段的意义在于：
1）已有的数据库方向的接入可以持续集成和改进
2）在早期接入过程中，及时发现接口设计的规范和适配性，不要等到后期集成才发现局限性
3）后端执行层的接入可以同步考虑，比如ansible,saltstack的执行接入可以同步集成，这样在后续的业务集成中，如果业务方没有成型的技术方案，可以完全复用我们提供的技术栈。
这个阶段的目标是：
1）完善接口的设计规范，通过规划化的接口设计，对已有的接口进行补充和完善
2）该阶段主要对标异步任务，通过异步任务的接入能够实现批量任务的处理
3）开始规划后续的定时任务接入
4）分析和完善已有flower的接口信息，通过解密得到任务执行结果，持久化到数据库中
5）对于任务异常的处理要开始规划和设计完善
6）任务执行日志的补充，这个是集成业务最关键的一个目标，如果任务执行我们不能给予业务查询反馈，我们的集成就是黑盒的处理方式，不够透明和友好
接下来需要考虑定时任务的处理，在这个阶段上会对已有的异步任务的方案有一定的参考，在任务系统的处理方式上需要考虑一些边界问题。
