2. 蓝绿发布基础：传统发布痛点、蓝绿发布原理、流量切换模型、环境隔离设计
2.1 传统发布的四大痛点
在微服务和云原生架构普及之前，应用发布通常采用滚动更新或停机更新。随着业务规模增长，这些方式暴露出以下核心问题：
| 痛点 | 描述 | 典型后果 |
|---|---|---|
| 灰度能力缺失 | 新版本一经部署即全量接管流量，无法小范围验证 | 线上故障影响所有用户，回滚周期长 |
| 回滚速度慢 | 回滚需要重新拉取旧镜像、重建 Pod，耗时数分钟 | 故障窗口期长，SLA 难以保障 |
| 流量与实例耦合 | Service 直接指向所有 Pod，版本变更时流量无法精细控制 | 无法实现 A/B 测试或金丝雀发布 |
| 环境冲突风险 | 新旧版本共享同一套基础设施或数据库 schema | 数据兼容性问题导致脏数据或服务中断 |
关键指标：传统滚动更新中，若新版本存在严重 Bug，从发现到全量回滚平均需要 8-15 分钟；而蓝绿发布可将回滚时间压缩至 30 秒以内（仅需切换流量标签）。
2.2 蓝绿发布原理
蓝绿发布（Blue-Green Deployment）的核心思想是维护两套完全独立的生产环境——蓝环境（当前稳定版本）和绿环境（新版本）。在任何时刻，只有一套环境承载全部生产流量，另一套环境处于待命或验证状态。
命名约定：本课程统一使用“蓝环境”表示当前生产环境，“绿环境”表示待发布的新环境。实际项目中也可互换命名，但原理一致。
发布流程分为三个阶段：
- 准备阶段：在绿环境中部署新版本应用，执行集成测试、冒烟测试，确保服务正常启动。
- 切换阶段：通过流量路由规则（如修改 Service Selector、Ingress 后端或负载均衡器目标组），将流量从蓝环境瞬间切换到绿环境。
- 观察与清理：观察绿环境运行状态，若稳定则下线蓝环境；若异常则立即切回蓝环境。
2.3 流量切换模型
蓝绿发布的流量切换并非只有“全量切换”一种模式。根据业务场景和风险容忍度，可以选择以下三种模型：
| 模型 | 切换方式 | 切换时间 | 适用场景 |
|---|---|---|---|
| 全量切换 | 一次性将 100% 流量从蓝切到绿 | < 1 秒 | 非核心业务、有完善回滚预案 |
| 渐进切换 | 按比例逐步迁移（如 10% → 50% → 100%） | 数分钟至数小时 | 核心交易链路、需要实时监控 |
| 灰度验证后切换 | 先切小部分流量验证，确认无误后全量切换 | 数十分钟 | 涉及数据库 schema 变更或重大重构 |
注意：渐进切换和灰度验证后切换本质上属于“金丝雀发布”与“蓝绿发布”的混合模式。在 Kubernetes 中，这两种模式通常需要借助 Service Mesh（如 Istio）或自定义 Ingress Controller 实现权重路由，而非简单的 Service Selector 切换。
2.4 环境隔离设计
蓝绿发布成功的关键在于两套环境之间的强隔离性。若隔离不彻底，新版本的故障可能通过共享资源污染生产环境。隔离设计需覆盖以下四个维度：
2.5 蓝绿发布的关键设计原则
- 幂等部署：绿环境的部署过程必须可重复，不依赖蓝环境的任何状态。
- 流量原子切换：路由规则的变更应具备原子性，避免出现“部分流量进入未就绪环境”的情况。
- 数据双向兼容：若蓝绿环境共享数据库，新版本的 schema 变更必须向后兼容旧版本。
- 快速回收：验证完成后，及时释放非活跃环境的资源，避免资源浪费。
实战提示：在 Kubernetes 中实现蓝绿发布，最轻量的方式是使用两个 Deployment + 两个 Service，通过修改 Service 的
selector 字段实现流量切换。但这种方式仅支持全量切换。若需要渐进切换，建议使用 Istio VirtualService 或 Nginx Ingress 的 canary 注解。