把老版的应用实例完全停止，再发布新的版本。
这种发布模式主要为了解决新老版本互不兼容、无法共存的问题，
- 缺点：是一段时间内服务完全不可用。
- 优点：资源消耗小，升级速度快
- 逐渐将流量从老版本切换到新版本上。如果观察一段时间后没有发现问题，就进一步扩大新版本流量，同时减少老版本上流量。
A/B 测试 - 同时上线两个或多个版本，收集用户对这些版本的反馈，分析评估出最好版本正式采用。
金丝雀发布一般先发 1 台，或者一个小比例，例如 2% 的服务器，主要做流量验证用，也称为金丝雀 (Canary) 测试（国内常称灰度测试）。以前旷工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来，金丝雀发布由此得名。简单的金丝雀测试一般通过手工测试验证，复杂的金丝雀测试需要比较完善的监控基础设施配合，通过监控指标反馈，观察金丝雀的健康状况，作为后续发布或回退的依据。
如果金丝测试通过，则把剩余的 V1 版本全部升级为 V2 版本。如果金丝雀测试失败，则直接回退金丝雀，发布失败。
流量模式: 少量金丝雀先接受流量，再全量发布
优势：
用户体验影响小，金丝雀发布过程出现问题只影响少量用户
不足：
发布自动化程度不够，发布期间可引发服务中断
适用场合：
对新版本功能或性能缺乏足够信心
用户体验要求较高的网站业务场景
缺乏足够的自动化发布工具研发能力
分批次逐步替换应用实例。
这种发布模式不会中断服务，同时也不会消耗过多额外的资源， 但由于新老版本实例同时在线，可能导致来自相同客户端的请求在新老版中切换而产生兼容性问题。
一次滚动式发布一般由若干个发布批次组成，每批的数量一般是可以配置的（可以通过发布模板定义）。例如第一批 1 台（金丝雀），第二批 10%，第三批 50%，第四批 100%。每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程是比较缓慢的 (其中金丝雀的时间一般会比后续批次更长，比如金丝雀 10 分钟，后续间隔 2 分钟)。
回退是发布的逆过程，将新版本流量从 LB 上摘除，清除新版本，发老版本，再将 LB 流量接入老版本。和发布过程一样，回退过程一般也比较慢的。
滚动式发布国外术语通常叫 Rolling Update Deployment。
两者主要区别在于灰度强调是部分节点给指定用户体验没问题后再扩大发布，而滚动强调的是自动节点的更换，相对有一定风险两都结合即减少人工工作量风险也降低。
优势：
用户体验影响小，体验较平滑
不足：
发布和回退时间比较缓慢
发布工具比较复杂，LB 需要平滑的流量摘除和拉入能力
适用场合：
用户体验不能中断的网站业务场景
有一定的复杂发布工具研发能力；
在线上同时部署相同数量的新老版本应用实例。待新版本测试通过后，将流量一次性地切到新的服务实例上来。
这种发布模式解决了停机发布中存在的服务完全不可用问题， 但会造成比较大的资源消耗。
优势：
升级切换和回退速度非常快
不足：
切换是全量的，如果 V2 版本有问题，则对用户体验有直接影响；
需要两倍机器资源；
适用场合：
对用户体验有一定容忍度的场景
机器资源有富余或者可以按需分配（AWS 云，或自建容器云）
暂不具备复杂滚动发布工具研发能力；
金丝雀发布通过少量新版本服务器接收生产流量的方式去验证新版本，可以显著降低风险。金丝雀发布适用于大部分场景，一般成长型公司就可以采用。
对于达到一定业务体量的公司，考虑到用户体验对业务的关键性，则需要投入研发资源开发支持滚动式发布的工具和配套的智能 LB，实现自动化和零停机的发布。滚动式发布一般和金丝雀发布配合，先发一台金丝雀去验证流量，再按批次增量发布。
随着轻量级虚拟化（例如容器）的普及，双服务器组发布方式具有更快的发布和回退速度，是值得投入的高级发布技术。蓝绿部署仅适用于双服务器组，滚动式发布既可以在单服务器组上实现，也可以在双服务器组上实现。
对于涉及关键核心业务的新功能上线，采用 A/B 测试，可以显著降低发布风险，A/B 测试是唯一一种支持针对特定用户组进行生产测试的高级发布技术。当然 A/B 测试的投入不低，建议有一定研发能力的组织采用。
对于关键核心业务的迁移重构，为确保万无一失，最后的一个大招是影子测试，影子测试对生产流量和用户完全无影响。当然这个大招的投入成本和门槛都高，建议有足够业务体量和研发能力的组织投入。
参考链接：
upstream redapi {
server 172.19.33.90:8000 weight=99 max_fails=0;
server 172.19.33.91:8000 weight=1 max_fails=0;
keepalive 8;
}