4. 蓝绿发布原理：蓝绿环境定义、流量切换机制、回滚策略、与滚动更新的对比
蓝绿发布（Blue-Green Deployment）是一种通过维护两套完全独立的生产环境（蓝环境与绿环境）来实现零停机、低风险发布的部署模式。其核心思想是：在任何时刻，只有一套环境承载全部生产流量，另一套环境保持空闲或用于新版本验证，通过一次性切换流量路由器完成版本更新。
4.1 蓝绿环境定义与基础设施模型
蓝绿环境在基础设施层面要求两套逻辑或物理隔离的资源池，包括计算节点、网络配置、数据库连接池、缓存集群等。两套环境共享持久化数据层（如数据库、对象存储），但应用实例、配置、中间件版本完全独立。
环境定义关键属性：
- 蓝环境（Blue）：当前承载生产流量的稳定环境，运行旧版本（v1.0）。
- 绿环境（Green）：预部署新版本（v2.0）的环境，经过完整验证后接管流量。
- 共享层：数据库、消息队列、外部API网关——两套环境必须指向同一套持久化存储，避免数据分裂。
- 流量入口：负载均衡器（如 Nginx、AWS ALB、Kubernetes Service）作为切换闸口。
4.2 流量切换机制
流量切换是蓝绿发布的核心操作，通常由负载均衡器或流量路由层完成。切换动作本质上是修改路由规则，将流量入口从蓝环境指向绿环境（或反之）。
| 切换方式 | 实现组件 | 切换延迟 | 适用场景 |
|---|---|---|---|
| DNS 切换 | DNS 解析记录（A/CNAME） | TTL 生效时间（秒~分钟） | 非实时系统、灰度验证 |
| 负载均衡器切换 | Nginx upstream、AWS ALB 目标组 | 毫秒级 | 高实时性生产环境 |
| Kubernetes Service 切换 | k8s Service selector 标签更新 | 秒级（kube-proxy 同步） | 容器化微服务架构 |
| API 网关路由切换 | Kong、APISIX、Envoy 路由规则 | 毫秒~秒级 | 精细流量控制、灰度比例 |
最佳实践：推荐使用负载均衡器或 API 网关进行切换，因为它们支持原子化操作（一次性修改路由权重），且切换后可以立即通过健康检查确认新环境是否正常响应。DNS 切换因缓存问题，不适合需要精确控制切换时刻的场景。
4.3 回滚策略
蓝绿发布的最大优势在于回滚速度极快——只需将流量切回旧环境即可。回滚操作不涉及重新部署、镜像拉取或配置变更，本质上是流量路由的逆向切换。
回滚陷阱：如果新版本（绿环境）在运行期间修改了共享数据层的 schema 或写入了不兼容的数据，直接切回蓝环境可能导致数据不一致。解决方案：
(1) 数据库变更必须向前兼容（只加字段不删改）；
(2) 使用 Feature Flag 在应用层控制新功能逻辑，而非依赖数据库结构变化；
(3) 必要时执行数据回滚脚本，但会增加回滚时间。
(1) 数据库变更必须向前兼容（只加字段不删改）；
(2) 使用 Feature Flag 在应用层控制新功能逻辑，而非依赖数据库结构变化；
(3) 必要时执行数据回滚脚本，但会增加回滚时间。
4.4 蓝绿发布 vs 滚动更新
滚动更新（Rolling Update）是另一种常见的发布策略，它逐步替换现有实例，而非维护两套完整环境。两者在资源消耗、发布速度、回滚效率、隔离性等方面存在显著差异。
| 对比维度 | 蓝绿发布 | 滚动更新 |
|---|---|---|
| 环境数量 | 2 套完整环境（蓝 + 绿） | 1 套环境，逐步替换实例 |
| 资源成本 | 高（双倍计算资源） | 低（仅需额外 1 个实例缓冲） |
| 发布速度 | 快（一次性切换） | 慢（逐步替换，受实例数影响） |
| 回滚速度 | 极快（秒级流量切换） | 慢（需逐步回退实例版本） |
| 隔离性 | 完全隔离（新旧版本不共存） | 部分隔离（新旧实例短暂共存） |
| 流量影响 | 零停机（切换瞬间可能丢包） | 零停机（优雅关闭旧实例） |
| 验证能力 | 可在全量流量切换前进行完整预验证 | 无法预验证全部实例 |
| 适用场景 | 核心服务、高风险变更、需要快速回滚 | 非关键服务、资源受限、低风险更新 |
4.5 蓝绿发布与 Feature Flag 的协同
蓝绿发布解决的是“环境级”的版本切换，而 Feature Flag 解决的是“功能级”的开关控制。两者结合可以实现更精细的发布策略：
- 蓝绿环境 + Feature Flag 双重闸口：流量切换到绿环境后，新功能默认关闭，通过 Feature Flag 逐步放量给特定用户群体。
- 降低回滚粒度：如果绿环境中的某个功能出现问题，无需回滚整个环境，只需关闭对应的 Feature Flag。
- 金丝雀发布增强：在绿环境中使用 Feature Flag 实现用户分群灰度，先让内部用户或 Beta 用户看到新功能。
实践建议：在蓝绿发布流程中，始终将 Feature Flag 作为第二道安全闸口。即使流量已经切换到绿环境，新功能仍应默认关闭，待监控稳定后再通过 Flag 逐步开放。这样即使绿环境整体健康，也能避免因单个功能缺陷导致全量回滚。