马蜂窝ABTest多层分流系统的设计与实现

 什么是 ABTest

产品的改变不是由我们随便「拍脑袋」得出，而是需要由实际的数据驱动，让用户的反馈来指导我们如何更好地改善服务。正如马蜂窝 CEO 陈罡在接受专访时所说：「有些东西是需要 Sense，但大部分东西是可以用 Science 来做判断的。」

说到 ABTest 相信很多读者都不陌生。简单来说，ABTest 就是将用户分成不同的组，，同时在线试验产品的不同版本，通过用户反馈的真实数据来找出采用哪一个版本方案更好的过程。

我们将原始版本作为对照组，以每个版本进行尽量是小的流量迭代作为原则去使用 ABTest。一旦指标分析完成，用户反馈数据表现最佳的版本再去全量上线。

很多时候，一个按钮、一张图片或者一句文案的调整，可能都会带来非常明显的增长。这里分享一个ABTest 在马蜂窝的应用案例：

如图所示，之前我们搜索团队和电商团队希望优化一个关于「滑雪」的搜索列表。可以看到优化之前的页面显示从感觉上是比较单薄的。但是大家又不确定复杂一些的展现形式会不会让用户觉得不够简洁，产生反感。因此，我们将改版前后的页面放在线上进行了 ABTest。最终的数据反馈表明，优化之后的样式 UV 提高了 15.21%，转化率提高了 11.83%。使用 ABTest 帮助我们降低了迭代的风险。

通过这个例子，我们可以更加直观地理解 ABTest 的几个特性：

先验性：采用流量分割与小流量测试的方式，先让线上部分小流量用户使用，来验证我们的想法，再根据数据反馈来推广到全流量，减少产品损失。

并行性：我们可以同时运行两个或两个以上版本的试验同时去对比，而且保证每个版本所处的环境一致的，这样以前整个季度才能确定要不要发版的情况，现在可能只需要一周的时间，避免流程复杂和周期长的问题，节省验证时间。

科学性：统计试验结果的时候，ABTest 要求用统计的指标来判断这个结果是否可行，避免我们依靠经验主义去做决策。

为了让我们的验证结论更加准确、合理并且高效，我们参照 Google 的做法实现了一套算法保障机制，来严格实现流量的科学分配。

基于 Openresty 的多层分流模型

大部分公司的 ABTest 都是通过提供接口，由业务方获取用户数据然后调用接口的方式进行，这样会将原有的流量放大一倍，并且对业务侵入比较明显，支持场景较为单一，导致多业务方需求需要开发出很多分流系统，针对不同的场景也难以复用。

为了解决以上问题，我们的分流系统选择基于 Openresty 实现，通过 HTTP 或者 GRPC 协议来传递分流信息。这样一来，分流系统就工作在业务的上游，并且由于 Openresty 自带流量分发的特性不会产生二次流量。对于业务方而言，只需要提供差异化的服务即可，不会侵入到业务当中。

选型 Openresty 来做 ABTest 的原因主要有以下几个：

整体流程

在设计 ABTest 系统的时候我们拆分出来分流三要素，第一是确定的终端，终端上包含了设备和用户信息;第二是确定的 URI ;第三是与之匹配的分配策略，也就是流量如何分配。

首先设备发起请求，AB 网关从请求中提取设备 ID 、URI 等信息，这时终端信息和 URI 信息已经确定了。然后通过 URI 信息遍历匹配到对应的策略，请求经过分流算法找到当前匹配的 AB 实验和版本后，AB 网关会通过两种方式来通知下游。针对运行在物理 web 机的应用会在 header 中添加一个名为 abtest 的 key，里面包含命中的 AB 实验和版本信息。针对微服务应用，会将命中微服务的信息添加到 Cookie 中交由微服务网关去处理。

稳定分流保障：MurmurHash算法

分流算法我们采用的 MurmurHash 算法，参与算法的 Hash 因子有设备 id、策略 id、流量层 id。

MurmurHash 是业内 ABTest 常用的一个算法，它可以应用到很多开源项目上，比如说 Redis、Memcached、Cassandra、HBase 等。MurmurHash 有两个明显的特点：

快，比安全散列算法快几十倍

变化足够激烈，对于相似字符串，比如说「abc」和「 abd 」能够均匀散布在哈希环上，主要是用来实现正交和互斥实验的分流

下面简单解释下正交和互斥：