发布系统：蓝绿发布（Blue-Green Deployment）

一、什么是蓝绿发布？

蓝绿发布：

同时维护 两套完全独立、等价的生产环境：

蓝环境（Blue）：当前线上正在对外服务的稳定版本
绿环境（Green）：新版本环境，只接收测试流量

发布时 通过一次流量切换，将所有用户从蓝环境切到绿环境。

一句话：

双环境，一次切流，秒级回滚

二、蓝绿发布的核心目标

零停机
极低发布风险
极速回滚
发布过程可控、可验证

三、蓝绿发布整体架构

        用户流量
           │
     ┌─────▼─────┐
     │  LB / DNS │
     └─────┬─────┘
           │
   ┌───────┴────────┐
   │                │
蓝环境（v1）     绿环境（v2）
稳定版本          新版本

关键点

两套环境配置一致
流量切换是“原子操作”

四、蓝绿发布的完整流程（标准版）

1️⃣ 准备绿环境

部署新版本代码
使用同样配置（参数、资源）
连接同一或兼容的数据源

2️⃣ 绿环境自测

功能测试
接口回归
健康检查
压测（可选）

此时：

线上用户仍在蓝环境

3️⃣ 切换流量（关键一步）

切换方式：

负载均衡（Nginx / SLB / ALB）
DNS 切换
Ingress 切换

切换动作

秒级完成
不影响连接（取决于实现）

4️⃣ 观察 & 验证

错误率
延迟
业务指标
日志异常

5️⃣ 回滚 or 下线蓝环境

有问题：立即切回蓝环境
稳定后：下线蓝环境，或保留作为下一次发布备用

五、蓝绿发布的前置条件（非常重要）

1️⃣ 环境必须完全一致

系统版本
配置
网络
权限

❌ 环境不一致 = 发布结果不可控

2️⃣ 数据库兼容性

两套环境共享数据库，或
数据库升级向前兼容

⚠️ 蓝绿发布 ≠ 数据库可随便改

3️⃣ 会话管理

Session 不依赖本地
Cookie / Token 可跨环境

六、蓝绿发布的常见实现方式

1️⃣ 负载均衡切换（最常见）

修改 upstream 指向
Ingress backend 切换
权重从 100/0 -> 0/100

优点：

快
可控
可自动化

2️⃣ DNS 切换

修改 A/AAAA 记录
依赖 TTL

缺点：

生效不可控
回滚慢

⚠️ 生产环境不推荐作为唯一方式

3️⃣ Kubernetes 中的蓝绿

实现方式：

两套 Deployment（blue / green）
一个 Service
切换 selector 或 Ingress

七、蓝绿发布 vs 滚动发布

维度	蓝绿发布	滚动发布
停机	无	无
回滚	秒级	较慢
风险	极低	中
成本	高（双环境）	低
实现复杂度	中	低

八、蓝绿发布的优点 & 缺点

✅ 优点

回滚极快
发布影响面小
发布结果明确
非常适合核心系统

❌ 缺点

资源成本高
数据库变更复杂
双环境维护成本

九、蓝绿发布的最佳实践（重点）

切流前必须全量验证
切流动作必须自动化
切流必须支持一键回滚
数据库先做兼容升级
切流后观察 10~30 分钟
保留蓝环境至少 1 个发布周期
切流必须有监控与告警兜底

十、什么时候最适合用蓝绿发布？

核心交易系统
用户量大
不允许失败
对回滚时间极度敏感
SLA 要求高（99.99%+）

十一、总结

蓝绿发布用“资源换确定性”，是高可靠系统最值得投入的发布方式。