蓝绿发布,红黑发布和灰度发布的优缺点。

科学部署的意义:

尽可能减少服务停机时间,控制新版本带来的质量风险。

各种部署方式的定义

在这里插入图片描述

蓝绿部署

蓝绿部署,是采用两个分开的集群对软件版本进行升级的一种方式。它的部署模型中包括一个蓝色集群 A 和一个绿色集群 B,在没有新版本上线的情况下,两个集群上运行的版本是一致的,同时对外提供服务。

系统升级时,蓝绿部署的流程是:
在这里插入图片描述

首先,从负载均衡器列表中删除集群 A,让集群 B 单独提供服务。然后,在集群 A 上部署新版本。
在这里插入图片描述

接下来,集群 A 升级完毕后,把负载均衡列表全部指向 A,并删除集群 B,由 A 单独提供服务。
在这里插入图片描述

在集群 B 上部署完新版本后,再把它添加回负载均衡列表中。
在这里插入图片描述

这样,我们就完成了两个集群上所有机器的版本升级。

在这里插入图片描述

红黑部署

与蓝绿部署类似,红黑部署也是通过两个集群完成软件版本的升级。
在这里插入图片描述

当前提供服务的所有机器都运行在红色集群 A 中,当需要发布新版本的时候,具体流程是这样的:
在这里插入图片描述

先在云上申请一个黑色集群 B,在 B 上部署新版本的服务; 等到 B 升级完成后,我们一次性地把负载均衡全部指向 B;
在这里插入图片描述

把 A 集群从负载均衡列表中删除,并释放集群 A 中所有机器。
在这里插入图片描述

这样就完成了一个版本的升级。

可以看到,与蓝绿部署相比,红黑部署只不过是充分利用了云计算的弹性伸缩优势,从而获得了两个收益:一是,简化了流程;二是,避免了在升级的过程中,由于只有一半的服务器提供服务,而可能导致的系统过载问题。

至于这两种部署方式名字中的“蓝绿”“红黑”,只是为了方便讨论,给不同的集群取的名字而已,通过不同颜色表明它们会在系统升级时运行不同的版本。

在这里插入图片描述

灰度部署

灰度发布,也被叫作金丝雀发布。与蓝绿部署、红黑部署不同的是,灰度发布属于增量发布方法。也就是说,服务升级的过程中,新旧版本会同时为用户提供服务。

灰度发布的具体流程是这样的:在集群的一小部分机器上部署新版本,给一部分用户使用, 以测试新版本的功能和性能;确认没有问题之后,再对整个集群进行升级。简单地说,灰度发布就是把部署好的服务分批次、逐步暴露给越来越多的用户,直到最终完全上线。
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

之所以叫作灰度发布,是因为它介于黑与白之间,并不是版本之间的直接切换,而是一个平滑过渡的过程。

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

### 工作原理 #### 蓝绿发布 (Blue-Green Deployment) 蓝绿发布是一种常见的应用部署策略,其核心思想是在生产环境中维护两个完全相同的环境:蓝色环境绿色环境。其中一个环境处于活动状态并处理所有用户请求,而另一个则为空闲状态用于新版本的部署。当新版本准备就绪后,流量会从旧版本切换到新版本所在的环境[^1]。 这种切换通常是瞬时完成的,因此可以实现零停机时间更新。然而,在实际操作过程中,如果目标系统较为复杂,则可能涉及额外的数据同步或其他协调工作来确保一致性[^3]。 ```python # 假设我们有两个服务实例分别代表蓝色绿色环境 blue_service = Service(version="v1", status="active") green_service = Service(version="new_version", status="inactive") def switch_to_green(): global blue_service, green_service if validate(green_service): # 验证新版本是否正常运行 blue_service.status = "inactive" green_service.status = "active" switch_to_green() ``` #### 灰度发布 (Canary Release 或 Golden Canary) 灰度发布也被称为金丝雀发布,是指在将应用程序的新版本全面推广之前,先将其部署给一小部分用户群体进行测试。这种方法允许开发团队观察少量真实用户的反馈,并据此决定是否继续扩大范围直至全部替换原有版本或者回滚至稳定版[^2]。 通常情况下,这部分早期体验者不会察觉自己正在使用的是最新功能;而对于开发者来说,他们可以通过监控这些先行者的交互行为发现潜在问题从而降低风险。 --- ### 主要差异 | 特性 | **蓝绿发布** | **灰度发布** | |---------------------|--------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------| | 流量分配 | 所有流量一次性切向新的环境 | 初始阶段仅有一小部分流量导向新版本 | | 实施难度 | 对于简单的单体应用较易实现 | 更加灵活但也更复杂,需支持动态路由 | | 故障恢复能力 | 如果出现问题可迅速倒回到原版本 | 若发现问题也能快速减少甚至停止流向新版本的比例 | | 数据一致性迁移需求| 可能存在挑战,特别是在数据库模式变更方面 | 同样面临此问题,但由于逐步推进故相对容易管理 | 尽管两者都旨在最小化升级期间的服务中断服务质量下降的可能性,但它们各自适用场景有所不同。例如,对于希望尽快验证新特性而又不想承担过高失败成本的企业而言,采用灰度发布可能是更好的选择;而对于那些追求极致速度且有信心控制变量变化幅度的小型项目或内部工具类软件,则可以直接运用蓝绿技术。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值