一篇文章说尽全部软件发布

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

                                                                   

 

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

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

　　

一、 金丝雀发布

 

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

 

 

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

 

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

若是金丝测试经过，则把剩余的原有版本所有升级为新版本。若是金丝雀测试失败，则直接摘除金丝雀的流量，宣布发布失败。

    

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

 

二、 一群金丝雀发布

 

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

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

前提：滚动发布须要比较复杂的发布工具和智能 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（负载均衡），不要有其余联想…

三、 蓝绿发布

 

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

 

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

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

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

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

 

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

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

四、 功能开关发布

 

若是土豪拥有了技术，能够在代码层面上作文章。那么就是另外一种发布方式：功能开关发布。

说得通俗一点儿，至关于在功能上作了一个if … else … ，固然实际比这个复杂得多。

五、 红蓝金丝雀发布

 

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

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

    红蓝金丝雀发布，若是有问题回退很快，直接经过LB将流量切回老版本便可。

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

 

六、 进阶的发布模式--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发布是高定款。

 

七、 技术大咖才能操做的--影子发布

 

设想如下场景：

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

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

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

……

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

 

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

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

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

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

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

若是有响应比对失败，则认为二者在功能逻辑上不等价，须要修复新的环境，并从新进行影子测试，直到所有比对成功。

 

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

 

影子发布最大的优点，由于旁路在独立测试环境中进行，能够对生产流量彻底无影响。

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

 

八、 终极大招--LB发布

 

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

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