1. 蓝绿发布概述
1.1 什么是蓝绿发布
蓝绿发布（Blue-Green Deployment）是一种零停机、快速回滚的软件发布策略。生产环境维护两套完全相同的独立基础设施——蓝环境（Blue）与绿环境（Green），任意时刻只有一套环境承载真实用户流量，另一套处于待命或空闲状态。
- 蓝环境（当前生产）：运行现有稳定版本，处理所有用户请求。
- 绿环境（新版本）：部署新版本应用，完成内部验证与健康检查。
- 流量切换：健康检查通过后，通过负载均衡器或网关将流量从蓝环境瞬间切换至绿环境。
- 快速回滚：若新版本出现异常，立即将流量切回蓝环境，恢复时间仅需一次路由变更。
核心思想：两套环境始终就绪，切换而非升级，将发布风险与变更窗口压缩到极致。
1.2 与传统发布方式对比
| 对比维度 | 蓝绿发布 | 滚动发布 | 金丝雀发布 | 传统停机发布 |
|---|---|---|---|---|
| 停机时间 | 零停机（切换瞬间） | 零停机 | 零停机 | 有停机窗口 |
| 回滚速度 | 秒级（路由切换） | 分钟级（逐步回退） | 分钟级（流量调整） | 小时级（重新部署） |
| 基础设施成本 | 高（双倍资源） | 低（与生产一致） | 中（额外少量实例） | 低（单套环境） |
| 环境一致性 | 完全一致 | 逐步替换 | 部分实例运行新版本 | 单版本运行 |
| 发布风险 | 低（全量切换前可验证） | 中（逐步暴露） | 低（小范围验证） | 高（全量一次性） |
| 适用变更类型 | 应用版本、配置、数据库迁移 | 应用版本 | 功能验证、A/B测试 | 紧急修复、低频发布 |
关键差异：蓝绿发布的核心优势在于“切换而非升级”，回滚时无需重新部署，只需将流量切回原环境，这是其他策略无法比拟的。
1.3 适用场景
蓝绿发布并非万能策略，以下场景最能发挥其价值：
- 高可用在线服务：电商、支付、社交、游戏等要求零停机、用户体验不中断的业务。
- 数据库 Schema 变更：配合兼容性设计（前向兼容），蓝绿环境可安全执行迁移脚本。
- 配置与基础设施变更：Nginx 配置、Kubernetes 版本、中间件升级等底层变更。
- 合规与审计场景：金融、医疗等需要完整发布记录与快速回滚能力的行业。
- 自动化 CI/CD 流水线：与 Jenkins、GitLab CI、ArgoCD 等工具集成，实现全自动发布。
不适用场景：资源成本敏感的小型项目、无状态微服务（滚动发布更经济）、需要长时间会话保持且无法迁移的应用。
1.4 核心优势
- 零停机发布：流量切换在毫秒级完成，用户无感知。
- 秒级回滚：发现异常立即切回蓝环境，无需重新构建或部署。
- 全量验证：新版本在绿环境上运行完整健康检查，模拟真实流量。
- 环境隔离：蓝绿环境互不干扰，可并行运行不同版本。
- 自动化友好：健康检查脚本驱动切换决策，适合 CI/CD 流水线。
- 降低人为失误：发布流程标准化，减少手工操作风险。
1.5 健康检查在蓝绿发布中的关键角色
蓝绿发布并非简单部署后直接切换流量，健康检查脚本是决定切换是否执行的核心裁判。没有可靠的健康检查，蓝绿发布将失去安全保障。
- 前置检查：新版本部署后，脚本验证应用进程、端口、API 响应、数据库连接、缓存状态等。
- 持续监控：切换前持续运行多轮检查，确保新环境稳定。
- 切换决策：所有检查通过后，脚本自动触发流量切换；任意检查失败则中止发布并告警。
- 后置验证：切换完成后，脚本再次验证新环境是否正常处理用户请求。
本课程目标：从零构建一套生产级蓝绿发布健康检查脚本，涵盖 HTTP 探测、进程检测、依赖检查、超时重试、告警通知与 CI/CD 集成，确保每次发布安全可控。