4. 灰度批次策略
灰度批次策略是云原生网关升级窗口演练的核心决策环节，决定了流量从旧版本平滑迁移至新版本的速度、风险与可观测性。合理的批次策略能够在保证系统稳定性的前提下，快速验证新版本的正确性，并为回归报告留痕提供结构化的数据来源。
4.1 灰度批次的概念
灰度批次（Gray Release Batch）是指将目标升级实例划分为多个有序的子集，按预设顺序逐步将流量或实例切换至新版本的过程。每个批次都是一个独立的验证单元，完成该批次的回归测试并确认无异常后，方可进入下一批次。
4.2 批次划分原则
批次划分需根据网关集群的部署特征和业务流量模型选择最合适的维度。常见的划分原则包括以下三种，实际生产中通常组合使用。
| 划分原则 | 适用场景 | 优势 | 风险 |
|---|---|---|---|
| 按实例数 | 同质化节点、无状态网关 | 操作简单，批次大小均匀 | 无法感知流量热点 |
| 按流量比例 | 流量分布不均、核心路由需精细控制 | 直接控制爆炸半径 | 需要流量染色或权重路由能力 |
| 按地域/标签 | 多可用区、多集群、多环境部署 | 隔离故障域，保留回退能力 | 批次数量可能过多 |
4.2.1 按实例数划分
将网关实例按固定数量分组，例如总共有 10 个实例，按 1-2-3-4 的批次大小依次升级。此方式最直观，适用于所有实例承载能力一致的场景。
4.2.2 按流量比例划分
通过网关的路由规则（如 Nginx Ingress 的 weight、Kong 的 percentage）将一定比例的流量导向新版本。例如第一批次仅接收 5% 流量，观察无误后逐步提升至 10%、25%、50%、100%。
4.2.3 按地域/标签划分
利用 Kubernetes 的 nodeSelector、availability zone 或自定义标签（如 env=canary、region=cn-east-1）将实例分组。此原则天然具备故障隔离能力，即使某个批次出现问题，也不会影响其他地域的用户。
4.3 批次大小设计
批次大小直接决定升级窗口的总时长和单次故障影响面。设计时需平衡以下三个因素：
- 风险容忍度： 业务允许的最大故障实例比例（通常建议 ≤ 20%）。
- 验证效率： 每个批次需要足够的流量样本以触发回归测试断言。
- 回滚成本： 批次越大，回滚时需恢复的实例越多，耗时越长。
以下为推荐的批次大小设计参考表：
| 总实例数 | 推荐批次数量 | 典型批次大小序列 | 说明 |
|---|---|---|---|
| 3 ~ 5 | 2 ~ 3 | 1 → 2 → 剩余 | 小集群，首批次仅 1 个实例 |
| 6 ~ 20 | 3 ~ 5 | 1 → 2 → 4 → 剩余 | 中等规模，指数增长 |
| 21 ~ 100 | 5 ~ 8 | 1 → 2 → 5 → 10 → 20 → 剩余 | 大规模，前 3 批严格控制 |
| 100+ | 8 ~ 12 | 1 → 2 → 5 → 10 → 20 → 50 → 100 → 剩余 | 超大规模，需配合自动金丝雀 |
4.4 灰度批次策略流程
下图展示了从批次划分到回归报告留痕的完整策略流程：
4.5 批次策略与回归报告留痕的映射
每个灰度批次必须对应一份独立的回归报告留痕记录。建议在批次策略中预定义以下留痕字段：
- 批次 ID： 格式如
batch-{序号}-{时间戳}，确保全局唯一。 - 批次实例列表： 记录该批次包含的 Pod IP 或实例名称。
- 流量比例： 该批次实际承接的流量百分比。
- 验证结果： 通过 / 失败 / 需人工介入。
- 关键指标快照： 延迟 P99、错误率、CPU/内存水位。
4.6 常见批次策略对比
| 策略名称 | 划分依据 | 典型批次序列 | 回归报告粒度 | 推荐场景 |
|---|---|---|---|---|
| 线性递增 | 实例数 | 1 → 2 → 3 → 4 | 每实例 | 测试环境、低风险升级 |
| 指数递增 | 实例数 | 1 → 2 → 4 → 8 | 每批次聚合 | 生产环境、中等风险 |
| 流量权重 | 流量比例 | 5% → 15% → 30% → 50% → 100% | 每比例段 | 核心网关、流量敏感型 |
| 地域优先 | 地域/标签 | az1 → az2 → az3 | 每可用区 | 多 AZ 部署、容灾演练 |
选择批次策略时，应结合网关的部署架构、业务流量特征以及团队的可观测性能力综合决策。无论采用何种策略，都必须确保每个批次都有完整的回归报告留痕，以便在升级窗口结束后进行全链路复盘。