部署 - 蓝绿部署、AB测试、灰度发布
本节主要企业中常见的部署与发布策略。
参考资料
- 蓝绿部署、红黑部署、AB测试、灰度发布、金丝雀发布、滚动发布的概念与区别 (opens new window)
- 一文读懂蓝绿发布、A/B 测试和金丝雀发布的优缺点 (opens new window)
蓝绿部署（Blue/Green Deployment）
蓝绿部署是最常见的一种0 downtime部署的方式，是一种以可预测的方式发布应用的技术，目的是减少发布过程中服务停止的时间。
原理: 通过冗余来解决问题。通常生产环境需要两组配置（蓝绿配置），一组是active的生产环境的配置（绿配置），一组是inactive的配置（蓝绿配置）。
用户访问的时候，只会让用户访问active的服务器集群。
- 在绿色环境（active）运行当前生产环境中的应用，也就是旧版本应用version1。
- 当你想要升级到version2 ，在蓝色环境（inactive）中进行操作，即部署新版本应用，并进行测试。
- 如果测试没问题，就可以把 负载均衡器／反向代理／路由 指向蓝色环境了。
- 随后需要监测新版本应用，也就是version2 是否有故障和异常。
- 如果运行良好，就可以删除version1 使用的资源。
- 如果运行出现了问题，可以通过负载均衡器指向快速回滚到绿色环境。
升级和回滚
蓝绿部署升级:
蓝绿部署回滚:
优缺点
优点
- 蓝绿部署无需停机，并且风险较小。
- 新版本上线的过程中，并没有修改老版本的任何内容，如发生故障可以快速回滚。
- 服务升级过程操作简单，周期短。
弱点
- 当切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。
- 资源冗余，需要部署两套生产环境。产生的额外维护、配置的成本，以及服务器本身运行的开销。
- 需要提前考虑数据库与应用部署同步迁移/回滚的问题。
适用的场景
- 不停止老版本，额外搞一套新版本，等测试发现新版本OK后，删除老版本。
- 蓝绿发布是一种用于升级与更新的发布策略，部署的最小维度是容器，而发布的最小维度是应用。
- 蓝绿发布对于增量升级有比较好的支持，但是对于涉及数据表结构变更等等不可逆转的升级，并不完全合适用蓝绿发布来实现，需要结合一些业务的逻辑以及数据迁移与回滚的策略才可以完全满足需求。
红黑部署(Red-Black Deployment)
这是Netflix采用的部署手段，Netflix的主要基础设施是在AWS上，所以它利用AWS的特性，在部署新的版本时，通过AutoScaling Group用包含新版本应用的AMI的LaunchConfiguration创建新的服务器。测试不通过，找到问题原因后，直接干掉新生成的服务器以及Autoscaling Group就可以，测试通过，则将ELB指向新的服务器集群，然后销毁掉旧的服务器集群以及AutoScaling Group。
红黑部署的好处是服务始终在线，同时采用不可变部署的方式，也不像蓝绿部署一样得保持冗余的服务始终在线。
A/B 测试（A/B Testing）
相比于蓝绿发布的流量切换方式，A/B 测试基于用户请求的元信息将流量路由到新版本，这是一种基于请求内容匹配的灰度发布策略。
只有匹配特定规则的请求才会被引流到新版本，常见的做法包括基于 Http Header 和 Cookie。
- 基于 Http Header 方式的例子，例如 User-Agent 的值为 Android 的请求 （来自安卓系统的请求）可以访问新版本，其他系统仍然访问旧版本。
- 基于 Cookie 方式的例子，Cookie 中通常包含具有业务语义的用户信息，例如，普通用户可以访问新版本，VIP 用户仍然访问旧版本。
某服务当前版本为 v1，现在新版本 v2 要上线。希望安卓用户可以尝鲜新功能，其他系统用户保持不变。
通过在监控平台观察旧版本与新版本的成功率、RT 对比，当新版本整体服务预期后，即可将所有请求切换到新版本 v2，最后为了节省资源，可以逐步下线到旧版本 v1。
优点：
- 可以对特定的请求或者用户提供服务新版本，新版本故障影响范围小；
- 需要构建完备的监控平台，用于对比不同版本之间请求状态的差异。
缺点：
- 仍然存在资源冗余，因为无法准确评估请求容量；
- 发布周期长。
灰度发布/金丝雀发布
与前面两种方式的对比：
- 在蓝绿发布中，由于存在流量整体切换，所以需要按照原服务占用的机器规模为新版本克隆一套环境，相当于要求原来1倍的机器资源。
- 在 A/B 测试中，只要能够预估中匹配特定规则的请求规模，我们可以按需为新版本分配额外的机器资源。
灰度发布也叫金丝雀发布，相比于前两种发布策略，它的思想则是将少量的请求引流到新版本上，因此部署新版本服务只需极小数的机器。验证新版本符合预期后，逐步调整流量权重比例，使得流量慢慢从老版本迁移至新版本，期间可以根据设置的流量比例，对新版本服务进行扩容，同时对老版本服务进行缩容，使得底层资源得到最大化利用。
某服务当前版本为 v1，现在新版本 v2 要上线。为确保流量在服务升级过程中平稳无损，采用金丝雀发布方案，逐步将流量从老版本迁移至新版本。
优点：
- 按比例将流量无差别地导向新版本，新版本故障影响范围小；
- 发布期间逐步对新版本扩容，同时对老版本缩容，资源利用率高。
缺点：
- 流量无差别地导向新版本，可能会影响重要用户的体验；
- 发布周期长。
**趣闻 **：
金丝雀部署（同理还有金丝雀测试），“金丝雀”的由来：17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离。
滚动发布（rolling update）
滚动发布，一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。
优点：
- 相对于蓝绿部署，更加节约资源——它不需要运行两个集群、两倍的实例数。可以部分部署，例如每次只取出集群的20%进行升级。
缺点：
- 没有一个确定OK的环境。使用蓝绿部署，我们能够清晰地知道老版本是OK的，而使用滚动发布，我们无法确定。
- 修改了现有的环境。如果需要回滚，很困难。
- 可能对系统进行动态伸缩，如果部署期间，系统自动扩容/缩容了，需要判断到底哪个节点使用的是哪个代码。
并不是说滚动发布不好，滚动发布也有它非常合适的场景。