蓝绿部署、AB测试、灰度发布、⾦丝雀发布、滚 动发布的概念与区别

⼀、蓝绿部署（Blue/Green Deployment）

过去的 10 年⾥，很多公司都在使⽤蓝绿部署（发布）来实现热部署，这种部署⽅式具有安全、可靠的特点。蓝绿部署虽然算不上“ Sliver
Bullet”，但确实很实⽤。
蓝绿部署是最常见的⼀种0 downtime部署的⽅式，是⼀种以可预测的⽅式发布应⽤的技术，⽬的是减少发布过程中服务停⽌的时间。蓝绿
部署原理上很简单，就是通过冗余来解决问题。通常⽣产环境需要两组配置（蓝绿配置），⼀组是active的⽣产环境的配置（绿配置），⼀
组是inactive的配置（蓝绿配置）。⽤户访问的时候，只会让⽤户访问active的服务器集群。在绿⾊环境（active）运⾏当前⽣产环境中的
应⽤，也就是旧版本应⽤version1。当你想要升级到version2 ，在蓝⾊环境（inactive）中进⾏操作，即部署新版本应⽤，并进⾏测试。
如果测试没问题，就可以把负载均衡器／反向代理／路由指向蓝⾊环境了。随后需要监测新版本应⽤，也就是version2 是否有故障和异
常。如果运⾏良好，就可以删除version1 使⽤的资源。如果运⾏出现了问题，可以通过负载均衡器指向快速回滚到绿⾊环境。
蓝绿部署的优点：
这种⽅式的好处在你可以始终很放⼼的去部署inactive环境，如果出错并不影响⽣产环境的服务，如果切换后出现问题，也可以在⾮常短的
时间内把再做⼀次切换，就完成了回滚。⽽且同时在线的只有⼀个版本。蓝绿部署⽆需停机，并且风险较⼩。
(1) 部署版本1的应⽤（⼀开始的状态），所有外部请求的流量都打到这个版本上。
(2) 部署版本2的应⽤，版本2的代码与版本1不同(新功能、Bug修复等)。
(3) 将流量从版本1切换到版本2。
(4) 如版本2测试正常，就删除版本1正在使⽤的资源（例如实例），从此正式⽤版本2。
从过程不难发现，在部署的过程中，应⽤始终在线。并且，新版本上线的过程中，并没有修改⽼版本的任何内容，在部署期间，⽼版本的状
态不受影响。这样风险很⼩，并且，只要⽼版本的资源不被删除，理论上，可以在任何时间回滚到⽼版本。
蓝绿部署的弱点：
使⽤蓝绿部署需要注意的⼀些细节包括：
1、当切换到蓝⾊环境时，需要妥当处理未完成的业务和新的业务。如果数据库后端⽆法处理，会是⼀个⽐较⿇烦的问题。
2、有可能会出现需要同时处理“微服务架构应⽤”和“传统架构应⽤”的情况，如果在蓝绿部署中协调不好这两者，还是有可能导致服务
停⽌；
3、需要提前考虑数据库与应⽤部署同步迁移/回滚的问题。
4、蓝绿部署需要有基础设施⽀持。
5、在⾮隔离基础架构（ VM 、 Docker 等）上执⾏蓝绿部署，蓝⾊环境和绿⾊环境有被摧毁的风险。
6、另外，这种⽅式不好的地⽅还在于冗余产⽣的额外维护、配置的成本，以及服务器本⾝运⾏的开销。
蓝绿部署适⽤的场景：
1、不停⽌⽼版本，额外搞⼀套新版本，等测试发现新版本OK后，删除⽼版本。
2、蓝绿发布是⼀种⽤于升级与更新的发布策略，部署的最⼩维度是容器，⽽发布的最⼩维度是应⽤。
3、蓝绿发布对于增量升级有⽐较好的⽀持，但是对于涉及数据表结构变更等等不可逆转的升级，并不完全合适⽤蓝绿发布来实现，需要结
合⼀些业务的逻辑以及数据迁移与回滚的策略才可以完全满⾜需求。

二、A/B 测试（A/B Testing）

A/B 测试跟蓝绿部署完全是两码事。A/B 测试是⽤来测试应⽤功能表现的⽅法，例如可⽤性、受欢迎程度、可见性等等。 蓝绿部署的⽬的
是安全稳定地发布新版本应⽤，并在必要时回滚。
A/B 测试与蓝绿部署的区别在于， A/B 测试⽬的在于通过科学的实验设计、采样样本代表性、流量分割与⼩流量测试等⽅式来获得具有代
表性的实验结论，并确信该结论在推⼴到全部流量可信。
A/B 测试和蓝绿部署可以同时使⽤。

三、灰度发布／⾦丝雀发布

灰度发布／⾦丝雀发布
灰度发布是指在⿊与⽩之间，能够平滑过渡的⼀种发布⽅式。灰度发布是增量发布的⼀种类型，灰度发布是在原有版本可⽤的情况下，同时
部署⼀个新版本应⽤作为“⾦丝雀”（⾦丝雀对⽡斯极敏感，矿井⼯⼈携带⾦丝雀，以便及时发发现危险），测试新版本的性能和表现，以
保障整体系统稳定的情况下，尽早发现、调整问题。
灰度发布／⾦丝雀发布由以下⼏个步骤组成：
1、准备好部署各个阶段的⼯件，包括：构建⼯件，测试脚本，配置⽂件和部署清单⽂件。
2、从负载均衡列表中移除掉“⾦丝雀”服务器。
3、升级“⾦丝雀”应⽤（排掉原有流量并进⾏部署）。
4、对应⽤进⾏⾃动化测试。
5、将“⾦丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。
6、如果“⾦丝雀”在线使⽤测试成功，升级剩余的其他服务器。（否则就回滚）
灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
灰度发布/⾦丝雀部署适⽤的场景：
1、不停⽌⽼版本，额外搞⼀套新版本，不同版本应⽤共存。
2、灰度发布中，常常按照⽤户设置路由权重，例如90%的⽤户维持使⽤⽼版本，10%的⽤户尝鲜新版本。
3、经常与A/B测试⼀起使⽤，⽤于测试选择多种⽅案。AB test就是⼀种灰度发布⽅式，让⼀部分⽤户继续⽤A，⼀部分⽤户开始⽤B，如
果⽤户对B没有什么反对意见，那么逐步扩⼤范围，把所有⽤户都迁移到B上⾯来。
趣闻 ：
⾦丝雀部署（同理还有⾦丝雀测试），“⾦丝雀”的由来：17世纪，英国矿井⼯⼈发现，⾦丝雀对⽡斯这种⽓体⼗分敏感。空⽓中哪怕有
极其微量的⽡斯，⾦丝雀也会停⽌歌唱；⽽当⽡斯含量超过⼀定限度时，虽然鲁钝的⼈类毫⽆察觉，⾦丝雀却早已毒发⾝亡。当时在采矿设
备相对简陋的条件下，⼯⼈们每次下井都会带上⼀只⾦丝雀作为“⽡斯检测指标”，以便在危险状况下紧急撤离。
滚动发布（rolling update）
滚动发布，⼀般是取出⼀个或者多个服务器停⽌服务，执⾏更新，并重新将其投⼊使⽤。周⽽复始，直到集群中所有的实例都更新成新版
本。这种部署⽅式相对于蓝绿部署，更加节约资源——它不需要运⾏两个集群、两倍的实例数。我们可以部分部署，例如每次只取出集群的
20%进⾏升级。
这种⽅式也有很多缺点，例如：
(1) 没有⼀个确定OK的环境。使⽤蓝绿部署，我们能够清晰地知道⽼版本是OK的，⽽使⽤滚动发布，我们⽆法确定。
(2) 修改了现有的环境。
(3) 如果需要回滚，很困难。举个例⼦，在某⼀次发布中，我们需要更新100个实例，每次更新10个实例，每次部署需要5分钟。当滚动发
布到第80个实例时，发现了问题，需要回滚。此时，脾⽓不好的程序猿很可能想掀桌⼦，因为回滚是⼀个痛苦，并且漫长的过程。
(4) 有的时候，我们还可能对系统进⾏动态伸缩，如果部署期间，系统⾃动扩容/缩容了，我们还需判断到底哪个节点使⽤的是哪个代码。尽
管有⼀些⾃动化的运维⼯具，但是依然令⼈⼼惊胆战。
并不是说滚动发布不好，滚动发布也有它⾮常合适的场景。