Назад | Перейти на главную страницу

Как развернуть веб-приложение в режиме A / B-тестирования

Я ищу идеи относительно того, как развернуть веб-приложение и беспрепятственно перенаправить определенный процент пользователей в новое приложение, при этом отправив остальных пользователей в старое приложение. То, что я ищу, похоже на то, как, например, Google вносит изменения в Gmail - не все пользователи мгновенно получают новую версию; вместо этого пользовательская база сначала небольшая, а затем медленно растет.

Любые идеи приветствуются. У меня есть несколько собственных идей, но я не хочу ненадлежащим образом влиять на ответы.

Вы можете вычислить pt файла cookie раздела на основе некоторых характеристик пользователя, таких как guid. Например, вы можете преобразовать guid в целое число, а затем вычислить мод N, где N - количество серверов, а затем установить это значение в pt cookie. На уровне балансировщика нагрузки проанализируйте файл cookie pt раздела и направьте его на соответствующий сервер. Много балансировщики нагрузки (Такие как Зевс ZXTM) позволяют реализовать этот тип интеллектуальной маршрутизации в сценариях балансировщика нагрузки.

В качестве альтернативы вы могли бы фактически встроить функциональность разделения A / B в свою кодовую базу, а не делать это на балансировщике нагрузки.

Что ж, есть несколько способов ответить на этот вопрос ... и 99,9% из них сильно зависят от вашего веб-приложения. Существуют балансировщики нагрузки http, которые могут выполнять неравные нагрузки, которые могут (например) помещать 5% нагрузки на один сервер ... и оставшиеся 95% на ваши обычные серверы ... и балансировщик нагрузки может отслеживать сеансы поэтому ограниченный круг пользователей будет постоянно получать определенный сервер ... но Google работает иначе.

Вам нужна не просто балансировка нагрузки, а управление учетной записью. Что Google делает для обновления пользователей, так это просто обновляет данные (при необходимости) за кулисами, а затем корректирует учетную запись пользователя, связанную с недавно обновленной учетной записью, для нового приложения. Это ничем не отличается от простого связывания совершенно новой функции с учетной записью пользователя, а затем удаления другой функции ... за исключением того, что «функциями» могут быть «gmail версии 1» и «gmail версии 2». Серверы аутентификации отвечают за «перенаправление» пользователя к соответствующему приложению в своей структуре. Просто они делают это очень чисто. У них есть скрипты на сервере, которые делают весь процесс очень плавным. (т.е. установите версию приложения 2 ... обе учетные записи работают параллельно ... а затем удалите версию приложения 1)