架构设计之部署版本回滚

代码测试完成后，接下来就要进行系统的部署，在部署系统时，要考虑当代码逻辑出现错误后如何快速恢复，总结为部署版本化，小版本增量发布、大版本灰度发布、架构升级并发发布。

部署版本化每次部署时，应该将上一版本的报记录到部署系统中，在发布时应该采用全量发布，避免增量发布（只发布修改过的类和文件）。如有需要，全量版本可直接回滚，不会受到约束或限制。小版本增量发布比如修复bug，添加一些简单的业务逻辑，这些我们叫作小版本。增量发布的意思是比如我们有100台服务器，先发布1台验证，如果没有问题，则接着发布10台，最后全量发布。大版本灰度发布在页面改版，添加新的功能时需要进行灰度发布，一般情况下是两个并行跑一段时间，一些用户访问老版本，一些用户访问新版本，功能验证成功后或者新版本效果不错时，再全量发布。比如，我们可以通过类似如下带有版本号的URL来区分新版本和老版本。不同的版本其实就是不同的服务，在一套集群部署即可，出问题是要能非常快速地切换老版本。架构升级并发发布架构升级后，我们不太清楚新版本是否功能正常，因此，新版本部署集群会同时存在一段时间。然后，等所有流量迁移到新版本集群后，老版本集群就可以下线了。一般前端应用我们会采用Nginx作为接入层，通过A/B方式慢慢地将流量引入到新版本集群，比如1%->10%->50%->100%。如果新版本集群处理出现问题，那么要自己降级到老版本集群继续服务。若新版本出现大面积故障，则要将所有流量引入到老版本集群。因此，接入层要能灵活控制流量方向，示意图如下所示：