4. 蓝绿发布原理：蓝绿发布定义、流量切换机制、与传统滚动更新的对比
4.1 蓝绿发布定义
蓝绿发布（Blue-Green Deployment）是一种通过维护两套完全独立的生产环境（蓝环境与绿环境）来实现零停机、低风险应用更新的发布策略。在任意时刻，只有一套环境承载全部生产流量，另一套环境处于待命或闲置状态。
- 蓝环境（Blue）：当前运行稳定版本、承载所有生产流量的环境。
- 绿环境（Green）：部署新版本应用、完成内部验证但尚未接入流量的环境。
当绿环境经过充分的功能测试、集成验证与健康检查后，通过流量切换机制将生产流量从蓝环境瞬间转移至绿环境，完成发布。蓝环境随即进入待命状态，作为快速回滚的备用环境。
核心优势： 流量切换在基础设施层（负载均衡器/网关/Service Mesh）完成，应用层无需感知，切换时间通常在秒级甚至毫秒级。
4.2 蓝绿发布流量切换机制
流量切换是蓝绿发布的核心操作，其本质是改变流量分发规则，使入口流量指向新版本环境。在 Kubernetes 生态中，常见的流量切换方式包括：
| 切换方式 | 实现原理 | 切换粒度 | 适用场景 |
|---|---|---|---|
| Service Selector 切换 | 修改 Kubernetes Service 的 spec.selector 字段，将标签指向新版本 Pod |
Pod 级别 | 小型集群、简单微服务 |
| Ingress/网关路由切换 | 在 Ingress Controller 或 API 网关中修改后端 Service 权重或目标 | Service 级别 | 多集群、灰度策略 |
| Service Mesh 流量路由 | 通过 VirtualService/DestinationRule 定义流量权重，实现精细路由 | 请求级别 | 大规模微服务、金丝雀发布 |
以下 SVG 展示了蓝绿发布中流量从蓝环境切换至绿环境的完整流程：
切换原子性： 蓝绿发布的流量切换应保证原子性，即所有流量在极短时间内完成转移，避免出现部分用户访问旧版本、部分用户访问新版本的“混合状态”。在 Kubernetes 中，修改 Service Selector 或更新 Ingress 规则后，kube-proxy 和 Endpoint Controller 的传播延迟通常为 1-5 秒。
4.3 蓝绿发布与传统滚动更新的对比
滚动更新（Rolling Update）是 Kubernetes 默认的更新策略，通过逐步替换旧版本 Pod 实例来发布新版本。蓝绿发布与滚动更新在多个维度存在显著差异：
| 对比维度 | 蓝绿发布 | 滚动更新 |
|---|---|---|
| 环境数量 | 同时运行两套完整环境 | 仅运行一套环境，逐步替换 |
| 资源消耗 | 高（2x 资源需求） | 低（1x + 临时增量） |
| 切换速度 | 秒级，瞬间完成 | 分钟级，逐步完成 |
| 回滚速度 | 秒级，切回旧环境即可 | 分钟级，需反向滚动 |
| 流量影响 | 零停机，切换瞬间完成 | 零停机，但存在新旧版本共存期 |
| 版本兼容性要求 | 低（切换前无混合流量） | 高（新旧版本需兼容） |
| 数据库兼容性 | 需前向/后向兼容 | 需前向/后向兼容 |
| 适用场景 | 关键业务、高风险变更、需快速回滚 | 常规更新、资源受限、版本兼容性好 |
以下 SVG 从资源占用和时间维度对比两种发布策略：
4.4 蓝绿发布的关键考量
- 数据库与状态兼容性：蓝绿发布切换时，新版本应用必须能读写旧版本数据库 schema。通常采用前向兼容（新代码兼容旧 schema）或数据库迁移分阶段执行策略。
- 会话保持（Session Stickiness）：若应用依赖本地会话，切换后用户会话可能丢失。建议将会话状态外置至 Redis 或数据库，或使用 Service Mesh 的会话亲和性配置。
- CNI 网络策略影响：蓝绿环境切换时，CNI 插件的网络策略、安全组规则、Service 端点更新延迟可能导致短暂连通性中断。本课程后续章节将重点讨论此类故障的自动化恢复与验证。
- 资源成本：蓝绿发布需要同时运行两套完整环境，资源消耗翻倍。在资源受限的集群中，可考虑使用命名空间隔离或 HPA 临时缩容蓝环境来降低成本。
常见陷阱： 蓝绿发布并非万能。若新版本存在严重 Bug 且数据库 schema 已变更，回滚蓝环境可能导致数据不一致。务必在切换前完成数据库迁移的回滚预案，或采用“仅前向迁移”策略。