在项目迭代的过程中，不可避免需要“上线”。上线就需要部署，或者重新部署；部署就意味着有修改；有修改意味着有风险。
目前有很多部署的技术，有的简单，有的复杂，有的得停机，有的不需要停机即可完成部署。
常用的部署方案：
一、蓝绿部署
蓝绿部署是不停老版本，部署新版本然后进行测试，确认ok，将流量切换到新版本，然后老版本也升级到新版本。
1、特点
蓝绿部署无需停机，并且风向较小
2、部署过程
第一步：部署版本1的应用，所有请求流量都打到这个版本上。
第二步：部署版本2的应用，版本2的代码与版本1不同（有新功能、bug修复等）
第三步：将流量从版本1切换到版本2
第四步：如果版本2测试正常，就可以删除版本1的应用，从此正式使用版本2
3、小结：从过程不难发现，在部署的过程中，我们的应用始终在线，并且新版本上线的过程中，并没有修改老板的任何内容，在部署期间，老版本状态不受影响。这样风险很小，并且，只要老版本的资源不被删除，理论上，我们可以在任何时候回滚到老版本。
4、蓝绿发布的注意事项
当切换到蓝色环境时（新的代码），需要妥善处理未完成的业务和新的业务。如果你的数据库后端无法处理，会是一个比较麻烦的问题
· 可能会出现需要同事处理“微服务架构应用” 和 “传统架构应用”的情况
· 需要提前考虑数据库与应用同步迁移或者回滚的问题
· 蓝绿部署需要有基础设施的支持
· 考虑是否需要基础架构的隔离（VM、Docker）
二、滚动发布
1、滚动发布定义
一般是取出一个或者多个服务器停止服务，执行更新操作，并重新启动投入使用，周而复始，知道集群中所有的实例都更新成最新版本。
2、特点
· 这种部署方式相对于蓝绿部署，更加节约资源（它不需要运行两个集群，2倍的实例数）。我们可以取出部分部署，例如每次只取出20%进行升级。
· 修改了现有的环境
· 因为是逐步更新，你们我们在上线代码的时候，就会出现新老版本不一致的情况，如果对上线要求较高的场景，那么就需要考虑如何做好兼容问题
· 如果需要回滚，很困难。举个例子，在某一次发布中，我们需要更新100个实例，每次更新10个实例，每次部署需要5分钟，当滚动发布到90个实例时，发现了问题，需要回滚，这个回滚是一个漫长，痛苦的过程。
· 无法确定OK的环境，不易回滚
三、灰度发布/ 金丝雀发布
1、定义
灰度发布是指在黑与白之间，能够平滑过度的一种发布发昂是。ABtest就是一种灰度发布发昂是，让一部分用户继续使用A，一部分用户开始使用B，如果用户对B没有什么反对意见，那么就可以逐步扩大范围，把所有的用户都迁移到B上面来。灰度发布可以保证系统整体的稳定，在初试灰度的时候就可以发下安问题，调整问题以保证影响尽量小，而我们平常所说的金丝雀发布也是灰度发布的一种方式。
灰度发布／金丝雀发布由以下几个步骤组成：
准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。
从负载均衡列表中移除掉“金丝雀”服务器。
升级“金丝雀”应用（排掉原有流量并进行部署）。
对应用进行自动化测试。
将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。
如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）
除此之外灰度发布还可以设置路由权重，动态调整不同的权重来进行新老版本的验证
— 总结 —
蓝绿发布：两套环境交替升级，旧版本保留一定时间便于回滚。
灰度发布：根据比例将老版本升级，例如80%用户访问是老版本，20%用户访问是新版本。
滚动发布：按批次停止老版本实例，启动新版本实例。
如果你们运维自动化能力储备不够，肯定是越简单越好，建议蓝绿发布，如果业务对用户依赖很强，建议灰度发布。如果是K8S平台，滚动更新是现成的方案，建议先直接使用
参考： https://www.cnblogs.com/williamjie/p/9497390.html
https://www.cnblogs.com/nulige/articles/10929182.html
————————————————
版权声明：本文为CSDN博主「一丝轻风、」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u014365523/article/details/112388031