项目发布

项目发布

线上的项目最容易出现问题的时候就是发布的过程中。如果将某变化较大的版本一次全部线上发布给用户，遇到生产事故对用户的影响会非常大，甚至有时需要紧急回滚到前一版本。因此在发布的时候可以采取一些措施来防止问题的扩散。

我们常见的几种发布方案有：蓝绿发布、滚动发布、灰度发布

蓝绿发布

部署的时候就部署两套系统：一套是正在提供服务系统(也就是上面说的旧版)，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的，并且正在运行的系统，只是系统版本和对外服务情况不同。正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。

部署两套的主要目的就是为了在蓝系统运行出现问题的时候可以迅速切换流量为绿系统，恢复服务提供。

示意图

蓝色的主要作用是用来做发布前测试，测试过程中发现任何问题，可以直接在蓝色系统上修改，不干扰用户正在使用的系统。

蓝色系统经过反复的测试、修改、验证，确定达到上线标准之后，直接将用户切换到蓝色系统, 切换后的一段时间内，依旧是蓝绿两套系统并存，但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统（新系统）工作状态，如果出现问题，直接切换回绿色系统。

当确信对外提供服务的蓝色系统工作正常，不对外提供服务的绿色系统已经不再需要的时候，蓝色系统正式成为对外提供服务系统，成为新的绿色系统。原先的绿色系统可以销毁，将资源释放出来，用于[部署下一个蓝色系统。

蓝绿发布的优点在于：发布时间短，并且如果新的版本出现问题能够随时切换为老版本。

蓝绿发布的缺点在于：由于其发布机制，需要额外一倍的硬件资源，成本提高，并且要求两个版本应该避免耦合，原因在于该发布方式相当于需要使用常规运行时的两倍的资源，比如数据库。有可能出现数据库连接不够的情况。

滚动发布

从旧的服务中提出一个或多个节点停止服务，进行跟新（为保证负载一般会让另外一批部署好新版本的节点代替旧版本提供服务），跟新后的节点重新投入使用知道原版本的全部被换成新版本。

示意图

相比于蓝绿发布更加节省资源，但是该方式新版本与旧版本柔和在一起没有明确的可用版本，出现问题的时候回滚困难，（其实回滚就又相当于一次滚动发布，新版本回退到老版本）而蓝绿发布就很明显，一旦新版本出现问题能都及时回到旧版本，

灰度发布

启动新的版本，一点一点的将流量从老版本切换到新版本，期间进行A/B测试（让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。）然后再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比。当确认新版本运行良好后，再逐步将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。

示意图

A/B测试时，线上同时运行多个版本的服务，这些服务通常会有一些体验上的差异，譬如说页面样式、颜色、操作流程不同。相关人员通过分析各个版本服务的实际效果，选出效果最好的版本。

A/B测试关注的是不同版本的服务的实际效果，譬如说转化率等，举个例子：新的版本加了一个功能，希望这个功能可以为某个业务的数据带来提升。

总结

每一种发布方案都有着自己的优点和劣势，在实际生产环境中采用那种发布方式需要根据具体情况具体分析。