微软 AB/Testing EXP 实验管理平台
Conference Paper · May 2018 The Anatomy of a Large-Scale Online
Experimentation Platform。
因为工作负责和ABTest相关的事情，所以对ABTest系统理论与工程落地情况一直在调研，根据上面这篇论文，我们一起来学习下微软EXP系统的工程实现。摘要及其相关工作啥的废话略过，先放一张架构图：
整个系统包含四部分：
1. experiment portal：
portal属于一个实验管理后台系统，为实验者与实验系统之间提供交互接口，实验者可以方便的在系统中创建，配置，运行并分析实验。其中系统包含三个重要的组件：
1. experiment management
实验管理界面应具有以下功能：
- 选择实验地域群体（US CN等）
- targeting or traffic filters（浏览器，操作系统，应用版本以及更复杂的实验条件，比如刚满一个月的新用户等）
- Overall Evaluation Criteria (OEC) 综合评价标准，实验者要选择好评估指标，可以内置一些常用的CTR，PV，UV等产品优化指标
- 配置实验组和对照组流量，以及实验的开始和结束时间
- 支持
re-randomization：使用历史数据批量做AA实验，一般通过AA实验选择最合适的hash算法，目的是为了让样本尽可能均匀，然后才能做AB实验，为了提高销量，巧妙的使用历史数据做AA，这个过程叫做SeedFinder。 - 实验管理界面 对不同产品提供不同的实验配置模版
- isolation group 是一个变量集合，每个变量都会被打上所属的isolation group，实验里的所有变量共享同样的isolation group，如果两个变量所属的isolation group有交集，那么说明这两个变量会是相互影响的，对于这两个变量，在做实验的时候应该是互斥的
- 后端管理系统能够控制变量所对应的线上业务行为。对于server端实验，代码可以随时重新发布上线，对于client端实验，比如app发版都是周期性的，所以需要能够在管理系统配置feature的开关
- 后端管理系统还可以让用户自定义metric，微软开发了Metric Definition Language (MDL)，去构造metric，如ctr等，底层会重新翻译成SQL等其它语言。对于各种metric：产品效果指标，实验的置信度，实验是否分流均匀
2.experiment execution service
这个是ABTest的核心服务，为各个接入AB的服务分配实验变量。每个变量V是一个参数集合，实验可以表示为E{V1, V2}， 如V1实验组，V2对照组。isolation group 会切分成多个变量，如下图：
每个变量都会被关联上一个或多个isolation group，比如存在两个实验E1{V1, V2}， E2{V3, V4}，E1关联隔离组G1，G2。同时E2的变量也关联G1，G2。 会发现两个实验变量所关联的隔离组是有交集的，那么这时候说明两个实验是会相互影响的，不能同时进行。
列举了三种实验组参数配置下发方式：
总之都是从experiment execution service拿到实验组参数配置并缓存在本地。
- 可以通过应用程序在启动时直接通过服务接口调用，去请求实验组参数配置，这样做到用户在session内有一致的用户体验。服务端和客户端均可采用这种方式
- Edge Node可以类比nginx，可以负载均衡服务， 它和
experiment execution service交互，对请求进行加强（填充改次请求 所对应的实验参数配置）。这种方式不适合客户端实验， 因为客户端用户操作很多都是本地行为，没有发生网络交互 - 第三种方式通过为AB实验打包一个专门的lib， 客户端实验不需要将实验参数在各个组件传来传去，而是每次都从这个lib去拿就可以了。lib负责和
experiment execution service周期性交互
还有个配置管理服务 去控制experiment execution service 进行一个实验下不同的变量分配的开关， 该开关配置应该放到lib里
