📚 课程目录第2章任务粒度设计的基本概念

什么是任务粒度，为什么重要

先问你一个问题：一个大项目几十个模块、上百个微服务，如果每次代码提交都要跑一次完整的CI流水线，从编译到部署，耗时两三个小时——你愿意等吗？反正我不愿意。我刚带团队的时候，遇到过这种情况，每次改一行代码，就得等上两个多小时才能看到结果。那感觉，就像你写完作业交给老师，老师说过两天再告诉你对错。反馈慢到让人抓狂。

后来我发现，问题出在任务粒度上。说白了，就是每个CI任务有多大的“块头”。你要是把整个项目堆成一个任务，那就是一个巨型胖子；你要是拆成几十个细碎的小任务，又可能被依赖关系拖死。所以，搞清楚“任务粒度”到底是什么、为什么重要，是设计高效CI流水线的第一步。

1. 任务粒度的定义

任务粒度，在CI语境里，指的就是流水线中每个独立任务（job或stage）的规模和边界。一个任务可以包含编译、单元测试、静态分析、集成测试……还是只做其中一件事？这就是粒度问题。

粗粒度：一个任务里塞进多个步骤，比如“编译+全部测试+打包”。我见过一个项目，整个CI只有一个job，跑完要2.5小时。
细粒度：每个步骤拆成独立任务，比如编译单独一个任务、单元测试单独一个、集成测试再单独一个。每个任务可能就几分钟到十几分钟。

举个例子，你有个Java项目，包含模块A、B、C。

# 粗粒度示例（单任务）
job:
  name: build_all
  script:
    - compile A
    - compile B
    - compile C
    - run unit tests
    - run integration tests
    - package

# 细粒度示例（多任务）
compile-A:
  script: compile A
compile-B:
  script: compile B
compile-C:
  script: compile C
unit-tests:
  needs: [compile-A, compile-B, compile-C]
  script: run unit tests
integration-tests:
  needs: [unit-tests]
  script: run integration tests
package:
  needs: [integration-tests]
  script: package

你看，细粒度版本里，每个任务职责单一，依赖关系明确。粗粒度版本则是一个“大黑盒”。

2. 为什么粒度设计如此重要？

我为什么一直强调这件事？因为任务粒度直接影响CI系统的效率、稳定性和可维护性。咱们来拆开看。

2.1 反馈速度

跑CI，最核心的需求是快速知道这次提交有没有问题。粗粒度意味着你改了一行代码，也得等2小时才知道结果。细粒度可以并行执行互不依赖的任务，比如模块A编译和模块B编译可以同时跑，反馈时间就能大幅缩短。

关键指标：任务平均耗时。我习惯把每个任务控制在5～20分钟以内，超过30分钟就要考虑拆分了。

2.2 失败隔离

粗粒度任务一旦失败，整个任务都要重跑。比如编译通过了，但一个集成测试挂了，你修完那个测试，还得重新编译、重新跑所有测试——浪费巨大。细粒度任务中，如果只有“集成测试”失败，你可以只重跑那个任务，其他任务的结果缓存起来。我在项目中遇到过，当时把一个大测试任务拆成10个子任务，失败重跑时间从2小时降到15分钟。

2.3 资源利用

细粒度更容易利用并行资源。比如你有4核机器，把任务拆成4个并行的小任务，每个用1核，整体速度提升。粗粒度任务可能单核跑满，其他核闲着。但你想想看，拆得太碎也有问题：任务启动和调度的开销会变大。我曾经把一个任务拆成50个微任务，结果每次光启动任务就花掉几分钟，得不偿失。

2.4 调试与可追溯性

谁都不想在一个巨型任务的日志里翻找错误。细粒度任务的日志清晰明了，哪个任务报错就看哪个。我记得有一次线上问题，一个粗粒度任务的日志有10万行，我找了一个小时才定位到真正的错误行。后来拆开后，类似的排查只需要5分钟。

3. 粗粒度 vs 细力度：一个对比表格

维度	粗粒度	细粒度
反馈速度	慢（顺序执行）	快（并行执行）
失败隔离	差（全量重跑）	好（部分重跑）
资源利用率	低（单核瓶颈）	高（充分利用并行）
依赖管理复杂度	低（简单线性）	高（需要编排）
调度开销	低	高（任务增多）
适合场景	小项目、流程稳定	大项目、频繁变更

没有一个正确的粒度，只有合适你的项目的粒度。

4. 任务粒度设计的知识地图

下面这张图概括了任务粒度设计的核心逻辑。我自己经常用它来指导决策。

这张图展示了一个决策流：提交代码后，你要判断怎么拆。三种典型的结果我都见过。我自己最推荐的还是适中粒度——每个任务5到20分钟，依赖关系控制在三五层以内。既不会太慢，也不会太碎。

5. 避坑指南

我曾经把任务拆分得太细，以为越多越好。结果呢？任务DAG变得非常复杂，一个很小的改动就要触发几十个任务，调度器本身就成了瓶颈。而且有些任务执行时间只有几十秒，但排队和启动时间就花了一分多钟，效率反而下降了。

教训：不要追求极致的细粒度。如果你的任务平均执行时间小于1分钟，就应该考虑合并一些了。

如何评估当前粒度是否合适？我通常看两个指标：

任务平均等待时间 vs 执行时间比值：如果等待时间超过执行时间的50%，说明任务太多或者并行度用完了，需要合并。
失败重跑的成本：如果有20%的失败需要重跑整个阶段，那可能是粒度太粗了。尝试把失败率最高的部分拆出来单独作为任务。

6. 小结

任务粒度不是什么高深的概念，但它决定了CI流水线的成败。说白了，就是找到一个平衡点：你的任务不能太粗，否则反馈慢、资源浪费；也不能太细，否则调度开销高、依赖复杂。我个人的习惯是，先粗后细——刚开始用粗粒度跑通整个流程，然后根据实际运行数据（任务耗时、失败率、并行度）逐步拆分。记住，粒度设计不是一次性工作，而是需要持续优化的。