DAG

概述 凌晨两点，某出行平台的发布窗口刚打开，Jenkins Master 突然 CPU 100%，构建队列积压了 200 多个任务，整个发布流水线卡死。运维团队花了 40 分钟才定位到根因——一个老项目的 Git 仓库里塞了 15G 二进制文件，单次 clone 就要 20 分钟，把 Master 的线程池全部耗尽。 这不是个例。Jenkins 是个优秀的 CI 工具，但当你有 120+ 微服务、发布依赖关系错综复杂、需要精细化控制并发度和回滚顺序时，Jenkins 的 Stage 模型就开始捉襟见肘了。Stage 是线性的，parallel 虽然能并行但无法表达复杂的 DAG 依赖——“服务 A 和 B 可以并发部署，但 C 必须等 A 和 B 都完成后才能部署，D 只依赖 B”——这种关系用 Jenkinsfile 写出来就是一堆嵌套的 parallel 和 stage，维护噩梦。 我在为某新能源物流平台搭建运维平台时，用 Go 自研了一套 DAG 调度引擎，把 120+ 微服务的发布耗时从 1.5 小时压缩到 5 分钟。这篇文章不是教你重新造轮子（除非你的发布场景确实需要），而是把架构决策过程和踩过的坑完整记录下来，让你在选型时有参考、在实现时有避坑指南。 这篇文章适合谁：有 CI/CD 使用经验、正在考虑自研发布平台或对任务编排有深度定制需求的运维开发工程师。我会假设你已经熟悉 Jenkins/GitLab CI 的基本概念，直接上生产级架构设计。 为什么不用现成工具 先说结论：如果你的发布场景是"一个仓库一条流水线"，用 Jenkins/GitLab CI/ArgoCD 完全够了，别自研。但如果你遇到以下场景，自研 DAG 引擎就值得考虑。...