直接发布

使用拷贝、rsync无差异同步或者使用FTP方式进行代码发布，在早期使用此种发布方式，这种发布就是把所有的旧版本代码直接替换成了新版本代码

优点：成本低，发布速度快，简单粗暴

缺点：出现问题直接影响用户，回退代码较慢

适用场景

1、开发测试场景

2、不影响用户的业务

3、初创型公司，流量较少，可以选择流量低谷期发布代码

金丝雀发布

金丝雀发布一般先发布一台，或者一个小比例，例如2%的服务器，主要做流量验证用，也称为金丝雀测试（国内常称灰度测试）

以前在矿工开矿下矿洞前，会先放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来，金丝雀发布由此得名，简单的金丝雀测试一般通过手工测试验证，复杂的金丝雀测试需要比较完善的监控基础设施设施配合，通过监控指标反馈，观察金丝雀的监控状况，作为后续发布或回退的依据。

如果金丝雀测试通过，则把剩余的v1版本全部升级为v2版本，如果金丝雀测试失败，则直接回退金丝雀的版本

优点：用户体验影响小，出现问题只对少数用户有影响

缺点：自动化程度不够，发布期间可能会引发服务的中断

适用场景

1、对新代码缺乏自信，在判断测试过程中的项目

2、用户体验要求较高的网站业务

3、缺乏足够自动化发布的公司


滚动式发布

在金丝雀发布基础上的进一步优化改进，是一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术所采用的主流发布方式。

分成发布前，发布一台或一定比例的金丝雀，发布若干台，全部发布完毕这几个阶段

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

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

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

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

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

6、滚动式发布国外术语通常叫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、有一定的发布工具研发能力

此外也有一些其他发布方式，功能开关、A/B测试、影子测试等等，就不多介绍了。