高效能组织和低效能组织在软件交付的效率上有数量级上的差异。技术组织的软件交付能力是一种综合能力，涉及众多环节，其中发布是尤为重要的环节。——鲁迅

　　即使作为非开发工程师，相信很多人也听说过“金丝雀发布”、“滚动发布”和“蓝绿发布”等术语。一个稳定、可控、灵活、用户体验良好的发布流程是发布流程的一个较为理想状态

　　老司机想通过一篇文字给各位分享一下常见的几种发布模式，让开发或者非开发人员对软件发布一个更为清晰全面的认识，让大家能够根据自己的所在团队的情况，对发布策略给出正确的实践，必要时候参与讨（si）论（bi）。

1、 金丝雀发布

金丝雀 (Canary) 测试。源于以前矿工下矿洞前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来，由此得名。

简单的金丝雀测试一般通过手工测试验证，复杂的金丝雀测试需要比较完善的监控基础设施配合，通过监控指标反馈，观察金丝雀的健康状况，作为后续发布或回退的依据。

金丝雀发布，一般先把新版本发布到单集群1台服务器，或者一个小比例，主要做流量验证用。

如果金丝测试通过，则把剩余的原有版本全部升级为新版本。如果金丝雀测试失败，则直接摘除金丝雀的流量，宣布发布失败。

金丝雀发布，简单可控不粗暴！初创型公司比较适合。

2、 一群金丝雀发布

单服务器集群滚动发布，老司机给起个名字叫“一群金丝雀发布”。

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

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

单服务器集群滚动发布实践起来这样的：

1. 先发 1 台，或者一个小比例，主要做流量验证用，是不是很像金丝雀 (Canary) 测试；

2. 每次发布时，先将老版本流量从LB上摘除，清除老版本，发布新版本，再将LB流量接入新版本；

3. 滚动式发布每次操作一般由若干个批次组成，每批的数量一般是可以预设的（使用发布模板设定）。例如：第一批2%，第二批10%，第三批50%，第四批100%。每批上线之间留观察间隔，通过人工验证或监控反馈确保没有问题，再发下一批次。所以总体上滚动式发布过程是可控的 (其中第一批的时间一般会比之后的批次更长)；

4. 回退过程：将新版本流量从LB上摘除，清除新版本，替换上老版本发布，再将LB 流量接入老版本。和发布过程一样，回退过程一般也比较可控的；

滚动发布学名叫 Rolling Update Deployment。

在老司机看来，像是先放一只金丝雀，看看没问题？再放10只金丝雀，还没问题？再放N只… 直到整个矿井充满了金丝雀…

上面说的是单服务器集群的滚动发布，后面会讲多服务器集群的滚动发布。

以上说的都是单服务器集群的发布模式，下面讲讲双组服务器集群的发布模式。

非单集群发布的，都需要LB（Load Balance）进行流量引导和负载均衡调控来实现。

以下提到的LB，仅仅指代Load Balance（负载均衡），不要有其他联想…

3、 蓝绿发布

蓝绿发布，为一次发布分配两组服务器，一组运行现有的老版本，一组运行待上线的新版本，再通过LB切换流量方式完成发布，这就是所谓的双服务器组发布方式，俗称“蓝绿发布”。

蓝绿发布实践起来，简单粗暴！

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

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

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

蓝绿发布，适合简单粗暴的服务器土豪，毕竟需要准备双倍的服务器/容器资源。

简单粗暴，其实也意味着对用户体会很明显。

4、 功能开关发布

如果土豪拥有了技术，可以在代码层面上做文章。那么就是另一种发布方式：功能开关发布。

说得通俗一点儿，相当于在功能上做了一个if … else … ，当然实际比这个复杂得多。

5、 红蓝金丝雀发布

配合金丝雀发布，可以让蓝绿发布不那么简单粗暴，能够更精益！

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

红蓝金丝雀发布，如果有问题回退很快，直接通过LB将流量切回老版本即可。

完成发布后，一般老版本版本要保留观察以备万一，比如留1~2天，后没有问题则回收老版本服务器、容器资源。

6、 进阶的发布模式--A/B发布

A/B发布，跟A/B测试异曲同工，类似于升级版的功能切换发布。

配合LB，控制流量。移动端的流量进A集群，PC端的流量进B集群。

A/B发布实践起来分两种：

1. 简单配置：

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

2. 高级定制：

高级的A/B测试需要专门的平台支撑，这类平台可以细粒度到针对某类用户做 A/B 测试。不在本文讨论之列。

功能开关发布和A/B发布看起来类似，但前者一般是无状态和全量的，而A/B发布一般是有状态的，能够跟踪事务和用户级别的状态可以实现针对某类特定用户的。

一句话，功能开关发布是成衣，A/B发布是高定款。

7、 技术大咖才能操作的--影子发布

设想以下场景：

• 核心业务要技术转型，但是服务不能停；

• 关键业务从.NET转型JAVA，服务不能停；

• 现金业务后台DB从Oracle转到MySQL，服务不能停；

……

为了确保万无一失，有一种称为影子测试的大招，采用比较复杂的流量复制、回放和比对技术实现。

影子发布，具体实践有点儿复杂：

目标：实现老的遗留系统服务迁移升级到新的服务；

部署启动前，需要在测试环境部署一份遗留系统服务和新的服务，将生产数据库复制两份到测试环境。

同时需要将生产请求导流出来一份，一般可以通过消息队列收集、导流。导流目标是将生产请求日志，复制回放，分发到测试环境里面的遗留系统服务和新的服务。

测试环境中的两种服务，收到响应后进行比对，如果所有响应比对成功，则可以认为 遗留系统服务和新的服务在功能逻辑上是等价的。

如果有响应比对失败，则认为两者在功能逻辑上不等价，需要修复新的环境，并重新进行影子测试，直到全部比对成功。

根据系统复杂度和关键性不同，比对测试时间短的可能需要几周，长的可达几个月之久。

影子发布最大的优势，因为旁路在独立测试环境中进行，可以对生产流量完全无影响。

能完成影子发布的，必须是研发、测试、运维三路大咖联手才能完成。

8、 终极大招--LB发布

最终极、最无敌、最强力、最有效、最无招胜有招…… LB发布，即：老板发布！

老板说怎么发布，咱们就怎么发布…