vivo 互联网平台产品研发团队 - Bao Dawei

本篇介绍了vivo霍金试验平台的零碎架构以及业务倒退过程中遇到的问题以及对应的解决方案。

《平台产品》系列文章：

1.vivo平台化实际探索之旅-平台产品系列01

一、前言

互联网企业经验过横蛮成长的开辟红利期之后，逐步越发器重产品倒退的科学化、精细化，从粗放型向集约型转换。在美国，增长黑客等数据驱动增长的方法论，正在帮忙如Google、Microsoft、Facebook等寰球科技巨头实现继续的业务增长；在国内，数据精密经营、AB试验剖析来驱动业务无效增长也逐步成为共识，成为外围伎俩。其中，A/B测试平台作为典型代表，天然成为了国内支流公司中必不可少的外围工具，无效的晋升流量的转化效率和产研的迭代效率。

在过来几年，vivo互联网继续器重迷信的试验决策，这意味着所有对用户的改变的公布，都要决策者以相应的试验论断作为根据。比方，批改顶部广告的背景色、测试一个新的广告点击率 (CTR) 预测算法，都须要通过试验的形式进行，那么一个弱小的A/B试验平台就十分重要了。vivo霍金试验平台（以下简称霍金）曾经从一个繁多零碎成长为了解决A/B试验相干问题的公司级一站式平台，助力互联网外围业务的疾速、精确试验，高效推动业务增长。

二、我的项目介绍

2.1  A/B试验

在互联网畛域，A/B试验通常指一种迭代办法，这种办法能够领导如何改良现有产品或者服务。以晋升某个产品下单转化率为例，AB试验过程中，咱们设计了新的下单页面，和原页面相比，页面布局和文案做了调整。咱们将用户流量随机分成A/B两组（别离对应新旧页面），50%用户看到A版本页面，50%用户看到B版本页面，通过一段时间的察看和统计，发现A版本用户下单转化率为70%，高于B版本的50%。那么咱们得出A版本成果好，进而将新页面推送并展现给所有用户。

以上就是一个利用AB测试迭代产品性能的具体利用，咱们将A/B试验的残缺生命周期分为三个阶段：

  1. 试验前，明确改良指标，定义试验指标，实现相干性能开发和上线；
  2. 试验中，制订每个实验组流量比例，依照分流比例凋谢线上流量进行测试；
  3. 试验后，试验成果评估并决策。

2.2 分层试验模型

霍金的分层试验模型参考谷歌公布的重叠试验框架论文：《Overlapping Experiment Infrastructure: More, Better, Faster Experimentation》实现设计。

2.3 平台倒退及在vivo业务中的利用和价值

霍金启动于2019年，历经三年多的倒退，目前日均试验数量达到900多个，高峰期1000+。

  • 撑持vivo国内与海内业务，服务公司20多个部门。
  • 通过标准化的试验流程升高了试验门槛，晋升试验效率。
  • 通过自动化的数据分析工具辅助业务疾速决策，晋升产品迭代速度，无效助力业务倒退。
  • 平台能力复用，防止不同组织反复建设的状况，无效的晋升了生产效率。

三、霍金零碎架构

3.1【试验人员】

试验人员蕴含多个角色，供业务方在霍金治理后盾进行试验、指标的治理和试验成果的剖析。

3.2【试验门户】

包含两局部性能：试验治理和试验成果剖析。

3.2.1 试验治理

平台提供可视化页面供业务方进行试验配置、分流策略的抉择、流量的调配以及白名单的治理。

3.2.2 试验成果剖析

包含如下4个外围能力：

1. 指标治理

不同试验关注指标不同，为了实现成果评估自动化，平台提供了指标配置和集成能力。

【必看指标】：通常为业务外围指标，每个试验都须要保障不能有显著负向的指标，平台通过集成大数据指标管理系统，这部分指标后果间接复用指标管理系统的数据服务。

【个性化指标】：通常为试验中长期剖析的指标，如某banner款式试验，察看的指定banner的曝光点击率。平台提供了自定义指标配置的能力，并通过大数据计算平台主动生成计算工作，实现自定义指标自动化产出数据的能力。

2. 比照剖析和显著性论断

成果评估的可视化展现，平台积淀了比照剖析和显著性论断等可视化组件。十分直观的告知实验者，每个试验计划相比对照计划整体晋升幅度以及每日的涨跌幅。同时给出指标的置信区间和显著性论断。

3. AA剖析

平台提供的AA剖析，目标是帮忙实验者验证理论进入试验的不同计划的人群，试验前在业务外围指标上是否存在显著差别，辅助实验者判断试验论断是否牢靠。

4.分流实时监控

能够直观的看到实时分流的成果，针对流量异样能够及时人工干预和解决。

3.3  【试验分流服务】

1. 多端接入服务

平台依据业务的不同诉求提供丰盛的接入能力，如针对安卓客户端的Android SDK、服务端的JAVA SDK、基于NGINX进行分流的H5试验服务、dubbo/http服务，C++ SDK待建设。

2.试验分流的形式

平台提供了稳固高效的在线实时分流服务。

  • 【随机分流】：依据用户标识符基于哈希算法对人群进行随机分组并分流
  • 【指定人群分流】：试验前圈定一拨人群并打上标签进行分流
  • 【协变量平均分流】：在基于哈希算法对人群随机分组的时候，尽管分组的人群数量等比例划分，然而分组的人群散布的指标存在不平均的状况，导致试验成果达不到预期。为了解决这个痛点，平台推出了协变量均衡算法，

该算法可能保障人群在进行分组样本量平均的同时，人群上指标散布也是平均的。

详见本文：4. vivo霍金试验平台实际→4.1 协变量均衡算法 的具体介绍。

  • 【基于openresty web服务分流】：针对服务端非JAVA语言，对性能有着严苛要求的业务方，咱们在NGINX基于OpenResty采纳lua脚本实现了一套试验分流性能，以http接口提供服务，均匀响应工夫小于1ms，p9999<20ms。

3.4 【分流数据处理服务】

采纳公司对立的数据采集组件进行分流数据的采集、加工，并最终存储至HDFS。

3.5【指标计算服务】

独立的服务用于高效计算指标后果，同时装备了指标计算失败重试和监控告警机制，无效的保障了指标计算成功率。

3.6【数据存储】

次要是利用MySQL来进行业务数据的存储，同时采纳Ehcahe进行试验配置的次要缓存，Redis作为辅助缓存，最初试验分流的数据通过加工解决后保留到HDSF中，供后续的试验数据分析应用。

四、霍金实际

下面介绍了霍金的倒退状况以及整体的零碎架构，接下来介绍下在平台倒退过程中遇到的问题以及对应的解决方案。

4.1  协变量均衡算法

4.1.1 遇到的问题

业务方在进行试验对象分组的时候，最罕用的做法是依据试验对象的某个属性进行哈希后对100取模，依据后果分到不同组。尽管hash算法分流能够做到尾号号段散布平均，然而分完组后，可能存在不同组的试验对象在某些指标特色上散布不匀均，导致试验成果评估不精确。如下图所示（图中四个不同色彩代表不同的人群以及对应的指标类型）：

有没有一种形式可能实现对人群进行平均分组的同时，保障人群对应的指标散布也是平均的呢，如下图所示：

4.1.2 解决方案

1. 协变量均衡算法

该算法可能保障对人群进行平均分组的同时，人群对应的指标散布也是平均的。整体由三局部组成，示意图如下：

（1）离线分层抽样

须要经验如下3个步骤：

  • 和业务方确定外围指标
  • 采纳等比例分层+Kmeans聚类模型实现指标对应的用户的分层抽样
  • 将分层抽样好的数据写入hive库相干表中

这里介绍下等比例分层抽样

等比例分层抽样：

第i层应抽取的样本数量；第i层的总体样本数量；N 整体可用的流量总数；n 本次试验设定的流量样本数量

假如N为3kw，n为50w。依照以下维度进行分类：

共有9种组合，确定每种组合别在总量中的占比（总数N=3kw，通过在整体可用流量中筛取特定人群）：

通过公式计算失去每层的样本数量；对应分类的样本数量（总样本量60w）：

至此实现了整个离线分层抽样的工作，接下来介绍下实时平均分组。

（2）实时平均分组

须要经验如下4个步骤：

  • 数据同步

通过配置的定时工作将筹备好的分层抽样数据由hive库相干表同步至redis，数据包含每天的用户标识符（uid，下同）到层的映射，以及每天每层所领有的用户占比。

  • 试验创立

通过试验编号，实验组编号和每个实验组的样本量创立试验。创立的试验会与以后最新一天的用户数据相关联，通过 样本量 * 层用户占比能够确定该层每个实验组的样本量。

  • 试验分流

通过试验编号和用户标识符（uid） 先找到用户所在的层，之后将用户平均的调配到该层下的实验组中，保障实验组之间在不同层上分流的用户平均。如下图所示：

  • 用户数据删除

因为咱们采取的计划须要每天同步大量数据，所以对于无用的用户数据须要及时删除，减少资源利用率。

实时平均分组整体流程图如下：

在做实时平均分组的时候，面临性能和存储的压力，为此咱们别离设计了高性能分流计划和高内存利用率用户信息存储方案设计。

高性能分流计划

咱们通过不同的redis数据结构和lua脚本实现层下桶的平均调配

计划1

事后调配每一个桶的样本量，每次选出以后样本量最多的桶Redis构造：HASH，field为对应的桶编号，value为桶对应的以后样本量

计划2

事后调配每一个桶的样本量，每次选出以后样本量最多的桶Redis构造：SORTED SET，key为对应的桶编号，score为桶对应的以后样本量

计划3

通过以后层样本量与桶大小取模选出命中的桶Redis构造：HASH

计划1：在只有两个桶时领有最高的性能，是计划3的1.05倍，但其性能随着桶的增多而线性缩小。

计划2：领有稳固的性能。

计划3：领有稳固的性能，但性能是计划2的1.12倍，是单GET申请性能的58%。

综合思考抉择计划3。

高内存利用率用户信息存储方案设计

uid-层的内存耗费比照

计划1：应用redis string存储。

计划2：分为10000个hash存储。

计划3：分为10000个一级桶，每个一级桶下有125个二级桶。

假如uid为15位数字，层id为2位数字，思考过期工夫，不思考cluser模式下的额定耗费，不思考malloc内存碎片和占用。

综合思考抉择计划3。

（3）离线剖析验证

因为协变量算法试验流程比较复杂，所以咱们还是采纳人工取数的形式进行试验成果的剖析。

4.2   Java SDK

4.2.1 遇到的问题

晚期Java SDK的能力较弱，只提供了分流，须要接入方上报分流后果数据，对接入方而言革新老本较大；故过后次要以Dubbo接口对外分流服务，在服务内由平台服务端对立进行分流后果数据的上报。

随着接入方越来越多，频繁产生Dubbo线程池耗尽、或者因为网络起因导致分流失败的状况产生，导致分流体验很差，影响试验成果剖析；面对上述问题，平台除了一直地做性能优化外，还须要不停的对应用服务器等资源做扩容，造成肯定的资源节约。

4.2.2 解决方案

针对上述情况，霍金开发团队通过充沛的技术计划钻研，对Java SDK进行了数次降级，胜利解决上述问题。目前具备了试验分流、分流后果的上报、试验配置实时&增量更新、SDK自监控等外围性能，极大的晋升了分流的稳定性和成功率。

4.2.3 SDK6大外围能力

1. 分流后果上报

在SDK外部依靠公司的数据采集组件进行分流后果的上报。

2. 分流后果上报失败的兜底计划

在进行分流上报的时候，因为数据链路无奈保证数据100%的完整性，如果遇到机器宕机，业务服务异样，网络异样等状况，试验分流数据上报失败，间接影响试验成果剖析。

如何保障在任何状况下试验分流数据100%不失落，为此霍金试验平台设计了一套分流数据落磁盘的计划，作为异样场景的兜底措施，从而100%保障了数据的完整性，设计图如下：

3. 试验配置实时&增量更新

在通过定时工作拉取试验配置至业务方本地缓存的形式外，还提供了实时和增量更新，实用于对试验配置变更时效性要求高的业务，能够通过开关管制，动静失效，默认采纳实时增量更新 + 定期全量更新，不便业务方灵便应用。上面是配置实时与增量更新的流程图：

在实时更新产生失败的状况下，咱们设计了失败退却策略：采纳指数级失败退却策略, 默认长轮询的距离为1s，每次失败距离减少2倍, 最大为60, 所以增长序列为1, 2, 4, 8, 16, 32, 60；每次胜利将距离置为1。

此外咱们做了数据最终一致性的保障，保障SDK拉取配置时最终能够拉取到最新的配置，且不会呈现配置回退：

  • 试验信息和模块信息缓存的刷新是线性的。
  • 同一次变更的试验信息缓存的刷新在模块信息缓存刷新之前（发送缓存刷新音讯时保障试验缓存刷新音讯在模块缓存刷新音讯之前）。
  • 模块信息缓存的刷新时不会呈现版本号跳跃问题（缓存办法入加入上版本号，刷新缓存时将数据库的版本号与传入的版本号比照，如果版本号不统一则打印日志并应用传入的版本号作为此次缓存刷新的版本号）。
  • SDK拉取配置并更新本地配置时，只更新拉取配置版本号大于等于本地配置版本号的配置

4. 多级配置管理

SDK 反对多级配置管理，优先级顺次为：办法入参的配置(原有) > 业务方配置核心灰度配置 > 业务方配置核心配置 > 近程默认配置 > 本地默认配置；业务方配置核心灰度配置是指在配置核心通过配置指定机器ip进行性能灰度。

5. 分流策略兜底

采纳SDK痛点之一是新增性能后须要业务方随之降级，否则新性能无奈应用，进而影响业务。为此霍金设计了一套兜底计划，在SDK中探测到新增的策略不存在时，通过dubbo泛化调用的形式拜访霍金服务器，保障分流性能失常；无效的保障业务方有短缺的工夫降级到最新版本，晋升用户体验。

6. SDK监控告警

采纳SDK的另一个痛点是SDK集成在业务方服务端的过程中，所打印的错误信息本人看不到，依赖业务方的反馈，显得很被动，不能第一工夫跟进解决和解决问题；针对这种状况，霍金试验平台设计一套SDK自监控计划。

自监控数据依照工夫精度预聚合后通过埋点域名上报到通用监控，自监控反对外销，新加坡和印度环境。通过监控咱们能够直观的看到每个业务、试验、SDK版本等维度是否存在错误信息，并依据相应维度配置告警，不便开发人员第一工夫跟进解决和解决问题。

4.3  H5试验

4.3.1 遇到的问题

业界在做H5试验时，通常做法是开发H5 SDK，让业务方前端引入。

存在如下几个问题：

  • 须要业务方前端做代码改变进行适配
  • 另外须要对试验的页面或者元素做遮罩，因存在页面跳转对用户体验有肯定影响
  • 试验性能发生变化时，须要业务方降级H5 SDK
  • 整个H5试验接入周期比拟长，存在肯定的接入门槛

4.3.2 解决方案

那么有没有一种简略快捷的形式，只须要接入方在后盾配置完试验就实现整个H5试验的接入呢？为此霍金开发团队设计了一套计划顺利解决了该问题，整个H5试验架构基于开源apisix搭建，业务方在霍金治理后盾创立试验时，所有基于nginx的路由配置全副自动化通过接口下发实现（配合工单审核），无需接入方在代码层面做任何批改，无侵入性，大大晋升业务方做H5试验的效率。

这里解释下几个名词：

  • 【公共VUA】：vivo unified access。vivo对立接入层，能够了解是后续替换nginx的产品，基于开源apisix搭建。
  • 【霍金VUA】：为霍金独自搭建的VUA平台，做H5试验时，公共VUA将须要做试验的页面代理到霍金VUA，霍金VUA通过开发的霍金分流APISIX插件实现试验分流。
  • 【VUA变更平台】：基于NGINX的配置变更通过在该平台上可视化操作后下发至VUA平台（公共VUA/霍金VUA）。

（1）H5试验的整体时序图

（2）NGINX → VUA 分流计划切换

公共VUA将须要做试验的页面代理到霍金VUA，霍金VUA通过开发的霍金试验平台分流APISIX插件实现试验分流。

多版本试验分流

 1）H5多版本试验介绍

同一个url做试验，通过霍金分流，不同用户拜访到的url都是雷同的，然而页面拜访内容不同（因为多版本试验是将页面版本资源公布到不同的机器上），而后通过霍金试验平台分流拜访不同的资源。

 2）H5多版本试验分流原理

  • 公共VUA将多版本试验对应的动态资源申请代理到霍金VUA。
  • 霍金VUA通过APISIX插件 依照试验配置抉择upstream并代理到对应的动态资源服务器。

3）流程示意图

  1. 多版本试验分流
  2. 多页面试验分流
  3. 霍金试验平台分流APISIX插件
  4. H5试验的分流数据采集
多页面试验分流

1）H5多页面试验介绍

多个不同url做试验，通过霍金分流，不同用户拜访到不同的url页面。

2）H5多页面试验原理

  • 公共VUA将多页面试验对应的入口业务门路的动态资源申请代理到霍金VUA。
  • 霍金VUA通过APISIX插件 依照试验配置重写门路到不同的页面。

3）流程示意图

霍金试验平台分流APISIX插件

流程示意图如下：

插件开发标准参考：https://apisix.apache.org/zh/docs/apisix/plugin-develop

H5试验的分流数据采集

H5试验的分流数据保留在霍金VUA平台的access_log中，通过如下几个步骤最终存入HIVE库的DW表中，供后续的数据分析应用。

五、试验成果剖析

该模块包含指标服务、数据分析与成果展现、准实时指标计算、AA剖析等性能，因篇幅无限，不在此开展。

六、总结与瞻望

本文次要通过介绍A/B试验在vivo的平台化、产品化的建设和实际，实现了以下的价值和能力：

  1. 用户可在平台上实现创立试验-数据分析-决策-调整试验的闭环，操作简略，灵活性高；
  2. 提供迷信牢靠的多层分流算法，流量可复用，无需发版即可疾速验证产品计划、经营策略、优化算法；
  3. 提供实时试验分流监控、小时级的指标监控以及离线数据分析性能；
  4. 反对自定义指标，无需期待分析师开发报表，即配即查。

但还存在用户体验等问题，后续咱们会重点在试验流程，数据服务性能诸如指标配置（罕用指标固化、指标配置简化）和数据展现（交互优化、多维分析、归因剖析）等进行优化和欠缺，继续晋升用户体验。

参考资料：

  • Overlapping Experiment Infrastructure:More, Better, Faster Experimentation
  • AB试验在滴滴数据驱动中的利用
  • Java™ Servlet Specification（2.3.3.3 Asynchronous processing）
  • Github：apollo
  • apolloconfig/apollo
  • APISIX文档
  • APISIX插件开发文档
  • openresty文档