转自:https://zhuanlan.zhihu.com/p/124912164
1.灰度测试
灰度测试,就是在某项产品或应用正式发布前,选择特定人群试用,逐步扩大其试用者数量,以便及时发现和纠正其中的问题。
1.1具体步骤:
- 确定自己的目标;
- 选择策略:要根据自己产品的规模和功能的多样性来确定互联网灰度发布试用用户的规模和发布的频率,以得出比较全面的结果。
- 对用户进行筛选:用户的选择一定要具有代表性,要选择一部分的新用户和一部分的老用户来交替使用产品。对用户的筛选包括用户特征、用户数量、用户常用功能、用户范围等。
- 部署系统;
- 发布总结;
- 产品完善。
灰度发布和灰度测试应该是一个意思。
1.2 灰度测试环境
灰度测试环境就是生产环境,生产数据,所影响的也是生产环境,只是范围比测试环境更广,更真实。其实就是小范围的生产环境。
2.实现方式
- 修改代码,通过对代码的修改实现灰度测试的逻辑。【这也太笨了吧。。】
- 通过负载均衡系统实现,在负载均衡服务器上调整配置,使得用户在访问应用的时候能够自动被分配到不同的版本上去。
直到将100%的流量都切换到新版本上,最后关闭剩下的老版本服务,完成灰度发布。
3.实例
https://www.infoq.cn/article/ghh4bzehbdlz23rz8dco
灰度发布是通过少量的用户试点来验证新功能有没有问题。所以要保证有两批用户能在同一时间体验到不同的功能。这就要求我们至少准备两台服务器,分别部署不同的代码版本。
需要定义一个灰度策略,即满足什么情况下的流量会走到灰度边,而其他流量走向正常边。
4.发布方案
https://www.woshipm.com/pd/4381854.html
灰度发布如果按照端来分的话,可以分为web前端、客户端、服务端灰度。
无论是哪种灰度,一般需要满足以下2点要求:
- 需要一个放量配置,给产品/运营等工作人员配置放量策略;
- 需要做到同一个用户始终访问的是同一个版本的代码,如果同个用户上个请求访问的是A版本,下个请求访问的是B版本,就可能会出问题。
4.1 不同端
web前端灰度:
给资源分配一个唯一的版本号,再把所有的版本号存储起来。当处理请求时,根据动态配置的分流策略来决定用户使用哪个版本。比如分流策略是放量10%,即新版本随机放量给10%的用户使用,当用户首次命中资源版本号时,需要把用户id和版本号的映射关系存储起来(可存到cookie),这样就能保证同个用户上次请求和下次请求访问到的都是同个版本的代码。
服务端灰度:
服务端灰度分为兼容变更灰度和不兼容变更灰度。
兼容变更又可分为物理灰度和逻辑灰度。物理灰度就是第2节说的通过负载均衡实现的,逻辑灰度就是修改代码来实现。
客户端灰度:
web前端和服务端灰度发布可以在客户无感知的情况下平滑进行,遇到问题也可以快速回滚,但是移动客户端涉及到用户的主动安装行为,所以上述的方式已经不适用。
客户端在启动时,会向灰度系统发起请求,灰度系统根据客户端传过来的参数和当前的放量策略来决定是否要给客户端升级提醒。
4.2 灰度放量策略
- 按流量百分比:先到先得的方式比如限制10%的用户体验的是新版本,90%的用户体验的是老版本。
- 按人群划分:按用户id、用户ip、设备类型比如可通过平时的埋点上报数据得知用户的pv、uv、页面平均访问时长等数据,根据用户活跃度来让用户优先体验新版本,进而快速观察使用效果。
- 按渠道划分:根据用户的注册来源来放量。