一、滚动发布
在滚动部署中，应用的新版本逐步替换旧版本。实际的部署发生在一段时间内。在此期间，新旧版本会共存，而不会影响功能和用户体验。这个过程可以更轻易的回滚和旧组件不兼容的任何新组件。
每次只升级一个或多个服务，通过观察无问题，不断执行这个过程，直到集群中的全部旧版本升级到新版本。属有损发布。
但是滚动升级有一个问题，在开始滚动升级后，流量会直接流向已经启动起来的新版本，但是这个时候，新版本是不一定可用的，比如需要进一步的测试才能确认。那么在滚动升级期间，整个系统就处于非常不稳定的状态，如果发现了问题，也比较难以确定是新版本还是老版本造成的问题。
为了解决这个问题，我们需要为滚动升级实现流量控制能力。
优点：
- 成本较低，只需要部署一套环境。出现问题影响范围，只限于发生在若干正在滚动发布的服务上。
缺点：
- 停止旧版本的过程中，无法精确计算旧版本是否已经完成它正在执行的工作，需要靠业务自身去判断。就版本不保留，一旦全部升级完毕后才发现问题，无法快速回滚，必须重新降级部署，发布和回滚需要较长的时间周期。
二、蓝绿发布
需要对服务的新版本进行冗余部署，一般新版本的机器规格和数量与旧版本保持一致，相当于该服务有两套完全相同的部署环境，只不过此时只有旧版本在对外提供服务，新版本作为热备。当服务进行版本升级时，我们只需要将流量全部切换到新版本即可，旧版本作为热备。由于冗余部署的缘故，所以不必担心新版本资源不够。如果新版本上线后出现严重的程序BUG，那么我们只需将流量全部切回旧版本，大大缩短故障恢复时间。
优点：
- 故障恢复时间短。新旧系统同时在线，只需控制网关流量导向，即可回滚。
缺点：
- 资源利用率不高。需要双倍的硬件资源
有了灰度发布之后，为什么还需要蓝绿
主要有如下几点考虑：
- 应用在生产环境全量发布后，发现故障时回滚时间慢。当线上核心应用存在几十上百的服务实例时，应用实例分批滚动回滚，部分业务应用启动时间需要几分钟，导致整个回滚过程的时间可能超过十分钟，甚至几十分钟。
- 灰度发布期间能发现的问题有限。如数据库慢查问题、死锁问题等，10%流量很难发现，可能只会在100%流量中才容易暴露。
- 灰度发布成功后，仍然需要进行全量发布，在此过程中仍有较多不确定性，如因一些未预料的异常导致发布失败等。
对于上面几个问题，使用蓝绿发布系统都可以较好地解决：
- 蓝绿发布期间，流量全部切至新集群时，原稳定集群继续保持在线，若新集群有问题，可通过流量控制秒级切回至原稳定集群，没有应用启动以及其他等待时间。
- 蓝绿发布期间，新集群规模与原稳定集群规模一致，即使是瞬时大流量也没有问题。
- 蓝绿发布期间，新集群承载全站流量，容易验证各种场景，如数据库死锁等并发问题。
- 蓝绿发布新集群验证完成后，已经处于正常服务状态，不会再引入不确定性的变更操作。
三、灰度发布（金丝雀发布）
灰度发布，也叫金丝雀发布。即将少量请求引流到新版本，验证新版本符合预期后，逐步调整流量比例权重，使得流量慢慢从老版本迁移到新版本，期间可以根据设置的流量比例，对新版本服务进行扩容，同时对老版本服务进行缩容。
滚动更新也是有缺点的：滚动更新短时间就直接结束了，不能直接控制新老版本的存活时间；而金丝雀发布却可以实现这样的功能。
优点：
1、按照比例流量无差别地导向新版本，新版本故障影响范围小。
2、发布期间逐步对新版本进行扩容，同时对老版本进行缩容，资源利用率高。
缺点：
1、流量无差别的导向新版本，可能会影响重要用户的体验。
2、发布周期长。
“ 为什么叫金丝雀发布呢，是因为金丝雀对矿场中的毒气比较敏感，所以在矿场开工前工人们会放一只金丝雀进去，以验证矿场是否存在毒气，这便是金丝雀发布名称的由来。”
灰度发布（金丝雀发布）流程
步骤一：将流量从待部署节点移出，更新该节点服务到待发布状态，将该节点称为金丝雀节点；
步骤二：根据不同策略，将流量引入金丝雀节点。策略可以根据情况指定，比如随机样本策略（随机引入）、狗粮策略（就是内部用户或员工先尝鲜）、分区策略（不同区域用户使用不同版本）、用户特征策略（这种比较复杂，需要根据用户个人资料和特征进行分流，类似于千人千面）；
步骤三：金丝雀节点验证通过后，选取更多的节点称为金丝雀节点，重复步骤一和步骤二，直到所有节点全部更新
金丝雀部署和蓝绿有点像，但是它更加规避风险。你可以阶段性的进行，而不用一次性从蓝色版本切换到绿色版本。
采用金丝雀部署，你可以在生产环境的基础设施中小范围的部署新的应用代码。一旦应用签署发布，只有少数用户被路由到它。最大限度的降低影响。如果没有错误发生，新版本可以逐渐推广到整个基础设施。
四、三种策略区别
滚动发布：每次按一定比例将旧版本替换为新版本，直到全部替换
蓝绿发布：启动新版本后，新旧版本同时在线，将流量从旧版本导向新版本即可
灰度发布：每次按一定比例将旧版本替换为新版本，并根据策略将部分流量引入新版本，待测试无误后，继续升级其余的旧版本
| 滚动发布 | 蓝绿发布 | 灰度发布 | |
|---|---|---|---|
| 成本 | 低 | 高（双倍资源） | 低 |
| 发布周期 | 短 | 短 | 长（看测试时间） |
| 回滚时间 | 长 | 短 | 短 |
| 故障影响范围 | 大 | 大 | 小（测试通过后上线） |
蓝绿发布：操作简单，硬件数量翻倍，以硬件换取操作。SLB进行切换几乎不停机，需考虑新旧环境切换对业务的影响。
灰度发布：硬件数量在原数量+1，此方式实现不停机发布，并且通过分流实现新旧并行，出问题后也可区分出新旧环境。
滚动发布：硬件数量在原数量+1，此方式实现不停机发布，并没有灰度发布明确的分流，出问题后不能快速区分出新旧环境，滚动发布主要体现出自动的发布策略依赖自动发布工具。如k8s就是现成的支持。滚动发布对于达到一定业务体量的公司，考虑到用户体验对业务的关键性，则需要投入研发资源开发支持滚动式发布的工具和配套的智能 LB，实现自动化和零停机的发布。
滚动与灰度：滚动式发布一般和金丝雀发布配合，先发一台金丝雀去验证流量，再按批次增量发布。两者主要区别在于灰度强调是部分节点给指定用户体验没问题后再扩大发布，而滚动强调的是自动节点的更换，相对有一定风险两都结合即减少人工工作量风险也降低。
五、A/B测试
A/B测试和蓝绿发布、滚动发布以及金丝雀发布，完全是两回事。
蓝绿发布、滚动发布和金丝雀是发布策略，目标是确保新上线的系统稳定，关注的是新系统的BUG、隐患。
A/B测试是效果测试，同一时间有多个版本的服务对外服务，这些服务都是经过足够测试，达到了[上线标准的服务，有差异但是没有新旧之分（它们[上线时可能采用了蓝绿部署的方式）。
A/B测试关注的是不同版本的服务的实际效果，譬如说转化率、订单情况等。
A/B测试时，线上同时运行多个版本的服务，这些服务通常会有一些体验上的差异，譬如说页面样式、颜色、操作流程不同。相关人员通过分析各个版本服务的实际效果，选出效果最好的版本。
