Управление пользовательским интерфейсом при развертывании канареек или А / Б с Istio

Question

У меня есть приложение с несколькими службами, которое вызывается из основной службы приложений. Я понимаю основы выполнения канареек и А / Б развертываний, однако все примеры, которые я вижу, показывают циклический перебор, где каждый запрос переключается между версиями.

Я бы предпочел, чтобы, когда данный пользователь / сеанс ассоциировался с определенной версией, он оставался таким, чтобы избежать путаницы для пользователя.

Как этого достичь с помощью Kubernetes или Istio / Envoy?

Answer 1

Вы можете сделать это с Istio, используя Request Routing - Маршрут на основе идентификатора пользователя , но я не знаю, насколько зрелой является эта функция. Также может быть возможно выполнить маршрутизацию на основе файлов cookie или значений заголовка.

Answer 2

Мы столкнулись с этим, потому что мы хотим развернуть тестовые микросервисы в рабочей среде и предоставить их только в том случае, если первый запрос содержит заголовок «темного выпуска».

Как упоминалось Jonas, файлы cookie и значения заголовковтеоретически может быть использован для достижения того, что вы ищете. Этого очень легко достичь, если услуга, которую вы перевозите, находится на грани, и ваш пользователь имеет прямой доступ.

Проблема в том, что вы упомянули, что у вас есть несколько служб. Если у вас есть цепочка, в которой пользователь обращается к пограничному сервису A, который затем выполняет вызовы к сервису B, сервису C и т. Д., Заголовки или файлы cookie не будут передаваться от одного сервиса к другому.

Это та же проблемачто мы попали при попытке сделать распределенную трассировку. Документы Istio в настоящее время имеют этот FAQ:

https://istio.io/faq/distributed-tracing/#istio-copy-headers

Суть в том, что вам придется выполнять распространение заголовка вручную. К счастью, большинство моих микросервисов основано на Spring Boot, и я могу добиться распространения заголовка с помощью простого 5-строчного класса, который перехватывает все исходящие вызовы. Но это, тем не менее, агрессивно и должно быть сделано везде. Антитеза сервисной сетки.

Возможно, есть разумный способ обойти это, но из документов трудно понять, что возможно, а что нет. Я видел несколько проблем с github, поднятых разработчиками Istio для решения этой проблемы, но все, что я видел, устарели после первоначального энтузиазма.