文章背景 滚动部署、蓝绿部署、灰度发布/金丝雀发布、A/B测试等名词在讲述“微服务”、“DevOps”，甚至更抽象的“Cloud-native”的交付时可能会有所涉及，学习这几个名词作为基
文章背景
.-
滚动部署、蓝绿部署、灰度发布/金丝雀发布、A/B测试等名词在讲述“微服务”、“DevOps”，甚至更抽象的“Cloud-native”的交付时可能会有所涉及，学习这几个名词作为基础打底；
-
有几篇网络上浏览量较高的文章在这几者的所谓“对比说明”中，槽点太多，故而有了本文作为概念层面的纠正；
先明确一个概念，这些名词为两类：部署 VS 分布。
部署，针对环境而言；发布则是一种策略，需要在业务层面理解，包含如何发布、如何回滚、发布那些功能、哪些用户可以使用等等。
好了，先聊聊部署。
Blue/Green Deployment（蓝绿部署）
从过去到现在，蓝绿部署模式因为安全、可靠的实用特征，在很多大企业中落了地。
步骤：
.-
准备蓝、绿两个相同环境，蓝色跑旧版。
-
部署v1（蓝），此时v1成为外部请求流量的靶子。
-
部署v2（绿），此时v2状态为“备用”（负载均衡的池里把这些地址去掉），待v2启动成功，则自动测试备用集群的部署情况。
-
v2（绿）状态改成存货，蓝绿连接相同数据库，进入了存活负载均衡池，随后v1（蓝）同样操作。最终v2代码完成部署。
-
视情况进行数据库迁移。
看似步骤麻烦，理解了还好。蓝绿部署无需停机，风险相对较小。
不过蓝绿部署在考虑到两个环境的在线服务随版本切换的特征，版本一致性和数据的一致性保证非常重要。
另外，在非隔离基础架构（VM、Docker等）上蓝绿部署有一定毁灭性风险，不是高手要慎用。
滚动部署
滚动发布，相对小众的市场，一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。
之所以小众，看缺点：
.-
没有一个环境确定ok，因为直接改了现有环境；
-
既然没有环境确定ok，如果滚动发布到了第90个实例，需要回滚……程序猿可能会摔键盘；
-
万一部署期间系统自动做了动态伸缩，不好判断哪个节点用了哪个代码。此时一款强大的自动化运维工具就派上用场了，but，有些运维部门没有呢；
灰度发布／金丝雀发布
灰度发布指版本在黑白之间平滑过渡，最传神写意的就是金丝雀部署。
“金丝雀部署”，在业界有两种策略形式：
.-
一种是部分服务器升级到新的版本。这种形式的重点在于，接入网关要精确的匹配某个特征的用户（灰度）流量导入到这批新版本集群中；
-
另外一种是所有服务器升级新的版本。这种形式的重点在于，接入网关要精确的匹配某个特征的用户（灰度）流量使用到新接口；
A/B Testing（AB测试）
A/B测试和蓝绿部署是两码事，
A/B测试和蓝绿部署是两码事，
A/B测试和蓝绿部署是两码事，
重要的事情说三遍~
很多行业都有A/B测试的概念，A/B测试更像是用户侧的新旧版本机制，通过灰度一部分试验客户，使用A/B不同的效果，达到验证不同版本在可用性、受欢迎程度、可见性等等实际表现上的对比。
A/B测试是推广到全部流量可信新版前的科学验证方式，facebook改版就用过这个方式；蓝绿部署是直接发布到可信新版。
A/B测试和蓝绿部署可以同时使用，可以到最后选定最受欢迎最靠谱的可信版本。
