灰度发布是什么?

在如今的互联网时代,大厂都是采用灰度发布的策略进行应用线上部署的。如果身在小公司的测试同学想进入大厂,那么灰度发布就是大家必须要了解的知识点了!希望通过本文能够帮助大家快速的理解什么是灰度发布,并让大家了解研发,运维,测试,运营是如何在这一策略下开展实际工作的。

灰度发布定义

灰度发布(又名金丝雀发布)是指在黑与白之间,能够平滑过渡的一种发布方式。在其上可以进行A/B testing,即让一部分用户继续用产品特性A,一部分用户开始用产品特性B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B 上面来。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。

马化腾的灰度机制是这样的:很多公司在一开始做产品定义时,要么确定它是黑的,要么确定它是白的。但是马化腾发现,互联网产品的定义是有用户投票决定的。在一开始,我们不定义它是黑,还是白,有一个灰度的周期。在这个灰度周期里,让用户的口碑决定它是生是死,是白还是黑。

灰度发布具体流程

灰度发布具体流程如下所示:

灰度发布流程细节如下:

1.在灰度发布开始后,先启动一个新版本应用,但是并不直接将流量切过来,而是测试人员对新版本进行线上测试,启动的这个新版本应用,就是我们的金丝雀。

2.如果测试没有问题,那么可以将少量的用户流量导入到新版本上,然后再对新版本做运行状态观察,收集各种运行时数据,如果此时对新旧版本做各种数据对比,就是所谓的A/B测试。

3.当确认新版本运行良好后,再逐步将更多的流量导入到新版本上,在此期间,还可以不断地调整新旧两个版本的运行的服务器副本数量,以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上,最后关闭剩下的老版本服务,完成灰度发布。如果在灰度发布过程中发现了新版本有问题,就应该立即将流量切回老版本上,这样,就会将负面影响控制在最小范围内。具体流程如下图所示:

为什么做灰度发布

1、灵活选择用户参与产品测试。

2、规避一定的发布风险,降低产品迭代升级所影响的范围。

3、快速获取用户的反馈意见,完善产品功能,提升产品质量。

4、避免停服发布给用户带来不便。

5、具有容灾能力:降低全量发布引起的服务器崩溃等风险,逐步发布产品,逐步控制服务器压力。

灰度发布重点

定义目标

1.新功能验证(看这个新功能的指标是否能达到预期,或者是否会对产品造成损失,大多数是这个目的)

2.新功能尝试(看这个功能是否符合用户需求,不符合则下线)

选定灰度策略

用户选择:地理位置、使用终端

功能覆盖度:逐步功能开放还是全部功能开放

提供用户数据反馈入口,让运营人员能够及时了解用户反馈

公关运营

筛选用户

用户范围:内部用户 >活跃用户 >所有用户。

灰度发布上线

设定分流规则

灰度发布新版本

运营数据采集分析

分流规则微调

灰度发布>产品完善>新一轮灰度发布>完整发布

灰度发布问题

1、以偏概全

选择的样本不具有代表性,样本用户使用习惯并没有涉及所有升级的核心功能。

2、无法定量分析

结果没有量化手段,只依赖用户问卷调查,没有分析灰度系统。

运营数据不全面,只有核心业务指标,没有用户体验指标等。

3、用户参与度不够

如果用户参与度不够就很难对灰度版本的优劣进行分析评价

具体实施

运维同学

方式一,利用nginx配置负载控制

方式二,使用http头信息判断+权重(灰度值)

http请求传输过程中,会自动带上User-Agent,Host,Referer,Cookie等信息。我们需要分析ip地址段,用户代理,Cookie中的信息。根据Cookie查询version值,如果该version值为v1转发到host1,为v2转发到host2,都不匹配的情况下转发到默认配置。

方式三,使用灰度发布工具

从长远来看需要使用工具作灰度发布,业界相关工具包括:阿里acm、NepxionDiscovery、Istio

研发同学

1.版本控制

通过切换不同分支来选择上线的版本并制定打版回退策略

2.代码开关

一套代码,通过代码开关控制新功能上线与否。利用代码中的功能开关来控制发布逻辑,一般不需要复杂的发布工具和智能 LB 配合,是一种相对比较低成本和简单的发布方式。研发人员可以灵活定制和自助完成的发布方式。实现过程如下:

功能开关发布需要一个配置中心,通过配置中心,运维或研发人员可以在运行期动态配置功能开关的值。

新功能和老功能在同一套代码中,新功能隐藏在开关后面,如果开关没有打开,则走老代码逻辑,如果开关打开,则走新代码逻辑。

应用上线后,开关先不打开,然后运维或研发人员通过配置中心打开新功能,经过流量验证新功能没有问题,则发布完成;如果有问题,则随时可以通过配置中心切回老功能逻辑。

运营同学

监控新功能使用情况,是否使用频繁

用户满意度的监控,带来了新用户?导致老用户卸载?

测试同学

除了正常功能以外,还要确保每一台服务器上的应用功能都是可用的(灰度时验证,全部上线时还需验证)

作者:测试开发Kevin
链接:https://www.jianshu.com/p/65b8c14c2e82
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

### 灰度发布的概念 灰度发布是一种逐步将新版本功能或服务推送给用户的方式。它通过控制流量比例,让一部分用户先使用新版本,验证其稳定性和兼容性后再逐步扩大范围,直至全量覆盖所有用户[^5]。这种方式可以有效降低新版本对系统整体的影响,同时为快速回滚提供了便利。 灰度发布通常适用于需要渐进式引入新版本的场景,例如社交应用的新功能测试、性能优化验证等[^3]。 --- ### 灰度发布的实现方式 #### 1. 流量切分 灰度发布的核心是通过流量切分技术,将部分流量导向新版本。常见的流量切分方法包括基于用户 ID、地域、设备类型等维度进行分流。以下是一个简单的基于用户 ID 的流量切分算法示例: ```python def分流逻辑(user_id): # 假设 user_id 是一个整数 if user_id % 10 < 2: # 10% 的用户进入新版本 return "green" # 新版本 else: return "blue" # 旧版本 ``` 上述代码中,`user_id % 10 < 2` 表示将 10% 的用户流量分配给新版本(绿色环境),其余用户继续使用旧版本(蓝色环境)。 #### 2. Kubernetes 中的灰度发布 在 Kubernetes 中,可以通过调整 Deployment 的副本数量来实现灰度发布。例如,通过缩放旧版本(蓝色)和新版本(绿色)的 Pod 数量,控制流量比例[^2]。 以下是一个简单的命令示例: ```bash # 蓝色环境(旧版本) kubectl scale deployment/py-hello-blue --replicas=9 # 绿色环境(新版本) kubectl scale deployment/py-hello-green --replicas=1 ``` 上述操作表示将 90% 的流量分配给旧版本,10% 的流量分配给新版本。 #### 3. 数据一致性 与蓝绿发布类似,灰度发布也需要解决数据一致性问题。由于新旧版本可能共享同一数据库,因此需要确保数据库模式兼容,或者通过双写机制同步数据[^4]。 --- ### 灰度发布与蓝绿发布的区别 | 特性 | 灰度发布 | 蓝绿发布 | |---------------------|--------------------------------------------|--------------------------------------------| | **服务中断时间** | 零停机(逐步增加流量) | 零停机(切断流量瞬间完成) | | **资源消耗** | 单倍资源(部分资源分流) | 双倍资源(两套环境) | | **回滚难度** | 复杂回滚(需要动态分流规则) | 快速回滚(直接切回旧环境) | | **适合风险场景** | 需验证新版本稳定性(如新功能上线) | 高可用性要求场景(如金融系统) | 蓝绿发布更适合需要快速回滚的应急修复场合或跨机房容灾演练,而灰度发布则更适合新功能灰度测试或性能对比验证。 --- ### 经典应用场景 - **灰度发布**:适用于社交应用的新功能测试、性能优化验证等场景[^3]。 - **蓝绿发布**:适用于需要快速回滚的应急修复场合、跨机房容灾演练等场景。 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值