发布策略从总体上分为：
全量发布：蛮力发布、蓝绿发布、红黑发布；
增量发布：灰度发布/金丝雀发布、滚动发布。
目录
一、单服务器组发布
先解释下单服务器组的概念，早先我们机器资源比较紧张，不像现在云计算和虚拟化（包括容器技术）这么发达，所以应用机器基本是预先静态分配好的（一般由运维负责分配），原来应用 A 住在这 n 台机器上，那么下次升级发布的应用 A 也住在这 n 台机器上，所以称为单服务器组发布方式。
1、蛮力发布
如下图所示，这种发布方式比较简单粗暴，有点像我们传统的软件升级方式，主要靠手工完成，先将老版本 V1 全部下掉，再将新版本发到机器上去。这种方式会引入服务中断（停机），在开发测试环境是可行的，但对于生产环境发布，其会直接影响用户的使用体验，这种方式一般是不建议的。
优势
- 简单成本低。
不足
- 服务中断用户受影响，出了问题回退也慢。
适用场合
- 开发测试环境；
- 非关键应用（用户影响面小）；
- 初创公司什么都缺，找夜深人静用户访问量小的时间干。
流量模式
蛮力发布会引入服务中断时间。
2、金丝雀发布（单服务器组）
在蛮力发布基础上的一种简单改进发布方式，目前仍然是不少成长型技术组织的主流发布方式。单服务器组下的金丝雀发布的简化步骤如下图所示：
实践要点
金丝雀发布一般先发 1 台，或者一个小比例，例如 2% 的服务器，主要做流量验证用，也称为金丝雀 (Canary) 测试（国内常称灰度测试）。以前旷工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来，金丝雀发布由此得名。简单的金丝雀测试一般通过手工测试验证，复杂的金丝雀测试需要比较完善的监控基础设施配合，通过监控指标反馈，观察金丝雀的健康状况，作为后续发布或回退的依据。
如果金丝测试通过，则把剩余的 V1 版本全部升级为 V2 版本。如果金丝雀测试失败，则直接回退金丝雀，发布失败。
优势
用户体验影响小，金丝雀发布过程出现问题只影响少量用户。
不足
发布自动化程度不够，发布期间可引发服务中断。
适用场合
对新版本功能或性能缺乏足够信心；
用户体验要求较高的网站业务场景；
缺乏足够的自动化发布工具研发能力。
流量模式
少量金丝雀先接受流量，再全量发布
3、滚动式发布（单服务器组）
在金丝雀发布基础上的进一步优化改进，是一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流发布方式。单服务器组下的滚动发布的简化步骤如下图所示：
实践要点
滚动式发布一般先发 1 台，或者一个小比例，如 2% 服务器，主要做流量验证用，类似金丝雀 (Canary) 测试。
滚动式发布需要比较复杂的发布工具和智能 LB，支持平滑的版本替换和流量拉入拉出。
每次发布时，先将老版本 V1 流量从 LB 上摘除，然后清除老版本，发新版本 V2，再将 LB 流量接入新版本。这样可以尽量保证用户体验不受影响。
一次滚动式发布一般由若干个发布批次组成，每批的数量一般是可以配置的（可以通过发布模板定义）。例如第一批 1 台（金丝雀），第二批 10%，第三批 50%，第四批 100%。每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程是比较缓慢的 (其中金丝雀的时间一般会比后续批次更长，比如金丝雀 10 分钟，后续间隔 2 分钟)。
回退是发布的逆过程，将新版本流量从 LB 上摘除，清除新版本，发老版本，再将 LB 流量接入老版本。和发布过程一样，回退过程一般也比较慢的。
滚动式发布国外术语通常叫 Rolling Update Deployment。
优势
用户体验影响小，体验较平滑。
不足
发布和回退时间比较缓慢；
发布工具比较复杂，LB 需要平滑的流量摘除和拉入能力。
适用场合
用户体验不能中断的网站业务场景；
有一定的复杂发布工具研发能力。
流量模式
滚动式发布，流量平滑过渡
二、双服务器组发布
1、蓝绿发布
蓝绿发布仅适用于双服务器组发布，可以认为是对蛮力发布的一种简单优化发布方式。简化过程如下图所示：
实践要点
V1 版本称为蓝组，V2 版本称为绿组，发布时通过 LB 一次性将流量从蓝组直接切换到绿组，不经过金丝雀和滚动发布，蓝绿发布由此得名。
出现问题回退也很直接，通过 LB 直接将流量切回蓝组。
发布初步成功后，蓝组机器一般不直接回收，而是留一个待观察期，视具体情况观察期的时间可长可短，观察期过后确认发布无问题，则可以回收蓝组机器。
优势
升级切换和回退速度非常快。
不足
切换是全量的，如果 V2 版本有问题，则对用户体验有直接影响；
需要两倍机器资源。
适用场合
对用户体验有一定容忍度的场景；
机器资源有富余或者可以按需分配（AWS 云，或自建容器云）；
暂不具备复杂滚动发布工具研发能力。
流量模式
蓝绿发布一次完成流程切换
2、金丝雀发布（双服务器组）
对蓝绿部署的一种简单优化，发布时先从绿组拉入 1 台金丝雀，待金丝雀验证通过再发全量。对比蓝绿发布，该发布方式的优势是有一个生产流量的金丝雀验证过程，可以减轻 V2 可能有问题的风险和影响面。简化发布过程如下图所示：
3、滚动式发布（双服务器组）
滚动式发布是对上面的蓝绿和金丝雀发布的进一步优化，按批次增量滚动发布，提供更平滑的用户体验。
实践要点
发布前先申请一批新服务器，数量一般和 V1 版本相同，将 V2 版本应用发布到新服务器上。例如如果在 AWS 云上，则可以直接调用 API 申请一批新 VM，如果用容器云 Kubernetes，则可以直接启动一批新容器（使用 V2 版本容器镜像）。
一般会先通过 LB 拉入 1 台 V2 版本的机器，这台机器也相当于金丝雀，用于流量验证。
逐步按批次完成发布，每批只需要通过 LB 拉入 V2 版本，再拉出对应数量的 V1 版本。批次之间留有观察间隔，通过手工或监控反馈确保没有问题再继续发布。
发布有问题回退很快，直接通过 LB 将流量切回 V1 即可。
完成发布后，一般 V1 版本要保留观察以备万一，比如留 1 天，1 天后没有问题则回收 V1 机器资源。
优势
用户体验影响小；
升级切换和回退（rollback）速度比单服务器组滚动发布要快，LB 切流量即可。
不足
需要两倍机器资源；
发布工具比较复杂，LB 需要流量切换能力。
适用场合
用户体验不能中断的网站业务场景；
机器资源有富余或者可以按需分配（AWS 云，或自建容器云）；
有一定的发布工具研发能力。
流量模式
滚动式发布，流量平滑过渡
三、结论和建议
下面是对发布策略的一些选型建议，供不同阶段公司参考：
蛮力发布一般是不建议采用的，除非是开发测试环境，用户体验不敏感的非关键应用，或者是创业期什么都缺时候的无奈之举。
如果暂时还不具备研发较复杂的滚动发布工具和配套智能 LB，则功能开关是一种不错的轻量级发布技术，投入相对较小的成本，可以让研发人员灵活定制发布逻辑。
金丝雀发布通过少量新版本服务器接收生产流量的方式去验证新版本，可以显著降低风险。金丝雀发布适用于大部分场景，一般成长型公司就可以采用。
对于达到一定业务体量的公司，考虑到用户体验对业务的关键性，则需要投入研发资源开发支持滚动式发布的工具和配套的智能 LB，实现自动化和零停机的发布。滚动式发布一般和金丝雀发布配合，先发一台金丝雀去验证流量，再按批次增量发布。
随着轻量级虚拟化（例如容器）的普及，双服务器组发布方式具有更快的发布和回退速度，是值得投入的高级发布技术。蓝绿部署仅适用于双服务器组，滚动式发布既可以在单服务器组上实现，也可以在双服务器组上实现。
对于涉及关键核心业务的新功能上线，采用 A/B 测试，可以显著降低发布风险，A/B 测试是唯一一种支持针对特定用户组进行生产测试的高级发布技术。当然 A/B 测试的投入不低，建议有一定研发能力的组织采用。
对于关键核心业务的迁移重构，为确保万无一失，最后的一个大招是影子测试，影子测试对生产流量和用户完全无影响。当然这个大招的投入成本和门槛都高，建议有足够业务体量和研发能力的组织投入。
上述的各种发布策略并不是非此即彼的，一个公司常常会综合采用多种发布技术作为互补，实现灵活的发布能力。例如主流的发布手段是金丝雀 + 滚动式发布，某些业务线可能根据业务场景需要采用功能开关发布，还有一些业务线则可能采用高级的 A/B 测试发布手段。
三种方式均可以做到平滑式升级，在升级过程中服务仍然保持服务的连续性，升级对外界是无感知的。
那生产上选择哪种部署方法最合适呢？
这取决于哪种方法最适合你的业务和技术需求。
1、如果你们运维自动化能力储备不够，肯定是越简单越好，建议蓝绿发布。
2、如果业务对用户依赖很强，建议灰度发布。
3、如果是K8S平台，滚动更新是现成的方案，建议先直接使用。
蓝绿发布：两套环境交替升级，旧版本保留一定时间便于回滚。
灰度发布：根据比例将老版本升级，例如80%用户访问是老版本，20%用户访问是新版本。
滚动发布：按批次停止老版本实例，启动新版本实例。
扫一扫
1005
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
