部署的几种方式

由于之前只接触了单服务应用，并且是自己做的，所以部署的方式也比较随意，想要部署的话直接打一个war包部署上去就好了。接触过分布式的多服务后，事情就没有这么简单了，如果还是采用之前的方式，会存在两个问题，一方面，在新版本升级过程中，服务是暂时中断的，另一方面，如果新版本有BUG，升级失败，回滚起来也非常麻烦，容易造成更长时间的服务不可用。

下面是对集中常见部署方式的了解：

蓝绿部署

image

蓝绿部署是我可以不看其他推荐，自己想到了部署方式。直接运行两个版本的应用，并不停止旧版本的运行，而是等新版本运行正常后将流量切到新版本，但是缺点也很明显，我需要双倍的资源，平时10台服务器就可以解决的问题现在需要20台了。

滚动发布

image

滚动发布能够解决掉蓝绿部署时对硬件要求增倍的问题。在升级的时候不是把所有的服务都启动，而是启动一台新的服务就替换掉对应的老服务，这样正常需要10台服务器，现在只需要11台就好了，缺点也很明显，就是太不稳定了，出了问题不容易追溯。

灰度发布

灰度发布也叫金丝雀发布，起源是，矿井工人发现，金丝雀对瓦斯气体很敏感，矿工会在下井之前，先放一只金丝雀到井中，如果金丝雀不叫了，就代表瓦斯浓度高。

image

在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版本进行线上测试，启动的这个新版本应用，就是我们的金丝雀。如果没有问题，那么可以将少量的用户流量导入到新版本上，然后再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比，就是所谓的A/B测试。

当确认新版本运行良好后，再逐步将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。

如果在灰度发布过程中（灰度期）发现了新版本有问题，就应该立即将流量切回老版本上，这样，就会将负面影响控制在最小范围内。