背景

设计目标

开放系统接口，对外提供 REST API，便于对接业务

jobTracker

准实时调度，任务计划的变更，即时生效
周期性任务，规则类似crontab，允许控制有限次数允许
单次任务即刻或者延时执行
支持执行机器资源发现和健康度评估
计算任务进度及估算完成时间

允许多实例运行
提供任务运维能力
任务超时监控

P1 支持agent负载分析及流控
P1 支持任务优先级
P2 任务流水记录(状态更新，操作变更等)
P2 条件触发任务,DAG工作流

agent：

基于docker 对worker资源进程级别隔离
http/shell方式执行任务
执行机器资源监控及上报（使用了docker可能不好实现）
任务超时监控
任务结果上报

P1 worker资源使用限制  （cgroup? docker?）
P1 支持动态扩缩容
P1 主节点发现  --基于配置中心
P1 任务消耗cpu/内存等rofile数据记录。便于异常任务跟踪

实现

agent

方案一:

默认启动进程包含agent和http server, 运行在一个docker内部
一个agent某一个时刻最多运行一个任务
以shell+http方式执行任务
a.http 方式默认是短任务，在docker内部运行一个http server提供服务。由业务提供默认执行时长
b.shell 方式默认为长任务，运行拆分任务，提供一定的并行执行能力，由tracker提供执行进度更新和时长估计
        或者用来执行非python代码
优势:
    1. agent模型简单，便于实现，允许异构系统

劣势: 
    1. http方式调用本质为跨进程调用代码，不如直接给予同一个进程以函数方式调用?
    2. 每个模块需要独立的docker镜像，对于运维比较麻烦
    3. 不容易感知机器当前负载等情况

方案二:

一个agent可以运行一个或者多个worker，agent作为一个代理，worker常驻执行任务
以函数或者shell方式调用
a. 函数方式调用，需要一个taskname到function的映射，类似django的url patterns，长短任务均可以执行
b. shell 可以用来执行非python代码
worker可以基于cgroup对任务资源进行限制(主要为cpu和内存)

优势:
    1. 函数间调用相比http方式更简洁, 对任务控制更加方便
    2. 相对docker可以更精细化控制任务对资源使用
    3. 感知机器当前负载等情况，决定运行任务并行度

劣势：
    1. agent以多进程模型运行，需要进程间通信，代码稍微复杂一些。并且限定只能使用python实现