【问题标题】:A/B testing. Routing Clients in a gateway APIA/B 测试。在网关 API 中路由客户端
【发布时间】:2018-01-16 16:25:14
【问题描述】:

我正在开发一个基于微服务的新项目。它是一个内部应用程序,只有大约 10 个微服务。我们将使用网关 API 进行身份验证,并可能使用一些微服务聚合。 (可能是带有 Spring Boot 的 Netflix zuul)

我不清楚的是我们如何进行 A/B 测试和 Canary 测试的路由。假设我有 100 个客户端,我们想要 A/B 测试一个新版本的微服务。客户端应用不需要更改,只是对微服务提供的功能进行内部更改。

我知道我们会建立一个新的微服务,即(比如说)v2。我感到困惑的是如何将(例如)客户 1-10 引导到新版本。我们需要能够集中配置,而不是更改客户端上的任何内容。

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

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

【问题讨论】:

    标签: microservices ab-testing api-gateway canary-deployment


    【解决方案1】:

    如果描述高级的通用方法,您可以这样做:

    1. 您的客户需要有一些参数来唯一标识它们。看起来你已经有了这个。
    2. 实现额外的 API 服务(我们称之为实验 API)。该服务应至少有一个端点接收客户端识别属性并说明客户端是否参与 A/B 测试。
    3. 对于每个传入请求,Gateway API 需要使用该 Experiment API 端点来决定使用哪个微服务版本(v1 或 v2)进行重定向/调用。
    4. 为避免每次调用 Experiment API,您可以在 Gateway API 中引入一些缓存层。作为另一种选择,您可以使用一些自定义 cookie(包含客户端是否在“实验”下),仅在未指定该 cookie 时调用 Experiment API,并将 cookie 与响应一起返回给客户端。

    【讨论】:

      【解决方案2】:

      我在 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/

      【讨论】:

        【解决方案3】:

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

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

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 2018-12-10
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2011-09-27
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多