蓝绿发布是干什么的
维护两套同构环境（蓝与绿），新版本部署到非生产槽位，验证通过后把流量整体切过去；出问题切回旧槽位，回滚是分钟级。代价是发布窗口内两套并行、资源接近双倍，且两个版本必须兼容同一份数据：数据库结构变更要向前兼容，否则新结构暴露给旧代码后，切回去也恢复不了。适用于发布频率不高、对回退速度要求苛刻的服务。
基本信息
| 流量切换 | 负载均衡或路由指向新环境 |
|---|---|
| 回滚 | 切回旧环境，分钟级 |
| 资源 | 发布窗口内两套并行，接近双倍 |
| 前提 | 两个版本兼容同一份数据 |
| 适用 | 发布频率低、要求快速回退的服务 |
典型使用场景
- 单体应用整体升级：一次性切换整个版本，验证重点是切换前的全量检查。
- 高风险切换演练：先在预发演练切换流程，正式发布按同一脚本执行。
- 回退要求苛刻：监管或业务要求分钟级恢复时，切回旧环境的确定性高于前滚修复。
- 发布窗口受限：在夜间或低峰窗口完成切换与观察，降低切换动作本身的风险。
- 数据库兼容优先：配合先扩展后收缩式迁移，才能安全切回旧版本。
- 与负载均衡配合：健康检查先在目标组通过，再开始承接流量。
- 定期空转演练：保持切换脚本、权限与排空流程持续可用。
切流量与验证
切流量与验证
kubectl patch service web -p '{"spec":{"selector":{"slot":"green"}}}' # 切到绿环境
kubectl rollout status deployment/web-green # 确认新环境收敛
# 出问题切回：
kubectl patch service web -p '{"spec":{"selector":{"slot":"blue"}}}'切换时长连接会残留在旧环境：先摘除旧环境的新流量、等待连接排空，再完成数据库层面的收尾，否则排空期的报错会污染观察结论。
两套环境要有同构的配置管理：手工给绿环境开小灶，验证就不再代表生产行为。蓝绿不负责发现业务逻辑问题，切换前的验证深度决定发布质量。
切换完成后旧环境应保留待命一段时间再缩容：立即下线会让回退通道失效，也失去热备价值。