部署幾套系統，切分不同的流量占比。這樣的成本很高，可同時進行的實驗很少，且發布比較麻煩，壹個實驗得好多人配合。
BTS可以支持正交測試，如圖所示：我們分析實驗數據，只會針對同壹實驗內部的基準桶和實驗桶。
後來，參考google的壹篇論文，Overlapping Experiment Infrastructure More, Better, Faster Experimentation實現了壹套可能做很多實驗的平臺，且集分析和管理於壹體。
Tesla作為公***庫，即可植入前端應用中，也可植入後端引擎中進行實驗。
單層試驗
流量通道，流量隔離，壹個流量的容器，可想象成壹個電梯。可以嵌套多個Layer；
流量復用流經的壹個層，流量流經Layer時進行切流，可以嵌套多個Domain；
流量切分規則；acookie, nickname, random...
保障層間獨立、保障用戶看到頁面到壹致性。
真正到實驗，包含了實驗的參數；
Domain和Layer不可互相嵌套。簡單來說，Tesla將多個實驗分布到多個層中，流量依次流入每層，從而並行地進行多個實驗。
離散
加入隨機性
流量流過每壹層，加入離散因子，保障流入下壹層被重新打散。
每壹次使用固定到離散因子LayerId，同壹個用戶每次訪問到路徑壹致。
假設，每個實驗均可抽象為壹些參數的集合，這些參數的組合將決定當前流量將會進行哪些實驗。先考慮壹種簡單的情況，各個實驗直接相互沒有任何影響，可以同時對同壹流量做實驗，這種情況下對於流入的流量，僅需要按各個實驗需要的比例進行分配即可。同時因為各個實驗之間沒有任何影響，所以同壹個請求可以同時並行多個實驗。這種情形下相當於每層只有壹個實驗，流量在壹層之中分配到實驗所需要的比例的流量。如圖所示，同時並行3個實驗。
在實際的生產環境中，實驗之間常常是相互有影響的，在同壹個模塊中的兩個實驗通常都是有影響的，例如在Query Rewrite模塊同時做兩個實驗。在這種情況下，對於同壹個請求是不能同時進行這兩個實驗的。需要將這兩個或多個相互有影響的實驗放在同壹個層次裏，以使得他們分別占用壹定比例的流量，相互之間沒有流量的重用。如圖所示，可以看出互斥實驗被放在了同壹層中保證了它們的互不幹擾。
再考慮壹種更復雜的情況，Query Rewrite中的實驗1與Match中的實驗2是有耦合關系的。需要分出壹部分流量單獨供Query Rewrite的實驗1和Match的實驗2來做聯合實驗。此時，Domain的作用就體現出來了，將流量分到多個Domain中，其中壹個Domain專門用於該聯合實驗，如圖所示。
至此，Tesla已經可以支持幾乎全部的實驗情形，相比實驗田，Tesla更加靈活，同時也可以並行做多個實驗。
Tesla在實現以上的功能的時候，充分考慮到以下幾點：
1、簡潔：作為公***庫，輕量級實現，並提供簡潔實用的接口便於應用方使用；
2、解耦：應用方只需依賴Tesla即可，保持系統和Tesla各自的獨立性減少系統的復雜性；
3、靈活：提供各種靈活的分流策略以滿足多種應用，而且可以提供自定義的流量切分規則；也提供嵌套的Domain從而適合解決各種實驗對流量分配的需求；
目前Tesla只對外開放唯壹接口，內部實現對應用方透明。接口如下：
應用方將實驗參數透傳至各個實驗模塊，由各個實驗模塊獨立解析參數並進行執行。Tesla接收到請求req後，會依次按照Layer的序（ID）進行分流，查找該Layer對應的實驗，大概流程圖如下：
壹個Layer只能采用壹種Diversion，那麽計算步驟如下：
1、取到req中的分流參數值，如acookie；
2、對Diversion中指定的分流策略進行hash得到bucket；
3、根據bucket與該Layer內的所有Experiment或者Domain指定的Buckets，確定該次req落到那個Experiment或者Domain；
4、如果落到Experiment，那麽將實驗參數返回，如果落到Domain，那麽重復以上步驟，直至流量流出經過最後壹層
5、其他Layer計算步驟以此類推；
6、最後拼接bucketID和收集Parameters，bucketID即為每個Layer選出的Experiment的ID，如果沒有選出Experiment，那麽ID默認為0，ID間用“_”連接，示例：100_0_300_2；
不同的實驗會有不同的流量切分需求，因此，Tesla提供了多種切分規則供應用方選用，如表。
理論上，Tesla能夠同時並行無數的實驗，但是不建議設計如此復雜的實驗，壹方面流量是有限的，流量稀疏時，效果波動會很大，實驗效果置信低。值得註意的是，為了達到不同的Layer的流量是正交的，設計hash函數會很復雜，流量切分也很難做到簡單，且具可解釋性。因此，我們建議預先了解實驗流量需求，及實驗間的沖突，合理設計實驗。
在後端引擎接入Tesla，當引擎接收到請求後，首先請求Tesla取得對應的實驗信息，然後依次將實驗信息透傳給Query Rewrite和Rank，對於Query Rewrite和Rank各取所需實驗參數，最後將bucketID記錄到投放日誌對應的字段中，用於實驗效果統計用。
為了驗證Tesla的作用，設計了較為復雜的實驗，分別針對熱搜和導航場景設計了多個算法實驗，如圖所示。在Query Rewrite模塊中，為了確定那個多樣性參數效果最好，我們設計了三個並行實驗。在Rank模塊中，為了驗證結果多樣性、排序策略，我們也設計了三個並行實驗。
同時並行了12個實驗，已經很復雜了，通過Tesla能夠有效規避實驗間的沖突帶來的實驗效果的影響。
延伸文獻：