我遇到了客户的情况:他们想要进行A / B测试。
据我所知,大部分时间都发生在LoadBalancer级别(Kubernetes)将用户重定向到某个版本的应用程序(例如,新版本的Gmail和正在推出的版本)。
现在有了网络组件,这个客户希望拥有一个" dom-if"如果在组件中满足某个要求,则打开功能的情况。这当然会增加开销。
我想知道这是否可行。他们对这个客户的推理是,该组件可以在100多个应用程序中使用,然后创建一个构建并在其上工作,可能过于繁琐,并且在微观级别(如在组件中)将是最好的方法。他们关注Linkedin / AirBnB。
据我所知,这些公司没有使用Web Components。
问题是:什么是明智的?在微级别或应用程序级别上进行A / B测试(并使用kubernetes等负载平衡器)。
答案 0 :(得分:0)
不确定这是否涵盖了您的完整问题 - 但在微服务架构中,您可以在其自身的每项服务中进行测试。
说到Kubernetes作为托管服务的平台,您可以使用LoadBalancer
个服务从不同的Pods
中选择Deployments
。每个Deployment
可以提供不同的容器/应用程序版本,或者它可以提供相同的容器但具有不同的设置。
这是一个小例子 - 单个服务有一个选择器(app: testme
),它匹配来自两个部署的pod。部署从同一图像(yourcontainerimage:version
)定义容器,但具有不同的环境变量。此外,不同数量的副本将允许您将不同比例的流量路由到一个或另一个选项。
apiVersion: v1
kind: Service
metadata:
name: app
spec:
ports:
- name: http
port: 8080
selector:
app: testme
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: app-deployment-a
spec:
replicas: 2
template:
metadata:
labels:
app: testme
ab: on
spec:
containers:
- name: app
image: yourcontainerimage:version
env:
- name: FEATURE_TOGGLE
value: true
ports:
- containerPort: 8080
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: app-deployment-b
spec:
replicas: 1
template:
metadata:
labels:
app: testme
ab: off
spec:
containers:
- name: app
image: yourcontainerimage:version
env:
- name: FEATURE_TOGGLE
value: false
ports:
- containerPort: 8080
根据您的应用程序和您测试的功能类型,您可能需要调整服务,例如启用或禁用服务的SessionAffinity
。您可以在official docs。
答案 1 :(得分:0)
在Variant中清楚地解决了分布式服务器端(例如微服务)的情况。 (免责声明:我在那里工作)。无论哪个组件首先触及实验,都会创建一个Variant会话(独立于主机应用程序可能具有的任何会话概念,例如HTTP会话),然后将会话句柄传递给下一个组件,该组件将能够检索它并且来自Variant服务器的实验相关数据。唯一的问题是我们目前只支持Java组件。
同样,使用部署基础架构(如负载均衡器)来解决A / B测试等应用问题在很多层面都是个坏主意,应该放弃。