三种发布策略
蓝绿发布准备两套环境整体切换流量，回滚快但资源投入接近翻倍；金丝雀发布先放少量流量验证再逐步放大，风险小但需要版本级观测与快速回滚能力；滚动发布按批次替换实例，成本最低，但新旧版本会在较长时间内并存。
共同前提
三种策略都要求数据库变更向前兼容。如果新版本写入了旧版本无法解析的数据格式，回滚会直接失败，切换流量也救不回来。这也是发布策略必须与扩展-收缩式变更绑定使用的原因：先让新旧版本都能读写，再谈如何切流量。
策略对比
| 策略 | 切流方式 | 代价 |
|---|---|---|
| 蓝绿 | 整体切换流量入口 | 双份资源，数据库兼容要求高 |
| 金丝雀 | 按比例逐步放量 | 需要版本级监控与流量治理 |
| 滚动 | 按批次替换实例 | 新旧版本并存，需前后兼容 |
基本信息
| 观测 | 新版本的成功率、延迟与业务指标需按版本切分 |
|---|---|
| 流量治理 | 按比例、按用户或按地域分流 |
| 回滚 | 分钟级可回滚，且不依赖数据回退 |
| 资源 | 蓝绿约需双份容量，金丝雀只需少量额外容量 |
典型使用场景
- 大版本升级：验证稳定性后再全量切流
- 核心接口改版：先放量 1% 观察错误率与延迟
- 数据库兼容性变更：配合扩展-收缩分阶段发布
- 算法或模型上线：用业务指标判断新版本效果
- 面向大客户的灰度：按租户逐步开放新功能
按用户还是按流量
金丝雀按固定比例分流时，同一个用户可能一会儿命中新版本、一会儿命中旧版本，出现行为不一致。更稳妥的做法是按用户标识或会话哈希分流，保证同一用户在整个灰度期间只看到同一个版本；面向企业客户的产品还可以按租户分流，让问题影响范围可控且便于沟通。
三者共同前提是数据库变更向前兼容，也就是先扩展后收缩。缺少这一步时，回滚会因为数据格式不匹配直接失败，付出比发布本身更大的代价。