Mendel - A/B Testing Platform (Part 0)
背景 & 前言
其实很早之前就想重写我们的AB testing系统，因为现在的程序很简陋（虽然是很久之前某位大哥写的，而且也能凑合用），不支持分国家测试（这种测试很重要），每个返回的结果都会带上很长一串的配置代码（比如，Testing=abpha,Rank=abcde,Threshold=0.5….，巨长无比，比我都长），看起来非常罗嗦，也不友好，我们用什么测试都明文暴露出去了，并且现有程序很Java，晦涩难懂，不敢维护。本着破旧立新的原则，搜了一圈没有开源方案能够满足我们的要求，只得自己写一个。
历时两个月：写代码一个月，五千多行，期间还掺杂着乱七八糟的事儿；部署测试一个月，没有QA资源给我们测试，只能自己测，在mesos上部署还搞了一周，DB，DNS，deploy.json, 超级烦。
不过好歹，七月份终于上线了，又经过了两周的线上测试，修了几个bug，现在看起来还不错。
一些简单的功能：
- 支持多个项目：不同项目有自己不同的配置和实验
- 支持多service绑定测试：同一个项目中有多个不同的service
- 配置/实验区分国家： 不同的国家有不同的配置/测试
- 可根据UserID，SessionID等维度划分实验流量
- 支持配置权重：同一个配置有多个值，值附带权重属性
- 配置多版本，实验多版本：不同版本同时保存，互不冲突
- 实时分析试验结果：不必麻烦数据团队隔夜处理数据，计算CTR
大概有36个API，因为没有前端（PM画了界面，但是没人有时间写），我还写了一个简单的Python Cli程序。对了，程序语言是Golang，当然。
我给系统起名叫 Mendel，但是PM的PRD上叫MVT，Multiple Variable Testing system，这个名字个人感觉很low，不如“孟德尔”有意思。不过我才是写代码的人，我想怎么写就怎么写（傲娇）。
架构
整个系统分为四个部分：
- Mendel Server
- Mendel Assistant
- Database
- MySQL DB
- etcd
- influxDB
- Mendel Lib
Mendel Server 负责处理所有API请求，基本上就是CURD，接受请求，验证处理，存入DB，同步到etcd上。这部分写起来其实很讨厌，虽然简单，但是太麻烦，每一个接口都要有CURD，我原来想用MongoDB作为后端存储，但是公司不提供MongoDB的维护，自己用容器风险又太大（没人维护），只能用MySQL，然后用text保存数据。因为如果想要满足设计，配置就需要相当复杂，区分国家，配置权重，service关系，不同配置的层级关系，用MySQL字段保存的话太麻烦了，也不能满足多种层级。其实写好一个CURD也不是容易事，太多细节需要考虑，不仅仅是麻烦的问题。
Mendel Assistant
这个组件是为了实时分析实验结果的，通过实时读取Tracking数据，获取Tracking里面的AB Testing Siganture，解开Signature，写入InfluxDB和暴露metrics给Prometheus，计算不同实验的CTR，对比效果。Mendel Server部署一个就够了，他只是个CURD Server，但这个Assistant需要部署很多个，毕竟Tracking的数据量太大了。
Database
MySQL，所有的“配置”都在这里，包括各个项目的元信息，基础配置，实验配置，流量分配（以后还会有用户管理，没来得及实现用户系统）
Etcd，也是存储各种的配置信息，不过它还有解藕client与db的功能，也是作为一个缓存的存在，也作为发布/更新配置与实验的中间件（归功与etcd v3的gRPC长连接watch）（唉，但是自从接手etcd以来，已经踩了好多坑了……）。
InfluxDB，存储我们的试验结果，因为其支持多个field，不像projetheus那样只能有固定个数的lables。需要多个fields的原因是，系统运行中，配置会随时更改，增加或者删除某一些层级配置，比如有时候想测试某种算法的好坏，但一旦测试完成，就有可能把这一层的配置删掉，固定用测试结果优秀的算法，或者动态更改配置的阈值，有时候是0.2,有时候是0.3,有时候是0.5,这都是不可预测的，所以只能用InfluxDB解决。且InfluxDB聚合能力还可以，虽然是单点（公司不给出钱买商业版），但我还没遇到什么瓶颈，如果数据丢了，重新set一下Kafka的Offset，再跑一边写进去就是了。
Mendel Lib
原来的设计是没一个请求进来，我们用一个TrackingID去标记，然后在TrackingID上append不同的配置，写入一个KV存储中，但是Lead说，公司的Codis不靠谱，没有一个靠谱的持久化KV存储，如果TrackingID的数据丢了就麻烦了，所以最后折中了一个Signature的方案，从很长的配置细节变成一个能够自解的signature，并且signature对外不可读。对于signature的介绍将在本文最后进行。
其实用trackingID的方式是最好的，这样不仅可以用来标记数据，也可以用这个ID对请求进行追踪，比如在什么时候产生了访问，返回了多少广告，关键词是什么，在什么时候点击的，点击了第几个位置，这个位置的广告的平均CTR是多少，rank分是多少，similarity是多少，这些数据对于我们分析用户行为，提升算法精准度，都是有很大帮助的，但是无奈，只能用signature去自解AB Testing的数据。无奈。
配置结构
在这套系统中，有几个关键的概念：
- project: 拥有独立流量（独立请求和返回结果）的业务线称为一个项目
- base_config: 项目的基础配置，一个项目配置中，可以包含多个服务
- service: 服务，一个服务配置中，包含多个模块配置
- module:：模块，具体表现为程序的某个模块，可以包含多个层级配置
- layer: 在程序中的特定层，具体为某一个模块中的某一个步骤
- config value: 对层级的配置，包括这个层中，对国家的配置值，不同值的权重等
- traffic slots: 每一个项目拥有自己独立的流量分配，每一个国家也有独立的流量分配（保证了实验的可以在国家的维度进行）
- experiment: 每一个实验本质上也是一套配置，不过是建立在基础配置之上的特定修改，而且实验配置不能超出基础配置，一定是修改。实验可以根据不同的维度划分，比如根据UID划分，根据SessionID划分，但是它们一定是共享整个项目的流量的，相同国家内的流量不能够重叠交叉。实验中对于layer的配置也可以有多种，且对于每一种配置值，其权重都是相同的（有别于base config中的config value）。对于实验没有修改的layer，当base config中layer有变更时，experiment也要同步进行修改，更新，下发。
对于base config和expeirment config，所有数据都有唯一的ID和版本号，保证了不会有数据丢失，方便回滚和审计。
文字描述起来有些枯燥啦，但我不确定能不能把图放上来，权且当个备忘录吧。
其实实际应用起来，区分service和module的意义不大，而且还增加了client lib的复杂度，因为程序只需要从一个layer中根据国家，session，uid取出一个值而已，设计service和module这两个层级，是为了“人”方便配置，区分不同的服务和模块。当时设计的时候，也是不想把那么多层都罗列起来，看起来就很乱，也避免了多个模块有相同名称的layer的情景，比如常见的，大家都叫handler，或者score，或者threshold。
所以猜也能猜到，这个配置会巨长无比，虽然复杂了点，但至少逻辑清晰，通俗易懂。用数据的冗余换取计算的轻便。
Signature
这个地方比较有意思，我甚至一开始还在考虑能否实现。但程序没有做不到的事情，最终还是通过各种方法做到了。
一个signature要表示很多东西，完全独立的“自解”，就只能沿袭曾经的做法，把每一层配置都写上，但是因为层的名称太长了，我们就可以给每一层编号，变成ABCDE，这里也有个问题是，一个项目中的配置不能超过26层，否则就溢出了（当然可以用小写字母缓解，但因为目前还没有这么多层，估计以后也不可能在一个项目中出现这么多的测试，所以就先只用大写字母来表示每一层的名称），所以，就需要一个外部的map，去解释ABCD分别代表着哪一层，而且不同的层有多个值，每种值又多种多样，有数字，有字符串，有布尔，有小数。所以类似于给层名编号，我们也可以给这些值编号，012345，所以也需要一个map，用来解释在某一层中，第0号的值是多少。
所以，一个signagure可以从 algorithm=abcdefg; threshold=0.1 变成 A0B0 的形式，进而，变成 AB0。所以我们就会得到一些 AB0C1D3, AE0BC1D2 的signature。还可以保留一些负值，作为特殊用途，比如default，failed，skip等。
但是光这个还不够，我们还要区分是在哪一个项目中，在哪一个实验中，在哪一个实验的哪一个版本中。因为PM们肯定会想着修改实验参数和实验条件的，这就导致了实验的配置会变化，以致相同的signature会有不同的阐述。所以，就需要引入一个prefix，去表示是在哪一个项目的哪一个实验的哪一个版本中：1.2.1, 1.b.3, b表示base config。有了这三个数字，我们就可以在数据库中拿到一个唯一的配置。比如 1.2.1 就表示第1号项目的第2个实验的第1个版本，1.b.3 就表示1号项目的第3个版本的基础配置。
同时，我们还要有一个最关键的额外参数，国家。对于不同的国家，每一个signature所表示的含义也都不一样，不仅是因为在相同的实验版本中，对国家的测试值不同，还有可能是在base config中，不同国家的配置值也有可能不一样。 但是由于请求和返回结果中都带了country这个字段，所以没有必要在signature中也保存国家。
所以我们最终的signature就会变成 1.2.1@AC0B2D1 这种形式。
解释这个signature的时候，我们需要取出 project, experiment(or base config), version, 这三个基础ID来确定我们的配置是哪个，然后根据不同的层的应用值（A0, B1, C0），在配合是哪个country，来确定具体应用的值是哪个。
当然，signature client实现的时候，还要考虑缓存（相同的signature会有很多，因为就那么几种组合），考虑insert db（不用每次都range config然后找对应的配置是什么），考虑各种错误等等。