发布策略

在有关微服务、DevOps、Cloud-native的迭代过程中，不可避免的需要“上线”，上线就需要部署，需要部署就意味着有修改，修改则意味着有风险。发布这事儿，也越来越频繁，策略也越来越丝滑、无损，这里聊几个常见的。

目前有很多部署模式，本文的目的是对部署方案的总结。

包括如下：

• 停机发布
• 蓝绿发布
• 灰度发布
• 滚动发布
• A/B Test 发布

一、停机发布

停机发布是一种很古老的发布策略，说白了就是“夜深人静时，停机发布日”。新老迭代，升级发布，要先切断服务，停止旧程序，一顿操作猛如虎，然后再放开外部访问。

停机发布也叫Recreate，也不用觉得太low，现在挺多场景都在用，比如部分游戏发布、企业内部管理系统发布。一方面是因为有些场景没必要做那么高级，还有一方面原因是很多时候，这种最安全，只是迭代速度慢，影响范围大。

二、蓝绿发布

定义蓝绿部署是不停老版本，部署新版本，然后进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本。

第一步:初始化状态，流量全部打到版本1中。

第二步:发布版本2（发布的代码包含新功能和Bug修复等）

第三步:将流量从版本1切换到版本2。

第四步：等到版本2测试正常，则删除版本1正在使用的资源（例如实例，数据库），从此正式用版本2。

4、蓝绿发布的注意事项

• 当切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。如果你的数据库后端无法处理，会是一个比较麻烦的问题；
• 蓝绿部署在蓝绿阶段，需要平时服务器的数量的两倍，所有，如果基础设施层有更好的支持就更好了。
• 如果应用之间有MQ，需要在业务架构层面做好兼容。
• 蓝绿发布对于增量升级有比较好的支持，但是对于涉及数据表结构变更等等不可逆转的升级，并不完全合适用蓝绿发布来实现，需要结合一些业务的逻辑以及数据迁移与回滚的策略才可以完全满足需求。

过去的 10 年里，很多公司都在使用蓝绿部署（发布）来实现热部署，这种部署方式具有安全、可靠的特点。蓝绿部署虽然算不上“ Sliver Bullet”，但确实很实用。

不过蓝绿发布在大型的微服务系统已经很难在用了，主要是考虑到服务器成本，以及如果本次改动涉及到的中间件过多，数据迁移和回滚都很麻烦。如果丹丹做应用层面的蓝绿，写代码就需要考虑各种向前和向后的兼容。

BlueGreenDeployment中给出的一张图特别形象：

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

A/B测试跟蓝绿部署完全是两码事。A/B测试是用来测试应用功能表现的方法，例如可用性、受欢迎程度、可见性等等。A/B测试通常用在应用的前端上，不过当然需要后端来支持。

A/B测试与蓝绿部署的区别在于，A/B测试目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论，并确信该结论在推广到全部流量可信；蓝绿部署的目的是安全稳定地发布新版本应用，并在必要时回滚。

A/B测试和蓝绿部署可以同时使用。

四、灰度发布

定义：灰度发布是一种增量发布的类型，在原有版本可用的i情况下，采用一种平滑过渡的方式发布。例如：现在有一个应用有100台服务器，我们用一台将某一台的服务器更新到最新版本作为“金丝雀”，然后通过服务路由的方式，将流量切到“金丝雀”的服务中，最后让测试人员测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现、调整问题。

如果测试没有问题，就一只只发布“金丝雀”，直到这100台的服务器都更新成最新版本。

金丝雀发布的来历：

注释：矿井中的金丝雀

17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离。

灰度发布／金丝雀发布由以下几个步骤组成：
1、准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。
2、从负载均衡列表中移除掉“金丝雀”服务器。
3、升级“金丝雀”应用（排掉原有流量并进行部署）。
4、对应用进行自动化测试。
5、将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。
6、如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）
灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

灰度发布/金丝雀部署适用的场景：
1、不停止老版本，额外搞一套新版本，不同版本应用共存。
2、灰度发布中，常常按照用户设置路由权重，例如90%的用户维持使用老版本，10%的用户尝鲜新版本。
3、经常与A/B测试一起使用，用于测试选择多种方案。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。

五、滚动发布

滚动发布，一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。这种部署方式相对于蓝绿部署，更加节约资源——它不需要运行两个集群、两倍的实例数。我们可以部分部署，例如每次只取出集群的20%进行升级。

这种方式也有很多缺点，例如：
(1) 没有一个确定OK的环境。使用蓝绿部署，我们能够清晰地知道老版本是OK的，而使用滚动发布，我们无法确定。
(2) 修改了现有的环境。
(3) 如果需要回滚，很困难。举个例子，在某一次发布中，我们需要更新100个实例，每次更新10个实例，每次部署需要5分钟。当滚动发布到第80个实例时，发现了问题，需要回滚。此时，脾气不好的程序猿很可能想掀桌子，因为回滚是一个痛苦，并且漫长的过程。
(4) 有的时候，我们还可能对系统进行动态伸缩，如果部署期间，系统自动扩容/缩容了，我们还需判断到底哪个节点使用的是哪个代码。尽管有一些自动化的运维工具，但是依然令人心惊胆战。
并不是说滚动发布不好，滚动发布也有它非常合适的场景。

闲言总结

在实际的开发实践中，国内一般叫“灰度发布”。这种所谓的灰度，跟上述的金丝雀和滚动发布都不完全一样，我理解是两种理念的结合。就是每次按滚动发布里的操作一样，对现网某台服务器进行升级，然后慢慢放正式流量，验证OK，逐一扩大。

当然，在某些组织的工作中，其实在自动化方面，是有可改进空间的。比如灰度某现网服务器时，可以在升级前，自动调整负载均衡，把比重调为0，然后自动慢慢放大到100%，再根据成功率逐一灰度其它节点。