这个任务调度系统能做什么

1.批量执行脚本
2.版本发布
3.发布流程管理
4.服务检测故障自愈
5.定时任务的集中管理
6.任务编排
7.等等.....

与同类型产品相比的优点

1. 高可用
2. 灵活可扩展
3. 组件间依赖程度低，可以替换其中任意组件
4. 对失败率进行控制

任务调度原理图

msched.png

调度顺序gateway-->api-->schedule-->agent-->gitlab-->job-server-->job-cache-->agent-->log-server-->log-center

gitlab：用于脚本的版本管理，权限的控制

job-server: 保存任务，对任务打包等

gateway:  多个机房间的调度通过gateway执行任务的分配

log-center:  日志集中管理服务器

api:    任务调度的入口

schedule:  任务调度的主程序

agent：  客户端，执行具体的任务

log-server:  日志服务器

job-cache:   任务的缓存服务器，下载的任务保存在这里，agent来这里下载任务

zookeeper:  组织任务调度的结构

步骤一:

创建一个任务,任务序号033451dcabe9465eb03e683fe2a2f295,这个任务需要对100台机器执行脚本。所以我们要知道目标机器有哪些，这些机器的执行结果是怎样的？成功或者失败。所以我们要有一种结构表示这种关系。

   msched
        |
        |----tasks
                |
                |-----$task_id {'job_id':test1,fail_rate:0,concurrent:10}
                            |
                            |----targets
                                    |
                                    |-----$hostname  N:新建
                                                     W:等待
                                                     R:执行
                                                     S:成功
                                                     F:失败

步骤二：

一个新任务的创建，任务的状态为N,同时将新建的任务的信息调度给agent(将task_id的信息({‘job_id’:test1,fail_rate:0,concurrent:10})复制给agent的task_id),复制成功后将tasks中的任务状态改为W,复制失败将tasks中的任务状态改为F,同时更新signal信号，以便重新进行调度.

         msched
        |
        |----tasks
        |       |
        |       |-----$task_id {'job_id':test1,fail_rate:0,concurrent:10}
        |                   |
        |                   |----targets
        |                           |
        |                           |-----$hostname  N:新建
        |                                            W:等待
        |                                            R:执行
        |                                            S:成功
        |                                            F:失败
        |
        |----agents
                |
                |-----$target
                        |
                        |
                        |-----tasks
                        |       |
                        |       |-----$task_id   复制过来的任务信息
                        |       
                        |-----alive     心跳信息，临时节点

步骤三:

此时进入第二阶段。当任务被调度到agent后，客户端监控到agent的节点发生变化后，开始在客户端执行任务。执行任务分为这样的几个步骤：
（1）从job－server中选取一个任务地址，下载任务
（2）将下载后的任务文件解压并且渲染为一个可执行的脚本。
（3）调用命令执行脚本，修改server端的tasks的状态为R.
（4）将执行的结果写入log-server.
(5) 如果脚本执行成功了，更改server端tasks的状态为S,如果 失败更改Server端的tasks状态为F,同时更改signal的信号，以便任务可以重新调度
(6) 执行后清理工作空间

步骤四:

一个任务执行完毕后，将server端的callback的状态设置为S，以便于根据callback信息做其他任务

步骤五:

各个客户端的日志可以通过log-server传送给一个日志集中管理的服务器log-center

步骤六:

多个机房间的调度通过gateway执行任务的分配

完整的zookeeper结构图：

   msched
        |
        |----tasks
        |       |
        |       |-----$task_id {'job_id':test1,fail_rate:0,concurrent:10}
        |                   |
        |                   |----targets
        |                           |
        |                           |-----$hostname  N:新建
        |                                            W:等待
        |                                            R:执行
        |                                            S:成功
        |                                            F:失败
        |
        |----agents
        |       |
        |       |-----$target
        |               |
        |               |
        |               |-----tasks
        |               |       |
        |               |       |-----$task_id   复制过来的任务信息
        |               |       
        |               |-----alive     心跳信息，临时节点
        |               
        |
        |----signal
        |       |
        |       |-----$task_id
        |
        |
        |----callback
                |
                |----$task_id