一篇文章理解AB测试和灰度发布

一、灰度发布

1.1 简介

灰度发布，是指黑与白之间，能够平滑过渡的一种发布方式。 通过不同策略对用户进行分流，不同的用户组使用不同的应用版本。

1.2 优缺点

  • 优点 互联网服务变动频繁，发布周期短。速度和质量总是难以双全。灰度发布有以下优点： （1）降低发布风险，减少影响范围 （2）可以灰度测试账号，降低测试依赖，减少自测的数据构造成本 （3）方便回滚
  • 缺点 （1）开发、测试和部署的成本较高 （2）数据存储层需要兼容

二、AB测试

2.1 简介

AB Test是一种灰度方式，通常差异度较小，侧重从多种方案中选择最优方案。

简单的说，就是为同一个目标制定两个方案（比如两个页面），让一部分用户使用 A 方案，另一部分用户使用 B 方案， 记录下用户的使用情况，看哪个方案更符合。

一般来说，每个设计方案大体上是相同的，只是某一个地方有所不同，比如某出排版、文案、图片、颜色等。然后对不同的用户展示不同的方案。

2.2 优缺点

  • 优点：避免选择分歧和反复试错，优化决策，最终方案有数据支持
  • 缺点：开发和测试周期增加，多套方案出现want的可能性高

2.3 核心思想

  • 多方案并行测试
  • 同一个用户（一般通过cookie控制）展示同一版本
  • 以某种规则优胜劣汰

2.4 实现步骤

  1. 定义策略：确定分流的目的、放量规模、递增的频率、回滚的策略等；
  2. 筛选用户：确定分流访问的用户特征，定义规则（根据IP，user_id，cookie，业务需求（商户）等因素，指定分流策略）或导入名单；
  3. 访问分流：技术支撑，根据分流策略向用户展示不同内容；
  4. 发布运行：根据不同的实现方案进行部署；
  5. 采集分析：收集数据，比较不同的方案效果，确定最终方案。

2.5 实现方案

关键点：控制逻辑的颗粒度

2.5.1 Nginx控制

两套代码分布部署在不同的机器，通过Nginx配置分流 大多数公司采用这种方案（google，阿里，腾讯，新浪等）

优缺点： 优点：对业务侵入性小，灰度发布和正式上线都非常方便 缺点：开发流程是分支开发模式；代码部署比较复杂

实现：

  • Nginx 根据权重分流
  • Nginx + Lua + redis/memcache
  • Nginx + cookie

2.5.2 后台代码控制

业务逻辑中控制分流

优缺点： 优点：对外部系统以来小，全部逻辑都在业务服务器完成，适合主干开发的模式； 缺点：对业务侵入性大，灰度发布不方便，代码维护还有整洁度下降。

实现：

  • 路由层控制
  • Control 层控制重定向

2.5.3 前台代码控制

js 通过 if-else 控制分流

优缺点和第二种类似，比较适合差异度小的测试

两个版本只有一个较小的区域不一样，我们可以同时将两个区域的 HTML 都加载到当前页面中，先用 CSS 把他们隐藏起来（也可以默认显示一个版本），等通过 JS 判断该显示哪个版本后，再控制对应版本的 CSS 显示。

测试区域比较大，代码比较多，或者需要后台比较多的计算资源，如果一开始就把两个版本的 HTML 全部都加载当当前页面中，就会需要比较大的开销（比如带宽、后台计算量）。这种情况下，我们可以先把测试区留空，之后再用Ajax的方式延迟加载。

2.5.4 第三方框架

三、总结

以上就是我们为大家总结的AB测试和灰度发布了，可以说这两者是一个包含的关系，灰度发布方法里面是可以包含AB测试的，反之，AB测试是灰度发布众多方法当中的其中一个

参考资料

posted on 2021-08-09 14:28  一叶飞天  阅读(835)  评论(0)  编辑  收藏  举报

导航