部署策略

五种发布模式速查

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1           # 最多多起 1 个新 Pod
    maxUnavailable: 0     # 旧 Pod 不能少（保证容量）

K8s Deployment 默认用滚动——绝大多数业务这就够。

⚠ 必须前向兼容：

[Blue（线上）] ← Service → 用户
[Green（新版）]   待机

切换：Service selector 从 blue → green
出问题：切回 blue

优点：

代价：

90% 流量 → v1（旧）
10% 流量 → v2（新）
观察 10 分钟 / 1 小时 / 1 天 → 没问题逐步加比例

实现层：

关键是有自动判据：

没有判据的"手动观察金丝雀" = 让人盯屏幕，扩大不可避免会被忘掉。

复制真流量到新版本，但不返回响应给用户：

⚠ 注意副作用：

正交于上面所有策略：

if flag("new-pricing-engine", user=user):
    return new_pricing(user)
return old_pricing(user)

部署 ≠ 启用：代码先上线（走滚动 / 蓝绿），开关默认关；通过控制台逐步打开。

工具：

Feature Flag 是把"部署"和"发布"解耦的最有效工具。强烈推荐配合金丝雀使用。

能停服务（夜间维护窗口）→ Recreate（最简单）
不能停 + 资源够 + 想最快回滚 → 蓝绿
不能停 + 资源紧 + 业务量大 → 金丝雀（推荐有 K8s 的团队）
风险特别高（核心算法）→ 金丝雀 + Feature Flag + Shadow

无论哪种部署策略，DB 改动跨版本时都要遵循：

1. 加列 / 加表（向后兼容）→ 部署
2. 新代码同时读写新旧 schema（双写）→ 部署
3. 数据回填
4. 切换为只用新 schema（旧的还留着）→ 部署
5. 删旧列 / 旧表 → 部署

每一步都先部署再做下一步，每一步都可独立回滚。这是大型 schema 改动唯一稳妥的姿势。