蓝绿部署的流量切换，核心就一句话：两套环境共用同一个入口，通过网关或负载均衡一键切换，秒级生效，回滚就是把流量再拨回去。
这套打法在业内已经非常成熟，主要解决的是“上线即风险”的痛点，下面我从原理、操作、踩坑、选型四个维度,把这件事掰开揉碎讲清楚。
为什么需要两套环境切换流量：一次发布事故的复盘
想象一个周五晚上，你刚把新版本推上线，用户就开始反馈页面打不开，这时候你面临两个选择：一是让用户等着，你现场修Bug；二是直接回滚到旧版本，如果是传统滚动发布，回滚意味着要把上一个版本的代码重新编译、打包、部署，整个过程至少需要十几分钟，而蓝绿部署的玩法是：新版本在绿环境里已经跑了一整天了，流量切换就是改一个配置项的事。
这套机制的核心价值在于把“发布”这个高风险动作，拆解成“部署”和“切换”两个独立步骤，部署不碰线上流量，切换不碰代码逻辑，业内专家指出，超过七成的线上事故发生在发布窗口期,而蓝绿部署能把这个窗口期的不确定性降到最低。
具体到架构上,蓝绿部署最小单元包含四样东西：
- 一套负载均衡器（Nginx、SLB、HAProxy均可）
- 一组蓝环境（当前稳定版本）
- 一组绿环境（待发布新版本）
- 一个流量开关（脚本或控制台按钮）
这个组合没有魔法，就是把“切换”这个动词做到了极致简单。
蓝绿部署流量切换怎么做：一个标准的操作路径
理解原理之后，最关心的肯定是操作细节，拿最常见的Nginx加Tomcat组合举例，一个标准的切换流程长这样：
第一步：确认两套环境的“出身”一致
这步特别容易被忽略，不要只检查代码版本，要检查环境配置差异，比如数据库连接池大小、JVM内存参数、日志级别，这些都要和蓝环境保持一致，否则切换过去之后，绿环境因为配置参数不同，可能会出现诡异的性能问题。
业内共识认为，环境的漂移是蓝绿切换失败的最大隐性杀手，代码正确不等于环境正确,这一点在实操中翻车率极高。
第二步：预检清单是保命符
切换之前，按顺序跑一遍这些检查项：
- 健康检查接口返回200，且耗时峰值在正常范围
- 数据库迁移脚本已执行完毕，无锁表情况
- 缓存预热任务已完成，命中率达标
- 消息队列消费者组已全部连接成功
- 业务日志无ERROR级别告警
每一项都跑通之后再谈切换，这里有一个小技巧：可以先切10%的流量到绿环境，观察5分钟日志，再全量切，但这个比例不是固定的，如果你对这套发布流程非常有信心，直接全量切也完全可以,关键是给自己留一个观察窗口。
第三步：执行切换并验证
切换动作本身不复杂，关键在于可逆，以Nginx为例，核心操作就是修改upstream指向，强烈建议把切换脚本写成可重复执行的幂等脚本，而不是手动改动配置文件，脚本里要包含自动校验逻辑：切换后立即查询Nginx统计接口，确认UPSTREAM的活跃连接数落在绿环境上。
切换后的验证顺序也很重要：
- 先看负载均衡连接数是否平滑迁移
- 再看应用日志是否有异常堆栈
- 然后看核心业务指标（下单成功率、支付回调耗时）是否正常
- 最后看用户侧反馈渠道是否安静
流量切换中DNS与网关的区别
这里需要区分一个概念：流量切换到底是改DNS还是改网关？DNS切换（比如把域名解析指向新IP）的生效时间受TTL影响，短则几十秒，长则数分钟，这在发布场景下是不可接受的，所以蓝绿部署里的“切换”，指的是网关或负载均衡层面的即时切换，不碰DNS解析，DNS适合做灾备切换，不适合做日常发布切换，这个区别决定了你的架构设计方向。
蓝绿部署的最大坑：数据一致性与回滚陷阱
代码可以切来切去，但数据库不会自动跟着切，这是蓝绿部署一个绕不开的话题。
数据库层面双写问题
假设绿环境跑了一个新功能，给用户表增加了一个字段，如果这个字段没有默认值，回到蓝环境就可能导致插入数据失败，行业共识是：代码回滚快，数据回滚难，所以蓝绿部署通常要求数据库变更必须向前兼容，即旧的代码也要能正常运行在新数据结构上，如果实在做不到兼容，就需要引入双写或异步迁移的机制，这会让整个发布复杂度上升一个档次。
回滚不是无脑切
很多人以为回滚就是把流量切回蓝环境，很简单，但如果你在绿环境运行期间产生了大量业务数据，回滚后这些数据怎么办？比如用户下了订单、改了密码、收藏了商品，这些操作都写进了数据库，而数据库是共享的，这时候回滚代码意味着新功能下线，但数据已经留下了，处理不好，就会造成数据状态错乱。
所以比较稳妥的做法是：把“回滚”拆成“代码回滚”和“数据补偿”两步，先切流量，再根据业务情况决定是回补数据、清理由新版本产生的脏数据，还是干脆保留新版数据结构只下线入口，在发布前思考清楚这些问题,能避免很多线上事故。
场景适用性分析：蓝绿部署、灰度发布与滚动发布的取舍
蓝绿部署听起来很美好，但也不是万能的，它的核心优势是快速切换和快速回滚，短板是资源成本翻倍你得长期养着两套完整的生产环境，对于很多中小团队来说，这确实是一笔负担。
这里做一个横向对比,方便你根据实际情况选型：
| 发布策略 | 资源成本 | 回滚速度 | 风险暴露面 | 适用场景 |
|---|---|---|---|---|
| 蓝绿部署 | 高（双倍资源） | 极快（秒级） | 低（整体切换） | 核心稳定性要求极高的系统 |
| 灰度发布 | 中（新增一部分） | 快（按批次回切） | 中（部分用户暴露） | 新功能验证、用户反馈收集 |
| 滚动发布 | 低（复用现有资源） | 慢（重新部署） | 高（持续暴露） | 无状态服务、快速迭代 |
从表里能清楚看到，蓝绿部署在“快速回滚”这个维度上优势明显，但代价是需要支撑双倍资源，如果业务规模很大，两套环境都是几十台机器起步，那这个成本确实不低，搜过“蓝绿部署价格”的人应该知道，很多云厂商会对这类架构多收费，因为资源是双份的，不过也有变通方案：共用一套基础设施，只在切换前才把绿环境扩容到全量规模，切完后缩容，这种做法在实际操作中很常见,本质上是用自动化换资源效率。
蓝绿部署和灰度发布能一起用吗
完全可以，比较理想的组合是：先通过灰度发布把新版本暴露给5%的内部用户，观察核心指标没有异常后，再部署到绿环境，完成蓝绿切换的第二步，这种方式兼顾了风险的精准控制和切换的干净利落。
应用层切换的持久化难题
这一类常被忽略但极容易坑到人的问题，必须单独展开说清楚，很多人顺利切换了流量，却发现用户的登录状态丢了，这通常是因为会话(Session)信息绑定在具体的机器节点上,没有做会话共享。
解决方案只有两种：
- 将Session持久化到外部缓存，比如Redis
- 在网关层配置基于Cookie的粘滞会话
前者是根治方案，后者只能缓解，如果应用没有做会话外部化，贸然切换流量，就会导致老环境里的用户会话全部失效，表现为大批量的“需要重新登录”甚至“购物车清空”的投诉,这是行业里因为蓝绿问题翻车比较经典的场景之一。
相关问答：关于蓝绿部署流量切换的关键疑问
蓝绿部署和灰度发布区别是什么？
蓝绿部署是两套完整环境通过一次切换整体置换流量，用户面对的是完全一致的版本，回滚也是整体回滚，灰度发布是同一套环境里逐步放量，不同用户可能访问不同版本，核心区别在于流量是“整体平移”还是“逐步渗透”，以及回滚时的粒度不同。
蓝绿部署的切换时间到底有多快？
纯配置层面看，Nginx或SLB的修改生效时间通常在毫秒级，但整个切换过程还包括前期的预检、切换时的观察、切换后的验证，这些步骤加起来需要几分钟到十几分钟，如果你把自动化做得很扎实，把预检和验证都写进脚本里，整个流程可以压缩到几秒内完成。
数据库没有回滚，蓝绿部署是不是就不适合用了？
并非如此，蓝绿部署关注的是应用层的切与回，它不要求数据库也跟着切回，大多数团队的实践是：数据库变更走独立发布通道，与代码发布解耦，只要数据库变更遵循向前兼容原则，蓝绿部署的应用层切换和回滚就不会受数据库问题牵连，风险就能被限制在一个可控的范围内。