ABTest介绍及abtest流量切换实现

　　本文为学习abtest切流方案方便以后查看大部分内容转载自原文 https://blog.csdn.net/tanweii163/article/details/80543083

　　互联网公司的业务发展过程中，当业务发展到一定阶段后，野蛮生长的红利逐渐消退，用户增长空间在可见策略下变得不那么明显的情况下，如何合理地规划产品迭代策略就显得尤为重要了，而具体如何判断产品策略是否有效，往往就需要数据进行判断，其结果决定了该产品或策略的生命力以及与之配套的各类资源的调配，毕竟大部分公司是不会愿意将资源浪费在无效的产品和策略上的。那么，通过什么样的工具或手段才能确保数据驱动策略的有效落地和实施呢？

　　目前支付宝通过ABTest及建设与之相适配的实验基础设施平台来实现这样的目标。作为比较前沿的一种思路与实践，虽然目前在国内的普及程度还并不是很高，但是随着国内互联网ToC流量红利的消退，这种工具会被越来越多的公司重视起来。

　　ABTest的目标&背景

　　在现实的产品设计场景中，我们经常会遇到多个设计方案的选择。例如，App或网页端某个页面的某个按钮的颜色是用蓝色还是红色，是放在左边还是右边？传统的解决方案通常是集体表决或由某位Leader拍板，类似的选择还有很多，从概率上很难保证传统的选择策略每次都是有效的，而ABTest显然是一种更加科学的方法。

　　ABTest，简单来说，就是为同一个产品目标制定两个方案（比如两个页面一个用红色的按钮、另一个用蓝色的按钮），让一部分用户使用A方案，另一部分用户使用B方案，然后通过日志记录用户的使用情况，并通过结构化的日志数据分析相关指标，如点击率、转化率等，从而得出那个方案更符合预期设计目标，并最终将全部流量切换至符合目标的方案。

　　ABTest的最终目标就是通过较少量用户体验来发布某些应用新功能。

　　实现思路

abtest对于业务开发来说，最好是独立的，也就是我们需要在业务开发之外实现，无感知切入abtest，同时注意保持业务一致性，例如在某一时期，a用户始终看到A版，B用户始终看到B版。最终我们选用nginx+lua方案，通过在nginx中执行嵌入的lua脚本，动态计算upstream,将不同的用户导向不同的程序版本，达到abtest的目的。
　　

　　具体实现

我们通过提取某一个特征cookie标识用户，该cookie在一定周期内针对同一个用户不是随意改变的。假如存在这个cookie，名称为__abc=testuser.123123,如果cookie值为数值化，可以直接进行模运算取余，如果是字符型，先进行一个hash运算得到数值，再进行模运算取余。

如果业务系统不存在特征cookie，条件允许可以在网站域下种一个新的cookie。

数据流示意图如下：