灰度发布、蓝绿部署、金丝雀都是啥？

最新推荐文章于 2024-09-13 20:52:51 发布

小盒子的技术分享

最新推荐文章于 2024-09-13 20:52:51 发布

阅读量7k

点赞数 3

文章标签：微服务 ab测试

本文链接：https://blog.csdn.net/m0_38017860/article/details/124274741

版权

本文介绍了灰度发布、蓝绿发布和金丝雀发布的概念和特点，以及它们在微服务和ab测试中的应用。通过案例展示了这些部署策略如何确保服务的稳定性和效率，包括滚动升级的问题、蓝绿发布的流量控制、金丝雀发布的风险规避，以及A/B测试的差异。文章还讨论了不同实现方案，如kubernetes、istio、spring cloud和云原生网关的使用，帮助读者理解如何在实践中实施这些部署策略。

摘要由CSDN通过智能技术生成

滚动部署

在滚动部署中，应用的新版本逐步替换旧版本。实际的部署发生在一段时间内。在此期间，新旧版本会共存，而不会影响功能和用户体验。这个过程可以更轻易的回滚和旧组件不兼容的任何新组件。

下图显示了该部署模式：旧版本显示为蓝色，新版本显示为绿色，它们部署在集群中的每一台服务器上。

应用程序套件升级是一个滚动部署的典型例子。如果原始应用部署在容器中，升级可以一次处理一个容器。修改每个容器从应用供应商的站点上下载最新的镜像。如果其中的一个应用存在兼容性问题，旧的镜像可以重新创建这个容器。在这种情况下，套件的新旧版本应用可以共存，直到每个应用都更新完毕。

但是滚动升级有一个问题，在开始滚动升级后，流量会直接流向已经启动起来的新版本，但是这个时候，新版本是不一定可用的，比如需要进一步的测试才能确认。那么在滚动升级期间，整个系统就处于非常不稳定的状态，如果发现了问题，也比较难以确定是新版本还是老版本造成的问题。

为了解决这个问题，我们需要为滚动升级实现流量控制能力。

蓝绿发布

蓝绿发布提供了一种零宕机的部署方式。不停老版本，部署新版本进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本。始终有两个版本同时在线，有问题可以快速切换。

蓝绿发布的特点：

在部署应用的过程中，应用始终在线。并且新版本上线过程中，不会修改老版本的任何内容，在部署期间老版本状态不受影响。只要老版本的资源不被删除，可以在任何时间回滚到老版本。

以下示意图可描述灰度发布的大致流程：先切分20%的流量到新版本，若表现正常，逐步增加流量占比，继续测试新版本表现。若新版本一直很稳定，那么将所有流量都切分到新版本，并下线老版本。

切分20%的流量到新版本后，新版本出现异常，则快速将流量切回老版本。

蓝绿部署要求在升级过程中，同时运行两套程序，对硬件的要求就是日常所需的二倍，比如日常运行时，需要10台服务器支撑业务，那么使用蓝绿部署，你就需要购置二十台服务器。

为什么还需要蓝绿

有了灰度发布之后，为什么还需要蓝绿发布呢？主要有如下几点考虑：

应用在生产环境全量发布后，发现故障时回滚时间慢。当线上核心应用存在几十上百的服务实例时，应用实例分批滚动回滚，部分业务应用启动时间需要几分钟，导致整个回滚过程的时间可能超过十分钟，甚至几十分钟。
灰度发布期间能发现的问题有限。如数据库慢查问题、死锁问题等，10%流量很难发现，可能只会在100%流量中才容易暴露。
灰度发布成功后，仍然需要进行全量发布，在此过程中仍有较多不确定性，如因一些未预料的异常导致发布失败等。

对于上面几个问题，使用蓝绿发布系统都可以较好地解决：