一篇文章理解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  一叶飞天  阅读(762)  评论(0编辑  收藏  举报

导航