ylbtech-发布机制-滚动式发布:百科 |
1. 滚动式发布(单服务器组)返回顶部 |
在金丝雀发布基础上的进一步优化改进,是一种自动化程度较高的发布方式,用户体验比较平滑,是目前成熟型技术组织所采用的主流发布方式。单服务器组下的滚动发布的简化步骤如下图所示:
发布前
发布中,先发一台金丝雀
发布中,再发若干台
直到全部发完
实践要点-
滚动式发布一般先发 1 台,或者一个小比例,如 2% 服务器,主要做流量验证用,类似金丝雀 (Canary) 测试。
-
滚动式发布需要比较复杂的发布工具和智能 LB,支持平滑的版本替换和流量拉入拉出。
-
每次发布时,先将老版本 V1 流量从 LB 上摘除,然后清除老版本,发新版本 V2,再将 LB 流量接入新版本。这样可以尽量保证用户体验不受影响。
-
一次滚动式发布一般由若干个发布批次组成,每批的数量一般是可以配置的(可以通过发布模板定义)。例如第一批 1 台(金丝雀),第二批 10%,第三批 50%,第四批 100%。每个批次之间留观察间隔,通过手工验证或监控反馈确保没有问题再发下一批次,所以总体上滚动式发布过程是比较缓慢的 (其中金丝雀的时间一般会比后续批次更长,比如金丝雀 10 分钟,后续间隔 2 分钟)。
-
回退是发布的逆过程,将新版本流量从 LB 上摘除,清除新版本,发老版本,再将 LB 流量接入老版本。和发布过程一样,回退过程一般也比较慢的。
-
滚动式发布国外术语通常叫 Rolling Update Deployment。
优势:
-
用户体验影响小,体验较平滑
不足:
-
发布和回退时间比较缓慢
-
发布工具比较复杂,LB 需要平滑的流量摘除和拉入能力
适用场合:
-
用户体验不能中断的网站业务场景
-
有一定的复杂发布工具研发能力;
滚动式发布,流量平滑过渡,图片来自附录 6.1
2.返回顶部 |
随着云计算和虚拟化技术的成熟,特别是容器等轻量级虚拟化技术的引入,计算资源受限和申请缓慢问题已经逐步解决,可以做到弹性按需分配。为一次发布分配两组服务器,一组运行现有的 V1 老版本,一组运行待上线的 V2 新版本,再通过 LB 切换流量方式完成发布,这就是所谓的双服务器组发布方式。
滚动式发布是对上面的蓝绿和金丝雀发布的进一步优化,按批次增量滚动发布,提供更平滑的用户体验。
-
发布前先申请一批新服务器,数量一般和 V1 版本相同,将 V2 版本应用发布到新服务器上。例如如果在 AWS 云上,则可以直接调用 API 申请一批新 VM,如果用容器云 Kubernetes,则可以直接启动一批新容器(使用 V2 版本容器镜像)。
-
一般会先通过 LB 拉入 1 台 V2 版本的机器,这台机器也相当于金丝雀,用于流量验证。
-
逐步按批次完成发布,每批只需要通过 LB 拉入 V2 版本,再拉出对应数量的 V1 版本。批次之间留有观察间隔,通过手工或监控反馈确保没有问题再继续发布。
-
发布有问题回退很快,直接通过 LB 将流量切回 V1 即可。
-
完成发布后,一般 V1 版本要保留观察以备万一,比如留 1 天,1 天后没有问题则回收 V1 机器资源。
优势:
-
用户体验影响小;
-
升级切换和回退(rollback)速度比单服务器组滚动发布要快,LB 切流量即可;
不足:
-
需要两倍机器资源;
-
发布工具比较复杂,LB 需要流量切换能力
适用场合:
-
用户体验不能中断的网站业务场景
-
机器资源有富余或者可以按需分配(AWS 云,或自建容器云)
-
有一定的发布工具研发能力;
滚动式发布,流量平滑过渡,图片来自附录 6.1
3.返回顶部 |
4.返回顶部 |
5.返回顶部 |
6.返回顶部 |
![]() |
作者:ylbtech 出处:http://ylbtech.cnblogs.com/ 本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。 |