灰度发布、蓝绿发布、滚动发布

背景

线上的项目最容易出现问题的时候就是发布的过程中。如果将某变化较大的版本一次全部线上发布给用户，遇到生产事故对用户的影响会非常大，甚至有时需要紧急回滚到前一版本。因此在发布的时候可以采取一些措施来防止问题的扩散。
常见的发布方案有：蓝绿发布、滚动发布、灰度发布

• 蓝绿发布

蓝绿部署，是指同时运行两个版本的应用。

在蓝绿部署时，蓝绿部署的时候，并不停止掉老版本，而是直接部署一套新版本，等新版本运行起来后，再将流量切换到新版本上。
例如发布前，在蓝色的系统上进行测试，测试完成后切换为蓝色系统，同时观察蓝色系统的运行状态，如果运行出现问题可以及时切回绿色系统。

优点
这样做可以减少发布影响的时间。例如某网站要进行后端升级，无需完全停掉服务更新，且出现问题后可以及时切回老版本。
缺点
需要两倍的硬件资源，需要额外进行付费；微服务架构很难这样进行迁移；要求蓝绿两套系统完全没有耦合；迁移后未完成的任务进行迁移需要一定的成本，如数据库的迁移。

• 滚动发布

一般是取出部分服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。

如上图所示，先取出一部分的机器，执行更新逻辑；更新完成后，让流量流向此更新完成的机器。

优点：不需要准备两套完整的机器，节约资源
缺点：回滚困难，流量直接到新的机器上，出现问题后，无法实现快速回滚；更新时间长，带来额外的风险，如果80%完成更新后发生重大漏洞，回滚会比较耗时和困难。

• 灰度发布

灰度发布，又名金丝雀发布，是指在黑与白之间能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继灰度发布是对某一产品的发布逐步扩大使用群体范围，也叫灰度放量。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离。

在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来。测试成功后，将少量的用户流量导入到新版本上，然后再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比。当确认新版本运行良好后，再逐步将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。

常见名词
灰度期：灰度发布开始到结束期间的这一段时间，称为灰度期。续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。
流量切分：例如具体在部署的服务器上，给最初更新的10台服务器设置较低的权重、控制发送给这10台服务器的请求数，然后逐渐提高权重、增加请求数。这个过程叫流量切分。

灰度策略
常见的灰度策略有：

按照比例划分
可以搭配负载均衡使用，如5%的用户首先使用新的版本，95%的仍然使用老版本。
按照用户属性划分
如限制IP、地域、性别、年龄或者浏览时间、客户等级等等用户画像，例如活跃度高的用户优先使用新版本
按照渠道划分
如内部客户优先使用新版本，大客户要保证服务稳定，使用旧版本
可以根据自己的业务情况以及变更情况修改自己的灰度策略。例如，某产品UI发生了变化，可以根据比例进行流量切分；某产品上线了新的接口，可以按照用户属性，优先内部客户和中小客户使用新版本。

但是，为了找到符合业务逻辑和需求的灰度发布，是需要开发人员进行额外的开发工作的，尤其项目如果同时涉及前端和后端，需要两边都要进行灰度发布的支持。