线上发版如何做到分批发的？详解蓝绿部署，滚动升级，A/B 测试，灰度发布/金丝雀发布

过去的 10 年里，很多大公司都在使用蓝绿部署，安全、可靠是这种部署方式的特点。蓝绿部署虽然算不上” Sliver Bullet “，但确实很实用。在有关于“微服务”、“ DevOps ”、“ Cloud-native ”的讨论中，蓝绿部署、滚动发布、 A/B 测试、灰度发布，这三种部署方式往往同时出镜。

那么问题来了，蓝绿部署、滚动发布、 A/B 测试、灰度发布，这四者之间究竟有何不同？

蓝绿部署

https://martinfowler.com/bliki/BlueGreenDeployment.html
Martin Flower 曾在文章中阐述了蓝绿部署的整体要点，建议大家看看。

基本上，蓝绿部署是一种以可预测的方式发布应用的技术，目的是减少发布过程中服务停止的时间。

简单来说，你需要准备两个相同的环境（基础架构），在蓝色环境运行当前生产环境中的应用，也就是旧版本应用，如图中 App1 version1 、 App2 version1 、 App3 version3 。

当你想要升级 App2 到 version2 ，在蓝色环境中进行操作，即部署新版本应用，并进行测试。如果测试没问题，就可以把负载均衡器／反向代理／路由指向蓝色环境了。

随后你需要监测新版本应用，也就是 App2 version2 是否有故障和异常。如果运行良好，就可以删除 App2 version1 使用的资源。如果运行出现了问题，你可以通过负载均衡器指向快速回滚到绿色环境。

理论上听起来很棒，但还是要注意一些细节：

• 当你切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。如果你的数据库后端无法处理，会是一个比较麻烦的问题；
• 有可能会出现需要同时处理“微服务架构应用”和“传统架构应用”的情况，如果在蓝绿部署中协调不好这两者，还是有可能导致服务停止的；
• 需要提前考虑数据库与应用部署同步迁移 /回滚的问题；
• 蓝绿部署需要有基础设施支持
• 在非隔离基础架构（ VM 、 Docker 等）上执行蓝绿部署，蓝色环境和绿色环境有被摧毁的风险

从过程不难发现，在部署的过程中，我们的应用始终在线。并且，新版本上线的过程中，并没有修改老版本的任何内容，在部署期间，老版本的状态不受影响。这样风险很小，并且，只要老版本的资源不被删除，理论上，我们可以在任何时间回滚到老版本。

滚动发布

什么是滚动发布？

滚动发布，一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。

滚动发布有什么特点呢？

这种部署方式相对于蓝绿部署，更加节约资源——它不需要运行两个集群、两倍的实例数。我们可以部分部署，例如每次只取出集群的20%进行升级。

这种方式也有很多缺点，例如：

• 没有一个确定OK的环境。使用蓝绿部署，我们能够清晰地知道老版本是OK的，而使用滚动发布，我们无法确定。
• 修改了现有的环境。
• 如果需要回滚，很困难。举个例子，在某一次发布中，我们需要更新100个实例，每次更新10个实例，每次部署需要5分钟。当滚动发布到第80个实例时，发现了问题，需要回滚，这个回滚却是一个痛苦，并且漫长的过程。
• 有的时候，我们还可能对系统进行动态伸缩，如果部署期间，系统自动扩容/缩容了，我们还需判断到底哪个节点使用的是哪个代码。尽管有一些自动化的运维工具，但是依然令人心惊胆战。
• 因为是逐步更新，那么我们在上线代码的时候，就会短暂出现新老版本不一致的情况，如果对上线要求较高的场景，那么就需要考虑如何做好兼容的问题。

A/B Testing

A/B 测试跟蓝绿部署完全是两码事。

A/B 测试是用来测试应用功能表现的方法，例如可用性、受欢迎程度、可见性等等。 A/B 测试通常用在应用的前端上，不过当然需要后端来支持。

A/B 测试与蓝绿部署的区别在于， A/B 测试目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论，并确信该结论在推广到全部流量可信；蓝绿部署的目的是安全稳定地发布新版本应用，并在必要时回滚。

A/B 测试和蓝绿部署可以同时使用。

灰度发布／金丝雀发布

灰度发布是在原有版本可用的情况下，同时部署一个新版本应用作为“金丝雀”（金丝雀对瓦斯极敏感，矿井工人携带金丝雀，以便及时发发现危险），测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现、调整问题。

灰度发布／金丝雀发布由以下几个步骤组成：

• 准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。
• 从负载均衡列表中移除掉“金丝雀”服务器。
• 升级“金丝雀”应用（排掉原有流量并进行部署）。
• 对应用进行自动化测试。
• 将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。
• 如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）

总结

对于云计算来说，以上三种策略都是可用的。不难想象，通过 docker 和 kubernetes ，我们可以很简单的实现蓝绿部署、 A/B 测试、灰度发布……比如好雨云，深度整合 Docker 和 Kubernetes ，提供给用户包括代码滚动上线、一键代码回滚等功能和特性在内的强大的 CI/CD 体验 ：）