过去的10多年里，很多大公司都在使用蓝绿部署，安全、可靠是这种部署方式的特点。蓝绿部署虽然算不上”Sliver Bullet“，但确实很实用。在有关于“微服务”、“DevOps”、“Cloud-native”的讨论中，蓝绿部署、A/B测试、灰度发布，这三种部署方式往往同时出镜。
那么问题来了，蓝绿部署、A/B测试、灰度发布，这三者之间究竟有何不同？
A/B测试
- 消除客户体验（UX）设计中不同意见的纷争，根据实际效果确定最佳方案；
- 通过对比试验，找到问题的真正原因，提高产品设计和运营水平；
- 建立数据驱动、持续不断优化的闭环过程；
- 通过A/B测试，降低新产品或新特性的发布风险，为产品创新提供保障。
参考：https://baike.baidu.com/item/AB%E6%B5%8B%E8%AF%95/9231223?fr=aladdin
但是关于A/B测试的有效性，在一份关于 A/B 测试的报告中，Qubit 的 Martin Goodson 认为：大多数 A/B 测试的结果都不太准确。Web Arts 的 Andre Morys 甚至断论：“ 这些测试结果 90% 都是假的。”如果真的是这样，那么很多决策的制定都基于这些无效的实验，这也是之所以很多非首席风险官经理对 A/B 测试结果的可持续性持怀疑态度的原因。
参考：http://baijiahao.baidu.com/s?id=1603336396513574172
蓝绿部署
Martin Flower曾在文章中阐述了蓝绿部署的整体要点，建议大家看看。
基本上，蓝绿部署是一种以可预测的方式发布应用的技术，目的是减少发布过程中服务停止的时间。
简单来说，你需要准备两个相同的环境（基础架构），在蓝色环境运行当前生产环境中的应用，也就是旧版本应用，如图中App1 version1、App2 version1、App3 version3。
当你想要升级App2到version2，在蓝色环境中进行操作，即部署新版本应用，并进行测试。如果测试没问题，就可以把负载均衡器／反向代理／路由指向蓝色环境了。
随后你需要监测新版本应用，也就是App2 version2是否有故障和异常。如果运行良好，就可以删除App2 version1使用的资源。如果运行出现了问题，你可以通过负载均衡器指向快速回滚到绿色环境。
理论上听起来很棒，但还是要注意一些细节：
-
当你切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。如果你的数据库后端无法处理，会是一个比较麻烦的问题；
-
有可能会出现需要同时处理“微服务架构应用”和“传统架构应用”的情况，如果在蓝绿部署中协调不好这两者，还是有可能导致服务停止的；
-
需要提前考虑数据库与应用部署同步迁移/回滚的问题；
-
蓝绿部署需要有基础设施支持
-
在非隔离基础架构（VM、Docker等）上执行蓝绿部署，蓝色环境和绿色环境有被摧毁的风险。
蓝绿测试适合于任何的环境，无论是互联网应用还是企业应用。
灰度发布（金丝雀发布）
金丝雀发布（Canary）也是一种发布策略，和国内常说的灰度发布是同一类策略。
蓝绿部署是准备两套系统，在两套系统之间进行切换，金丝雀策略是只有一套系统，逐渐替换这套系统。
譬如说，目标系统是一组无状态的Web服务器，但是数量非常多，假设有一万台。
这时候，蓝绿部署就不能用了，因为你不可能申请一万台服务器专门用来部署蓝色系统（在蓝绿部署的定义中，蓝色的系统要能够承接所有访问）。
可以想到的一个方法是：
只准备几台服务器，在上面部署新版本的系统并测试验证。测试通过之后，担心出现意外，还不敢立即更新所有的服务器。
先将线上的一万台服务器中的10台更新为最新的系统，然后观察验证。确认没有异常之后，再将剩余的所有服务器更新。
这个方法就是金丝雀发布。
实际操作中还可以做更多控制，譬如说，给最初更新的10台服务器设置较低的权重、控制发送给这10台服务器的请求数，然后逐渐提高权重、增加请求数。
这个控制叫做“流量切分”，既可以用于金丝雀发布，也可以用于后面的A/B测试。
蓝绿部署和金丝雀发布是两种发布策略，都不是万能的。有时候两者都可以使用，有时候只能用其中一种。
上面的例子中可以用金丝雀，不能用蓝绿，那么什么时候可以用蓝绿，不能用金丝雀呢？整个系统只有一台服务器的时候。
参考：
https://www.v2ex.com/t/344341
https://www.jianshu.com/p/5862d7573bf2