项目迭代过程中，上线是不可避免的。上线对应的是部署或者重新部署；部署对应修改；修改意味着风险。目前部署和发布的技术有很多。这里总结一下常见的。
上面难免有点抽象。举个例子，如果你是微博项目的负责人，新版本相比旧版本有很大的变化。这个设计包括服务架构、前端UI等等，经过测试，功能没有任何障碍，那么这个时候如何让用户切换到新版本呢？
显然，第一个发布的应用程序不存在这个问题。这种如何发布的思考只会出现在后续的版本迭代中。
蓝绿部署的系统有两个：一个是服务系统（也就是上面提到的旧版本），标记为“绿色”；另一种是准备发布的系统，标记为“蓝色”。两个系统都是功能齐全、正在运行的系统，但系统版本和对外服务不同。正在对外提供服务的旧系统是绿色系统，新部署的系统是蓝色系统。
蓝色系统不对外提供服务，它是用来做什么的？
用于预发布测试。测试过程中发现的任何问题都可以直接在蓝色系统上进行修改，不会干扰用户正在使用的系统。
经过反复测试、修改、验证，确定符合上线标准后，蓝色系统将直接将用户切换到蓝色系统。切换后的一段时间内，蓝绿两个系统仍然共存，但用户访问的是蓝色系统。在此期间，观察蓝色系统（新系统）的工作状态。如果出现问题，直接切换回绿色系统。
当确认对外提供服务的蓝色系统工作正常，不再需要不对外提供服务的绿色系统时，蓝色系统正式成为对外提供服务的系统并成为一个新的绿色系统。原来的绿色系统可以被破坏，释放资源用于【部署下一个蓝色系统。
蓝绿部署的目的是为了减少释放时的中断时间，能够快速撤回释放。
只有两个系统不耦合才能100%保证不会出现干扰
蓝绿的部署只是线上策略之一。它并不是一种可以应对所有情况的灵丹妙药。蓝绿的部署能够简单快速地实施的前提是目标体系具有很强的凝聚力。如果目标系统比较复杂，那么如何切换，是否需要两个系统的数据，如何同步，就需要仔细考虑。
切换到蓝色环境时，未完成的业务和新业务需要妥善处理。如果你的数据库后端无法处理，那将是一个麻烦的问题。
可能存在需要同时处理“微服务架构应用”和“传统架构应用”的情况。如果蓝绿[部署期间两者协调不好，仍有可能导致服务停止。
需要提前考虑数据库和应用部署同步迁移/回滚的问题。
蓝绿的部署需要基础设施的支持。
在非隔离基础设施（虚拟机、Docker等）上执行蓝绿[部署]，蓝绿环境面临被破坏的风险。
通常，一台或多台服务器会停止服务、更新并重新投入使用。重复该循环，直到集群中的所有实例都更新到新版本。
发布流程：
与蓝绿的发布需要一整套机器不同，滚动发布只需要一台机器（这是为了理解，实际上可能是多台）。我们只需要在这台机器上部署一些功能，然后更换运行的机器即可。
如上图所示，更新的功能部署在Server1上，然后Server1替换正在运行的Server。被替换的物理机可以继续部署新版本的Server2，然后替换正在工作的Server2，以此类推。 ，直到更换所有服务器。至此，服务更新完成。
这种部署方式比蓝绿的部署更节省资源——不需要运行两个集群和两倍的实例数量。我们可以部分部署，比如一次只取出集群的20%进行升级。
回滚困难
滚动发布没有万无一失的环境。对于 蓝绿[部署]，我们清楚地知道旧版本是可行的，而对于滚动版本，我们无法确定。
修改了现有环境。
回滚困难。例如，在某个版本中，我们需要更新100个实例，每次更新10个实例，每次部署需要5分钟。当滚动发布到第80个实例时，发现问题，需要回滚。这个回滚是一个痛苦而漫长的过程。
有时，我们也可能会动态扩展系统。如果系统在部署过程中自动扩容/缩容，我们仍然需要确定哪个节点使用哪个代码。虽然现在有一些自动化运维工具，但还是很吓人。
因为是逐步更新，所以我们在上线代码的时候，会出现新旧版本暂时不一致的情况。如果有启动要求较高的场景，那么我们就需要考虑如何保证兼容性。
灰度发布，也叫金丝雀发布。指一种能够在黑白之间平滑过渡的出版方式。 AB测试是一种灰度发布方式，让部分用户继续使用A，部分用户开始使用B。如果用户对B没有异议，则逐步扩大范围，将所有用户迁移到B。
灰度发布可以保证整个系统的稳定性。可以在初始灰度阶段发现问题并进行调整，以确保其影响。我们通常所说的金丝雀部署是灰度发布的一种。方式。
具体到服务器，实际操作中可以做更多的控制。例如，为最初更新的10台服务器设置较低的权重，控制发送到这10台服务器的请求数量，然后逐渐增加权重。增加请求数量。一种平滑过渡的思想，这种控制称为“流量分段”。
