四种灰度分布方案

简介: 【6月更文挑战第10天】产品迭代加速,灰度发布成为降低风险、优化用户体验的关键。它允许新老版本并存,逐步引入流量验证新版本稳定性。

伴随着互联网技术的高速发展,产品功能的迭代速度也越来越快,年度、季度发布几乎成为历史,一线互联网公司都支持周度上万次发布。如此高频的发布,如果新版本不够稳定,或者新特性的用户体验不好,对于企业来说可能会带来口碑或经济上的损失。


那么从技术角度如何保障每次发布风险最低、让用户获得更好的体验呢?在持续部署方面通常的做法是新老版本并存,先引入少部分流量到新版本,验证通过后,逐步加大新版本流量的比例,这正是灰度发布要解决的问题。灰度发布的核心能力是可以通过配置流量策略,将用户在同一访问入口的流量导到不同的版本上,一般有如下几种方案。

1、蓝绿发布

在老版本不变的情况下,完全独立部署一套新的版本,但新版本并不加入代理后端。当新版本经过线下验证后,直接将流量全量切换到新版本上,并删除老版本。当新版本有问题时,可快速切换回老版本。

在新老版本都存在时,蓝绿发布切换会非常快,快速切换的代价是要多出一倍的资源,即服务的实例个数是平常运行时的2倍。另外,由于流量全部切换,如果新版本有问题,那么所有用户都将会受到影响。即便如此,仍然比发布在同一套资源上重新安装新版本导致用户全部中断要好很多。因此,蓝绿发布适用于对用户体验有一定容忍度、机器资源有富余或者可以按需分配的场景

2、滚动发布

所谓滚动发布,就是在升级过程中,并不像蓝绿发布那样全量启动所有新版本(V1),而是先启动一台新版本,并停止一台老版本(V2),再启动一台新版本,并停止一台老版本,如此循环,直到全量发布完成。比如有10台服务器,滚动发布将会按照先V1:V2=9:1,然后V1:V2=8:2,V1:V2=7:3……直至V1:V2=0:10的模式执行。

滚动发布虽然解决了蓝绿发布在资源层面浪费2倍服务器的问题,但也有相应的弊端。在开始滚动发布后,流量会直接流向已经启动的新版本,而此时新版本的状态是待验证状态,往往需要进行线上回归测试才能确认。在滚动升级期间,整个系统处于一种不稳定状态,如果发现线上问题,也比较难确定是新版本还是老版本造成的问题。


为了解决这个问题,我们需要为滚动升级实现流量控制能力,即控制一部分精确的线上流量进行验证。

3、金丝雀发布

金丝雀发布起源于矿工对矿井的检测。矿井工人发现,金丝雀对瓦斯气体很敏感,矿工会在下井之前,先放一只金丝雀到井中,如果金丝雀不叫了,就代表瓦斯浓度很高。映射到软件工程中,就是当上线新版本应用时,先启动一台新版本的服务器,然后切入少部分流量到新版本,比如5%的线上流量,此时观察新版本在生产环境的表现,就像把一只金丝雀放到瓦斯井里一样,探测这个新版本在环境中是否可用,先让一小部分用户尝试新版本。在观察到新版本没有异常后再增加切换流量的比例,如20%、50%、80%,直到100%全部切换完成。

金丝雀发布是一个渐变、逐步尝试的过程,实际上只有金丝雀发布才可以算作灰度发布。这里把蓝绿发布、滚动发布都称为灰度发布,可能与其他资料的定义不同,但是也不用纠结这些概念名词的划分,抓住问题的本质即可。灰度发布的核心是支持对流量的管理,能否提供灵活的流量策略是判断基础设施灰度发布能力的重要指标

4、AB测试

AB测试是金丝雀发布的一种变形。两者示意图很像,但目的不同。金丝雀发布的核心是在上线前验证新版本是否稳定,而AB测试通常用于核心功能的更改与老版本的效果对比,比如更改了推荐搜索的算法,但不确定新算法是否能达到预期,需要和老版本的算法进行收益比较,按一定的目标策略选取一部分用户使用老版本,另一部分用户使用新版本,收集两部分用户的使用反馈,对用户采样后做比较,通过分析数据来决定最终采用哪个版本。

相关文章
|
4月前
|
监控 测试技术 持续交付
持续部署的内涵和实施路径问题之定义灰度批次以及每一批的比例和观察时间的问题如何解决
持续部署的内涵和实施路径问题之定义灰度批次以及每一批的比例和观察时间的问题如何解决
|
5月前
|
SQL
云架构数据倾斜问题之无效值的数据源表以避免长尾效应如何解决
云架构数据倾斜问题之无效值的数据源表以避免长尾效应如何解决
|
6月前
|
传感器 Unix 5G
技术心得记录:关于灰度的一些知识(转)
技术心得记录:关于灰度的一些知识(转)
74 0
|
Kubernetes 负载均衡 安全
【服务网格】最佳实践在哪里-1:全链路灰度
作为完全兼容社区Istio的服务网格产品,服务网格ASM针对全链路灰度场景提出了自己的思考,并针对性地设计了对应的流量标签方案,来解决上述全链路灰度实现方案中的痛点问题。
|
JSON 监控 安全
分享一例有意思的灰度设计缺陷,浅谈灰度方案的设计
灰度很重要,灰度的策略也需要结合实际情况进行灵活的调整,本文跟大家分享了一个前些时间发现的灰度设计bug。
|
缓存 监控 Kubernetes
MSE 风险分布管理功能发布(一)| 学习笔记
快速学习 MSE 风险分布管理功能发布。
MSE 风险分布管理功能发布(一)| 学习笔记
|
缓存 监控 网络协议
MSE 风险分布管理功能发布(二)| 学习笔记
快速学习 MSE 风险分布管理功能发布。
MSE 风险分布管理功能发布(二)| 学习笔记
|
机器学习/深度学习 算法 数据处理
常见的降维技术比较:能否在不丢失信息的情况下降低数据维度
本文将比较各种降维技术在机器学习任务中对表格数据的有效性
310 0
常见的降维技术比较:能否在不丢失信息的情况下降低数据维度
|
负载均衡 测试技术 微服务
分布式中灰度方案实践
将版本的分支号加载到服务的元数据信息中,再结合服务名称或者IP地址,来实现对服务列表的多维度过滤,可以支撑大部分轻量级灰度策略的实现。
547 0
分布式中灰度方案实践
|
Kubernetes 安全 机器人
Linkerd 流量拆分方案
Linkerd 流量拆分方案
282 1