灰度、蓝绿、滚动发布到底怎么选：以及上线失败后怎么回滚

很多人学 CI/CD 时，会把注意力放在：

• 工具怎么写
• 流水线怎么跑

但真正决定线上风险大小的，往往不是这些，而是发布策略本身。

先说结论

如果把发布理解成“把新版本传上去并启动”，那只解决了 30% 的问题。

剩下更关键的 70% 在于：

• 新版本怎么接流量
• 老版本什么时候下线
• 发现问题后怎么快速退回

一、最简单的全量发布

全量发布就是：

• 直接把所有实例都切到新版本

它的优点是：

• 简单
• 快

它的问题也很明显：

• 一旦有问题，影响面就是全部用户

二、滚动发布

滚动发布指的是：

• 分批替换旧实例
• 保证服务过程中始终有一部分实例对外可用

它的优点：

• 可用性更高
• 不需要额外双倍资源

它的风险：

• 新旧版本会同时在线一段时间
• 如果版本不兼容，问题会很隐蔽

三、蓝绿发布

蓝绿发布可以理解成：

• 蓝环境跑旧版本
• 绿环境跑新版本
• 验证通过后把流量整体切到绿环境

它的优点：

• 切换快
• 回滚快
• 旧环境还完整保留

四、灰度发布

灰度发布强调的是：

• 先让一小部分流量进入新版本
• 确认没问题后再逐步放大比例

它的价值在于：

• 把风险控制在小范围内

五、我更推荐怎么选

1. 静态站点或个人博客

大多数时候：

• 直接全量替换静态文件

就够了。

2. 普通 Java 业务服务

很多场景下：

• 滚动发布 + 健康检查

已经是很实用的组合。

3. 核心链路服务

更推荐：

• 蓝绿发布
• 或灰度发布

六、为什么回滚要在上线前就设计

很多团队上线时默认想法是：

• 真出问题了再说

但这通常会导致：

• 镜像 tag 混乱
• 老版本配置找不到
• 数据库脚本已不可逆

七、一个更实用的回滚清单

上线前至少确认下面几件事：

• 当前版本号已记录
• 上一版本镜像或 jar 可直接获取
• 数据库脚本是否可回退或兼容旧版本
• 开关配置是否能快速关闭新功能
• 关键监控指标已准备好

八、发布策略和系统设计其实是连在一起的

如果系统本身存在这些问题：

• 新旧版本字段不兼容
• 消息格式强依赖新版本
• 数据写入不可逆

那再高级的发布策略也很难救场。

一句话总结

发布策略的核心，不是“用哪个名词更高级”，而是你的系统能不能在可接受风险下平稳切流量，并在出问题时快速退回到安全状态。