零停机部署：蓝绿 vs 金丝雀策略在生产环境

Source: Dev.to

引言

在星期五下午 5 点部署不应该像拆除炸弹一样让人紧张。然而对许多团队而言，每一次部署都是一次风险：会不会出错？回滚有多快？我们是不是应该等到星期一再发布？零停机时间的部署策略正是为了解除这种焦虑而存在的。下面我们来探讨两种经过实战检验的方法：**蓝绿（Blue‑Green）和金丝雀（Canary）**部署。

传统部署的问题

在一次典型的部署过程中：

1. 停止运行中的应用
2. 部署新版本
3. 启动应用
4. 希望一切正常

在步骤 1‑3 期间服务不可用。如果步骤 4 发现问题，回滚就意味着重新执行整个过程。对于需要高可用性的系统来说，这是不可接受的。

蓝绿部署

工作原理

• Blue 负责所有生产流量（当前版本）
• 将新版本部署到 Green（不影响用户）
• 对 Green 进行彻底测试
• 将路由切换到 Green
• Green 成为活动环境，Blue 成为备用环境

回滚？ 只需把路由切回 Blue——瞬间完成。

优缺点

优势

• 即时回滚
• 切换前可完整测试
• 零停机时间
• 易于理解

劣势

• 需要 2 倍的基础设施
• 数据库迁移可能比较复杂
• 切换为全有或全无的方式

金丝雀部署

工作原理

1. 将新版本与稳定版本并行部署。
2. 将一小部分流量（例如 5 %）路由到金丝雀实例。
3. 监控错误率、延迟和业务指标。
4. 若表现良好，逐步提升流量比例：5 % → 25 % → 50 % → 100 %。
5. 若发现问题，则把全部流量切回稳定版本。

优缺点

优势

• 限制冲击范围
• 实际用户验证
• 渐进式建立信心
• 基于数据的决策

劣势

• 路由更复杂
• 需要完善的监控体系
• 完全发布速度较慢
• 会话亲和性（Session‑affinity）挑战

如何选择

适合使用蓝绿的场景

• 需要即时、完整的切换。
• 基础设施成本不是主要顾虑。
• 数据库模式变更较少。
• 偏好更简洁的运维模型。

适合使用金丝雀的场景

• 想要最大限度降低风险。
• 已具备强大的监控能力。
• 用户体验因细分而异。
• 需要在全量发布前进行真实环境验证。

很多团队会两者结合使用：基础设施变更采用蓝绿，应用代码变更采用金丝雀。

数据库注意事项

这两种策略在数据库迁移时都面临挑战。关键原则是让数据库变更向后兼容，从而使旧版和新版应用能够同时工作。

实际案例

零停机部署对那些可用性直接影响业务的系统至关重要：

快速参考

结论

零停机部署的目标不仅是避免宕机，更是让发布变得自信且频繁。当部署变得安全可靠时，团队会更愿意频繁发布。发布越多，改动越小，改动越小，风险也就越低。

想了解高可用分布式系统中完整的部署自动化模式，请参阅 casino solution architecture guide。

自信地交付。无需惊慌地回滚。