3. 同步波次编排概念
在 GitOps 声明式发布模型中，同步波次（Sync Wave） 是控制多个资源按预定顺序、分组、间隔进行同步的核心编排机制。它解决了“一次性全量发布”带来的不可控风险，将发布过程拆解为多个可观测、可暂停、可回滚的步骤。
3.1 什么是同步波次
同步波次是指将一组 Kubernetes 资源（Deployment、ConfigMap、Service、CRD 等）划分为多个逻辑批次，每个批次称为一个“波次”。Argo CD 等 GitOps 工具按照波次序号从小到大依次执行同步，同一波次内的资源并行同步，不同波次之间可设置等待条件或手动确认。
核心特征：
- 波次序号（Wave ID）：整数标识，数字越小越先执行，默认所有资源属于波次 0。
- 波次内并行：同一波次内的资源同时同步，无先后依赖。
- 波次间串行：只有前一波次所有资源同步成功，才会触发下一波次。
- 可配置间隔：支持设置波次间的等待时间或健康检查条件。
3.2 为什么需要波次编排
没有波次编排的发布（即所有资源同时同步）存在以下严重问题：
| 问题场景 | 无波次编排的风险 | 波次编排的解决方案 |
|---|---|---|
| 基础设施依赖 | 业务 Pod 启动时 CRD/存储尚未就绪，导致 CrashLoopBackOff | 基础设施资源放在 Wave 1，业务资源放在 Wave 3 |
| 数据库迁移 | 新版本代码先启动，数据库 Schema 尚未变更，引发 500 错误 | DB Migration Job 放在 Wave 2，应用 Deployment 放在 Wave 3 |
| 配置热更新 | ConfigMap 变更后，所有 Pod 同时滚动重启，造成全量中断 | 分批波次 + 间隔等待，保持至少 N 个副本可用 |
| 金丝雀验证 | 无法在发布中途暂停验证，发现问题时已扩散到全量 | 金丝雀波次后设置手动确认门禁，通过后再继续 |
| 回滚复杂度 | 全量失败后需要整体回滚，影响范围大、耗时长 | 按波次回滚，仅回滚失败波次，保留已稳定波次 |
常见误区： 不要将波次编排等同于简单的“串行部署”。波次编排的核心价值在于 依赖管理 和 风险隔离，而非单纯的执行顺序控制。错误的波次划分（如将强依赖的资源分到不同波次但未设置等待条件）反而会引入新的故障模式。
3.3 波次编排在发布中的价值
波次编排为 GitOps 发布模型带来了四个核心价值维度：
- 风险隔离（Risk Isolation）：将高风险变更（如数据库迁移、CRD 升级）放在独立波次，失败时仅影响该波次，不会波及整个发布。
- 渐进式验证（Progressive Validation）：每个波次同步后自动执行健康检查、指标监控、人工确认，形成“发布-验证-继续”的闭环。
- 依赖保障（Dependency Guarantee）：通过波次序号显式声明资源间的启动依赖，避免竞态条件和时序错误。
- 可观测性提升（Observability）：每个波次的同步状态、持续时间、失败原因均可独立追踪，便于审计和复盘。
实践建议： 在 Argo CD 中，通过
argocd.argoproj.io/sync-wave 注解为资源分配波次序号。推荐将波次间隔设置为 30-60 秒，并配合 sync-wave-hook 实现波次间的自动化健康检查。对于关键生产发布，建议在波次 2 和波次 3 之间插入人工确认步骤。
3.4 波次编排的典型模式
根据发布场景的不同，波次编排通常采用以下几种模式：
| 模式名称 | 波次划分策略 | 适用场景 |
|---|---|---|
| 基础设施优先 | Wave 1: CRD/Namespace/RBAC → Wave 2: 中间件 → Wave 3: 业务应用 | 新环境初始化、平台迁移 |
| 金丝雀递进 | Wave 1: 1 个副本 → Wave 2: 25% 流量 → Wave 3: 全量 | 高风险业务版本发布 |
| 数据先行 | Wave 1: DB Migration Job → Wave 2: 只读副本 → Wave 3: 读写副本 | 数据库 Schema 变更、数据迁移 |
| 配置预热 | Wave 1: ConfigMap/Secret → Wave 2: 灰度 Pod → Wave 3: 全量 Pod | 配置热更新、特性开关切换 |
波次编排不是银弹。过度拆分波次（如每个资源一个波次）会导致发布耗时过长；波次粒度过粗（如所有资源一个波次）则失去编排意义。合理的波次数量通常控制在 3~5 个，每个波次包含 3~8 个 资源。