在项目迭代的过程中，不可避免需要进行项目上线。上线对应着部署或者重新部署，部署对应着修改，修改则意味着风险。
目前有很多用于部署的技术，有的简单，有的复杂，有的得停机，有的不需要停机即可完成部署。作为技术人员，大家可能听说过“滚动发布”和“蓝绿发布”等术语，但是很多人并不清楚这些术语背后的原理。本文试图总结当前主流的发布策略，每个的优劣，适用性，让开发人员特别是架构师对现代发布技术有一个更为清晰全面的认识，让大家能够根据自己的企业上下文，对发布策略做出正确的选型和实践。

单服务器组发布

先解释下单服务器组的概念，早先我们机器资源比较紧张，不像现在云计算和虚拟化（包括容器技术）这么发达，所以应用机器基本是预先静态分配好的（一般由运维负责分配），原来应用 A 住在这 n 台机器上，那么下次升级发布的应用 A 也住在这 n 台机器上，所以称为单服务器组发布方式。

蛮力发布

如下图所示，这种发布方式比较简单粗暴，有点像我们传统的软件升级方式，主要靠手工完成，先将老版本 V1 全部下掉，再将新版本发到机器上去。这种方式会引入服务中断（停机），在开发测试环境是可行的，但对于生产环境发布，其会直接影响用户的使用体验，这种方式一般是不建议的。

优势和适用场合

优势：

•简单成本低

不足：

•服务中断用户受影响，出了问题回退也慢

适用场合：

•开发测试环境

•非关键应用（用户影响面小）

•初创公司什么都缺，找夜深人静用户访问量小的时间干

蛮力发布会引入服务中断时间

金丝雀发布（单服务器组）

在蛮力发布基础上的一种简单改进发布方式，目前仍然是不少成长型技术组织的主流发布方式。单服务器组下的金丝雀发布的简化步骤如下图所示：

部署过程

1. 金丝雀发布一般先发 1 台，或者一个小比例，例如 2% 的服务器，主要做流量验证用，也称为金丝雀 (Canary) 测试（国内常称灰度测试）。以前旷工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来，金丝雀发布由此得名。简单的金丝雀测试一般通过手工测试验证，复杂的金丝雀测试需要比较完善的监控基础设施配合，通过监控指标反馈，观察金丝雀的健康状况，作为后续发布或回退的依据。

2. 如果金丝测试通过，则把剩余的 V1 版本全部升级为 V2 版本。如果金丝雀测试失败，则直接回退金丝雀，发布失败。

灰度发布／金丝雀发布由以下几个步骤组成：

• 准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。

• 从负载均衡列表中移除掉「金丝雀」服务器。

• 升级「金丝雀」应用（排掉原有流量并进行部署）。

• 对应用进行自动化测试。

• 将「金丝雀」服务器重新添加到负载均衡列表中（连通性和健康检查）。

• 如果「金丝雀」在线使用测试成功，升级剩余的其他服务器（否则就回滚）。

除此之外灰度发布还可以设置路由权重，动态调整不同的权重来进行新老版本的验证。

优势和适用场合

优势：

•用户体验影响小，金丝雀发布过程出现问题只影响少量用户

不足：

•发布自动化程度不够，发布期间可引发服务中断

适用场合：

•对新版本功能或性能缺乏足够信心

•用户体验要求较高的网站业务场景

•缺乏足够的自动化发布工具研发能力

少量金丝雀先接受流量，再全量发布

滚动式发布（单服务器组）

定义

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

特点

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

滚动发布是在金丝雀发布基础上的进一步优化改进，是一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流发布方式。单服务器组下的滚动发布的简化步骤如下图所示：

部署过程

1. 滚动式发布一般先发 1 台，或者一个小比例，如 2% 服务器，主要做流量验证用，类似金丝雀 (Canary) 测试。

2. 滚动式发布需要比较复杂的发布工具和智能 LB，支持平滑的版本替换和流量拉入拉出。

3. 每次发布时，先将老版本 V1 流量从 LB 上摘除，然后清除老版本，发新版本 V2，再将 LB 流量接入新版本。这样可以尽量保证用户体验不受影响。

4. 一次滚动式发布一般由若干个发布批次组成，每批的数量一般是可以配置的（可以通过发布模板定义）。例如第一批 1 台（金丝雀），第二批 10%，第三批 50%，第四批 100%。每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程是比较缓慢的 (其中金丝雀的时间一般会比后续批次更长，比如金丝雀 10 分钟，后续间隔 2 分钟)。

5. 回退是发布的逆过程，将新版本流量从 LB 上摘除，清除新版本，发老版本，再将 LB 流量接入老版本。和发布过程一样，回退过程一般也比较慢的。

6. 滚动式发布国外术语通常叫 Rolling Update Deployment。

优势和适用场合

优势：

•用户体验影响小，体验较平滑

不足：

•发布和回退时间比较缓慢

•发布工具比较复杂，LB 需要平滑的流量摘除和拉入能力

适用场合：

•用户体验不能中断的网站业务场景

•有一定的复杂发布工具研发能力；

滚动式发布，流量平滑过渡，图片来自附录 6.1

双服务器组发布

随着云计算和虚拟化技术的成熟，特别是容器等轻量级虚拟化技术的引入，计算资源受限和申请缓慢问题已经逐步解决，可以做到弹性按需分配。为一次发布分配两组服务器，一组运行现有的 V1 老版本，一组运行待上线的 V2 新版本，再通过 LB 切换流量方式完成发布，这就是所谓的双服务器组发布方式。

蓝绿发布（双服务器组）

蓝绿发布仅适用于双服务器组发布，可以认为是对蛮力发布的一种简单优化发布方式。简化过程如下图所示：

部署过程

1.V1 版本称为蓝组，V2 版本称为绿组，发布时通过 LB 一次性将流量从蓝组直接切换到绿组，不经过金丝雀和滚动发布，蓝绿发布由此得名；

2. 出现问题回退也很直接，通过 LB 直接将流量切回蓝组。

3. 发布初步成功后，蓝组机器一般不直接回收，而是留一个待观察期，视具体情况观察期的时间可长可短，观察期过后确认发布无问题，则可以回收蓝组机器。

从过程不难发现，在部署的过程中，我们的应用始终在线。并且新版本上线的过程中，并没有修改老版本的任何内容，在部署期间，老版本的状态不受影响，这样风险很小。并且只要老版本的资源不被删除，理论上，我们可以在任何时间回滚到老版本。

蓝绿发布的注意事项

当你切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。如果你的数据库后端无法处理，会是一个比较麻烦的问题。
• 可能会出现需要同时处理微服务架构应用和传统架构应用的情况，如果在蓝绿部署中协调不好这两者，还是有可能会导致服务停止。
• 需要提前考虑数据库与应用部署同步迁移 / 回滚的问题。
• 蓝绿部署需要有基础设施支持。
• 在非隔离基础架构（ VM 、 Docker 等）上执行蓝绿部署，蓝色环境和绿色环境有被摧毁的风险。

优势和适用场合

优势：

•升级切换和回退速度非常快

不足：

•切换是全量的，如果 V2 版本有问题，则对用户体验有直接影响；

•需要两倍机器资源；

适用场合：

•对用户体验有一定容忍度的场景

•机器资源有富余或者可以按需分配（AWS 云，或自建容器云）

•暂不具备复杂滚动发布工具研发能力；

蓝绿发布一次完成流程切换

金丝雀发布（双服务器组）

对蓝绿部署的一种简单优化，发布时先从绿组拉入 1 台金丝雀，待金丝雀验证通过再发全量。对比蓝绿发布，该发布方式的优势是有一个生产流量的金丝雀验证过程，可以减轻 V2 可能有问题的风险和影响面。简化发布过程如下图所示：

滚动式发布（双服务器组）

滚动式发布是对上面的蓝绿和金丝雀发布的进一步优化，按批次增量滚动发布，提供更平滑的用户体验。

部署过程

1. 发布前先申请一批新服务器，数量一般和 V1 版本相同，将 V2 版本应用发布到新服务器上。例如如果在 AWS 云上，则可以直接调用 API 申请一批新 VM，如果用容器云 Kubernetes，则可以直接启动一批新容器（使用 V2 版本容器镜像）。

2. 一般会先通过 LB 拉入 1 台 V2 版本的机器，这台机器也相当于金丝雀，用于流量验证。

3. 逐步按批次完成发布，每批只需要通过 LB 拉入 V2 版本，再拉出对应数量的 V1 版本。批次之间留有观察间隔，通过手工或监控反馈确保没有问题再继续发布。

4. 发布有问题回退很快，直接通过 LB 将流量切回 V1 即可。

5. 完成发布后，一般 V1 版本要保留观察以备万一，比如留 1 天，1 天后没有问题则回收 V1 机器资源。

优势和适用场合

优势：

•用户体验影响小；

•升级切换和回退（rollback）速度比单服务器组滚动发布要快，LB 切流量即可；

不足：

•需要两倍机器资源；

•发布工具比较复杂，LB 需要流量切换能力

适用场合：

•用户体验不能中断的网站业务场景

•机器资源有富余或者可以按需分配（AWS 云，或自建容器云）

•有一定的发布工具研发能力；

滚动式发布，流量平滑过渡

其它发布方式

上述都是偏传统的发布方式，能覆盖大部分应用发布场景。针对一些关键新功能的上线发布，或者一些特定的场景，还有一些特殊的发布方式。

功能开关发布

利用代码中的功能开关（Feature Flag/Toggle/Switch）来控制发布逻辑，一般不需要复杂的发布工具和智能 LB 配合，是一种相对比较低成本和简单的发布方式。这种方式也是支持现代 DevOps 理念，研发人员可以灵活定制和自助完成的发布方式。功能开关的原理如下图所示：

部署过程

• 功能开关发布需要一个配置中心或者开关中心这样的服务支持，例如携程的 Apollo 配置中心或者开源的 FF4J，这些都支持开关发布。业界还有专门的功能开关 SaaS 服务，例如 LaunchDarkly。通过配置中心，运维或研发人员可以在运行期动态配置功能开关的值。当然，功能开关发布只是配置中心的一种使用场景，配置中心还能支持其它很多动态配置场景。

• 功能开关服务一般提供客户端 SDK，方便开发人员集成。在运行期，客户端 SDK 会同步最新的开关值，技术实现有推方式 (push)，也有拉方式 (pull)，或者推拉结合方式。

• 新功能（V2 new feature）和老功能（V1 old feature）住在同一套代码中，新功能隐藏在开关后面，如果开关没有打开，则走老代码逻辑，如果开关打开，则走新代码逻辑。技术实现上可以理解为一个简单的 if/else 逻辑。

• 应用上线后，开关先不打开，然后运维或研发人员通过开关中心打开新功能，经过流量验证新功能没有问题，则发布完成；如果有问题，则随时可以通过开关中心切回老功能逻辑。

优势和不足

• 优势

升级切换和回退速度非常快。
相对于复杂的发布工具，实施比较简单，成本相对低廉。
研发能够灵活定制发布逻辑，支持 DevOps 自助发布。

• 不足

切换是全量的，如果 V2 版本有问题，则对用户体验有直接影响。
对代码有侵入，代码逻辑会变复杂，需要定期清理老版本逻辑，维护成本变高。

适用场合：

•对用户体验有一定容忍度的场景

•已有配置中心或开关中心服务

•暂不具备研发复杂发布工具能力；

影子测试

对于一些涉及核心业务的遗留系统的升级改造，为了确保万无一失，有一种称为影子测试的大招，采用比较复杂的流量复制、回放和比对技术实现。下面是影子测试的一个样例架构图：

部署过程

影子测试一般适用于遗留系统的等价重构迁移，例如 .net 转 Java，或者 SQLServer 数据库升级为 MySQL 数据库，且外部依赖不能太多，否则需要开发很多 mock，测试部署成本会很高，且比对测试更加复杂和不稳定。

• 目标实现老的 legacy 服务迁移升级到新的 experimental 服务。

• 测试开始前，需要在测试环境部署一份 legacy 服务和 experimental 服务，同时将生产数据库复制两份到测试环境。同时需要将生产请求日志收集起来，一般可以通过 kafka 队列收集，然后通过类似 goreplay 这样的工具，消费 kafka 里头的请求日志，复制回放，将请求分发到 legacy 服务和 experimental 服务，收到响应后进行比对，如果所有响应比对成功，则可以认为 legacy 服务和 experimental 服务在功能逻辑上是等价的；如果有响应比对失败，则认为两者在功能逻辑上不等价，需要修复 experimental 并重新进行影子测试，直到全部比对成功。根据系统复杂度和关键性不同，比对测试时间短的可能需要几周，长的可达半年之久。

• 影子测试因为旁路在独立测试环境中进行，可以对生产流量完全无影响。

优势和不足

• 优势

对生产用户体验完全无影响。
可以使用生产真实流量进行测试（复制比对）。

• 不足

搭建复杂度很高，技术门槛高，数据库的导出复制是难点。
外部依赖不能太多，否则测试部署成本很高，且比对测试更加复杂和不稳定。

适用场合：

•核心关键业务，比如涉及资金的

•具备一定影子测试平台研发能力，包括流量复制、数据库导出复制和分发比对系统。

A/B 测试

灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB Test 就是一种灰度发布方式，让一部分用户继续用 A，一部分用户开始用 B，如果用户对 B 没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到 B 上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度

A/B 测试原来主要用于产品功能的比对测试的方法，收集用户反馈和对比数据做产品功能设计的决策，例如可用性、受欢迎程度、可见性等等。 A/B 测试通常用在应用的前端上，不过当然需要后端来支持。实际上，A/B 测试也可以作为一种新功能发布技术。下图展示基于 LB 实现的一种 A/B 测试发布。

实践要点

1. 上图中，原来 PC 端和手机端都访问老版本 V1 服务（也称 A 组或控制组），当 V2 新版本（也称 B 组或实验组）发布以后，为了验证 V2 的功能正确性，同时也为了避免 V2 有问题时影响所有用户，先通过 LB 将手机端的流量切换到 V2 版本，经过一段时间的 A/B 比对测试和观察（主要通过用户和监控反馈），确保 V2 正常，则通过 LB 将全部流量切换到 V2。

2. 基于 LB 方式实现 A/B 测试，LB 需要能够通过某种条件做流量路由，例如通过 client ip，设备类型，浏览器类型，甚至是定制的 HTTP Header 或查询字符串。

3. 高级的 A/B 测试需要专门的平台支撑，wasabi 附录 6.6 就是 intuit 开源的一个支持高级 A/B 测试的平台，这类平台可以细粒度到针对某类用户做 A/B 测试，例如针对某个地区的用户，某个年龄段的用户，公司内部用户等等。举了例子，假设一个关键业务的新功能上线，为了降低风险采用 A/B 测试，可以做到先只让公司内部员工能访问到新功能，待新功能验证过，再全量放开给外部用户使用。

4. 功能开关和 A/B 测试有点相似，但功能开关一般是无状态和全量的，无法做到针对某类特定用户进行测试，而 A/B 测试一般是有状态的，能够跟踪事务和用户级别的状态，可以实现针对某类特定用户进行测试。

A/B 测试与蓝绿部署的区别在于， A/B 测试目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论，并确信该结论在推广到全部流量可信；蓝绿部署的目的是安全稳定地发布新版本应用，并在必要时回滚。A/B 测试原来主要用于产品功能的比对测试，收集用户反馈和对比数据做产品功能设计的决策。实际上，A/B 测试也可以作为一种新功能发布技术。下图展示基于 LB 实现的一种 A/B 测试发布。

优势和适用场合

优势：

•用户体验影响小；

•可以使用生产流量测试；

•可以做到针对某类特定目标用户进行测试；

不足：

•搭建复杂度相对高，有一定技术门槛

适用场合：

•核心关键业务，比如涉及资金的

•具备一定的 A/B 测试平台研发能力