滚动更新、蓝绿部署与灰度发布：概念、原理及区别详解

滚动更新、蓝绿部署与灰度发布：概念、原理及区别详解

引用

CSDN

1.

https://blog.csdn.net/nvd11/article/details/139889966

在现代软件开发和运维中，滚动更新、蓝绿部署和灰度发布是三种常见的应用发布策略。它们各有特点和适用场景，正确理解这些策略的区别对于实现高效、可靠的软件发布至关重要。

滚动更新（Rolling Update）

滚动更新主要用于多实例的服务。当一个服务有多个实例时，更新并不是一次性完成所有实例，而是按照一定的顺序逐步进行。这是Kubernetes（k8s）提供的一项重要特性。

解决的问题：

• 在整个更新过程中，始终保持至少一个实例在线，确保用户无感知，实现高可用和零停机时间。

未解决的问题：

• 如果新版本存在严重bug，在滚动更新期间没有充分验证，可能导致整个更新完成后出现风险。

蓝绿部署（Blue-Green Deployment）

蓝绿部署通常应用于传统的本地部署服务，但不一定局限于多实例服务。

定义：

这是一种在生产环境中同时部署并运行两个完全独立的应用程序版本的策略。在蓝绿部署中，蓝色环境代表当前的稳定版本，而绿色环境代表新版本。新版本的应用程序在绿色环境中进行测试和验证，然后通过切换路由或负载均衡器将流量从蓝色环境切换到绿色环境。一旦验证通过，可以将流量完全切换到绿色环境，并最终关闭蓝色环境。

部署流程：

1. 首先将新版本的服务部署到备用服务器（绿色环境）。
2. 在备用服务器上进行必要的验证。
3. 一旦验证通过，将正在运行的网关/负载均衡器切换到备用服务器，此时备用服务器成为正式生产环境（绿色环境）。
4. 最后关闭旧生产环境的实例（蓝色环境）。

解决的问题：

• 添加了验证步骤，规避了一些操作风险。对大部分用户来说更新是无感知的。

未解决的问题：

• 在有限时间内，IT人员的验证范围有限。
• 需要额外一套基础设施，成本较高。

灰度发布（Gray Release）/金丝雀发布（Canary Release）

灰度发布也被称为金丝雀发布，是一种逐步将新版本应用程序引入生产环境的策略。

定义：

在灰度发布中，新版本的应用程序会逐渐在一小部分用户或流量中进行测试和验证，然后逐步扩大范围，直到完全替换旧版本。它允许在生产环境中逐步验证新版本，并及时回滚以避免大规模影响。

部署流程：

假设某个服务在生产环境中运行着4个实例：

1. 首先将新版本发布到某1个实例上，这时其他3个实例还是旧版本。
2. 在这个阶段停留一段时间，此时在生产上有3/4的用户还是用着旧版本，没有受到影响，只有1/4的用户使用新版本进行验证。
3. 如果验证通过，再逐步发布到其他实例上。

解决的问题：

• 让部分用户参与验证，将生产事故的影响降到最低。

未解决的问题：

• 整个发布周期相对较长。