灰度发布和AB Test

hmtomyang 2019-08-15

展开全文

文章目录

一、灰度发布

1. 简介
2. 优点
3. 缺点

二、AB Test

1. 简介
2. 优缺点
3. 核心思想
4. 实现步骤

三、实现方案

1. nginx控制
2. 后台代码控制
3. 前端代码控制

四、第三方框架
五、参考资料

一、灰度发布

1. 简介

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

2. 优点

互联网服务变动频繁，发布周期短。速度与质量总是难以双全。灰度发布有以下优点：

降低发布风险，减少影响范围
可以灰度测试账号，降低测试依赖，减少线下自测的数据构造成本
方便回滚

3. 缺点

开发、测试和部署的成本较高
数据存储层需要兼容

二、AB Test

1. 简介

AB test 是一种灰度方式，通常差异度较小，侧重于从多种方案中选择最优方案。
简单来说，就是为同一个目标制定两个方案（比如两个页面），让一部分用户使用 A 方案，另一部分用户使用 B 方案，记录下用户的使用情况，看哪个方案更符。
一般来说，每个设计方案应该大体上是相同的，只是某一个地方有所不同，比如某处排版、文案、图片、颜色等。然后对不同的用户展示不同的方案。

在这里插入图片描述

2. 优缺点

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

3. 核心思想

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

4. 实现步骤

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

三、实现方案

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

1. nginx控制

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

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

实现：

nginx根据权重分流
nginx + lua + redis/memcache
nginx + cookie

阿里框架
新浪框架

2. 后台代码控制

业务逻辑中控制分流
优缺点

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

据说：微软和amazon是使用这套架构
实现

路由层控制
control 层控制重定向

3. 前端代码控制

js if-else 控制分流
优缺点和第二种类似，比较适合差异度小的测试
两个版本只有一个较小的区域不一样，我们可以同时将两个区域的 HTML 都加载到当前页面中，先用 CSS 把它们隐藏起来（也可以默认显示一个版本），等 JS 判断出该显示哪个版本后，再控制对应版本的 CSS 显示。
测试区域比较大，代码比较多，或者需要后台较多的计算资源，如果一开始就把两个版本的 HTML 全加载到当前页面中，就会需要比较大的开销（比如带宽、后台计算量）。这种情况下，我们可以先把测试区留空，之后再用 Ajax 的方式延迟加载。