金丝雀发布、滚动发布、蓝绿发布到底有什么差别？关键点是什么？

############

根据 2017 年的 DevOps 发展报告，高效能组织和低效能组织在软件交付的效率上有数量级上的差异。技术组织的软件交付能力是一种综合能力，涉及众多环节，其中发布是尤为重要的环节。

作为技术人员，大家可能听说过“滚动发布”和“蓝绿发布”等术语，但是很多人并不清楚这些术语背后的原理。本文试图总结当前主流的发布策略，每个的优劣，适用性，让开发人员特别是架构师对现代发布技术有
一个更为清晰全面的认识，让大家能够根据自己的企业上下文，对发布策略做出正确的选型和实践。

一、单服务器发布

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

1.1蛮力发布(单服务器组) - 蛮力发布会引入服务中断时间

如下图所示，这种发布方式比较简单粗暴，有点像我们传统的软件升级方式，主要靠手工完成，先将老版本 V1 全部下掉，再将新版本发到机器上去。这种方式会引入服务中断（停机），在开发测试环境是可行的，
但对于生产环境发布，其会直接影响用户的使用体验，这种方式一般是不建议的。
                                               发布前

                                          发布后

1）优势和不足
   优势：
      简单成本低
   不足：
      服务中断用户受影响，出了问题回退也慢

2）适用场合：
   a).开发测试环境
   b).非关键应用（用户影响面小）
   c)初创公司什么都缺，找夜深人静用户访问量小的时间干

3）流量模式

1.2金丝雀发布(单服务器组)【国内常称灰度测试】 - 少量金丝雀先接受流量，再全量发布

在蛮力发布基础上的一种简单改进发布方式，目前仍然是不少成长型技术组织的主流发布方式。单服务器组下的金丝雀发布的简化步骤如下图所示：
发布前

         先发布一台金丝雀(也可以先发布两台，可以设置允许多少流量先进入金丝雀发布服务)

                                     剩下服务全部发完

 

1）实践要点
   金丝雀发布一般先发 1 台，或者一个小比例，例如 2% 的服务器，主要做流量验证用，也称为金丝雀 (Canary) 测试（国内常称灰度测试）。以前旷工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒
气体，看金丝雀能否活下来，金丝雀发布由此得名。简单的金丝雀测试一般通过手工测试验证，复杂的金丝雀测试需要比较完善的监控基础设施配合，通过监控指标反馈，观察金丝雀的健康状况，作为后续发布或
回退的依据。
   如果金丝测试通过，则把剩余的 V1 版本全部升级为 V2 版本。如果金丝雀测试失败，则直接回退金丝雀，发布失败。

2）优势和不足
   优势：
      用户体验影响小，金丝雀发布过程出现问题只影响少量用户
   不足：
      发布自动化程度不够，发布期间可引发服务中断


3）适用场合：
   a).对新版本功能或性能缺乏足够信心
   b).用户体验要求较高的网站业务场景
   c).缺乏足够的自动化发布工具研发能力

4）流量模式

1.3滚动式发布(单服务器组) - 滚动式发布，流量平滑过渡

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

                                           发布前

               发布中，先发一台金丝雀

 

                              发布中，再发若干台

                                     直到全部发完

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）流量模式

二、双服务器组发布

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

2.1蓝绿发布(双服务器组) - 蓝绿发布一次完成流程切换 

蓝绿发布仅适用于双服务器组发布，可以认为是对蛮力发布的一种简单优化发布方式。简化过程如下图所示：

1）实践要点
   V1 版本称为蓝组，V2 版本称为绿组，发布时通过 LB 一次性将流量从蓝组直接切换到绿组，不经过金丝雀和滚动发布，蓝绿发布由此得名；
   出现问题回退也很直接，通过 LB 直接将流量切回蓝组。
   发布初步成功后，蓝组机器一般不直接回收，而是留一个待观察期，视具体情况观察期的时间可长可短，观察期过后确认发布无问题，则可以回收蓝组机器。

2）优势和不足
   优势：
      升级切换和回退速度非常快
   不足：
      切换是全量的，如果 V2 版本有问题，则对用户体验有直接影响；
      需要两倍机器资源；

3）适用场合：
   对用户体验有一定容忍度的场景
   机器资源有富余或者可以按需分配（AWS 云，或自建容器云）
   暂不具备复杂滚动发布工具研发能力；

4）流量模式

2.2金丝雀发布(双服务器组)

对蓝绿部署的一种简单优化，发布时先从绿组拉入 1 台金丝雀，待金丝雀验证通过再发全量。对比蓝绿发布，该发布方式的优势是有一个生产流量的金丝雀验证过程，可以减轻 V2 可能有问题的风险和影响面。
简化发布过程如下图所示：

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）流量模式

原文地址：http://www.54php.cn/default/224.html?source=cnblogs

############