在项目迭代过程中，“上线”是不可避免的。上线对应部署，或者说重新部署；部署对应修改；修改意味着风险。目前部署发布的技术有很多，这里总结一下常用的。以上难免有些抽象。让我举一个场景的例子。补充一下，你是微博项目的负责人。现在的新版本与原来的旧版本相比有了很多变化。这个设计包括服务架构，前端UI等等，经过测试，功能都没有那么这个时候怎么让用户切换到新版本呢？很显然，第一次发布的app并不存在这个所谓的问题，这种关于如何发布的思考只会出现在后续的版本迭代中。蓝绿发布在蓝绿部署中，有两套系统：一套是正在提供服务的系统（即上面提到的旧版本），标记为“绿色”；另一个是准备发布的系统，标记为“蓝色”。两个系统都是功能完备的运行系统，只是系统版本和对外服务不同。正在提供服务的旧系统为绿色系统，新部署的系统为蓝色系统。蓝色系统不对外提供服务，用来做什么？它用于预发布测试。如果在测试过程中发现问题，可以直接在蓝色系统上修改，不会影响用户正在使用的系统。经过反复测试、修改、验证，确定蓝系符合上线标准，用户直接切换到蓝系。切换后的一段时间内，两个系统仍然共存，但用户已经在访问蓝色系统。颜色系统。在此期间观察蓝色系统（新系统）的工作状态，出现问题直接切换回绿色系统。当确信对外提供服务的蓝色系统工作正常，不再需要对外提供服务的绿色系统时，蓝色系统正式成为对外服务系统，成为新的绿色系统。可以销毁原有的绿色系统，释放资源用于下一个蓝色系统的部署。蓝绿发布的特点蓝绿部署的目的是减少发布过程中的中断时间，快速撤回发布。只有两个系统不耦合，才能100%保证不干扰蓝绿发布注意事项蓝绿部署只是线上策略之一，并不是应对所有情况的万能药。蓝绿部署能够简单快速实现的前提是目标系统的内聚性很强。如果目标系统比较复杂，如何切换，是否需要两个系统的数据，如何同步，都需要慎重考虑。当你切换到蓝色环境时，未完成的业务和新业务需要妥善处理。如果你的数据库后台处理不了，那就是个麻烦的问题；可能会出现需要同时处理“微服务架构应用”和“传统架构应用”的情况，如果不能在蓝绿部署中协调两者，仍然可能导致服务停止。需要提前考虑数据库和应用部署的同步迁移/回滚问题。蓝绿部署需要基础设施支持。在非隔离基础设施（VM、Docker等）上进行蓝绿部署，蓝环境和绿环境存在被破坏的风险。滚动发布通常会使一台或多台服务器停止服务，执行更新，然后将它们重新投入使用。如此反复，直到集群中的所有实例都更新到新版本。发布流程：相对于蓝绿发布需要整套机器，滚动发布只需要一台机器（这里是为了理解，现实中可能有多套），我们只需要在这台机器上部署一些功能即可，然后更换运行机，如上图，在Server1上部署更新的功能，然后Server1更换运行的Server，被更换的物理机可以继续部署新版本的Server2，然后更换工作的Server2，以此类推，直到更换完所有服务器，至此，服务更新完成。滚动发布特性这种部署方式比蓝绿部署更节省资源——它不需要运行两个集群和两倍数量的实例。我们可以部分部署，比如每次只取出20%的集群进行升级。回滚困难滚动发布注意事项滚动发布没有万无一失的环境。通过蓝绿部署，我们可以清楚地知道老版本是可行的，但是通过滚动发布，我们就不能确定了。修改现有环境。回滚困难。比如一个release，我们需要更新100个实例，每次更新10个实例，每次部署需要5分钟。当滚动发布到第80次时，发现问题，需要回滚，但是这个回滚是一个痛苦而漫长的过程。有时，我们也可能动态扩展系统。如果部署时系统自动扩容/缩容，我们还需要判断哪个节点使用哪个代码。虽然现在有一些自动化运维工具，但还是让人望而却步。因为是渐进式更新，所以在我们上线代码的时候，新旧版本之间会出现短暂的不一致。如果有对上线要求比较高的场景，那么就需要考虑如何做好兼容性。灰度发布灰度发布，也叫金丝雀发布。指的是一种能够在黑白之间平滑过渡的发布方式。AB测试是一种灰度发布方式，让一部分用户继续使用A，一部分用户开始使用B，如果用户对B没有异议，然后逐步扩大范围，将所有用户迁移到B。灰度发布可以保证B的稳定性整体系统。可以在初始灰度阶段发现问题并进行调整，以确保其影响。我们通常所说的金丝雀部署也是灰度发布的一种方式。推荐：基于Nginx实现灰度发布和AB测试。具体到服务器，在实际操作中可以做更多的控制，比如对前10台更新的服务器设置较低的权重，控制发送给这10台服务器的内容。请求次数，然后逐渐增加权重，增加请求次数。一个平滑过渡的想法，这种控制被称为“流量拆分”。17世纪，英国矿工发现金丝雀对煤气等气体非常敏感。即使空气中有极少量的气体，金丝雀也会停止歌唱；当气体含量超过一定限度时，虽然迟钝的人类没有察觉，但金丝雀已经中毒身亡。当时，在采矿设备相对简单的条件下，工人们每次下矿都会带上一只金丝雀，作为遇到险情紧急疏散的“瓦斯检测指标”。该过程为部署的各个阶段准备工件，包括：构建工件、测试脚本、配置文件和部署清单文件。将“金丝雀”服务器部署到服务器中进行测试。从负载平衡列表中删除“金丝雀”服务器。升级“金丝雀”应用程序（排出遗留流量并部署）。自动测试应用程序。将“金丝雀”服务器添加回负载平衡列表（连接和健康检查）。如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则回滚）A/B测试A/B测试和蓝绿发布、滚动发布、金丝雀发布是完全不同的东西。蓝绿发布、滚动发布、金丝雀发布策略。目标是保证新上线系统的稳定性，重点是新系统的BUG和隐患。A/B测试是一种效果测试。同时存在多个版本的服务。这些服务已经过足够的测试并达到了在线标准。部署方法）。A/B测试关注的是不同版本服务的实际效果，比如转化率、订单状态等。A/B测试时，多个版本的服务同时在线运行。这些服务通常在体验上存在一些差异，例如不同的页面样式、颜色和操作流程。相关人员通过分析各版本服务的实际效果，选择效果最佳的版本。作者：等不及口琴链接：cnblogs.com/Courage129/p/14498788.html
