灰度发布基础

灰度发布，说白了就是一种“小流量先试，没问题再全量”的发布策略。我刚开始接触这个概念时，觉得它跟蓝绿发布差不多，后来踩过坑才发现——完全两码事。

什么是灰度发布

灰度发布（Canary Release）的核心思路是：先让一小部分用户使用新版本，验证稳定后，再逐步扩大范围，直到覆盖全部用户。 你想想看，就像一个矿工带着金丝雀下矿井——鸟没事，人再下去。

我在项目里遇到过线上全量发布出故障的情况，回滚花了整整两小时。从那以后，我强制团队所有核心服务必须走灰度流程。哪怕只放 1% 的流量，也能提前发现日志异常或者 DB 连接数飙升的问题。

灰度发布的历史演进

最早期的发布方式，就是停机更新。你说痛苦不痛苦？用户烦躁，运维紧张。后来出现了蓝绿发布，两套环境切换，总算解决了停机问题。

但蓝绿有个老毛病——成本高。双倍资源不是谁都扛得住。于是金丝雀发布（也就是灰度发布）开始流行。我记得 2015 年左右，Netflix 的 Spinnaker 把这套概念带进大众视野。再往后，结合开关控制和 A/B 测试，灰度发布变得非常精细。

时期	发布方式	典型痛点
2000s 前	全量停机更新	服务中断，风险极高
2010s 初	蓝绿发布	资源翻倍，切换复杂
2015s 后	金丝雀 / 灰度发布	需要精确流量控制与监控
当前	动态灰度 + 开关控制	配置管理、灰度期间数据一致性

嗯，这里要注意：很多团队把灰度发布直接等同于金丝雀发布，其实不太严谨。金丝雀是灰度的一种具体实现——通常按随机比例切流量；而灰度发布的外延更广，还可以按地域、用户群甚至用户画像做策略。

灰度发布 vs 蓝绿发布 vs 金丝雀发布

我经常被问到：“到底该用哪种？” 先看个对比表，再聊我的经验。

维度	蓝绿发布	金丝雀发布	灰度发布（广义）
环境数	两套完全独立	一套，新版与旧版共存	一套，多版本共存
流量切换	瞬间全量切换	逐渐增加新版流量	按策略逐步放量
回滚速度	秒级（切回旧环境）	分钟级（减小新版流量）	秒级（关闭灰度开关）
资源成本	高（双倍）	低（按需扩缩）	低（开关控制）
适用场景	数据库无大变更，快速全量	核心服务，需小流量验证	复杂策略，如 A/B 测试

我曾经在电商大促前做过一次蓝绿发布，结果旧环境与新环境的数据库 schema 不兼容，回滚后数据写错了——那叫一个惨。后来改用了灰度发布 + 动态开关，分 5 个阶段放量，每个阶段观察 10 分钟，再也没出过类似问题。