蓝绿、金丝雀与滚动部署

很多人对"部署"的理解，停留在 npm run build 然后把产物扔到服务器上。这种"直接替换"在生产环境几乎是定时炸弹——你不知道新版本有没有问题，直到它接管了全部流量、全部用户。真正成熟的工程实践,关心的是另一组问题:怎么推?怎么切?出问题怎么在最短时间里回到安全状态?

这三个问题,对应着三种经典的部署策略:蓝绿、金丝雀、滚动。它们不是非此即彼的对立选项,而是不同风险/成本权衡下的工具。下面我把每一种讲透,再告诉你生产里到底该怎么选。

一、部署策略决定风险,而不是版本号

先建立一个观念:部署的本质是流量切换,不是文件上传。

一个新版本推上去,它有没有问题,99% 的情况下你提前测不出来——单测覆盖再高,也无法重现真实流量的长尾、真实数据分布的边界、真实依赖的组合。所以"如何把新版本暴露给流量"这件事,直接决定了:

• 爆炸半径:出问题时,多少用户/流量受影响;
• 发现速度:多快能从真实指标里看出异常;
• 恢复速度:多快能把流量切回安全版本。

"直接替换"的策略,等于把这三个问题都押在新版本上——它一上线就接管 100% 流量,爆炸半径=全量,发现速度靠用户投诉,恢复速度靠重新跑一次 CI/CD。这是最朴素也最危险的方式。

所有"高级"的部署策略,本质上都在做同一件事:把"上线"这个动作,从"一锤子"拆成"可控的渐进过程",让你有机会在小范围内发现问题、在小范围内回滚。 区别只在拆法和代价。

二、蓝绿部署:两套完整环境,瞬切路由

蓝绿是最直观的"双保险"思路。

做法:

• 维护两套完全对等的环境,一套叫蓝(当前生产版本),一套叫绿(即将上线的版本)。
• 你先把新版本部署到绿环境,绿环境此刻不接外部流量,你可以尽情地冒烟测试、跑集成测试。
• 验证通过后,在路由层(负载均衡器、DNS、Nginx/反向代理)做一个配置切换,把入口流量从蓝瞬间导向绿。
• 切换完成,绿变成新的生产,原来的蓝闲下来,成为下一轮的"备用环境"和回滚目标。

回滚特别爽: 万一绿环境出问题,把路由切回蓝即可——几秒钟、一个配置变更的事。这是蓝绿最大的优点:回滚是 O(1) 的、干净的、不需要重新构建的。因为蓝环境那个旧版本还完整地活着。

代价也很明确:

1. 双倍资源。你得有两套服务器/实例/内存,常年空着一套。对云上按量付费的团队,账单直接翻倍;对资源紧张的小团队,常常根本拿不出。
2. 数据库是真正的难点。两套应用环境可以独立,但数据库通常只有一个。如果新版本带了 schema 变更:
   • 切到绿之后 schema 改了,再回滚到蓝,蓝可能就不兼容新 schema 了;
   • 所以蓝绿要求数据库变更必须向前向后兼容,或者用"扩展-收缩"(expand-contract)的模式分两次发布。这是新手最容易踩的坑——以为蓝绿能秒回,结果数据库一把锁死回滚路径。
3. 有状态/会话。如果应用在内存里持有用户会话,切路由的瞬间,绿环境看不到蓝环境的会话,用户会被踢登录。要么会话外置(Redis),要么在低峰期切。

适用场景:

• 物理机/虚拟机环境,K8s 之外的传统部署。蓝绿是这类环境下最干净的切换方式。
• 强需求"零停机 + 极速回滚" 的核心服务。
• 变更风险可控、但想留一道保险 的发布(比如配套做了兼容的 schema 变更)。

三、金丝雀部署:小流量探路,再放量

金丝雀的名字来自老矿工——下井前先放一只金丝雀进去,鸟没事人才敢下。部署里也是一样:先让新版本接一小撮真实流量,看它会不会"死"。

做法:

1. 新版本和旧版本同时在线,通过路由层的权重配置,让新版本只接收一小部分流量,比如 5%。
2. 在观察窗(几分钟到几小时)内,紧盯关键指标:
   • 错误率(5xx、异常计数);
   • 延迟(P95、P99);
   • 业务指标(转化率、支付成功率——这些比技术指标更能说明问题);
   • 日志/告警里的新异常模式。
3. 指标健康 → 放量到下一档(比如 25% → 50% → 100%);
4. 任何一档指标异常 → 立即把新版本的流量权重降到 0,流量全部回到旧版本,回滚完成。

相比蓝绿,金丝雀是"真正的渐进式"——蓝绿是 0% 和 100% 之间的瞬切,而金丝雀允许你在中间任意比例停留、观察。这意味着:

• 爆炸半径最小:出问题最多影响 5% 的流量;
• 可以基于真实数据做决策,而不是发布前的测试数据;
• 天然适合 A/B 测试——把流量按比例分到不同版本,对比业务效果。

代价:

1. 需要精细的流量路由能力。普通的轮询负载均衡做不到按权重分流,你需要:
   • Istio/Linkerd 这类服务网格,在 Service Mesh 层按权重切流量;
   • Nginx/Envoy 的 weighted upstream;
   • K8s + Argo Rollouts,它把"金丝雀 + 自动化指标判断 + 自动回滚"封装成了声明式 CRD,是当下云原生圈最主流的方案。
2. 监控/可观测性必须到位。没有按版本维度的指标拆分,金丝雀就是瞎子——你看到整体错误率涨了,根本不知道是新版本涨的还是旧版本。Prometheus + version label、链路追踪、按版本聚合的 dashboard,都是前置条件。
3. 观察期。放量节奏不能太快,每一档都要留足观察时间。这意味着一次发布可能要几个小时甚至几天。着急发布的团队会嫌它慢。
4. 版本兼容性。新旧版本同时在线、同时读写数据库,API 必须向后兼容(下面滚动部署会展开)。

适用场景:

• 大规模、高 QPS 的在线服务,5% 流量已经足够暴露绝大多数问题。
• 高风险变更:大重构、新依赖、性能敏感的改动。
• K8s/服务网格环境,工具链成熟。

四、滚动部署:K8s 的默认选择,逐步替换

滚动部署是 Kubernetes Deployment 的默认策略,也是绝大多数云原生服务的"日常发布方式"。

做法:

• 不是一次性替换所有实例,而是分批:
  • 启动若干个新版本的 Pod;
  • 等新 Pod 就绪,开始下线一部分旧 Pod;
  • 再启动新 Pod,再下线旧 Pod……如此滚动,直到全部替换。
• 用 maxSurge(超出期望副本数的上限)和 maxUnavailable(允许不可用副本的下限)两个参数控制节奏。比如副本数 10、maxSurge=1、maxUnavailable=0,意味着任何时候都至少有 10 个可用,最多 11 个,新 Pod 一个一个顶上来。

优点:

1. 不需要双倍资源。它只是"多出一点点 surge 容量",相比蓝绿的整套冗余,成本极低。这是它成为 K8s 默认的根本原因。
2. 无需额外的路由配置。K8s 的 Service + Endpoints 自动处理流量,你只管改镜像 tag。
3. 过程平滑。用户感知不到中断。

代价(关键):

1. 新旧版本短暂共存。滚动过程中,集群里同时有 v1 和 v2 的 Pod。这意味着:
   • API 必须向后兼容。v2 要能读懂 v1 写的数据、能处理 v1 发来的请求;反过来 v1 也要能兼容 v2。否则跨版本调用会出错。
   • 数据库 schema 变更要格外小心。还是 expand-contract:先加字段(v1/v2 都能读写)→ 部署 v2 切换到新字段 → 再清理旧字段。绝不能在滚动过程中直接做破坏性的 schema 变更。
2. 回滚比蓝绿慢。出问题要回滚时,等于再做一次反向的滚动部署——把 v2 一个个换回 v1。虽然没有重新构建那么慢,但也不是瞬切。
3. 没有"观察窗"。滚动是匀速推进的,不像金丝雀有"停留观察"的机制。除非你手动 pause,否则它一路滚到底。

适用场景:

• 无状态服务 + 向前向后兼容的版本——这是滚动的舒适区。
• 日常迭代发布,变更风险不高、没有破坏性 schema 变更。

五、特性开关:让"部署"和"上线"解耦

讲完三种策略,必须再补一层维度:特性开关(Feature Flags)。它是所有部署策略的最佳搭档,核心思想是——

代码部署 ≠ 功能上线。

具体做法:新代码照常部署上去(用滚动/金丝雀都行),但新功能被一个开关包着,默认 off。生产环境跑的是新代码,但用户看不到新功能——这叫 dark launch(暗中发布)。等你准备好了,在配置中心(LaunchDarkly、Unleash、自建的 Apollo/Nacos)把开关一开,功能对用户可见;出问题,关掉开关即可,不需要回滚代码。

特性开关解决了几个部署策略本身解决不了的问题:

1. 发布和上线分离。代码可以提前几天部署,功能按业务节奏开关(配合营销活动、灰度城市)。
2. 即时关闭,无需重新部署。回滚代码是分钟级到小时级的(重新构建+发布),关开关是秒级的。
3. 按维度放量。开关可以按用户 ID、地区、白名单做精细灰度,比金丝雀的"按流量百分比"更灵活。
4. 降低部署本身的压力。部署只是换代码,风险被压缩到"能不能跑起来"这一层。

注意:开关是技术债。功能全量稳定后,要及时把开关和死代码清理掉,否则代码里会堆满层层叠叠的 if feature_flag_xxx,变成维护噩梦。

实战中,金丝雀 + 特性开关 是当下最稳的组合:金丝雀负责"代码层面的渐进放量",特性开关负责"功能层面的即时开关"。两者叠加,基本能把发布风险压到最低。

六、生产选型:没有银弹,看环境看变更

三种策略各有取舍,生产里到底怎么选?给一个实操的判断框架。

策略对比

按环境选

• K8s 环境:
  • 默认就用滚动,这是开箱即用的,90% 的日常发布够用。
  • 高风险变更/想精细化放量 → 上 金丝雀,用 Argo Rollouts(声明式、自动按指标判断、自动回滚)或 Istio 的流量权重。这是云原生圈的事实标准。
  • 一般不会在 K8s 里硬上蓝绿——滚动 + 金丝雀已经覆盖了蓝绿能解决的问题,而且更省资源。
• 物理机/虚拟机环境:
  • 没有 K8s 的 Pod 概念,滚动替换成本高 → 蓝绿 是最干净的方案。维护两套机器组,Nginx/HAProxy 切 upstream。
  • 资源实在不够 → 至少做"半蓝绿":只对核心服务做蓝绿,周边服务用滚动。

按变更类型选

• 常规迭代、无 schema 变更:滚动。
• 大重构、新依赖、性能改动:金丝雀,小流量先跑。
• 破坏性变更(不兼容的 API/数据):别用任何"渐进"策略——先用 expand-contract 拆成多次兼容的发布,再滚动/金丝雀。强行滚动只会让你在回滚时哭。
• 营销活动/需要业务节奏控制:特性开关,把上线时机交给业务。

七、回滚是第一公民

最后,也是最容易被忽视的一条原则:

部署前,先想好怎么回滚。

这不是鸡汤,是工程纪律。很多团队在部署计划里花 90% 的篇幅讲"怎么上",对"怎么回"只有一句"出问题就回滚"——真出问题时才发现:

• 回滚要重新构建镜像,CI/CD 跑一遍要 20 分钟,这 20 分钟里线上一直在出血;
• 数据库已经写入了新版本的数据/格式,回滚到旧版本后旧代码读不了;
• 新版本依赖了一个新的下游服务,回滚后旧版本不调用,但其实下游已经在用新格式的缓存……

把回滚当第一公民,意味着:

1. 回滚路径要在部署前验证过。蓝绿:确认旧环境还在、路由能切回去。金丝雀:确认权重能瞬间归零。滚动:确认旧镜像 tag 还在、能反向滚动。
2. 数据库变更要做可逆设计。expand-contract 模式:新增字段(兼容)→ 部署双写版本 → 切换读取 → 清理旧字段。任何不可逆的 DDL(比如直接 DROP COLUMN)都会堵死回滚。
3. 回滚要有演练。Chaos Engineering / Game Day 里应该包含"强制回滚"的科目,让回滚动作变成肌肉记忆,而不是第一次实战就是真实故障。
4. 监控指标要能触发自动回滚。Argo Rollouts 这类工具能对接 Prometheus,错误率/延迟超阈值自动回滚,把 MTTD+MTTR 压到分钟级。人盯监控再手动回滚,反应时间往往是几十分钟。

部署这件事,衡量成熟度的不是"能多快上线",而是"出问题时能多快回到安全状态"。把回滚放在第一位,上线反而会更从容。

小结

1. 部署的本质是流量切换,不是文件上传。 决定风险的不是版本号,而是"怎么推、怎么切、怎么回"。
2. 蓝绿:两套环境瞬切,回滚极快,代价是双倍资源;适合物理机/VM 和强回滚需求,但数据库兼容性是最大坑。
3. 金丝雀:小流量探路再放量,爆炸半径最小,代价是依赖精细路由和成熟的监控;K8s 里用 Argo Rollouts / Istio 落地。
4. 滚动:K8s 默认,成本低、过程平滑,代价是新旧短暂共存、必须向前向后兼容。
5. 特性开关:让"部署"和"上线"解耦,代码可提前部署、功能按开关即时开关,是所有策略的最佳搭档(但也是技术债,要定期清理)。
6. 回滚是第一公民:部署前先想好回滚路径,数据库变更做可逆设计,关键指标能自动触发回滚。

金句:

一次好的部署,不是"成功上线了新版本",而是"无论新版本好坏,我都能在最短时间里回到安全状态"。成熟度的标尺从来不是上线速度,而是回滚速度。