3. 同步波次编排概念
在多租户 GitOps 场景中，成百上千个应用实例同时向集群同步会引发 API Server 过载、网络拥堵、资源争抢等问题。同步波次编排（Sync Wave Orchestration）正是为了解决这一规模化同步难题而设计的核心机制。它通过将应用发布过程拆解为多个有序的“波次”，实现可控、可观测、可回滚的渐进式交付。
3.1 波次定义
波次（Wave）是同步编排的最小逻辑单元，代表一组在相同时间窗口内执行同步操作的应用或资源集合。每个波次具有以下属性：
| 属性 | 类型 | 说明 |
|---|---|---|
| Wave ID | 整数 | 波次序号，决定执行顺序（从小到大） |
| Wave Name | 字符串 | 波次标识，如 "db-migration"、"core-service" |
| Member Count | 整数 | 该波次包含的应用/资源数量 |
| Max Concurrency | 整数 | 波次内最大并行同步数 |
| Cooldown | 持续时间 | 波次完成后等待下一波次的间隔 |
| Failure Policy | 枚举 | 失败处理策略：暂停/跳过/回滚 |
实践建议：波次粒度不宜过细。通常一个波次包含 5-20 个应用实例，既能发挥并行优势，又不会因单个实例失败导致整个波次阻塞。
3.2 波次编排目标
波次编排的核心目标可以归纳为以下四点：
- 控制并发压力 — 避免海量应用同时同步导致控制面过载，通过波次限制瞬时同步请求量。
- 保障依赖顺序 — 确保基础设施层（数据库、消息队列）先于业务层同步，防止应用启动时依赖缺失。
- 实现渐进式发布 — 先同步低风险租户或金丝雀实例，验证通过后再扩大波次范围，降低爆炸半径。
- 提升同步可观测性 — 每个波次独立记录状态、耗时、错误率，便于快速定位问题波次。
关键指标：波次编排的成效可通过“同步峰值 QPS 下降率”和“依赖冲突事件归零率”两个指标衡量。理想状态下，引入波次编排后控制面 API Server 的峰值 QPS 应下降 60% 以上。
3.3 波次与发布窗口的关系
波次和发布窗口是两个紧密关联但职责不同的概念。发布窗口定义了“什么时候可以发布”，波次定义了“发布时以什么顺序和节奏执行”。两者的关系可以用下表清晰区分：
| 维度 | 发布窗口（Release Window） | 同步波次（Sync Wave） |
|---|---|---|
| 职责 | 时间约束与准入控制 | 执行顺序与并发控制 |
| 粒度 | 天/小时级别 | 分钟/秒级别 |
| 决策依据 | 业务日历、变更冻结期、审批状态 | 资源依赖、租户优先级、风险等级 |
| 触发方式 | 定时触发或人工审批触发 | 窗口开启后自动按序执行 |
| 失败处理 | 窗口关闭，等待下一窗口 | 波次暂停/跳过/回滚，窗口继续 |
| 典型示例 | “每周二 14:00-16:00 为生产发布窗口” | “Wave 1: 数据库迁移 → Wave 2: 核心服务 → Wave 3: 边缘服务” |
常见误区：不要将波次等同于发布窗口。波次是窗口内的执行编排单元，一个发布窗口可以包含多个波次序列。如果窗口关闭，即使波次未执行完也应立即停止，等待下一窗口重新编排。
3.4 波次依赖与顺序
波次之间的依赖关系决定了同步的执行顺序。常见的依赖类型包括：
- 线性依赖（Sequential） — Wave N 必须等待 Wave N-1 全部成功后执行。适用于强依赖场景，如先升级数据库再升级应用。
- 扇出依赖（Fan-out） — 一个波次完成后，同时触发多个下游波次。适用于并行扩展场景，如核心服务升级后，多个边缘服务同时升级。
- 扇入依赖（Fan-in） — 多个上游波次都完成后，才能执行下游波次。适用于聚合场景，如所有微服务升级完成后，再执行集成测试波次。
- 条件依赖（Conditional） — 根据上游波次的执行结果决定是否执行下游波次。适用于灰度发布场景，如金丝雀波次成功率 > 99% 才执行全量波次。
3.5 波次编排配置示例
以下是一个实际的多租户 GitOps 波次编排配置（以 ArgoCD 的 sync-wave annotation 为例）：
# 租户 A 的数据库迁移波次（Wave 0）
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: tenant-a-db-migration
annotations:
argocd.argoproj.io/sync-wave: "0"
argocd.argoproj.io/sync-wave-cooldown: "30s"
spec:
source:
repoURL: https://git.example.com/tenant-a
path: db-migration
destination:
namespace: tenant-a
syncPolicy:
automated:
prune: true
---
# 租户 A 的核心服务波次（Wave 1，依赖 Wave 0）
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: tenant-a-core-service
annotations:
argocd.argoproj.io/sync-wave: "1"
argocd.argoproj.io/sync-wave-cooldown: "15s"
spec:
source:
repoURL: https://git.example.com/tenant-a
path: core-service
destination:
namespace: tenant-a
---
# 租户 A 的边缘服务波次（Wave 2，依赖 Wave 1）
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: tenant-a-edge-service
annotations:
argocd.argoproj.io/sync-wave: "2"
spec:
source:
repoURL: https://git.example.com/tenant-a
path: edge-service
destination:
namespace: tenant-a
编排执行流程：当发布窗口开启后，ArgoCD 首先执行 Wave 0（数据库迁移），等待 30 秒冷却期后，检查 Wave 0 状态。如果成功，则并行执行 Wave 1 中的所有应用（此处仅一个），再等待 15 秒后执行 Wave 2。如果 Wave 0 失败，则根据 failure policy 决定是暂停整个波次序列还是跳过 Wave 0 继续执行。
3.6 波次编排最佳实践
- 波次编号留空档 — 使用 0、10、20 而非 1、2、3 作为波次号，方便后续插入新波次而不影响已有顺序。
- 基础设施波次优先 — 将数据库迁移、消息队列创建、存储卷初始化等基础设施操作放在 Wave 0，确保业务层启动时依赖就绪。
- 金丝雀波次独立 — 为金丝雀租户或实例分配独立波次（如 Wave 5），验证通过后再触发全量波次（Wave 10）。
- 冷却期不宜过短 — 波次间冷却期建议至少 10-30 秒，给监控系统足够时间采集指标并触发告警。
- 失败策略差异化 — 关键基础设施波次失败应暂停整个编排；非关键业务波次失败可跳过并记录告警。