2. 蓝绿发布基础：蓝绿部署模式的定义、原理、与传统滚动更新的对比
2.1 蓝绿部署模式的定义
蓝绿部署（Blue-Green Deployment）是一种零停机的应用发布策略，通过维护两套完全独立的生产环境（蓝环境与绿环境），实现流量的瞬间切换。在任何时刻，只有一套环境对外提供服务，另一套环境则处于待命或预热状态。
核心思想： 永远保留一个可回滚的“已知良好版本”环境，新版本在空闲环境中完成验证后，通过路由层一次性切换流量。
2.2 核心原理与工作流程
蓝绿部署的运作遵循“保留旧环境 → 部署新环境 → 验证 → 切换流量”的闭环。以下为典型流程：
- 初始状态： 蓝环境（Blue）运行 v1.0 版本，承载 100% 生产流量；绿环境（Green）空闲或运行与蓝环境一致的 v1.0。
- 部署新版本： 将 v2.0 部署至绿环境（当前空闲环境），蓝环境继续服务。
- 冒烟测试： 在绿环境上执行自动化冒烟测试、健康检查与预验证，确保 v2.0 功能正常。
- 流量切换： 修改负载均衡器或网关路由规则，将 100% 流量从蓝环境切换至绿环境。
- 观察与回滚： 监控新环境运行状态。若出现异常，立即将流量切回蓝环境（v1.0），实现秒级回滚。
关键指标： 切换耗时通常控制在 < 1 秒（DNS 或 L4 负载均衡器级别），回滚耗时与切换耗时一致，这是蓝绿模式相比滚动更新的最大优势。
2.3 蓝绿部署 vs 传统滚动更新：核心对比
滚动更新（Rolling Update）是 Kubernetes 等编排平台的默认策略，其核心是逐步替换旧实例。蓝绿部署与滚动更新在多个维度存在显著差异：
| 对比维度 | 蓝绿部署 | 滚动更新 |
|---|---|---|
| 环境数量 | 两套完整生产环境（蓝 + 绿） | 一套生产环境，逐步替换实例 |
| 切换方式 | 路由层一次性全量切换 | 逐个或逐批替换 Pod/实例 |
| 回滚速度 | 秒级（流量切回旧环境） | 分钟级（需反向滚动替换） |
| 资源成本 | 高（双倍资源占用） | 低（仅需少量额外缓冲） |
| 验证窗口 | 新环境全量验证后再切换 | 边替换边验证，风险逐步暴露 |
| 流量影响 | 零停机，切换瞬间完成 | 零停机，但长连接可能中断 |
| 数据库兼容 | 需前/后向兼容（双环境共享 DB） | 需前/后向兼容（新旧实例共存） |
关键约束： 蓝绿部署要求数据库 Schema 必须同时兼容 v1.0 和 v2.0（前/后向兼容），否则切换后旧环境无法正常回滚。这是蓝绿模式最常见的失败原因。
2.4 蓝绿部署的适用场景与局限性
蓝绿部署并非银弹，其适用性取决于业务对风险容忍度与资源预算的权衡：
- 适用场景：
- 核心交易链路（支付、订单），要求回滚时间 < 10 秒。
- 大版本发布（架构重构、数据库迁移），需要全量预验证。
- 合规审计场景，需要保留旧环境作为即时回退点。
- 局限性：
- 资源成本翻倍：需维护两套完整生产集群（计算 + 网络）。
- 数据库状态管理复杂：共享数据库时需严格兼容性设计。
- 不适合频繁小版本迭代：每次发布都需预热整环境，效率低于滚动更新。
2.5 蓝绿部署的典型架构组件
一个生产级的蓝绿部署系统通常包含以下核心组件：
| 组件 | 职责 | 技术选型示例 |
|---|---|---|
| 负载均衡器 | 流量分发与切换决策 | Nginx、HAProxy、AWS ALB、K8s Service |
| 健康检查探针 | 验证新环境就绪状态 | HTTP / TCP / gRPC 健康端点 |
| 配置管理 | 动态更新路由规则 | Consul、etcd、K8s Endpoint Controller |
| 自动化编排 | 触发部署、切换、回滚流程 | Spinnaker、Argo Rollouts、Jenkins Pipeline |
| 监控告警 | 切换后实时观测错误率与延迟 | Prometheus + Grafana、Datadog |
生产建议： 在切换前，务必在绿环境上运行“预生产流量镜像”或“金丝雀验证”，确保新版本在真实流量模式下的表现符合预期。这是避免“切换即故障”的关键防线。