3. 蓝绿发布原理
蓝绿发布（Blue-Green Deployment）是一种通过维护两套完全独立的生产环境（蓝环境与绿环境）来实现零停机、低风险发布的云原生部署策略。其核心思想是：在任何时刻，只有一套环境承载全部生产流量，另一套环境保持空闲或用于新版本验证，通过一次性切换流量路由器完成版本更新。
3.1 蓝绿发布核心概念
| 概念 | 说明 | 典型实现 |
|---|---|---|
| 蓝环境（Blue） | 当前承载全部生产流量的稳定环境，运行旧版本应用 | Kubernetes Service 指向 blue-deployment |
| 绿环境（Green） | 部署新版本应用的待命环境，初始无生产流量 | Kubernetes Service 指向 green-deployment |
| 流量路由器 | 负责将用户请求导向蓝或绿环境的网关/负载均衡器 | Ingress / Service Mesh 路由规则 |
| 切换动作 | 将流量路由器从蓝环境指向绿环境的原子操作 | 更新 Service selector / 修改路由权重 |
| 回滚动作 | 将流量路由器重新指回蓝环境的逆向操作 | 恢复 Service selector / 重置路由权重 |
关键前提：蓝绿两套环境必须完全独立（计算、网络、存储），且具备相同的容量和配置，才能保证切换后系统行为一致。
3.2 流量切换机制
蓝绿发布的流量切换通常分为三个阶段，每个阶段都可通过 Prometheus 指标进行校验，确保发布包完整性。
- 预切换验证阶段：绿环境部署新版本后，通过内部端点（ClusterIP / 内部域名）进行功能、性能、数据一致性校验。Prometheus 采集绿环境的
up、http_request_duration_seconds、error_rate等指标，与基线对比。 - 原子切换阶段：修改流量路由器配置，将 100% 生产流量从蓝环境切换至绿环境。切换操作应在秒级完成，且对用户透明。
- 切换后观测阶段：持续观测绿环境的业务指标（如 5xx 错误率、P99 延迟、吞吐量），确认新版本稳定运行。同时保留蓝环境至少一个观测窗口（通常 15-30 分钟），以备快速回滚。
Prom 校验点：在切换前后，通过 PromQL 对比蓝绿两环境的
rate(http_requests_total{status=~"5.."}[5m]) 和 histogram_quantile(0.99, ...)，若绿环境指标劣化超过阈值（如错误率 > 0.1%），则触发告警并中止切换。
3.3 回滚策略
蓝绿发布的回滚操作极其简单且快速，这是其相比滚动发布的核心优势。回滚本质上是将流量路由器重新指向旧版本环境（蓝环境）。
| 回滚场景 | 触发条件 | 操作步骤 | 预期耗时 |
|---|---|---|---|
| 即时回滚 | 切换后观测窗口内发现严重错误（5xx 飙升、P99 超时） | 1. 停止绿环境流量 2. 路由器切回蓝环境 3. 保留绿环境用于问题排查 |
< 1 分钟 |
| 延迟回滚 | 切换后数小时发现数据不一致或性能退化 | 1. 确认蓝环境仍健康 2. 路由器切回蓝环境 3. 修复绿环境问题后重新发布 |
< 5 分钟 |
| 数据回滚 | 新版本写入不兼容数据，需恢复数据库快照 | 1. 回滚数据库至切换前快照 2. 路由器切回蓝环境 3. 验证数据一致性 |
取决于数据量 |
重要约束：蓝绿回滚的前提是蓝环境在切换后未被修改或回收。若蓝环境已释放资源或更新了数据，则回滚可能丢失增量数据。建议在切换后保留蓝环境至少一个完整观测周期（如 30 分钟），并确保数据库兼容双向读写或采用独立数据层。
3.4 与传统滚动发布的对比
滚动发布（Rolling Update）是 Kubernetes 默认的更新策略，逐步替换旧版本 Pod。蓝绿发布与滚动发布在原理、风险、资源消耗上存在显著差异。
| 对比维度 | 蓝绿发布 | 滚动发布 |
|---|---|---|
| 环境数量 | 两套完整环境（蓝 + 绿） | 一套环境，逐步替换 |
| 切换速度 | 秒级原子切换 | 分钟级逐步替换 |
| 回滚速度 | 秒级（切回旧环境） | 分钟级（反向滚动） |
| 资源消耗 | 2x 资源（双倍副本数） | 1x + 缓冲区（通常 125%） |
| 流量影响 | 零停机，切换瞬间可能丢包 | 零停机，但新旧版本共存 |
| 版本隔离 | 完全隔离，无混合流量 | 新旧版本短暂共存 |
| 测试验证 | 可在生产环境全量验证新版本 | 仅能验证部分实例 |
| 适用场景 | 关键业务、数据库 Schema 变更、高风险发布 | 常规功能更新、无状态服务 |
选型建议：在云原生灾备场景中，蓝绿发布是保障发布包完整性和快速回滚的首选方案。结合 Prometheus 对两套环境的全链路指标监控（如
container_cpu_usage_seconds_total、container_memory_working_set_bytes、istio_requests_total），可以在切换前自动校验新版本的健康状态，实现“发布即校验，回滚即恢复”的灾备目标。