调度工具的复杂，是被你把需求想复杂了

公司让我自研调度工具那会儿，我第一反应是把市面上所有开源调度系统的功能列了个表——定时任务、工作流编排、依赖管理、失败重试、分布式执行、可视化监控、权限控制……列完之后我陷入了巨大的焦虑：这得写到什么时候去？

后来实践证明，我焦虑了一个月，但真正落地的核心代码只写了一周。剩下的时间全花在了"删功能"上——把那些看起来很酷、但实际上现阶段根本不需要的东西从设计文档里一一划掉。

第一步：先搞清楚你的调度工具到底是给谁用的、用来干什么的。

我们团队的调度需求其实很朴素：每天定时跑几个数据同步任务、每周生成一次报表、某些任务之间有上下游依赖、失败了需要自动重试。这些需求用一个轻量级的Go程序加个配置文件就能解决，根本不需要造一个"小XXL-JOB"。

但最开始我被"调度工具"这个词吓到了，脑子里全是分布式、高可用、海量任务这些宏大叙事。导师后来跟我说了一句话帮我定了神："你要做的不是一个调度平台，是一个能帮你省时间的脚本管家。 "

第二步：从最小的可用版本开始，不要一上来就做"平台"。

我第一个版本的调度工具长什么样？一个Go程序，每分钟扫描一次数据库里的任务表，到时间了就启动一个goroutine去执行。依赖管理？没有。可视化界面？没有。分布式？没有。就三件事：读表、到点执行、记日志。

这个简陋的版本用了两周，跑了十几个定时任务。然后问题开始浮现：任务A执行完了才能执行任务B，这个怎么搞？于是加了"前置任务"字段，执行前先检查依赖任务的状态。任务失败了一直重试会把下游搞垮，怎么限制？于是加了"最大重试次数"和"重试间隔"。任务执行时间太长卡住了后面的任务，怎么办？于是加了"超时控制"和"并发限制"。

每个功能都是在真实需求驱动下加上去的，没有一行代码是我"预感以后可能要用"而提前写的。 这不是偷懒，是务实。因为你"预感"的那些需求，百分之八十永远不会出现，而提前写好的代码会变成你维护的负担。

第三步：把"不可靠"当作默认假设来设计。

自研调度工具跟用开源调度平台最大的区别在于——没有现成的高可用方案，出了事得你自己扛。所以从第一天起，我就把"调度器会崩溃"当成必然会发生的事来设计。

任务执行到一半程序重启了怎么办？我在任务表里加了"执行状态"字段——待执行、执行中、成功、失败、超时。每次启动时扫描"执行中"状态的任务，如果超过设定的心跳超时时间就重置为"待执行"重新调度。这个机制保证了调度器哪怕半夜突然挂了，第二天早上重启之后所有未完成的任务都能自动恢复。

类似的思路还用在任务日志上。每条日志写两份——数据库一份存结构化数据，本地文件一份存完整输出。数据库出问题了还能从文件里翻记录，不至于两眼一抹黑。

第四步：用配置文件代替界面，节省百分之八十的开发时间。

很多自研调度工具死在"界面开发"这个环节。管理者觉得没有可视化界面不够"产品化"，开发团队花大量时间写前端，后台调度逻辑反而没时间打磨。

我的做法很干脆：不做界面，用配置文件。 所有任务的调度参数、依赖关系、执行命令、重试策略，全部写在YAML文件里，程序启动时加载。修改任务直接改配置文件然后重启程序，整个过程不到十秒。

这个方案让开发周期大幅压缩，运维同事也很满意——改YAML比在界面上点来点去快多了。等调度规模真的上去了、管理复杂度超出配置文件能承载的范围时，再来考虑做界面也不迟。

第五步：监控和告警是调度工具的命脉。

调度工具跑起来了，但你不能每天登录服务器去看它跑得好不好。我花了两天时间在工具里集成了一个极简的监控模块：每个任务执行完成后，记录耗时和状态；连续失败达到阈值就发告警通知；整体任务积压超过设定值也发告警。

这些监控数据通过webhook推送到企业微信群里，团队所有成员都能看到。任务挂了、慢了、堵了，群里第一时间有通知，不用等人去查。调度工具做得再稳，没有可观测性你就不敢放心让它自己跑。 因为你永远不知道它现在在干什么。

最后回到"自研"这件事。 很多人觉得自研调度工具是为了省钱或者是为了炫技，但实际上自研最大的价值是"刚刚好"。开源的调度平台功能虽全，但大部分你用不上，反而要花大量精力去学习它的配置规则、处理它的版本升级。自研的工具刚好覆盖你当下的所有需求，没有冗余的功能、没有不必要的复杂度，改起来随心所欲。

当然，自研不是最终形态。等任务量从几十个涨到几百个，单机扛不住了、配置文件的维护成本越来越高的时候，再回过头来看那些开源方案，你带着"我已经知道我需要什么"的清晰认知去选型，就再也不会被"功能列表"晃花眼了。知道要什么，比知道有什么，重要得多。