跳转至

10.2 工业界几种发布模式介绍

蓝绿发布

  • 所谓蓝绿发布(Blue/Green Deployment), 本质上是通过系统冗余来解决上线风险问题. 通常生产环境中配置两套完全一样的环境, 一组是active的生产环境配置(绿色), 一组是inactivate的准备环境配置(蓝色), 两套系统都是功能完善的, 并且正在运行的系统, 只是系统版本和对外服务情况不同.

  • 最初始状态下, 没有任何系统, 也就没有蓝绿之分. 然后第一套系统开发完成, 直接上线, 这个过程只有一个系统, 也没有蓝绿之分. 再后来, 业务更新, 开发了新版本, 要用新版本替换线上的旧版本, 在线上的系统之外, 搭建了一个使用新版本代码的全新系统. 这个时候一共有两套系统在运行, 正在对外提供服务的老系统是绿色系统, 新部署的系统是蓝色系统.

  • 为什么会有蓝色系统的存在? 因为在蓝色环境(inactive)中进行操作(即部署新版本应用)是为了对新版本进行全方位的测试.
    • 如果测试没问题, 就可以把负载均衡器/反向代理/路由指向蓝色环境了, 随后需要监测新版本应用, 也就是v2.0是否有故障和异常. 如果运行良好, 就可以删除v1.0使用的资源, 为下一次蓝绿部署空出可用资源.
    • 如果测试有问题, 可以通过修改负载均衡器的指向, 快速回滚到绿色环境, 即v1.0版本.

  • 蓝绿部署的优点: 这种方式的好处在你可以始终很放心的去部署inactive环境，如果出错并不影响生产环境的服务，如果切换后出现问题，也可以在非常短的时间内把再做一次切换，就完成了回滚。而且同时在线的只有一个版本。蓝绿部署无需停机，并且风险较小.
    • 1: 部署版本1的应用（一开始的状态），所有外部请求的流量都打到这个版本上.
    • 2: 部署版本2的应用，版本2的代码与版本1不同(新功能、Bug修复等)
    • 3: 将流量从版本1切换到版本2
    • 4: 如版本2测试正常，就删除版本1正在使用的资源（例如实例），从此正式用版本2
  • 优点总结: 在部署的过程中，应用始终在线。并且，新版本上线的过程中，并没有修改老版本的任何内容，在部署期间，老版本的状态不受影响。这样风险很小，并且，只要老版本的资源不被删除，理论上，可以在任何时间回滚到老版本。
  • 蓝绿部署的缺点:
    • 1: 当切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。如果数据库后端无法处理，会是一个比较麻烦的问题.
    • 2: 有可能会出现需要同时处理“微服务架构应用”和“传统架构应用”的情况，如果在蓝绿部署中协调不好这两者，还是有可能导致服务停止
    • 3: 需要提前考虑数据库与应用部署同步迁移/回滚的问题
    • 4: 蓝绿部署需要有基础设施支持
    • 5: 在非隔离基础架构（ VM 、 Docker 等）上执行蓝绿部署，蓝色环境和绿色环境有被摧毁的风险
    • 6: 这种方式不好的地方还在于冗余产生的额外维护、配置的成本，以及服务器本身运行的开销。 蓝绿部署适用的场景
  • 蓝绿部署适用的场景:
    • 1: 不停止老版本，额外搞一套新版本，等测试发现新版本OK后，删除老版本
    • 2: 蓝绿发布是一种用于升级与更新的发布策略，部署的最小维度是容器，而发布的最小维度是应用
    • 3: 蓝绿发布对于增量升级有比较好的支持，但是对于涉及数据表结构变更等等不可逆转的升级，并不完全合适用蓝绿发布来实现，需要结合一些业务的逻辑以及数据迁移与回滚的策略才可以完全满足需求

金丝雀发布

  • 所谓金丝雀发布(Canary Releases), 和国内常说的灰度发布是同一类策略. 蓝绿部署是准备两套系统，在两套系统之间进行切换，金丝雀策略是只有一套系统，逐渐替换这套系统.

  • 灰度发布是增量发布的一种类型，灰度发布是在原有版本可用的情况下，同时部署一个新版本应用作为“金丝雀”（金丝雀对瓦斯极敏感，矿井工人携带金丝雀，以便及时发发现危险），测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现、调整问题.

  • 金丝雀发布的由来: “金丝雀”的由来：17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离.
  • 灰度发布／金丝雀发布的过程:
    • 1: 准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件
    • 2: 从负载均衡列表中移除掉“金丝雀”服务器.
    • 3: 升级“金丝雀”应用（排掉原有流量并进行部署.
    • 4: 对应用进行自动化测试
    • 5: 将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）
    • 6: 如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）
  • 金丝雀发布的优点: 灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度.
  • 金丝雀部署的适用场景:
    • 1: 不停止老版本，额外搞一套新版本，不同版本应用共存
    • 2: 灰度发布中，常常按照用户设置路由权重，例如90%的用户维持使用老版本，10%的用户尝鲜新版本
    • 3: 经常与A/B测试一起使用，用于测试选择多种方案。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来.

A/B测试

  • A/B测试(A/B Test)跟蓝绿部署完全是两码事:

    • A/B 测试A/B测试是效果测试，同一时间有多个版本的服务对外服务，这些服务都是经过足够测试，达到了上线标准的服务，有差异但是没有新旧之分（它们上线时可能采用了蓝绿部署的方式）, 核心目的是用来测试应用功能表现的方法，例如点击率, 转化率, 成交额等
    • 蓝绿部署和金丝雀是发布策略，目标是确保新上线的系统稳定，关注的是新系统的BUG、隐患. 目的是安全稳定地发布新版本应用，并在必要时回滚。

  • A/B 测试目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论，并确信该结论在推广到全部流量可信.

  • A/B测试时，线上同时运行多个版本的服务，这些服务通常会有一些体验上的差异，譬如说页面样式、颜色、操作流程不同。相关人员通过分析各个版本服务的实际效果，选出效果最好的版本

  • 注意: A/B测试与蓝绿部署可以同时使用!!!

滚动发布

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

  • 滚动发布的缺点:

    • 1: 没有一个确定OK的环境。使用蓝绿部署，我们能够清晰地知道老版本是OK的，而使用滚动发布，我们无法确定。
    • 2: 修改了现有的环境
    • 3: 如果需要回滚，很困难。举个例子，在某一次发布中，我们需要更新100个实例，每次更新10个实例，每次部署需要5分钟。当滚动发布到第80个实例时，发现了问题，需要回滚。此时，脾气不好的程序猿很可能想掀桌子，因为回滚是一个痛苦，并且漫长的过程
    • 4: 有的时候，我们还可能对系统进行动态伸缩，如果部署期间，系统自动扩容/缩容了，我们还需判断到底哪个节点使用的是哪个代码。

红黑部署

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

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