DevOps研究院

文章背景：

滚动部署、蓝绿部署、灰度发布/金丝雀发布、A/B测试等名词在讲述“微服务”、“DevOps”，甚至更抽象的“Cloud-native”的交付时可能会有所涉及，学习这几个名词作为基础打底；

有几篇网络上浏览量较高的文章在这几者的所谓“对比说明”中，槽点太多，故而有了本文作为概念层面的纠正；

先明确一个概念，这些名词为两类：部署 VS 分布。

部署，针对环境而言；发布则是一种策略，需要在业务层面理解，包含如何发布、如何回滚、发布那些功能、哪些用户可以使用等等。

好了，先聊聊部署。

Blue/Green Deployment（蓝绿部署）：

从过去到现在，蓝绿部署模式因为安全、可靠的实用特征，在很多大企业中落了地。

步骤：

1. 准备蓝、绿两个相同环境，蓝色跑旧版。

2. 部署v1（蓝），此时v1成为外部请求流量的靶子。

3. 部署v2（绿），此时v2状态为“备用”（负载均衡的池里把这些地址去掉），待v2启动成功，则自动测试备用集群的部署情况。

4. v2（绿）状态改成存货，蓝绿连接相同数据库，进入了存活负载均衡池，随后v1（蓝）同样操作。最终v2代码完成部署。

5. 视情况进行数据库迁移。

看似步骤麻烦，理解了还好。蓝绿部署无需停机，风险相对较小。

不过蓝绿部署在考虑到两个环境的在线服务随版本切换的特征，版本一致性和数据的一致性保证非常重要。

另外，在非隔离基础架构（VM、Docker等）上蓝绿部署有一定毁灭性风险，不是高手要慎用。

滚动部署：

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

之所以小众，看缺点：

1. 没有一个环境确定ok，因为直接改了现有环境；

2. 既然没有环境确定ok，如果滚动发布到了第90个实例，需要回滚……程序猿可能会摔键盘；

3. 万一部署期间系统自动做了动态伸缩，不好判断哪个节点用了哪个代码。此时一款强大的自动化运维工具就派上用场了，but，有些运维部门没有呢；

灰度发布／金丝雀发布：

灰度发布指版本在黑白之间平滑过渡，最传神写意的就是金丝雀部署。

“金丝雀部署”，在业界有两种策略形式：

1. 一种是部分服务器升级到新的版本。这种形式的重点在于，接入网关要精确的匹配某个特征的用户（灰度）流量导入到这批新版本集群中；

2. 另外一种是所有服务器升级新的版本。这种形式的重点在于，接入网关要精确的匹配某个特征的用户（灰度）流量使用到新接口；

A/B Testing（AB测试）：

A/B测试和蓝绿部署是两码事，

A/B测试和蓝绿部署是两码事，

A/B测试和蓝绿部署是两码事，

重要的事情说三遍~

很多行业都有A/B测试的概念，A/B测试更像是用户侧的新旧版本机制，通过灰度一部分试验客户，使用A/B不同的效果，达到验证不同版本在可用性、受欢迎程度、可见性等等实际表现上的对比。

A/B测试是推广到全部流量可信新版前的科学验证方式，facebook改版就用过这个方式；蓝绿部署是直接发布到可信新版。

A/B测试和蓝绿部署可以同时使用，就像嵌套if，最后选定最受欢迎最靠谱的可信版本。

DevOps研究院

运维司机们，您看明白了吗？

想看更多内容，还请添加微信公众号（ID：MornNews，或搜索DevOps研究院）