Как выполнить тестирование A/B в полимерных веб-компонентах?

Question

Я столкнулся с ситуацией у клиента: они хотят провести тестирование A/B.

Насколько я знаю, это чаще всего происходит на уровне LoadBalancer (Kubernetes), перенаправляющем пользователей на определенную версию приложения (например, с новой версией Gmail и выпуском релиза).

Теперь с веб-компонентами этот клиент хочет иметь ситуацию с «dom-if», когда функции включены, если в компоненте выполнено определенное требование. Конечно, это добавит накладные расходы.

Интересно, если это путь. Их аргументация этого клиента заключается в том, что компонент может использоваться в 100-х приложениях, а затем создавать сборку и работать над ней, может быть слишком громоздким, а на микроуровне (как и в компоненте IN) было бы лучшим способом. Они следуют за Linkedin/AirBnB.

Насколько я знаю, эти компании не используют веб-компоненты.

Вопрос в том, что желательно? Выполнение тестирования A/B на микроуровне или на уровне приложения (и использование балансиров нагрузки, таких как кубернеты).

Answer 1

не уверен, что этот вопрос охватывает весь ваш вопрос - но в рамках архитектуры Microservice вы должны тестировать каждую службу самостоятельно.

Говоря о Kubernetes как о вашей платформе для размещения ваших услуг, у вас может быть один сервис LoadBalancer, который выбирает Pods из разных Deployments. Каждый Deployment может предоставить различные версии контейнера/приложения или он может предоставить один и тот же контейнер, но с разными настройками.

Вот небольшой пример: у одиночных сервисов есть селектор (app: testme), который соответствует наборам обоих вариантов развертывания. Развертывания определяют контейнеры с одного и того же изображения (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.

Answer 2

Случай с распределенным сервером (например, микросервисы) чисто адресуется в Variant. (Отказ от ответственности: я там работаю). Независимо от того, какой компонент сначала затрагивает эксперимент, создается сеанс Variant (независимо от любого понятия сеанса, которое может иметь хост-приложение, например HTTP-сеанс), а затем передает дескриптор сеанса следующему компоненту, который сможет его восстановить и все связанные с экспериментом данные с сервера Variant. Единственный улов в том, что мы поддерживаем только Java-компоненты в это время.

Кроме того, использование инфраструктуры развертывания, например балансировки нагрузки, для задач приложений, таких как тестирование A/B, является плохой идеей на многих уровнях и должно быть отменено.