随着微服务架构的普及，线上服务越来越多，随之而来的就是部署越来越频繁；随着互联网行业的兴旺，产品迭代的频率也是越来越快，服务上线速度逐步提升。有上线、有部署，就有风险。有风险，就对业务有影响，然后就有了一系列减少这种风险的部署方案：蓝绿部署、金丝雀发布（灰度发布），也有适应产品迭代频率的AB测试。

本文主要是简单解释下这几个概念，帮助自己理解，如果有错误，请大佬们斧正。

蓝绿部署

蓝绿色部署是一种通过运行两个相同的称为 BLUE 和 GREEN 的生产环境来减少停机时间和降低风险的技术。

蓝绿部署，以颜色命名，简单的理解就是，线上有两套集群环境，在架构图中，一套标记成蓝色，称为蓝色集群BLUE；一套标记为绿色，称为绿色集群GREEN。通过将流量引入两个集群，完成系统升级切换。

blue_green_deployments.png

步骤一：部署绿色集群，这个时候是初始状态，蓝色集群承担全部责任，接收全部流量，等待被替换。绿色集群刚刚部署，还没有投入使用，流量为0，等待验证和上线。

步骤二：蓝色集群流量不变，向绿色集群引入流量。这个过程可以分成几个阶段完成。第一个阶段，引入少量非实时流量，仅用于数据测试；第二个阶段，引入全部实时流量，用于做系统验证。

步骤三：切断向蓝色集群引入流量，将全部流量引入绿色集群。这个时候，绿色集群已经承担全部责任，接收全部流量。这个过程也可以分阶段操作。第一个阶段，平衡蓝色和绿色集群流量，也就是蓝色和绿色集群一同承担职责；第二个阶段，切断蓝色集群流量，流量全部写入绿色集群。是否采用分阶段操作，完全看升级的功能是否是破坏性的，是否可兼容。

步骤四：监控系统运行，这个过程是必要的。因为没有人能够保证测试时100%的覆盖的，所以新集群可能会出现这样那样、或大或小的问题，如果评估需要回滚，就需要将全部流量切换到蓝色集群。也完成了版本回滚。

金丝雀发布（灰度发布）

金丝雀发布，与蓝绿部署不同的是，它不是非黑即白的部署方式，所以又称为灰度发布。它能够缓慢的将修改推广到一小部分用户，验证没有问题后，再推广到全部用户，以降低生产环境引入新功能带来的风险。

canarydeployment.png

步骤一：将流量从待部署节点移出，更新该节点服务到待发布状态，将该节点称为金丝雀节点；

步骤二：根据不同策略，将流量引入金丝雀节点。策略可以根据情况指定，比如随机样本策略（随机引入）、狗粮策略（就是内部用户或员工先尝鲜）、分区策略（不同区域用户使用不同版本）、用户特征策略（这种比较复杂，需要根据用户个人资料和特征进行分流，类似于千人千面）；

步骤三：金丝雀节点验证通过后，选取更多的节点称为金丝雀节点，重复步骤一和步骤二，直到所有节点全部更新

AB测试

AB测试和上面两种发布方式不是一个范围的概念，它是为了进行效果验证的手段，其他两种是为了实现线上平稳发布的手段，这里把他们放在一起说，是因为这三个概念很容易弄混。

AB测试是线上同时运行多个不同版本的服务，这些服务更多的是用户侧的体验不同，比如页面布局、按钮颜色，交互方式等，通常底层业务逻辑还是一样的，也就是通常说的换汤不换药。

abtesting.png

这个没有具体的步骤（也可以采用金丝雀部署的步骤，只不过不是全量更新），根据策略（这个策略可以是金丝雀分布中的策略一致），将一部分流量引入A版本，另外一部分流量引入B版本，也可能出现CDEF版本。然后相关人员通过分析不同版本的实际效果，选出最优解。最优解可能是一个版本获胜，取代另一个版本，也可能是催生出更多的版本，服务于用户，还有可能是多个版本在不同区域同时提供服务。

最后

这里总结一下：

AB测试和上面两个不是一个范畴，不做比较。但是需要说明的一点，AB测试可以采用上面两种部署方式的手法。

参考：Using Blue-Green Deployment to Reduce Downtime and Risk

Blue Green Deployment

Blue-green Deployments, A/B Testing, and Canary Releases

Canary Release