2. 在线服务系统
Tesla以lib库的方式接入在线服务系统。没有做成一个服务的形式，主要考虑到接入简单，不增加系统复杂性和运维的工作量。
(1) 分流规则。用户可以在各层指定不同的切分标记进行流量切分。系统会根据用户指定的切分标记值来计算hash值。计算出的hash值对100取模再加1可以得到分桶号，每个实验占了指定范围的桶号，这样便可以知道该次请求应当进行哪个实验。这里需要注意的是，选取一个偏差较小的hash函数，我们在数10种hash函数中选取了一个最优的hash函数，将偏差控制在实验效果统计可以忽略的范围。
假如每一层均使用这样的切分规则，不同层做实验的用户选用相同切分规则时，请求始终落入相同的桶。由于不同层的实验之间毫无关系，为了保证实验效果绝对可信，需要做到不同层的流量正交。为了达到这个目的，引入了layerID来作为离散因子。由于每一层layerID是固定的，也能保证同一请求两次访问能落到同一个实验，从而不会造成同一用户多次访问，返回结果不一致的困惑。示意图如下。
(2) 实验参数的处理。之前讲述了如何决定一次请求去作哪些实验。这一部分介绍一个具体实验的构成元素，以及系统如何执行实验。一个实验本质上是一堆抽象参数集合。每个请求被分配某个实验之后，系统便会将该实验的抽象参数集合，作为请求的一部分传递至在线服务系统的各个处理模块。
对于系统而言，可以根据请求携带的参数值来决定作哪个实验。这里需要注意的是，为了保证系统的健壮性，如果一个请求缺少了某个实验参数的数值，系统应该设置一个抄底的值。
(3) 实验发布。当某个实验效果非常好时，可以动态调整该实验的流量占比，从而迅速得到收益，并且在大流量上验证该实验的有效性。一旦确认该实验效果非常良好，便可以在全流量上线。这时需要删除该实验，把该实验的参数作用于全部的流量。这是通过在每个场景中设置一个初始化层来实现的。
每个场景的第一层设定为初始化层，该层会初始化需要作用于全流量的所有参数。一旦某个实验需要在全流量上线，便可以删除该实验，将该实验的参数移到初始化层去。这样便可以避免实验数量不断膨胀、层数不断增加的问题，同时也达到了在线全流量发布某个实验的目的。
3.日志分析展示系统
实验效果统计无疑是系统中非常重要的一个环节。对于简单的AB-test(物理集群隔离的实验方法)，实验数据的统计相对比较容易。对于这种复用流量，在一次请求上作多个实验的方式，统计实验效果相对要复杂一些。这里介绍一种相对简单的实验统计分析方法。每个实验均有一个唯一的实验ID。对于一次请求，调用分流库后，在返回所有实验参数的同时，会返回一个字符串，该字符串将所有作用于该次请求的实验ID以下划线连接起来，例如Exp1_Exp3_Exp6_Exp8_Exp9。请求同样会把这个字符串携带传输至系统的各个模块，在记录系统日志时将该字符串一并记录下来。
日志分析处理模块以“_”为分割符把该字符串进行分割，得到多个实验ID，利用storm等流式实时处理系统去实时统计分析各个实验的效果，再利用实验发布系统动态调整流量，从而获得了文中提出的一种良性的闭环反馈。
应用实例
下面以一个简单的广告引擎系统接入上述平台的例子，具体说明上述的方法。该系统共有两个实验点(Query Rewrite和Rank)，因此可以分为两层实验。下面以一次请求的处理流程来简单说明该引擎系统的工作原理。
如上图所示，Tesla以lib库的形式接入引擎中。引擎接收到请求后，调用Tesla的lib库获取对应的实验参数信息，然后依次将实验信息透传给Query Rewrite和Rank。在Query Rewrite和Rank模块中各取所需实验参数进行相应的实验，最后将bucketID记录到投放日志对应的字段中，用于实验效果统计用。