A/B测试。在网关中路由客户端API

我正在研究一个基于微服务的新项目。这是一个内部应用程序，只有10个微服务。我们将使用网关API进行身份验证，并可能使用一些微服务聚合。（可能与Netflix Zuul弹簧启动）A/B测试。在网关中路由客户端API

我不清楚的是我们如何做A/B测试和金丝雀测试的路由。让我们假设我有100个客户，我们想要A/B测试一个新版本的微服务。客户端应用程序不需要更改，只是微服务提供的功能的内部更改。

我知道我们会站起来一个新的微服务，比如说v2。我感到困惑的是如何将客户端1-10（比如说）导向新版本。我们需要能够集中配置，而不是改变客户端上的任何东西。

我们知道他们的mac地址（以及其他识别属性），并且可以插入任何类型的我们想要识别他们的消息的头。

那么，我如何将这些指向API的v2以进行A/B测试或Canary部署？

来源

2017-08-08 mark1234

如果描述了较高水平，通用的方法，你可以做这样的事情：

您的客户需要有一定的参数，这将使唯一识别它们。看起来你已经有了这个。
实施其他API服务（我们称之为Experiment API）。此服务应至少有一个端点接收客户端标识属性，并说明客户端是否参与A/B测试。
对于每个传入请求，网关API都需要使用该实验API端点来决定哪个微服务版本（v1或v2）用于重定向/调用。
为了避免每次在网关API中引入一些缓存层时调用实验API。作为另一种选择，您可以使用一些自定义Cookie（包含“实验”下的客户端），只有在未指定该cookie的情况下才会调用Experiment API，并将cookie返回给客户端并返回响应。

来源

2017-08-10 11:13:52 Set

说明@ Set的答案。您需要在网关API中引入一些检测代码，以便决定调用哪个下游端点。如果且仅当与您有关的分布式后端的唯一组件是网关API时，上述解决方案过度设计：您可以仅使用一个库。但很可能您很快就会发现您的其他一项或多项服务需要了解该实验，在这种情况下，您需要单独的服务。

一般来说，构建一个强大的实验框架是一项艰巨的任务。您将很快遇到意想不到的问题，例如体验稳定性（如何确保返回访问者的相同体验）或如何更改分配比例（或者可能完全关闭新代码），而无需重新启动主机应用程序。您应该调查那里的开源框架，甚至是商业服务器端仪器。（我们有一个在Variant）。

来源

2017-11-14 19:52:54

我在Github上发布了一个原型，展示了如何使用Zuul Gateway实现路由。此原型仅显示如何将基于Cookie的流量路由到同一应用程序的不同实例。您可以根据任何其他条件进行路由。你也应该看看Spring Cloud Gateway作为Zuul的替代方案。似乎是非常有前途的。 https://github.com/adiesner/spring-boot-sample-ci-gateway

更简单的设置是在服务前添加nginx并使用split_clients方法。

http { 
    # ... 
    # application version 1a 
    upstream version_1a { 
     server 10.0.0.100:3001; 
     server 10.0.0.101:3001; 
    } 

    # application version 1b 
    upstream version_1b { 
     server 10.0.0.104:6002; 
     server 10.0.0.105:6002; 
    } 

    split_clients "${arg_token}" $appversion { 
     95%  version_1a; 
     *  version_1b; 
    } 

    server { 
     # ... 
     listen 80; 
     location/{ 
      proxy_set_header Host $host; 
      proxy_pass http://$appversion; 
     } 
    } 
}

https://www.nginx.com/blog/performing-a-b-testing-nginx-plus/

来源

2018-01-15 12:26:15 adiesner

A/B测试。在网关中路由客户端API

回答

相关问题