发布策略有哪些
常见发布策略有蓝绿、金丝雀与滚动更新。蓝绿用两套环境切换流量，切换与回退都快，代价是双份资源；金丝雀按比例逐步放量并观察指标，风险控制最好，但需要流量治理与足够的观测能力；滚动更新逐批替换实例，资源开销最小，但回退较慢且会出现版本混跑。选择取决于回退要求、资源成本、观测能力以及应用是否支持多版本共存。
基本信息
| 蓝绿 | 两套环境 + 流量切换 |
|---|---|
| 金丝雀 | 按比例放量 + 指标观察 |
| 滚动 | 逐批替换实例 |
| 选择依据 | 回退速度、资源成本、观测能力 |
| 依赖条件 | 数据库与接口需支持多版本共存 |
| 常见组合 | 金丝雀放量 + 自动回滚 |
典型使用场景
- 核心交易系统发布：优先金丝雀，用小流量验证业务指标
- 要求快速回退的版本切换：蓝绿，切换即回滚
- 无状态服务集群更新：滚动更新，控制资源开销
- 数据库结构变更：配合兼容期做双写与灰度读
- 大规模容器集群：滚动更新配合就绪探针，避免流量打到未就绪实例
- 高风险重构：金丝雀叠加特性开关，分阶段验证
金丝雀观察示例
金丝雀观察示例
5% 流量观察 30 分钟：错误率、延迟、业务指标
正常 → 25% → 50% → 100%
异常 → 回滚并冻结后续批次
要求：回滚动作与阈值预先定义，且经过演练
注意：系统指标正常不代表业务指标正常，两者都要看策略对比
| 策略 | 优点 | 代价 | 适用范围 |
|---|---|---|---|
| 蓝绿 | 切换与回退快 | 双份环境成本 | 可接受双资源的核心系统 |
| 金丝雀 | 风险控制好、真实流量验证 | 需要流量治理与观测能力 | 业务指标敏感的服务 |
| 滚动 | 资源开销小 | 回退较慢、版本混跑 | 无状态服务的日常发布 |
无论采用哪种策略，回滚路径都要提前演练：没有验证过的回滚脚本，等于没有回滚能力。