蓝绿部署和金丝雀发布是持续交付中十分有效的方法，能够大大降低应用程序部署相关的风险。这两个方法让版本之间来回切换就像轻按开关一样容易。

Test

一、部署与发布的基础概念

1.1 如何将部署与发布解耦

虽然这两个词经常混淆使用，但实际上部署和发布是两个独立的过程。部署是指在特定环境（包括生产环境）安装指定软件版本的过程，更多是一种技术行为。它不一定必须与发布相关联。而发布则是指向客户群提供新功能，是一种业务决策。
传统过程中，会在发布日期前一天部署好更新或是新功能，该更新或功能发布后可能会在媒体中广泛传播。众所周知，在部署过程中可能会出错，而因为发布时间与部署时间十分相近，因此几乎没有解决问题的空间。而如果将部署和发布解耦，那么在整个功能开发过程中频繁进行生产部署可以降低IT部门的风险。那么，要实现部署和发布的解耦，需要代码和架构能够满足新功能发布不需要变更应用程序的代码。

1.2 什么是蓝绿部署

在蓝绿发布过程中，有两套生产环境：蓝环境和绿环境。蓝色是当前版本并拥有实时流量，绿色是包含更新代码的环境。无论任何时候，只有一套环境有实时流量。
要发布一个新本，需要先将代码部署到没有流量的环境中，这是执行最终测试的地方。当IT人员确认应用程序已经准备就绪，就会将所有流量都将路由到绿色环境。那么绿色环境就已经生效，并且执行发布。
这是新代码首次在生产负载（实际流量）进行测试。在实际发布代码之前，风险仍然存在，并且永远不会消失。但是，如果出现问题，IT部门可以快速将流量重新路由回蓝色版本。因此，他们所要做的就是密切监控代码行为，甚至可以使用适当的工具将其自动化，以查看绿色环境中的版本是否运行良好或是否需要回滚。
蓝绿部署：无论何时，只有一套生产环境有实时流量
这种方法已经不是新方法了。IT部门总会创建一个新版本，然后将实时流量重新路由到该版本。而版本控制中通过组件编码提供可靠性和可重复性是这一方法的亮点。
我们应该如何获得可靠性和可重复性？开发人员将所有参数编入版本控制中，该版本控制是一个跟踪所有代码更改的系统，类似于数据库。其中包括应用程序逻辑、构建过程、测试、部署过程、升级过程以及恢复过程等。总之，包含所有影响应用程序的因素。然后，计算机执行代码，在相应的环境中部署应用程序，该环境与版本控制中编码的exact state相匹配。
在DevOps出现之前，该流程通常是手动的，并且容易出错。因为所有更改都只能记录在文档中，基于此，开发人员可以重新创建应用程序和环境。由于需要手动执行两个关键步骤，因此此过程过于不可靠，从而导致频繁出现问题。
虽然将应用程序和环境进行编码也是一项需要手动进行的任务，但是它毕竟只是开发过程的一部分，而不是单独的工作，例如创建文档。在版本控制中编入了与生产环境相同的代码。任何更改或更新都将自动触发测试，以确保代码处于可部署状态。这样，如果出现人为错误，系统也能够很快发现它。

1.3 如何理解金丝雀发布（灰度发布）

与蓝绿部署类似，金丝雀发布也是始于两套环境：有实时流量的环境以及没有实时流量但包含了更新的代码的环境。与蓝绿部署不同的是，流量是逐渐迁移到更新的代码。一开始是1%，然后10%、25%，以此类推，直至100%。通过自动化发布，当确认代码能够正确运行时，它就可以逐步推广到更大、更关键的环境中。如果在任何时候发生了问题，所有流量都会被回滚到之前的版本。这在很大程度上降低了风险，因为仅有一小部分用户会使用到新的代码。
IT不仅可以控制用户部署的比例，而且金丝雀发布还可以从不太重要的用户开始，例如使用免费账户的用户或相对来说不太重要的业务市场。
金丝雀发布：实时流量逐渐从旧版本迁移到新版本直到更新生效

1.4 Cluster Immune System

Cluster Immune System可以让金丝雀发布更进一步。它会连接到生产监控系统，当面向用户的性能偏离预定义范围（例如，错误率高出2%）时，将会自动回滚版本。这种方法可以识别通过自动测试难以发现的错误，并减少了检测和响应性能下降所需的时间。
通过将发布与部署解耦并利用蓝绿部署或金丝雀发布，风险将会显著降低。在任何时候，IT都能够将应用程序回滚到之前的版本——这已经与传统的应用程序发布流程相去甚远了。
新的技术和方法首次让这一切成为可能：版本控制、作为代码的基础架构（Infrastructure as code）、容器和Kubernetes都能在这个崭新的、灵活的、面向DevOps的IT世界中发挥着作用。

部署策略的深入对比

二、蓝绿部署 vs 金丝雀发布

2.1 适用场景对比

蓝绿部署适合：

  • 需要快速切换的场景
  • 对停机时间要求严格的系统
  • 资源充足的环境
  • 需要完整测试新版本后再切换

金丝雀发布适合：

  • 需要逐步验证新版本的场景
  • 资源有限的环境
  • 需要观察新版本在真实环境中的表现
  • 对风险控制要求高的系统

2.2 成本对比

蓝绿部署：

  • 需要维护两套完整的环境
  • 资源成本较高
  • 但切换速度快，风险低

金丝雀发布：

  • 只需要部分资源用于新版本
  • 资源成本相对较低
  • 但需要更长的验证时间

三、其他部署策略

3.1 滚动更新（Rolling Update）

滚动更新是逐步替换旧版本实例的策略：

特点：

  • 逐步替换，不需要额外环境
  • 资源利用率高
  • 但回滚相对复杂

适用场景：

  • 无状态应用
  • 可以接受逐步更新的场景

3.2 A/B测试

A/B测试是同时运行两个版本，根据用户特征分配流量：

  • 可以对比两个版本的效果

  • 需要流量分配机制

  • 适合功能验证

  • 新功能验证

  • 用户体验优化

  • 需要数据对比的场景

四、实施蓝绿部署的步骤

1. 环境准备

  • 准备两套完全相同的生产环境
  • 确保网络、存储、数据库等基础设施就绪
  • 配置负载均衡器支持流量切换

2. 部署新版本

  • 在绿色环境部署新版本
  • 进行完整的测试验证
  • 确保新版本功能正常

3. 流量切换

  • 通过负载均衡器将流量切换到绿色环境
  • 监控系统运行状态
  • 观察关键指标

4. 回滚准备

  • 保持蓝色环境运行
  • 准备快速回滚方案
  • 设置监控告警

五、实施金丝雀发布的步骤

1. 初始部署

  • 部署新版本到少量实例
  • 配置流量分配（如1%）
  • 开始监控

2. 逐步扩大

  • 根据监控结果决定是否扩大
  • 逐步增加流量比例（5%、10%、25%等）
  • 持续监控关键指标

3. 全量发布

  • 确认新版本稳定
  • 将流量全部切换到新版本
  • 下线旧版本

4. 回滚机制

  • 设置自动回滚阈值
  • 监控错误率、响应时间等指标
  • 发现问题立即回滚

六、监控和告警

6.1 关键指标

  1. 错误率：HTTP错误率、应用异常率

  2. 响应时间：平均响应时间、P95/P99响应时间

  3. 吞吐量：QPS、TPS

  4. 资源使用：CPU、内存、网络使用率

  5. 业务指标：订单量、转化率等业务指标

6.2 告警设置

  • 设置合理的告警阈值
  • 配置自动回滚规则
  • 建立告警响应流程

七、最佳实践

1. 自动化部署

  • 使用CI/CD工具自动化部署流程
  • 减少人为错误
  • 提高部署效率

2. 版本管理

  • 使用语义化版本号
  • 保持版本历史记录
  • 支持快速回滚

3. 测试策略

  • 完整的自动化测试
  • 生产环境前的充分测试
  • 灰度环境的验证测试

4. 文档和培训

  • 完善的部署文档
  • 团队培训
  • 应急响应预案

八、常见问题和解决方案

8.1 问题1：数据库迁移

1
挑战：蓝绿部署时如何处理数据库迁移
1
解决方案：
  • 使用向后兼容的数据库迁移
  • 分阶段迁移
  • 使用数据库版本控制工具

8.2 问题2：会话保持

1
挑战：如何保证用户会话在切换时不断开
  • 使用外部会话存储（Redis等）
  • 配置负载均衡器的会话保持
  • 使用无状态设计

8.3 问题3：配置管理

1
挑战：如何管理不同环境的配置
  • 使用配置中心
  • 环境变量管理
  • 配置文件版本控制

九、总结

蓝绿部署和金丝雀发布是现代DevOps实践中的重要部署策略。选择合适的部署策略需要考虑：

  1. 业务需求：对停机时间、风险控制的要求
  2. 资源情况：可用的计算资源
  3. 团队能力：团队的运维能力
  4. 技术栈：使用的技术栈是否支持

无论选择哪种策略，关键是要有完善的监控、告警和回滚机制，确保部署过程的安全和可控。通过持续改进部署流程，可以显著提高系统的可靠性和团队的交付效率。

本文标题： 一文搞懂蓝绿部署和金丝雀发布

发布时间： 2019年09月05日 00:00

最后更新： 2025年12月30日 08:54

原始链接： https://haoxiang.eu.org/1d2cfa40/

版权声明： 本文著作权归作者所有，均采用CC BY-NC-SA 4.0许可协议，转载请注明出处！

赏
× 喜欢就赞赏一下呗！
打赏二维码