背景

为了验证一些想法是否真的有业务价值，往往需要做AB实验。

做AB实验，绕不过去的问题就是分流

什么是分流？

• 比如100个用户访问你的站点的某个path，假如分流是五五开，那么结果就是50个用户看的是A页面，另外的50看的是B页面

常见的三种分流方式

1. 接口分流
2. 投放侧分流
3. nginx层分流

1. 接口分流

原理：

• 展示AB内容前，先调接口，根据响应的结果渲染A或B

好处：

• 可以让运营参与配置，无需RD参与，就可以改实验条件

适用场景：

• 同一个集群内的需求

不适用的场景

• 不同集群的需求，比如：

  性能优化、内容/流程重构等对代码进行破坏性修改的，这种要做AB实验的话，是需要重新部署到新集群去的。这种接口分流就不再适用，因为2个集群，已经是2套代码了，只能在接口的更上层做分流

缺点：

1. 对于CSR项目来说，性能伤害比较大，因为要通过http接口，来获得AB信息

2. 对于SSR项目来说，要做成服务发现去调用，而不是前端去调用，否则也会伤害性能

2. 投放侧分流

原理：

• 给运营提供AB两个url，让运营去投放平台投放。这个分流其实跟技术方面就没啥太大关系了，但也是一种思路

好处：

1. 可以做接口分流做不了的AB实验
2. 还能做nginx层的更上层的CDN缓存的AB实验

适用场景：

• 可以做接口分流和nginx层分流做不了的场景

不适用的场景

• 无

缺点：

1. 投放平台可能会带来buff加成，导致影响实验真实性

   buff加成的意思是：为了让你更愿意在投放平台投放，在初期可能会有冷启动，给你分配更优质的用户，提升你的转化率

3. nginx层分流

原理：

• 流量打到对应服务器之前，会先经过nginx层，可以由nginx层把流量分到对应的服务器（集群）上

如何实现？

• 公司应该有这方面的基建，可以oncall问。否则只能让运维帮忙配置一下

好处：

1. 可以做接口分流做不了的场景

2. 可以解决投放侧分流带来的副作用

适用场景：

• 可以做接口分流做不了的场景

不适用的场景：

• nginx层更上层的实验，比如CDN缓存的AB实验就做不了

  CDN缓存的AB实验是什么意思？

  • 就是想验证CDN缓存的性能提升到底能为业务带来多少价值。
  • CDN缓存本身还是有不少副作用的，感兴趣的可以翻我之前关于CDN缓存的文章juejin.cn/post/716307…

缺点：

1. 需要考虑用户刷新的问题（比如：原本展示的是A，刷新后可能会展示B，这样会给实验结果造成点误差）

如何解决这个缺点？

• 用组合分流

  • cookie分流 + 50%随机分流 （假设我们要55开分流）

  举例：

  1. 假设实验A在A集群，实验B在B集群，我们总的需要配3条nginx配置

     1. 配置1：当cookie：a=1存在时，100%命中A集群

     2. 配置2：当cookie：b=1存在时，100%命中B集群

     3. 配置3：50%命中A集群，50%命中B集群

     4. 再加上前端的代码改造，A集群的代码会写入cookie：a=1，B集群的代码会写入cookie：b=1

  这样就配完了，解释一下为什么这样配置就可以解决

  1. 当用户初次访问时，肯定没有cookie，那么自然55开分流到AB

  2. 假设当前被分流到了B，那么此时会种下cookie：b=1，用户刷新后，会固定打到B集群，这样就可以保证实验结果的真实准确了！

总结

总的来说，各有优缺点和适用场景，大家可以根据自己业务需求，考虑对应的方案

---

码字不易，点赞鼓励！！