蓝绿部署、红黑部署、AB测试、灰度发布、金丝雀发布、滚动发布的概念与区别
版权声明：本文为博主原创文章，未经博主容许不得转载。 https://blog.csdn.net/wangyinghong_2013/article/details/78650290
在有关微服务、DevOps、Cloud-native、系统部署等的讨论中，蓝绿部署、A/B 测试、灰度发布、滚动发布、红黑部署等概念常常被提到，它们有什么区别呢？经过搜索相关资料，作一个简单的辨析，以下：
1、蓝绿部署（Blue/Green Deployment）
过去的 10 年里，不少公司都在使用蓝绿部署（发布）来实现热部署，这种部署方式具备安全、可靠的特色。蓝绿部署虽然算不上“ Sliver Bullet”，但确实很实用。
过去的 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。
从过程不难发现，在部署的过程当中，应用始终在线。而且，新版本上线的过程当中，并无修改老版本的任何内容，在部署期间，老版本的状态不受影响。这样风险很小，而且，只要老版本的资源不被删除，理论上，能够在任什么时候间回滚到老版本。
这种方式的好处在你能够始终很放心的去部署inactive环境，若是出错并不影响生产环境的服务，若是切换后出现问题，也能够在很是短的时间内把再作一次切换，就完成了回滚。并且同时在线的只有一个版本。蓝绿部署无需停机，而且风险较小。
(1) 部署版本1的应用（一开始的状态），全部外部请求的流量都打到这个版本上。
(2) 部署版本2的应用，版本2的代码与版本1不一样(新功能、Bug修复等)。
(3) 将流量从版本1切换到版本2。
(4) 如版本2测试正常，就删除版本1正在使用的资源（例如实例），今后正式用版本2。
从过程不难发现，在部署的过程当中，应用始终在线。而且，新版本上线的过程当中，并无修改老版本的任何内容，在部署期间，老版本的状态不受影响。这样风险很小，而且，只要老版本的资源不被删除，理论上，能够在任什么时候间回滚到老版本。
蓝绿部署的弱点：
使用蓝绿部署须要注意的一些细节包括：
一、当切换到蓝色环境时，须要稳当处理未完成的业务和新的业务。若是数据库后端没法处理，会是一个比较麻烦的问题。
二、有可能会出现须要同时处理“微服务架构应用”和“传统架构应用”的状况，若是在蓝绿部署中协调很差这二者，仍是有可能致使服务中止；
三、须要提早考虑数据库与应用部署同步迁移/回滚的问题。
四、蓝绿部署须要有基础设施支持。
五、在非隔离基础架构（ VM 、 Docker 等）上执行蓝绿部署，蓝色环境和绿色环境有被摧毁的风险。
六、另外，这种方式很差的地方还在于冗余产生的额外维护、配置的成本，以及服务器自己运行的开销。
使用蓝绿部署须要注意的一些细节包括：
一、当切换到蓝色环境时，须要稳当处理未完成的业务和新的业务。若是数据库后端没法处理，会是一个比较麻烦的问题。
二、有可能会出现须要同时处理“微服务架构应用”和“传统架构应用”的状况，若是在蓝绿部署中协调很差这二者，仍是有可能致使服务中止；
三、须要提早考虑数据库与应用部署同步迁移/回滚的问题。
四、蓝绿部署须要有基础设施支持。
五、在非隔离基础架构（ VM 、 Docker 等）上执行蓝绿部署，蓝色环境和绿色环境有被摧毁的风险。
六、另外，这种方式很差的地方还在于冗余产生的额外维护、配置的成本，以及服务器自己运行的开销。
蓝绿部署适用的场景：
一、不中止老版本，额外搞一套新版本，等测试发现新版本OK后，删除老版本。
二、蓝绿发布是一种用于升级与更新的发布策略，部署的最小维度是容器，而发布的最小维度是应用。
三、蓝绿发布对于增量升级有比较好的支持，可是对于涉及数据表结构变动等等不可逆转的升级，并不彻底合适用蓝绿发布来实现，须要结合一些业务的逻辑以及数据迁移与回滚的策略才能够彻底知足需求。
一、不中止老版本，额外搞一套新版本，等测试发现新版本OK后，删除老版本。
二、蓝绿发布是一种用于升级与更新的发布策略，部署的最小维度是容器，而发布的最小维度是应用。
三、蓝绿发布对于增量升级有比较好的支持，可是对于涉及数据表结构变动等等不可逆转的升级，并不彻底合适用蓝绿发布来实现，须要结合一些业务的逻辑以及数据迁移与回滚的策略才能够彻底知足需求。
A/B 测试（A/B Testing）
A/B 测试跟蓝绿部署彻底是两码事。A/B 测试是用来测试应用功能表现的方法，例如可用性、受欢迎程度、可见性等等。 蓝绿部署的目的是安全稳定地发布新版本应用，并在必要时回滚。
A/B 测试与蓝绿部署的区别在于， A/B 测试目的在于经过科学的实验设计、采样样本表明性、流量分割与小流量测试等方式来得到具备表明性的实验结论，并确信该结论在推广到所有流量可信。
A/B 测试和蓝绿部署能够同时使用。
灰度发布／金丝雀发布
灰度发布是指在黑与白之间，可以平滑过渡的一种发布方式。灰度发布是增量发布的一种类型，灰度发布是在原有版本可用的状况下，同时部署一个新版本应用做为“金丝雀”（金丝雀对瓦斯极敏感，矿井工人携带金丝雀，以便及时发发现危险），测试新版本的性能和表现，以保障总体系统稳定的状况下，尽早发现、调整问题。
灰度发布／金丝雀发布由如下几个步骤组成：
一、准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。
二、从负载均衡列表中移除掉“金丝雀”服务器。
三、升级“金丝雀”应用（排掉原有流量并进行部署）。
四、对应用进行自动化测试。
五、将“金丝雀”服务器从新添加到负载均衡列表中（连通性和健康检查）。
六、若是“金丝雀”在线使用测试成功，升级剩余的其余服务器。（不然就回滚）
灰度发布能够保证总体系统的稳定，在初始灰度的时候就能够发现、调整问题，以保证其影响度。
灰度发布是指在黑与白之间，可以平滑过渡的一种发布方式。灰度发布是增量发布的一种类型，灰度发布是在原有版本可用的状况下，同时部署一个新版本应用做为“金丝雀”（金丝雀对瓦斯极敏感，矿井工人携带金丝雀，以便及时发发现危险），测试新版本的性能和表现，以保障总体系统稳定的状况下，尽早发现、调整问题。
灰度发布／金丝雀发布由如下几个步骤组成：
一、准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。
二、从负载均衡列表中移除掉“金丝雀”服务器。
三、升级“金丝雀”应用（排掉原有流量并进行部署）。
四、对应用进行自动化测试。
五、将“金丝雀”服务器从新添加到负载均衡列表中（连通性和健康检查）。
六、若是“金丝雀”在线使用测试成功，升级剩余的其余服务器。（不然就回滚）
灰度发布能够保证总体系统的稳定，在初始灰度的时候就能够发现、调整问题，以保证其影响度。
灰度发布/金丝雀部署适用的场景：
一、不中止老版本，额外搞一套新版本，不一样版本应用共存。
二、灰度发布中，经常按照用户设置路由权重，例如90%的用户维持使用老版本，10%的用户尝鲜新版本。
三、常常与A/B测试一块儿使用，用于测试选择多种方案。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，若是用户对B没有什么反对意见，那么逐步扩大范围，把全部用户都迁移到B上面来。
一、不中止老版本，额外搞一套新版本，不一样版本应用共存。
二、灰度发布中，经常按照用户设置路由权重，例如90%的用户维持使用老版本，10%的用户尝鲜新版本。
三、常常与A/B测试一块儿使用，用于测试选择多种方案。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，若是用户对B没有什么反对意见，那么逐步扩大范围，把全部用户都迁移到B上面来。
趣闻 ：
金丝雀部署（同理还有金丝雀测试），“金丝雀”的由来：17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会中止歌唱；而当瓦斯含量超过必定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀做为“瓦斯检测指标”，以便在危险情况下紧急撤离。
金丝雀部署（同理还有金丝雀测试），“金丝雀”的由来：17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会中止歌唱；而当瓦斯含量超过必定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀做为“瓦斯检测指标”，以便在危险情况下紧急撤离。
滚动发布（rolling update）
滚动发布，通常是取出一个或者多个服务器中止服务，执行更新，并从新将其投入使用。周而复始，直到集群中全部的实例都更新成新版本。这种部署方式相对于蓝绿部署，更加节约资源——它不须要运行两个集群、两倍的实例数。咱们能够部分部署，例如每次只取出集群的20%进行升级。
这种方式也有不少缺点，例如：
(1) 没有一个肯定OK的环境。使用蓝绿部署，咱们可以清晰地知道老版本是OK的，而使用滚动发布，咱们没法肯定。
(2) 修改了现有的环境。
(3) 若是须要回滚，很困难。举个例子，在某一次发布中，咱们须要更新100个实例，每次更新10个实例，每次部署须要5分钟。当滚动发布到第80个实例时，发现了问题，须要回滚。此时，脾气很差的程序猿极可能想掀桌子，由于回滚是一个痛苦，而且漫长的过程。
(4) 有的时候，咱们还可能对系统进行动态伸缩，若是部署期间，系统自动扩容/缩容了，咱们还需判断到底哪一个节点使用的是哪一个代码。尽管有一些自动化的运维工具，可是依然使人心惊胆战。
并非说滚动发布很差，滚动发布也有它很是合适的场景。
滚动发布，通常是取出一个或者多个服务器中止服务，执行更新，并从新将其投入使用。周而复始，直到集群中全部的实例都更新成新版本。这种部署方式相对于蓝绿部署，更加节约资源——它不须要运行两个集群、两倍的实例数。咱们能够部分部署，例如每次只取出集群的20%进行升级。
这种方式也有不少缺点，例如：
(1) 没有一个肯定OK的环境。使用蓝绿部署，咱们可以清晰地知道老版本是OK的，而使用滚动发布，咱们没法肯定。
(2) 修改了现有的环境。
(3) 若是须要回滚，很困难。举个例子，在某一次发布中，咱们须要更新100个实例，每次更新10个实例，每次部署须要5分钟。当滚动发布到第80个实例时，发现了问题，须要回滚。此时，脾气很差的程序猿极可能想掀桌子，由于回滚是一个痛苦，而且漫长的过程。
(4) 有的时候，咱们还可能对系统进行动态伸缩，若是部署期间，系统自动扩容/缩容了，咱们还需判断到底哪一个节点使用的是哪一个代码。尽管有一些自动化的运维工具，可是依然使人心惊胆战。
并非说滚动发布很差，滚动发布也有它很是合适的场景。
红黑部署(Red-Black Deployment)
这是Netflix采用的部署手段，Netflix的主要基础设施是在AWS上，因此它利用AWS的特性，在部署新的版本时，经过AutoScaling Group用包含新版本应用的AMI的LaunchConfiguration建立新的服务器。测试不经过，找到问题缘由后，直接干掉新生成的服务器以及Autoscaling Group就能够，测试经过，则将ELB指向新的服务器集群，而后销毁掉旧的服务器集群以及AutoScaling Group。 红黑部署的好处是服务始终在线，同时采用不可变部署的方式，也不像蓝绿部署同样得保持冗余的服务始终在线。