3. CI/CD流水线架构概览

在深入 OpenTelemetry 采集之前，必须先理解 CI/CD 流水线的标准架构。现代自助流水线（Self-Service Pipeline）通常由开发者通过代码仓库中的声明式配置文件触发，经过一系列标准化阶段完成构建、测试与部署。本章以 GitLab CI、Jenkins 和 GitHub Actions 三种主流工具为例，拆解其阶段划分与性能瓶颈。

3.1 流水线通用阶段模型

无论使用哪种工具，CI/CD 流水线均可抽象为以下五个核心阶段。每个阶段都有明确的输入、输出和性能关键指标。

3.2 三种主流工具的流水线架构对比

GitLab CI、Jenkins 和 GitHub Actions 在架构设计上存在显著差异，这些差异直接影响性能关键点的分布。

3.3 典型流水线阶段划分与性能关键点详解

3.3.1 触发与准备阶段

该阶段是流水线的起点，性能瓶颈往往隐藏在环境初始化和缓存恢复中。

• GitLab CI： Runner 从 GitLab 实例拉取作业，若使用 Kubernetes 执行器，需等待 Pod 调度和镜像拉取。关键指标：作业排队时间、镜像拉取时间。
• Jenkins： Master 将作业分配给 Agent，Agent 需从 Master 同步 Jenkinsfile 和插件。关键指标：Agent 连接建立时间、SCM 检出时间。
• GitHub Actions： GitHub 分配 Hosted Runner，Runner 需下载 Action 和依赖。关键指标：Runner 分配延迟、Action 缓存命中率。

3.3.2 代码检查与编译阶段

这是 CPU 和网络 I/O 密集型阶段，也是最容易产生性能瓶颈的区域。

• 依赖安装： npm、Maven、pip 等包管理器的下载速度受限于镜像源和网络带宽。建议使用私有镜像仓库或缓存代理。
• 编译并行度： 多模块项目应启用并行编译（如 Maven -T 4、Gradle --parallel）。
• 增量编译： 仅编译变更的模块，可大幅减少重复工作。关键指标：编译耗时、增量编译命中率。

3.3.3 测试阶段

测试阶段通常是流水线中最耗时的部分，优化空间最大。

• 测试并行执行： 将测试用例拆分为多个分组，在多个 Runner/Agent 上并行执行。GitLab CI 使用 parallel 关键字，Jenkins 使用 parallel 步骤，GitHub Actions 使用 strategy.matrix。
• Flaky 测试管理： 不稳定的测试会导致流水线频繁失败，浪费大量重试时间。建议使用 OpenTelemetry 采集测试用例的执行历史，自动识别 Flaky 测试。
• 测试数据准备： 数据库迁移、测试数据种子脚本的执行时间应纳入监控。

3.3.4 构建与制品阶段

Docker 镜像构建是该阶段的核心，镜像层缓存是性能关键。

• Docker 层缓存： 合理组织 Dockerfile 的指令顺序，将不常变动的层放在前面，利用 BuildKit 的缓存特性。
• 制品上传： 制品库（如 Nexus、Artifactory、GitLab Container Registry）的写入速度和网络带宽直接影响该阶段耗时。

3.3.5 部署与验证阶段

部署阶段的性能关键点在于部署策略和回滚速度。

• 滚动更新 vs. 蓝绿部署： 滚动更新耗时较长但资源占用少，蓝绿部署切换快但需要双倍资源。
• 健康检查： 部署后的健康检查超时时间设置不当会导致流水线误判失败。

3.4 流水线架构与性能关键点总览图

下图展示了典型自助流水线的阶段划分，并标注了每个阶段的核心性能关键点。

3.5 性能关键点总结

无论使用哪种 CI/CD 工具，以下性能关键点都是 OpenTelemetry 采集的重点目标：

1. 排队时间（Queue Time）： 作业从提交到被 Runner/Agent 开始执行的时间间隔。反映资源池是否充足。
2. 缓存命中率（Cache Hit Ratio）： 依赖缓存、Docker 层缓存的命中率直接影响编译和构建速度。
3. 并行度（Parallelism）： 测试和编译阶段的并行执行效率，可通过 Span 的并发子 Span 数量衡量。
4. 网络 I/O 等待时间： 依赖下载、制品上传/下载的网络传输耗时。
5. Flaky 测试率： 不稳定测试导致的失败重试次数，浪费流水线资源。
6. 部署回滚时间： 部署失败后回滚到上一版本的速度，直接影响 MTTR（平均修复时间）。