部署 - 蓝绿部署、AB测试、灰度发布

本节主要企业中常见的部署与发布策略。

参考资料

蓝绿部署（Blue/Green Deployment）

蓝绿部署是最常见的一种0 downtime部署的方式，是一种以

原理: 通过冗余来解决问题。通常生产环境需要两组配置（蓝绿配置），一组是active的生产环境的配置（绿配置），一组是inactive的配置（蓝绿配置）。

用户访问的时候，只会让用户访问active的服务器集群。

  1. 在绿色环境（active）运行当前生产环境中的应用，也就是旧版本应用version1。
  2. 当你想要升级到version2 ，在蓝色环境（inactive）中进行操作，即部署新版本应用，并进行测试。
  3. 如果测试没问题，就可以把 指向蓝色环境了。
  4. 随后需要监测新版本应用，也就是version2 是否有故障和异常。
  5. 如果运行良好，就可以删除version1 使用的资源。
  6. 如果运行出现了问题，可以通过负载均衡器指向快速回滚到绿色环境。

升级和回滚

蓝绿部署升级:

蓝绿部署升级

蓝绿部署回滚:

蓝绿部署回滚

优缺点

优点

  • 蓝绿部署无需停机，并且风险较小。
  • 新版本上线的过程中，并没有修改老版本的任何内容，如发生故障可以快速回滚。
  • 服务升级过程操作简单，周期短。

弱点

  • 当切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。
  • 资源冗余，需要部署两套生产环境。产生的额外维护、配置的成本，以及服务器本身运行的开销。
  • 需要提前考虑数据库与应用部署。

适用的场景

  • 不停止老版本，额外搞一套新版本，等测试发现新版本OK后，删除老版本。
  • 蓝绿发布是一种用于升级与更新的发布策略，部署的最小维度是容器，而发布的最小维度是应用。
  • 蓝绿发布对于增量升级有比较好的支持，但是对于。

红黑部署(Red-Black Deployment)

这是Netflix采用的部署手段，Netflix的主要基础设施是在AWS上，所以它利用AWS的特性，在部署新的版本时，通过AutoScaling Group用包含新版本应用的AMI的LaunchConfiguration创建新的服务器。测试不通过，找到问题原因后，直接干掉新生成的服务器以及Autoscaling Group就可以，测试通过，则将ELB指向新的服务器集群，然后销毁掉旧的服务器集群以及AutoScaling Group。

红黑部署的好处是服务始终在线，同时采用不可变部署的方式，也不像蓝绿部署一样得保持冗余的服务始终在线。

A/B 测试（A/B Testing）

相比于蓝绿发布的流量切换方式，。

只有匹配特定规则的请求才会被引流到新版本，常见的做法包括基于 Http Header 和 Cookie。

  • 基于 Http Header 方式的例子，例如 User-Agent 的值为 Android 的请求 （来自安卓系统的请求）可以访问新版本，其他系统仍然访问旧版本。
  • 基于 Cookie 方式的例子，Cookie 中通常包含具有业务语义的用户信息，例如，普通用户可以访问新版本，VIP 用户仍然访问旧版本。

某服务当前版本为 v1，现在新版本 v2 要上线。希望安卓用户可以尝鲜新功能，其他系统用户保持不变。

AB测试Android

通过在监控平台观察旧版本与新版本的成功率、RT 对比，当新版本整体服务预期后，即可将所有请求切换到新版本 v2，最后为了节省资源，可以逐步下线到旧版本 v1。

AB测试老服务下线

优点：

  1. 可以对特定的请求或者用户提供服务新版本，新版本故障影响范围小；
  2. 需要构建完备的监控平台，用于对比不同版本之间请求状态的差异。

缺点：

  1. 仍然存在资源冗余，因为无法准确评估请求容量；
  2. 发布周期长。

灰度发布/金丝雀发布

与前面两种方式的对比：

  • 在蓝绿发布中，由于存在流量整体切换，所以需要按照原服务占用的机器规模为新版本克隆一套环境，相当于要求原来1倍的机器资源。
  • 在 A/B 测试中，只要能够预估中匹配特定规则的请求规模，我们可以按需为新版本分配额外的机器资源。

灰度发布也叫金丝雀发布，相比于前两种发布策略，验证新版本符合预期后，逐步调整流量权重比例，使得流量慢慢从老版本迁移至新版本，期间可以根据设置的流量比例，

某服务当前版本为 v1，现在新版本 v2 要上线。为确保流量在服务升级过程中平稳无损，采用金丝雀发布方案，逐步将流量从老版本迁移至新版本。

金丝雀发布过程

优点：

  1. 按比例将流量无差别地导向新版本，新版本故障影响范围小；
  2. 发布期间逐步对新版本扩容，同时对老版本缩容，资源利用率高。

缺点：

  1. 流量无差别地导向新版本，可能会影响重要用户的体验；
  2. 发布周期长。

**趣闻 **：

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

滚动发布（rolling update）

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

滚动发布

优点：

  • 相对于蓝绿部署，更加节约资源——它不需要运行两个集群、两倍的实例数。可以部分部署，例如每次只取出集群的20%进行升级。

缺点：

  • 没有一个确定OK的环境。使用蓝绿部署，我们能够清晰地知道老版本是OK的，而使用滚动发布，我们无法确定。
  • 修改了现有的环境。如果需要回滚，很困难。
  • 可能对系统进行动态伸缩，如果部署期间，系统自动扩容/缩容了，需要判断到底哪个节点使用的是哪个代码。

并不是说滚动发布不好，滚动发布也有它非常合适的场景。

Last Updated:
Contributors: klc407073648