RollingUpdate、Blue Green、Canary 怎么选

先说结论

• 默认最常用的是 RollingUpdate，适合大多数普通服务
• 如果回滚速度要求非常高、切换窗口明确，Blue Green 更稳
• 如果更关注灰度验证、风险收敛和逐步放量，Canary 更合适

一、三种策略分别在解决什么

1. RollingUpdate

它解决的是“不中断服务地逐步替换旧版本”。

优点：

• 原生支持
• 成本低
• 运维复杂度小

代价：

• 新旧版本会并存一段时间
• 出问题时回滚不是最快
• 对兼容性要求更高

2. Blue Green

它解决的是“新旧版本完全隔离，切流时一次切换”。

优点：

• 环境边界清晰
• 回滚快
• 适合大版本切换

代价：

• 资源成本高
• 环境维护复杂
• 数据和外部依赖兼容要提前考虑

3. Canary

它解决的是“先让少量真实流量验证新版本”。

优点：

• 风险收敛最细
• 适合核心链路
• 便于观察真实流量表现

代价：

• 需要更成熟的流量控制和监控
• 发布链路更复杂
• 指标和回滚策略要求更高

二、选的时候最该看哪三个问题

1. 回滚要多快

如果一分钟内就必须切回旧版本，Blue Green 往往更占优。

2. 新旧版本能不能共存

如果新旧版本协议、缓存、数据库结构不完全兼容，RollingUpdate 的风险会更高。

3. 有没有灰度能力

如果你已经有网关、服务网格或流量路由能力，Canary 的价值会更明显；如果没有，直接上 Canary 往往只会把发布链路搞复杂。

三、几类典型场景怎么选

1. 普通内部服务

大多数情况下，RollingUpdate 就够用。

2. 核心交易服务

更适合 Canary，先用少量真实流量验证关键指标。

3. 门户、活动页、大版本切换

如果切换窗口明确且回滚要快，Blue Green 会更稳。

四、最容易踩的坑

1. 只改发布策略，不补监控

没有错误率、RT、实例健康、关键业务指标，灰度和回滚都很难做准。

2. 数据库变更没兼容就做 RollingUpdate

新旧版本并存时最容易出问题的，往往不是 Pod，而是 schema 和数据写法。

3. Canary 只有流量切分，没有明确回滚阈值

灰度流量放出去了，但什么情况下回滚、看哪些指标、观察多久都没定义，最后会很被动。

总结

RollingUpdate、Blue Green、Canary 没有绝对最优，核心是看你更在意什么：简单稳定、回滚速度，还是灰度验证。大多数服务先用 RollingUpdate，关键链路逐步补 Canary，明确切换窗口的服务考虑 Blue Green，会更现实。