如何在 A/B 测试模式下部署 Web 应用程序

如何在 A/B 测试模式下部署 Web 应用程序

我正在寻找有关如何部署 Web 应用程序并无缝地将一定比例的用户转移到新应用程序同时仍将其余用户发送到旧应用程序的想法。我正在寻找类似于 Google 推出对 Gmail 的更改的方式 - 并非所有用户都会立即获得新版本;相反,用户群从小开始,然后慢慢增长。

任何想法都值得赞赏。我有一些自己的想法,但不想不恰当地影响回应。

答案1

您可以根据用户的某些特征(例如 guid)计算分区 cookie pt。例如,您可以将 guid 转换为整数,然后计算 mod N,其中 N 是服务器数量,然后将该值设置为 pt cookie。在负载平衡器级别,分析分区 pt cookie 并指向适当的服务器。许多负载均衡器(例如宙斯ZXTM 允许在负载均衡器脚本中实现这种类型的智能路由。

或者,您实际上可以将 A/B 分割功能构建到您的代码库中,而不是在负载均衡器上执行。

答案2

嗯,有很多方法可以回答这个问题……其中 99.9% 在很大程度上取决于您的 Web 应用程序。有些 http 负载平衡器可以执行不均衡负载,例如,可以将 5% 的负载放在一台服务器上……而将其余 95% 放在您的普通服务器上……负载平衡器可以跟踪会话,因此有限的一组用户将不断获得特定的服务器……但这不是 Google 的运作方式。

您要寻找的不仅仅是负载平衡问题,而是帐户管理。Google 为升级用户所做的只是在后台升级数据(如果需要),然后将与新升级帐户关联的用户帐户调整到新应用程序。这与简单地将一个全新的功能与用户帐户关联,然后删除另一个功能没有什么不同……只是“功能”可能是“gmail 版本 1”和“gmail 版本 2”。身份验证服务器负责将用户“重定向”到其框架内的相应应用程序。他们只是非常干净地完成这项工作。他们在后端有脚本,使整个过程非常无缝。(即安装应用程序版本 2……两个帐户并行运行……然后删除应用程序版本 1)

相关内容