引言
在线服务系统的AB-test方法有很多种。搭建多个可服务集群，从物理上对流量进行隔离是比较常见的一种方式。这种方式应用于大型复杂的在线服务系统时，存在部署比较慢的问题。这种方式的典型架构如下图所示。
QueryRewrite：改写用户搜索词以期望得到更好的查询结果。
Matching：根据用户搜索词，召回最符合用户意图的那些推广。
Ranking：确定推广的输出顺序，需要兼顾用户体验和搜索平台的收益。
这种架构有两个优点。
代码分为了基线和实验代码，实验代码对业务的侵入性比较小。
实验田的流量和基线的流量从物理上严格分开，严格控制了实验对业务的影响。
这种架构的缺点同样也很明显，主要有如下几点。
增加了运维的复杂性，运维需要维护多套环境。
每套环境接入的流量都是由单个实验田集群的物理机器数量固定上限的，不能灵活地验证流量扩大的情景。这会导致对小流量实验效果很好的算法，在基线上有可能无法收到好的效果。
实验的流量有限，导致实验的数量变少，而增大实验流量又会影响业务基线。
我们在总结现有的各种实验机制的基础上，结合阿里妈妈的应用场景实践出了一种高效便捷、能充分利用流量、并行多个实验的方法。该方法也能支持系统的灰度发布，有如下几个优点。
提高并发：实现多实验并行迭代，加快迭代的速度。
公平对比：做到实验效果公平、准确对比评估，即时停止不符预期的实验;随时扩大效果良好的实验的流量。
降低门槛：提供实验管理工具，除算法以外，其他有实验需求的如产品、运营、前端等都可以独立申请发布实验。
建立闭环：从想法、实验前线下评估、发布实验、实验进行、实验评估、最后实验总结，确保实验结果的质量。
系统架构和模块说明
一. 系统整体架构
架构整体可以划分为三个系统，如下图所示。
接下来对各个子系统进行详细的介绍。
1. 实验配置管理发布系统
此系统给用户提供便捷的UI操作界面，方便用户添加实验配置流量，然后动态地在线发布。为了弥补各种不可预期的错误，该系统支持历史版本的快速回滚。
2. 在线服务系统
根据用户的实验配置文件，进行分流处理，给各个实验分配相应的流量。实验分流模块以库的方式接入在线服务系统。在系统的流量入口处调用此分流库。后续会详细介绍分流的原理和作系统进行实验的方法。
3. 日志分析展示系统
根据在线服务系统记录的日志，统计出各个实验的效果，供系统分析师或实验观察者使用。然后根据实验的效果，使用实验管理系统去调整各个实验流量的占比。
二. 各模块介绍
1. 实验配置管理发布系统
(1) 实验场景。广告系统中，实验是针对某一批广告位或者特定页面进行的。针对PID(标记广告的位置信息)或页面来对流量进行分类就成了一个强需求。将这样一批广告位定义为一个实验场景。Web操作页面上需要提供配置实验场景的UI界面，用户可以在这个界面上新建一个场景，指定符合某些PID要求或者URL要求的请求进入相应的实验场景，UI界面如下所示。
在此页面上，用户可以方便地添加一个新场景，并指定该场景的入口PID(入口PID可以设定多个)。
(2) 实验分层和流量切分。进入某个实验场景后，通过分多层来达到流量的复用。每一层的流量均是流入这个场景流量的一个全集。每一层的流量可以按用户指定的切分标记进行分桶切流。
一层可以看成是多个实验的集合，实验分层的原则如下：
相互之间没有影响的实验可以分到不同层。
相互之间有影响的实验分到同一层。
由于互不影响的实验被分配到了不同的层，从而达到复用流量的目的。相互之间有影响的实验分到同一层，则保证了同一请求不会去作两个互斥的实验。