ABTest 平台设计 - 灰度发布和早鸟用户

上篇《ABTest 平台设计 - 实验开关和分组信息传递》简单介绍了 ABTest 实验开关和数据收集的一些实现，从流量划分、到实验开关、到数据收集，基本实现了 ABTest 的主要功能。下面则扩展谈一下 ABTest 的衍生功能：

基于 ABTest 的灰度发布

与 ABTest 一样，灰度发布也是圈出来一部分流量进行新功能的线上验证，验证基本能力没有问题之后再逐渐扩大覆盖面，支持扩展到全流量。

灰度发布本身也有很多种机制，例如最常用的：上线时先上单副本，再扩展到多副本，再扩展到单机房，再扩展到其它机房。这种方式非常自然，逐步扩量观察保证了服务稳定性。

但这样在上线的中间过程中，总不可避免地会出现一些用户体验问题。比如用户相邻的多次刷新请求被路由到版本不同的副本上，导致请求结果的跳变。

既然 ABTest 同样具备划分流量的能力，而且这种划分对于单个用户来说是稳定的，其实在很多情况下可以利用 ABTest 能力来实现灰度发布。

但基于 ABTest 的灰度发布，要求在架构上提供一些支持。

比如要发布新版本的网站静态文件（css/js 等），可以全量发布多个版本，然后通过 ABTest 圈定部分用户路由到新版本的静态文件，其余则路由到原版本的静态文件。

比如要发布新版本的服务程序，可以用新的 Docker 部署新版本程序，通过 ABTest 圈定部分用户请求路由到新的 Docker 上，其余则路由到线上的 Docker 上。

基于 ABTest 的灰度发布，很多情况下可以简化服务的部署和回滚操作，也保证了用户在灰度上线期间的体验稳定性。

服务好早鸟用户

在很多时候，企业的内外部总存在着一些早鸟用户，他们对灰度 / AB 新功能有着非常迫切的需求。

最典型的早鸟用户，就是公司的老板。当你开发了一个新功能，向上汇报了一下这功能多好多好。老板会问：

“为什么我没有看到这个新功能？”

你可能不得不解释说：

“老板你的 ID 没有被随机分到实验组里。”，

或者：

“老板这个功能只上了广州机房，北京访问不了。”

还有一种早鸟用户，是产品经理、测试人员，甚至可能包括提交 BUG 的外部用户。他们需要去回归新功能的线上效果是否达到预期，而且甚至他们需要一直不停地在不同的 AB 分支上切来切去比较效果。

这时候就需要一种灵活的机制，让这些早鸟用户有办法切换 AB 功能。

很多人最直接想到的方法，是在随机分桶之外搞一个 ID 分桶，收集上来早鸟用户的 ID，手动配置实验分组。这能在一定程度上解决问题，但设想这样的场景：

“老板，把你 UserID 发来一下，我给你配一下小流量实验。”

老板心里肯定在嘀咕，我要给了你 UserID，岂不是我看过啥发过啥你都能查出来了？这以后还能有隐私么？

而且配置 ID 的方式会增加运维的工作量，尤其是用户需要切来切去的时候。所以这时候不如提供一些强制命中灰度 / AB 的后门功能，能够大幅度降低沟通和维护的复杂度。

这种给早鸟用户的后门可以有很多种做法：

写 Cookie 机制。提供一个特殊的 URL，访问该 URL 就会种下一个强制命中的实验分组 Cookie，此后带着这个分组 Cookie 的访问都会中这个实验。这种适用于 WEB 端产品。APP 端使用的话，需要做一些 Cookie 同步工作。

配置注入机制。提供一个二维码，二维码内容是一段特殊的代码，APP 扫描到该二维码，就会被注入实验分组配置。这种适用于 APP 端产品。

隐藏功能机制。在某些内容上连续点 N 下，就会弹出一个配置面板，可以用来查看和调整当前所中的实验分组。

ABTest 平台如果能够提供这样的后门机制，将会大大方便与早鸟用户的沟通和合作。

下篇，我们聊一下流量分布问题。