4. 波次编排的核心要素：波次定义、波次顺序、波次依赖、波次并行度控制

在 GitOps 声明式发布模型中，波次编排（Wave Orchestration） 是将一次发布拆解为多个可独立验证、逐步推进的发布单元，从而降低批量变更带来的爆炸半径。波次编排的四个核心要素——波次定义、波次顺序、波次依赖、波次并行度控制——共同构成了发布策略的骨架。本节将逐一拆解这些要素，并给出可落地的配置范式。

4.1 波次定义：粒度与边界

波次定义的核心是回答“一个波次里放什么”。合理的波次粒度应满足：可独立验证、可回滚、业务语义完整。常见的波次划分维度包括：

4.2 波次顺序：执行序列的显式声明

波次顺序定义了波次之间的前后执行次序。在 GitOps 工具链中，顺序通常通过数字权重或拓扑排序来表达。以下是一个基于 Argo Rollouts 和 Argo CD 的波次顺序声明示例：

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: canary-rollout
spec:
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: {duration: 5m}
        - setWeight: 50
        - pause: {duration: 10m}
        - setWeight: 100
---
apiVersion: wave.argoproj.io/v1
kind: Wave
metadata:
  name: release-wave
spec:
  waves:
    - name: wave-1
      order: 1
      applications:
        - user-service
        - config-service
    - name: wave-2
      order: 2
      applications:
        - order-service
    - name: wave-3
      order: 3
      applications:
        - notification-service

顺序控制的关键原则：

• 先基础后业务：配置中心、服务网格等基础组件应排在前面。
• 先无状态后有状态：无状态服务可快速验证，有状态服务（如数据库）需更谨慎。
• 先低风险后高风险：内部 API 优先于对外暴露的网关。

4.3 波次依赖：前置条件的自动推导

波次依赖定义了“波次 B 必须在波次 A 成功后才能执行”的关系。依赖关系可以是显式声明（通过 dependsOn 字段），也可以是隐式推导（通过分析资源之间的 Service/Ingress/ConfigMap 引用）。

依赖关系必须形成有向无环图（DAG），避免循环依赖导致发布死锁。GitOps 控制器应在编排阶段进行依赖校验，拒绝无效的循环声明。

4.4 波次并行度控制：并发与节流

并行度控制决定了同一时间最多有多少个波次可以同时执行。合理的并行度设置可以平衡发布速度与系统稳定性。并行度控制通常包含两个维度：

• 全局并行度：整个发布流程中同时执行的波次数量上限。
• 波次内并行度：单个波次内同时更新的应用实例数量（即 maxSurge / maxUnavailable）。

以下是一个基于 Argo Rollouts 的并行度控制配置示例：

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: order-service-rollout
spec:
  replicas: 10
  strategy:
    canary:
      maxSurge: 2        # 波次内最多额外启动 2 个新实例
      maxUnavailable: 1  # 波次内最多允许 1 个实例不可用
      steps:
        - setWeight: 20
        - pause: {duration: 3m}
        - setWeight: 60
        - pause: {duration: 5m}
        - setWeight: 100
---
apiVersion: wave.argoproj.io/v1
kind: WaveOrchestrator
metadata:
  name: release-orchestrator
spec:
  maxConcurrentWaves: 2  # 全局最多同时执行 2 个波次
  waves:
    - name: wave-1
      order: 1
      maxConcurrency: 1   # 波次内串行更新
    - name: wave-2
      order: 2
      maxConcurrency: 3   # 波次内最多 3 个实例并行更新

4.5 四要素协同：波次编排的完整流程

四个要素并非孤立存在，而是协同工作形成完整的波次编排生命周期。下图展示了从波次定义到执行完成的完整流程：

4.6 四要素的配置清单与校验规则

在实际 GitOps 流水线中，波次编排的配置通常以 YAML 或 CRD 形式存在。以下是一个完整的配置清单及对应的校验规则：

通过合理组合这四个核心要素，团队可以构建出可预测、可观测、可回滚的声明式发布模型，将每次上线从“黑盒冒险”转变为“白盒可控流程”。