发布策略
上线是最高风险操作：发布策略决定故障影响面。面试主线：四种策略的机制与选型。
四种策略
滚动 / 蓝绿 / 金丝雀: 影响面递增可控
| 策略 | 机制 | 优点 | 缺点 |
|---|---|---|---|
| 滚动更新 | 逐个替换 Pod | 简单（K8s 默认）、资源占用小 | 新旧并存期间兼容性问题 |
| 蓝绿 | 两套环境切换 | 回滚快（切回蓝） | 双倍资源 |
| 金丝雀 | 小流量试新 | 风险最小、真实数据验证 | 需要流量治理（Ingress/网关） |
| 重建 | 先停后启 | 最简单 | 有停机窗口（小项目用） |
滚动更新（K8s 默认）
- Deployment 更新时逐个替换：新 Pod 就绪（readiness）才继续替换
- 参数：
maxSurge（最多多出几个）、maxUnavailable（最多几个不可用） - 风险：新旧版本并存期间，请求可能打到两种版本（数据库兼容性问题：加列先于代码、删列后于代码）
蓝绿
- 两套环境（蓝=旧、绿=新），验证绿后切换流量
- 回滚 = 切回蓝（秒级）
- 代价：两倍资源；数据库兼容（新旧代码同时连一个库）
金丝雀
- 5%-10% 流量到新版本，监控错误率/延迟，稳定后逐步放大
- 需要网关/Ingress 权重路由（或 K8s 多 Deployment）
- 配合：自动回滚（指标异常自动切回）、对比日志
- 面试话术：金丝雀是生产验证新版本的最优解（真实流量 + 最小影响）
回滚策略
| 层 | 手段 |
|---|---|
| 应用 | 旧镜像重新部署（不可变基础设施） |
| 数据库 | 变更脚本可逆（先加后删）、备份恢复（见数据库 PITR） |
| 配置 | 配置中心版本回退 |
| GitOps | git revert（见 CI/CD 篇） |
数据库兼容是发布的核心约束：代码先于数据变更部署（加列兼容旧代码），删除列要等旧代码下线。
面试追问
- 四种发布策略？ 滚动（默认）、蓝绿（切换）、金丝雀（小流量）、重建（停机）。按风险选
- 滚动更新的问题？ 新旧并存：请求打到两个版本，要数据库兼容
- 金丝雀怎么做？ 网关权重路由小流量，监控指标，稳定后放大，异常自动回滚
- 蓝绿的优势？ 回滚秒级（切流量）。代价双倍资源
- 数据库怎么配合发布？ 加列先于代码、删列晚于代码。变更可逆 + 备份兜底