发布机制-滚动式发布：百科

ylbtech-发布机制-滚动式发布：百科

1. 滚动式发布（单服务器组）返回顶部

1、

先解释下单服务器组的概念，早先我们机器资源比较紧张，不像现在云计算和虚拟化（包括容器技术）这么发达，所以应用机器基本是预先静态分配好的（一般由运维负责分配），原来应用 A 住在这 n 台机器上，那么下次升级发布的应用 A 也住在这 n 台机器上，所以称为单服务器组发布方式。

2、

1.3 滚动式发布（单服务器组）

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

发布前

发布中，先发一台金丝雀

发布中，再发若干台

直到全部发完

 实践要点

1. 滚动式发布一般先发 1 台，或者一个小比例，如 2% 服务器，主要做流量验证用，类似金丝雀 (Canary) 测试。

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

3. 每次发布时，先将老版本 V1 流量从 LB 上摘除，然后清除老版本，发新版本 V2，再将 LB 流量接入新版本。这样可以尽量保证用户体验不受影响。

4. 一次滚动式发布一般由若干个发布批次组成，每批的数量一般是可以配置的（可以通过发布模板定义）。例如第一批 1 台（金丝雀），第二批 10%，第三批 50%，第四批 100%。每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程是比较缓慢的 (其中金丝雀的时间一般会比后续批次更长，比如金丝雀 10 分钟，后续间隔 2 分钟)。

5. 回退是发布的逆过程，将新版本流量从 LB 上摘除，清除新版本，发老版本，再将 LB 流量接入老版本。和发布过程一样，回退过程一般也比较慢的。

6. 滚动式发布国外术语通常叫 Rolling Update Deployment。

 优势和适用场合

优势：

• 用户体验影响小，体验较平滑

不足：

• 发布和回退时间比较缓慢

• 发布工具比较复杂，LB 需要平滑的流量摘除和拉入能力

适用场合：

• 用户体验不能中断的网站业务场景

• 有一定的复杂发布工具研发能力；

 流量模式

滚动式发布，流量平滑过渡，图片来自附录 6.1

3、

2.返回顶部

1、

随着云计算和虚拟化技术的成熟，特别是容器等轻量级虚拟化技术的引入，计算资源受限和申请缓慢问题已经逐步解决，可以做到弹性按需分配。为一次发布分配两组服务器，一组运行现有的 V1 老版本，一组运行待上线的 V2 新版本，再通过 LB 切换流量方式完成发布，这就是所谓的双服务器组发布方式。

2、

2.3 滚动式发布（双服务器组）

滚动式发布是对上面的蓝绿和金丝雀发布的进一步优化，按批次增量滚动发布，提供更平滑的用户体验。

实践要点

1. 发布前先申请一批新服务器，数量一般和 V1 版本相同，将 V2 版本应用发布到新服务器上。例如如果在 AWS 云上，则可以直接调用 API 申请一批新 VM，如果用容器云 Kubernetes，则可以直接启动一批新容器（使用 V2 版本容器镜像）。

2. 一般会先通过 LB 拉入 1 台 V2 版本的机器，这台机器也相当于金丝雀，用于流量验证。

3. 逐步按批次完成发布，每批只需要通过 LB 拉入 V2 版本，再拉出对应数量的 V1 版本。批次之间留有观察间隔，通过手工或监控反馈确保没有问题再继续发布。

4. 发布有问题回退很快，直接通过 LB 将流量切回 V1 即可。

5. 完成发布后，一般 V1 版本要保留观察以备万一，比如留 1 天，1 天后没有问题则回收 V1 机器资源。

 优势和适用场合

优势：

• 用户体验影响小；

• 升级切换和回退（rollback）速度比单服务器组滚动发布要快，LB 切流量即可；

不足：

• 需要两倍机器资源；

• 发布工具比较复杂，LB 需要流量切换能力

适用场合：

• 用户体验不能中断的网站业务场景

• 机器资源有富余或者可以按需分配（AWS 云，或自建容器云）

• 有一定的发布工具研发能力；

 流量模式

滚动式发布，流量平滑过渡，图片来自附录 6.1

3、

3.返回顶部

 

4.返回顶部

 

5.返回顶部

1、

https://www.cnblogs.com/apanly/p/8784096.html

2、

 

6.返回顶部

 

作者：ylbtech 出处：http://ylbtech.cnblogs.com/ 本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。