2、蓝绿发布原理：蓝绿环境定义、流量切换机制、回滚策略、与传统滚动发布的对比
蓝绿发布（Blue-Green Deployment）是一种通过维护两套完全独立的生产环境（蓝环境与绿环境）来实现零停机发布与快速回滚的部署策略。其核心思想是：在任何时刻，只有一套环境承载全部生产流量，另一套环境保持空闲或用于部署新版本验证。
2.1 蓝绿环境定义与基础设施模型
蓝绿环境在逻辑上是对等的两套完整应用栈，通常包含负载均衡器、应用实例、数据库/缓存、配置中心等组件。两套环境共享同一套持久化层（如数据库主库），但应用代码与配置完全隔离。
环境角色说明：
- 蓝环境（Blue）：当前承载生产流量的稳定版本（Active）。
- 绿环境（Green）：部署新版本的空闲环境（Standby），验证通过后切换为 Active。
- 路由层（Router/LB）：流量切换的决策点，支持秒级切换。
2.2 流量切换机制
流量切换是蓝绿发布的核心操作，通过修改路由层（负载均衡器、网关或 DNS）的转发规则，将用户流量从蓝环境瞬间切换到绿环境。切换粒度可以是全量切换，也可以是灰度百分比切换。
| 切换方式 | 实现手段 | 切换耗时 | 风险等级 |
|---|---|---|---|
| DNS 切换 | 修改 DNS A 记录 / CNAME | 分钟级（受 TTL 影响） | 中 |
| 负载均衡器切换 | 修改后端服务器组权重 | 秒级 | 低 |
| 网关路由切换 | 修改路由规则 / 流量染色 | 毫秒级 | 低 |
| 服务网格切换 | 修改 VirtualService / DestinationRule | 毫秒级 | 极低 |
最佳实践：生产环境推荐使用负载均衡器或服务网格进行切换，避免 DNS 缓存带来的切换延迟。切换前务必执行完整的冒烟测试与健康检查。
2.3 回滚策略
蓝绿发布的最大优势在于回滚速度极快——只需将路由切回旧环境即可，无需重新部署或构建。回滚操作本质上是流量切换的逆向操作。
回滚注意事项：
- 数据库 schema 变更必须向前兼容，否则回滚后旧版本无法读取新 schema。
- 回滚后需清理绿环境中的临时数据（如缓存、队列消息），避免数据污染。
- 建议保留绿环境至少 24 小时，以便问题排查与数据修复。
2.4 与传统滚动发布的对比
滚动发布（Rolling Update）是 Kubernetes 等平台的默认更新策略，通过逐个替换实例来逐步升级。蓝绿发布与滚动发布在资源消耗、切换速度、回滚效率等方面存在显著差异。
| 对比维度 | 蓝绿发布 | 滚动发布 |
|---|---|---|
| 资源占用 | 需要双倍资源（两套完整环境） | 仅需额外 25%~50% 资源（滚动窗口） |
| 切换速度 | 秒级/毫秒级（路由切换） | 分钟级（逐个实例替换） |
| 回滚速度 | 秒级（路由切回） | 分钟级（反向滚动或重新部署） |
| 版本隔离 | 完全隔离，两套环境互不干扰 | 新旧版本共存于同一集群 |
| 测试验证 | 可在隔离环境充分验证后再切换 | 验证窗口有限，部分实例已更新 |
| 适用场景 | 关键业务、高风险变更、需要快速回滚 | 资源受限、低风险变更、无状态服务 |
选型建议：
- 对于核心交易链路、支付系统、用户认证等高可用要求场景，优先选择蓝绿发布。
- 对于非关键服务、内部工具、批量任务等，滚动发布在资源效率上更具优势。
- 混合策略：核心服务使用蓝绿发布，边缘服务使用滚动发布，通过服务网格统一管理。
2.5 蓝绿发布的关键约束
- 数据库兼容性：所有 schema 变更必须向后兼容，确保旧版本应用仍能正常读写。
- 会话状态：无状态服务最佳；若存在会话，需使用外部会话存储（Redis/数据库）或通过 sticky session 处理。
- 资源成本：双倍环境意味着双倍计算资源，在云环境下需评估成本预算。
- 环境一致性：蓝绿环境的基础设施配置、中间件版本、网络策略必须完全一致，避免环境差异导致问题。