金丝雀发布、滚动发布、蓝绿发布到底有什么差别?关键点是什么?
############
根据 2017 年的 DevOps 发展报告,高效能组织和低效能组织在软件交付的效率上有数量级上的差异。技术组织的软件交付能力是一种综合能力,涉及众多环节,其中发布是尤为重要的环节。 作为技术人员,大家可能听说过“滚动发布”和“蓝绿发布”等术语,但是很多人并不清楚这些术语背后的原理。本文试图总结当前主流的发布策略,每个的优劣,适用性,让开发人员特别是架构师对现代发布技术有
一个更为清晰全面的认识,让大家能够根据自己的企业上下文,对发布策略做出正确的选型和实践。
一、单服务器发布
先解释下单服务器组的概念,早先我们机器资源比较紧张,不像现在云计算和虚拟化(包括容器技术)这么发达,所以应用机器基本是预先静态分配好的(一般由运维负责分配),原来应用 A 住在这 n 台机器上,
那么下次升级发布的应用 A 也住在这 n 台机器上,所以称为单服务器组发布方式。
1.1蛮力发布(单服务器组) - 蛮力发布会引入服务中断时间
如下图所示,这种发布方式比较简单粗暴,有点像我们传统的软件升级方式,主要靠手工完成,先将老版本 V1 全部下掉,再将新版本发到机器上去。这种方式会引入服务中断(停机),在开发测试环境是可行的,
但对于生产环境发布,其会直接影响用户的使用体验,这种方式一般是不建议的。
发布前
![](https://img2020.cnblogs.com/blog/1274745/202011/1274745-20201103103508263-636168733.png)
发布后
![](https://img2020.cnblogs.com/blog/1274745/202011/1274745-20201103103540472-1986454929.png)
1)优势和不足 优势: 简单成本低 不足: 服务中断用户受影响,出了问题回退也慢 2)适用场合: a).开发测试环境 b).非关键应用(用户影响面小) c)初创公司什么都缺,找夜深人静用户访问量小的时间干 3)流量模式
![](https://img2020.cnblogs.com/blog/1274745/202011/1274745-20201103103406092-701820519.png)
1.2金丝雀发布(单服务器组)【国内常称灰度测试】 - 少量金丝雀先接受流量,再全量发布
在蛮力发布基础上的一种简单改进发布方式,目前仍然是不少成长型技术组织的主流发布方式。单服务器组下的金丝雀发布的简化步骤如下图所示:
发布前
![](https://img2020.cnblogs.com/blog/1274745/202011/1274745-20201103104426363-1466606665.png)
先发布一台金丝雀(也可以先发布两台,可以设置允许多少流量先进入金丝雀发布服务)
剩下服务全部发完
1)实践要点 金丝雀发布一般先发 1 台,或者一个小比例,例如 2% 的服务器,主要做流量验证用,也称为金丝雀 (Canary) 测试(国内常称灰度测试)。以前旷工开矿下矿洞前,先会放一只金丝雀进去探是否有有毒
气体,看金丝雀能否活下来,金丝雀发布由此得名。简单的金丝雀测试一般通过手工测试验证,复杂的金丝雀测试需要比较完善的监控基础设施配合,通过监控指标反馈,观察金丝雀的健康状况,作为后续发布或
回退的依据。 如果金丝测试通过,则把剩余的 V1 版本全部升级为 V2 版本。如果金丝雀测试失败,则直接回退金丝雀,发布失败。 2)优势和不足 优势: 用户体验影响小,金丝雀发布过程出现问题只影响少量用户 不足: 发布自动化程度不够,发布期间可引发服务中断 3)适用场合: a).对新版本功能或性能缺乏足够信心 b).用户体验要求较高的网站业务场景 c).缺乏足够的自动化发布工具研发能力 4)流量模式
![](https://img2020.cnblogs.com/blog/1274745/202011/1274745-20201103104147446-1567198131.png)
1.3滚动式发布(单服务器组) - 滚动式发布,流量平滑过渡
在金丝雀发布基础上的进一步优化改进,是一种自动化程度较高的发布方式,用户体验比较平滑,是目前成熟型技术组织所采用的主流发布方式。单服务器组下的滚动发布的简化步骤如下图所示:
发布前
![](https://img2020.cnblogs.com/blog/1274745/202011/1274745-20201103105505434-2099221573.png)
发布中,先发一台金丝雀
发布中,再发若干台
直到全部发完
1)实践要点 a).滚动式发布一般先发 1 台,或者一个小比例,如 2% 服务器,主要做流量验证用,类似金丝雀 (Canary) 测试。 b).滚动式发布需要比较复杂的发布工具和智能 LB,支持平滑的版本替换和流量拉入拉出。 c).每次发布时,先将老版本 V1 流量从 LB 上摘除,然后清除老版本,发新版本 V2,再将 LB 流量接入新版本。这样可以尽量保证用户体验不受影响。 d).一次滚动式发布一般由若干个发布批次组成,每批的数量一般是可以配置的(可以通过发布模板定义)。例如第一批 1 台(金丝雀),第二批 10%,第三批 50%,第四批 100%。每个批次之间留观察
间隔,通过手工验证或监控反馈确保没有问题再发下一批次,所以总体上滚动式发布过程是比较缓慢的 (其中金丝雀的时间一般会比后续批次更长,比如金丝雀 10 分钟,后续间隔 2 分钟)。 e).回退是发布的逆过程,将新版本流量从 LB 上摘除,清除新版本,发老版本,再将 LB 流量接入老版本。和发布过程一样,回退过程一般也比较慢的。 f).滚动式发布国外术语通常叫 Rolling Update Deployment。 2)优势和不足 优势: 用户体验影响小,体验较平滑 不足: 发布和回退时间比较缓慢 发布工具比较复杂,LB 需要平滑的流量摘除和拉入能力 3)适用场合: a).用户体验不能中断的网站业务场景 b).有一定的复杂发布工具研发能力; 4)流量模式
![](https://img2020.cnblogs.com/blog/1274745/202011/1274745-20201103105315844-1346014390.png)
二、双服务器组发布
随着云计算和虚拟化技术的成熟,特别是容器等轻量级虚拟化技术的引入,计算资源受限和申请缓慢问题已经逐步解决,可以做到弹性按需分配。为一次发布分配两组服务器,一组运行现有的 V1 老版本,一组
运行待上线的 V2 新版本,再通过 LB 切换流量方式完成发布,这就是所谓的双服务器组发布方式。
2.1蓝绿发布(双服务器组) - 蓝绿发布一次完成流程切换
蓝绿发布仅适用于双服务器组发布,可以认为是对蛮力发布的一种简单优化发布方式。简化过程如下图所示:
![](https://img2020.cnblogs.com/blog/1274745/202011/1274745-20201103110305673-2014036168.png)
1)实践要点 V1 版本称为蓝组,V2 版本称为绿组,发布时通过 LB 一次性将流量从蓝组直接切换到绿组,不经过金丝雀和滚动发布,蓝绿发布由此得名; 出现问题回退也很直接,通过 LB 直接将流量切回蓝组。 发布初步成功后,蓝组机器一般不直接回收,而是留一个待观察期,视具体情况观察期的时间可长可短,观察期过后确认发布无问题,则可以回收蓝组机器。 2)优势和不足 优势: 升级切换和回退速度非常快 不足: 切换是全量的,如果 V2 版本有问题,则对用户体验有直接影响; 需要两倍机器资源; 3)适用场合: 对用户体验有一定容忍度的场景 机器资源有富余或者可以按需分配(AWS 云,或自建容器云) 暂不具备复杂滚动发布工具研发能力; 4)流量模式
![](https://img2020.cnblogs.com/blog/1274745/202011/1274745-20201103110242015-948440079.png)
2.2金丝雀发布(双服务器组)
对蓝绿部署的一种简单优化,发布时先从绿组拉入 1 台金丝雀,待金丝雀验证通过再发全量。对比蓝绿发布,该发布方式的优势是有一个生产流量的金丝雀验证过程,可以减轻 V2 可能有问题的风险和影响面。
简化发布过程如下图所示:
![](https://img2020.cnblogs.com/blog/1274745/202011/1274745-20201103110611688-806901456.png)
2.3滚动式发布(双服务器组) - 滚动式发布,流量平滑过渡
滚动式发布是对上面的蓝绿和金丝雀发布的进一步优化,按批次增量滚动发布,提供更平滑的用户体验。
1)实践要点 a).发布前先申请一批新服务器,数量一般和 V1 版本相同,将 V2 版本应用发布到新服务器上。例如如果在 AWS 云上,则可以直接调用 API 申请一批新 VM,如果用容器云 Kubernetes,则可以直接启
动一批新容器(使用 V2 版本容器镜像)。 b).一般会先通过 LB 拉入 1 台 V2 版本的机器,这台机器也相当于金丝雀,用于流量验证。 c).逐步按批次完成发布,每批只需要通过 LB 拉入 V2 版本,再拉出对应数量的 V1 版本。批次之间留有观察间隔,通过手工或监控反馈确保没有问题再继续发布。 d).发布有问题回退很快,直接通过 LB 将流量切回 V1 即可。 e).完成发布后,一般 V1 版本要保留观察以备万一,比如留 1 天,1 天后没有问题则回收 V1 机器资源。 2)优势和不足 优势: 用户体验影响小; 升级切换和回退(rollback)速度比单服务器组滚动发布要快,LB 切流量即可; 不足: 需要两倍机器资源; 发布工具比较复杂,LB 需要流量切换能力 3)适用场合: 用户体验不能中断的网站业务场景 机器资源有富余或者可以按需分配(AWS 云,或自建容器云) 有一定的发布工具研发能力; 4)流量模式
![](https://img2020.cnblogs.com/blog/1274745/202011/1274745-20201103110748851-650259501.png)
原文地址:http://www.54php.cn/default/224.html?source=cnblogs
############