代码发布方式

直接发布

使用拷贝或者直接使用FTP方式进行发布代码，早期使用此种发布方式
优点: 成本较低，发布速度快，简单粗暴
缺点: 出现问题直接影响用户，回退代码较慢
适用场景:
1.开发测试场景
2.不影响用户的业务
3.初创型公司，流量较少，可以选择流量低谷期发布代码

金丝雀发布

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

优点: 用户体验影响小，出现问题只对少数用户有影响
缺点: 自动化程度不够，发布期间可能引发服务的中断

适用场合:
1.对新代码缺乏自信，在判断测试过程中的项目
2.用户体验要求较高的网站业务
3.缺乏足够自动化发布的公司

滚动式发布

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

滚动式发布一般先发 1 台，或者一个小比例，如 2% 服务器，主要做流量验证用，类似金丝雀 (Canary) 测试。
滚动式发布需要比较复杂的发布工具和智能 LB，支持平滑的版本替换和流量拉入拉出。
每次发布时，先将老版本 V1 流量从 LB 上摘除，然后清除老版本，发新版本 V2，再将 LB 流量接入新版本。这样可以尽量保证用户体验不受影响。
一次滚动式发布一般由若干个发布批次组成，每批的数量一般是可以配置的（可以通过发布模板定义）。例如第一批 1 台（金丝雀），第二批 10%，第三批 50%，第四批 100%。每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程是比较缓慢的 (其中金丝雀的时间一般会比后续批次更长，比如金丝雀 10 分钟，后续间隔 2 分钟)。
回退是发布的逆过程，将新版本流量从 LB 上摘除，清除新版本，发老版本，再将 LB 流量接入老版本。和发布过程一样，回退过程一般也比较慢的。
滚动式发布国外术语通常叫 Rolling Update Deployment。
优点: 用户体验影响小
缺点: 发布和回滚时间比较缓慢，发布工具比较复杂，负载需要平滑的流量摘除和拉入能力
使用场景:
1.用户体验不能中断的业务
2.有一定复杂发布工具的研发能力

双服务器组发布

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

蓝绿发布

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

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

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

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

金丝雀发布 双组服务器

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

滚动式发布 双组服务器

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

1. 发布前先申请一批新服务器，数量一般和 V1 版本相同，将 V2 版本应用发布到新服务器上。例如如果在 AWS 云上，则可以直接调用 API 申请一批新 VM，如果用容器云 Kubernetes，则可以直接启动一批新容器（使用 V2 版本容器镜像）。
2. 一般会先通过 LB 拉入 1 台 V2 版本的机器，这台机器也相当于金丝雀，用于流量验证。
3. 逐步按批次完成发布，每批只需要通过 LB 拉入 V2 版本，再拉出对应数量的 V1 版本。批次之间留有观察间隔，通过手工或监控反馈确保没有问题再继续发布。
4. 发布有问题回退很快，直接通过 LB 将流量切回 V1 即可。
5. 完成发布后，一般 V1 版本要保留观察以备万一，比如留 1 天，1 天后没有问题则回收 V1 机器资源。

优点: 用户体验影响小，升级切换回退速度比单服务器组滚动发布速度快，LB切流量即可
缺点: 成本较高，需要两倍机器资源，发布工具比较复杂，LB需要流量切换能力

使用场景：
1.用户体验不能中断的网站业务场景
2.机器资源有富余或者可以按需分配（AWS 云，或自建容器云）
3.有一定的发布工具研发能力

其他发布方式:

1.功能开关
2.A/B测试
3.影子测试
略…