前言
待过的公司有每次版本发布都要加班到很晚，也有大白天就发步的。对他们的发布方式很好奇，所以查了查资料。这里是我了解的蓝绿发布、滚动发布、灰度发布等部署方案对比与总结
蓝绿部署
1、定义
蓝绿部署是不停老版本，同时部署新版本，然后进行测试，确认OK，将流量切到新版本
2、特点
- 如果出问题，影响范围较大；
- 发布策略简单；
- 用户无感知，平滑过渡；
- 升级/回滚速度快。
3、缺点
- 需要准备正常业务使用资源的两倍以上服务器，防止升级期间单组无法承载业务突发；
- 短时间内浪费一定资源成本；
- 基础设施无改动，增大升级稳定性。
4、注意事项
当你切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。如果你的数据库后端无法处理，会是一个比较麻烦的问题；
- 可能会出现需要同时处理“微服务架构应用”和“传统架构应用”的情况，如果在蓝绿部署中协调不好这两者，还是有可能会导致服务停止。
- 需要提前考虑数据库与应用部署同步迁移 /回滚的问题。
- 蓝绿部署需要有基础设施支持。
- 在非隔离基础架构（ VM 、 Docker 等）上执行蓝绿部署，蓝色环境和绿色环境有被摧毁的风险。
滚动发布
1、定义
滚动发布：一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。
2、特点
- 用户无感知，平滑过渡；
- 节约资源。
3、部署过程：
- 先升级1个副本，主要做部署验证；
- 每次升级副本，自动从LB上摘掉，升级成功后自动加入集群；
- 事先需要有自动更新策略，分为若干次，每次数量/百分比可配置；
- 回滚是发布的逆过程，先从LB摘掉新版本，再升级老版本，这个过程一般时间比较长；
- 自动化要求高。
4、注意事项：
没有一个确定OK的环境。使用蓝绿部署，我们能够清晰地知道老版本是OK的，而使用滚动发布，我们无法确定。
修改了现有的环境。
如果需要回滚，很困难。举个例子，在某一次发布中，我们需要更新100个实例，每次更新10个实例，每次部署需要5分钟。当滚动发布到第80个实例时，发现了问题，需要回滚，这个回滚却是一个痛苦，并且漫长的过程。
有的时候，我们还可能对系统进行动态伸缩，如果部署期间，系统自动扩容/缩容了，我们还需判断到底哪个节点使用的是哪个代码。尽管有一些自动化的运维工具，但是依然令人心惊胆战。
因为是逐步更新，那么我们在上线代码的时候，就会短暂出现新老版本不一致的情况，如果对上线要求较高的场景，那么就需要考虑如何做好兼容的问题。
灰度发布/金丝雀部署
1、定义
灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度，而我们平常所说的金丝雀部署也就是灰度发布的一种方式。
2、灰度发布／金丝雀发布由以下几个步骤组成：
- 准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。
- 从负载均衡列表中移除掉“金丝雀”服务器。
- 升级“金丝雀”应用（排掉原有流量并进行部署）。
- 对应用进行自动化测试。
- 将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。
- 如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）
除此之外灰度发布还可以设置路由权重，动态调整不同的权重来进行新老版本的验证。
3、总结
在新版本应用发布时，为了服务器不停机升级，使用灰度发布策略，在灰度发布开始时，使用HTTP Header 匹配指定测试人员的流量到新版本上，然后当新版本内部测试通过后，可以再按百分比，将用户流量一点一点导入到新版本中，比如先导入10%观察一下运行情况，然后再导入20%，如此累加，直到将流量全部导入到新版本上，最后完成升级，如果期间发现问题，就立即取消升级，将流量切回到老版本。
