蓝绿部署、滚动部署、金丝雀发布（灰度发布）、A/B测试

蓝绿部署

减少发布时的中断时间、能够快速撤回发布

• 两套系统
  • 一套是正在提供服务系统，标记为绿色
  • 一套是准备发布的系统，标记为蓝色
  • 都是功能完善的，并且正在运行的系统，只是系统版本和对外服务情况不同
• 第一套系统开发完成，直接上线，这个过程只有一个系统，也没有蓝绿之分
• 后来，开发了新版本，要用新版本替换线上的旧版本，在线上的系统之外，搭建了一个使用新版本代码的全新系统。
• 这时候，一共有两套系统在运行，正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统
• 蓝色系统
  • 用来做发布前测试，测试过程中发现任何问题，可以直接在蓝色系统上修改，不干扰用户正在使用的系统
  • 注意：两套系统没有耦合的时候才能百分百保证不干扰
  • 蓝色系统经过反复的测试、修改、验证，确定达到上线标准之后，直接将用户切换到蓝色系统

切换后的一段时间内，依旧是蓝绿两套系统并存，但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统（新系统）工作状态，如果出现问题，直接切换回绿色系统。

当确信对外提供服务的蓝色系统工作正常，不对外提供服务的绿色系统已经不再需要的时候，蓝色系统正式成为对外提供服务系统，成为新的绿色系统。 原先的绿色系统可以销毁，将资源释放出来，用于部署下一个蓝色系统。

蓝绿部署只是上线策略中的一种，它不是可以应对所有情况的万能方案。 蓝绿部署能够简单快捷实施的前提假设是目标系统是非常内聚的，如果目标系统相当复杂，那么如何切换、两套系统的数据是否需要以及如何同步等，都需要仔细考虑。

滚动发布

一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。

周而复始，直到集群中所有的实例都更新成新版本。

相对于蓝绿部署，更加节约资源——它不需要运行两个集群、两倍的实例数，可以部分部署。

• 缺点
  • 没有一个确定OK的环境。使用蓝绿部署，我们能够清晰地知道老版本是OK的，而使用滚动发布，我们无法确定。
  • 修改了现有的环境。
  • 如果需要回滚，很困难。举个例子，在某一次发布中，我们需要更新100个实例，每次更新10个实例，每次部署需要5分钟。当滚动发布到第80个实例时，发现了问题，需要回滚，这个回滚却是一个痛苦，并且漫长的过程。
  • 有的时候，我们还可能对系统进行动态伸缩，如果部署期间，系统自动扩容/缩容了，我们还需判断到底哪个节点使用的是哪个代码。尽管有一些自动化的运维工具，但是依然令人心惊胆战。
  • 因为是逐步更新，那么我们在上线代码的时候，就会短暂出现新老版本不一致的情况，如果对上线要求较高的场景，那么就需要考虑如何做好兼容的问题。

金丝雀发布（灰度发布）

一种发布策略，和国内常说的灰度发布是同一类策略

蓝绿部署是准备两套系统，在两套系统之间进行切换，金丝雀策略是只有一套系统，逐渐替换这套系统

目标系统是一组无状态的Web服务器，但是数量非常多，假设有一万台。

这时候，蓝绿部署就不能用了，因为你不可能申请一万台服务器专门用来部署蓝色系统（在蓝绿部署的定义中，蓝色的系统要能够承接所有访问）。

可以想到的一个方法是：

只准备几台服务器，在上面部署新版本的系统并测试验证。测试通过之后，担心出现意外，还不敢立即更新所有的服务器。 先将线上的一万台服务器中的10台更新为最新的系统，然后观察验证。确认没有异常之后，再将剩余的所有服务器更新。

这个方法就是金丝雀发布。

实际操作中还可以做更多控制，譬如说，给最初更新的10台服务器设置较低的权重、控制发送给这10台服务器的请求数，然后逐渐提高权重、增加请求数。

这个控制叫做“流量切分”，既可以用于金丝雀发布，也可以用于后面的A/B测试。

蓝绿部署和金丝雀发布是两种发布策略，都不是万能的。有时候两者都可以使用，有时候只能用其中一种。

上面的例子中可以用金丝雀，不能用蓝绿，那么什么时候可以用蓝绿，不能用金丝雀呢？整个系统只有一台服务器的时候。

步骤：

• 准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。
• 从负载均衡列表中移除掉“金丝雀”服务器。
• 升级“金丝雀”应用（排掉原有流量并进行部署）。
• 对应用进行自动化测试。
• 将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。
• 如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）
• 除此之外灰度发布还可以设置路由权重，动态调整不同的权重来进行新老版本的验证。

A/B测试

A/B测试和蓝绿部署以及金丝雀，完全是两回事。

蓝绿部署和金丝雀是发布策略，目标是确保新上线的系统稳定，关注的是新系统的BUG、隐患。

A/B测试是效果测试，同一时间有多个版本的服务对外服务，这些服务都是经过足够测试，达到了上线标准的服务，有差异但是没有新旧之分（它们上线时可能采用了蓝绿部署的方式）。

A/B测试关注的是不同版本的服务的实际效果，譬如说转化率、订单情况等。

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

在A/B测试中，需要能够控制流量的分配，譬如说，为A版本分配10%的流量，为B版本分配10%的流量，为C版本分配80%的流量。