various system release [online]

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发布,即:老板发布!

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

posted on 2019-10-21 10:39  szllq2000  阅读(156)  评论(0编辑  收藏  举报