什么是蓝绿部署？两套环境切换，通俗版解释

在 AI 服务的发布环节，蓝绿部署是一套很常见的切换办法：准备两套配置完全相同的环境，一套正在对外服务，另一套空着待命。上线新版本时，先把新版发到待命环境，验证无误，再把用户流量整体切过去。整个过程用户几乎察觉不到中断，这也是它流行多年依然常见的原因。

一套在跑，一套待命

打个比方，一家餐厅有两个一模一样的后厨。A 厨房正在出餐，B 厨房里厨师就位、食材备齐，只是不接单。菜单要换新时，新菜谱先在 B 厨房试做，试熟了让前台把订单整体转过去，A 厨房再慢慢改造。两套后厨始终有一套能用，顾客永远吃不到闭门羹。

对应到线上，蓝和绿只是两个代号：蓝色环境跑旧版本模型，绿色环境部署好新版本，请求入口（通常是一个网关或负载均衡）决定把流量指给谁。切换之前，绿色环境已经完成验证；切过去之后，蓝色环境不急着销毁，先保留一段时间，随时可以切回来。

切换的瞬间发生了什么

很多人以为切换很复杂，其实动作只有一个：改一条转发规则。把入口指向从蓝改成绿，新请求全部走新版本，正在处理的老请求跑完收尾，切换通常几秒内完成。如果切过去后发现新版本有问题，把规则改回蓝色即可，这就是回滚，同样只需几秒。

需要留意的是数据这一层。两套环境往往共享同一批用户数据，新版本对数据的写法要和老版本兼容，否则切回去就会出乱子。这一点厨房类比帮不上忙——餐厅订单不管在哪个厨房做，端出来的都是同一道菜；而线上环境的数据库结构、缓存格式可能随版本变化，这才是蓝绿部署真正需要花心思的地方。

什么场景值得上蓝绿

它适合迭代频繁、对中断敏感的服务。比如一个接入豆包或 DeepSeek 提供问答能力的产品，白天用户量大，停机更新等于把用户往外推，蓝绿切换就很值。反过来，内部测试环境半夜重启没人抱怨，就没必要多养一套环境白花钱。是否采用，取决于中断代价和环境成本的权衡。

还有几个相关决策可以一起考虑：算力要提前备多少，参考容量规划的思路；数据敏感、要求部分留在本地的，可以看混合部署；要把服务推到用户设备侧的，适合走边缘部署；想比较两套模型孰优孰劣，则属于模型 A/B 的范畴，和切换发布是两件事。

什么时候不该用它？三类情形要绕开：一是环境搭建成本远高于服务本身的，多养一套得不偿失；二是变更极其频繁、每天上线十几次的，两套环境来回倒腾反而拖慢节奏，这类团队更适合滚动更新；三是新旧版本无法共存的状态，比如两个版本对同一份数据的写法互不兼容，切过去就互相打架，得先把数据层理顺再谈蓝绿。工具选型也是同理，适合的才是对的。

该不该上，把中断代价、变更频率和数据能否共存这三条排一排就清楚了。

蓝绿部署速查表

• 核心动作：新版上待命环境，验证后整体切流量
• 回滚方式：把转发规则改回去，秒级完成
• 主要成本：平时要多养一套环境
• 关键前提：两套环境对数据的读写保持兼容

带走一句：蓝绿部署买的是切换那一刻的从容，平时多备一套环境，就是为了出事时不用手忙脚乱。

蓝绿部署快问快答三则

• 蓝绿部署一定要两套完整机器吗？：不一定，它强调的是两套能独立服务的环境，资源规模看业务体量，小服务用两套轻量配置也成立。
• 切换时正在处理的请求会断吗？：一般不会，入口会等老请求处理完再收尾，这也是它比直接重启平滑的地方。
• 它和金丝雀发布是一回事吗？：两者目的不同，蓝绿是整批切换，金丝雀是先放一小部分流量试水，实践中常常配合使用。