作者：ianwen 温呈博

编辑：mavisxlmeng 蒙雪莲

1

前言

《面向数据开发之AB测试平台搭建》已经对微保AB实验平台搭建思路做了具体介绍，本文将对实验平台的设计实现做详细介绍。系统在设计之初就设定了两个目标：提升实验效率，提高实验准确性。为了提升实验效率，微保实验平台实现了实验全链路可配置化，从功能上把业务系统（微保小程序，微保H5）划分模块，在模块里再划分组件，组件定义好要参与实验的特性，把这些特性和具体的实验一起配置，经过流量染色，业务系统拿到具体的实验特性做渲染。为了保证实验数据准确，微保制定了埋点规范，梳理数据上报链路，统一埋点管理等措施。

      关系如图1所示：

图1 实体关系示例

2

系统架构

2.1 业务领域视图

图2 业务领域视图

实验平台提供的核心功能包括：实验管理、组件管理、实验分析。

组件管理：管理组件，模块，埋点的属性及生命周期。

实验构建在模块、组件之上，其中组件是最小粒度，在参与实验之前，需要在实验平台创建组件，同时需要配置组件的默认特性，如果组件没有参与实验或者用户没有命中实验，则展示给用户的是组件默认特性。

实验管理：提供实验创建，流量分配，实验特性配置，基线管理，实验干预等能力。

实验配置：选择要参与实验的组件，分配实验流量桶，配置实验特性，发布实验。实验发布之后，用户访问小程序时，请求中带上userid、组件id，从实验平台获取染色后的实验信息，小程序前端获取到实验和组件特性参数后，执行渲染。前端将用户行为通过日志埋点上报数据中心，用于统计分析实验效果。

基线管理后面会详细介绍。

实验分析：实验指标配置，实验结论分析，实验下钻分析，数据可视化。

 用户行为通过日志上报的方式统一上报到日志服务，数据中心订阅日志服务数据，进行统计分析，这部分会有专门的文章介绍。

2.2 系统架构

实验平台采用微服务架构，按业务功能进行拆分，服务端保存实验策略，并实现实验染色机制，小程序端通过SDK到实验平台实时染色，拉取策略并渲染，每个用户进入小程序不同的页面可能需要到服务端拉取实验策略，这里对实验平台的响应速度有比较高的要求，目前的措施是：前端批量拉取实验策略来减少请求频率，实验平台服务端热点数据存缓来提高接口响应速度，具体架构如图3所示。

图3 系统架构图

实验平台整体上由下列服务组成：

实验管理服务：负责实验，实验组的创建，其中包括流量分配，特性配置。

组件管理服务：负责组件，模块，埋点生¬命周期管理，同时也作为基础服务，为实验管理，实验broker提供C端信息服务。

实验broker：为业务提供AB实验能力，把用户分到对应的实验组，匹配组件对应的实验特性。

埋点管理服务：从日志收集埋点数据，通过这个服务，可以知道每个实验包含了那些埋点，每个埋点包含了那些数据，每个埋点最近上报时间是什么时候，通过这些信息，我们可以分析实验数据是否准确。埋点管理的详细介绍可以阅读：《面向数据开发之埋点上报》。

染色服务：负责对用户请求进行实验分组，具体的流量划分，流量染色原理可以阅读：《面向数据开发之AB测试平台搭建》流量管理，染色机制章节，这里不再叙述。

实验分析引擎：提供定时分析指标，自动分析实验结论，多维度P值分析，实验人群下钻分析等能力。这个一块会有专门的文章介绍。

3

实体关系

实验平台实体关系相对较为复杂，具体如图4所示：

图4 实体关系图

模块至少包含一个组件，模块的范围可以调整，但是不同模块的范围不能叠加。

组件同时只能属于一个模块，每个组件要配置默认特性：没有参加实验时展示的样式。

特性的具体配置存储在配置中心，每个组件有一个默认特性，同时组件参与的每个实验组有对应的实验特性。

实验和模块相关，每个模块同时只能有一个实验，单个实验只能在一个流量层运行，可以包含多个实验组、基线。

实验组包含具体参与实验的组件，以及组件的实验特性，以及分配的流量占比。

流量相关介绍可阅读《面向数据开发之AB测试平台搭建》流量管理章节。

4

实验过程

用户访问小程序，用户登录之后，实验小程序带上要渲染的组件列表和用户id请求实验broker，broker依次获取组件定义信息，组件对应的实验信息，根据获取的信息做一些前置检查，检查通过后，到染色服务进行流量划分，划定这个用户属于哪个实验组，获取到用户对应的实验组之后，再去获取组件对应实验组的实验特性，最后把组件实验特性返回给小程序，小程序根据返回的实验特性渲染页面。

小程序通过埋点SDK把用户行为上报到日志服务，日志服务把数据发布到CMQ（腾讯云消息队列），数据中心消费CMQ消息，通过一系列的计算产生有效的数据指标。我们根据这些指标做进一步的数据分析，来判断实验的效果，最终给出结论到实验人员。

图5 实体关系图

实验过程如图5所示，2,3,5过程都是获取实验相关的配置数据，为了避免给下游服务产生性能压力，同时也为了提高响应速度，这三个步骤都加了缓存，每一个组件对下游只会产生一次请求。

5

基线管理

基线本质上是特殊的实验组，有对应的流量，有对应的组件特性，基线主要有两个作用：

1、 通用对照组：其他实验组都可以把基线作为对照组，对比实验效果。

2、 跟踪提升效果：如果一个实验组效果显著，认为可以发布对应的版本，则可以把胜出的实验组特性更新到基线。通过基线更新日志，可以清晰的展示产品提升轨迹。

基线管理分以下几个过程：

a) 创建实验的同时，创建基线。在初始阶段，基线特性和组件默认特性一致，如图6所示：

图6 初始阶段

b) 实验组对比对照组，实验效果显著，把实验特性更新到基线，如图7所示：

图7 更新基线

c) 实验特性发布到组件默认特性，如图8所示：

图8 发布特性

6

总结

随着微保业务发展，AB实验平台将发挥越来越重要的作用。为了让实验人员更快，更方便的进行实验，我们在实验配置，实验接入，C端管理等方便做了些尝试。目前实验分析这块涉及到的环节比较多，实验数据展示不友好，还需要专业的实验分析人员才能分析出实验结论，分析维度也不够丰富，后续我们将在实验分析这块做进一步的整合和优化。