Обновить микросервис без прерывания текущего исполнения

Предположим, у вас есть микросервисная архитектура с топологией из двух сервисов A и B, на каждой из которых запущено по 3 экземпляра.

А это веб-служба, получающая веб-запросы, а Б - это приложение на основе cli, которое прослушивает события из очереди.

Теперь вы хотите развернуть новую версию B, но поскольку экземпляры B могут обрабатывать информацию в данный момент.

Как можно развернуть, заменив старые экземпляры на новые, не прерывая текущего выполнения?

Есть ли какой-нибудь инструмент, шаблоны или стратегия, которые справляются с этими сценариями?

Есть ли в вашей очереди стратегия повтора?

monstertjie_za 29.05.2018 15:40

Вы упомянули кубернеты в теге, пробовали ли вы прокручивать обновления в кубернетах? kubernetes.io/docs/tasks/run-application/…

teon 29.05.2018 16:10

Вы можете попробовать синюю / зеленую стратегию развертывания в кубернетах: github.com/ianlewis/kubernetes-bluegreen-deployment-tutorial‌!

Rafael Manzoni 29.05.2018 17:02

да, rabbitmq и связанный с кодом код обрабатывают повторные попытки, и как на кубернетах, так и на swarm Rolling освобождают его доступный. Но вопрос больше связан с тем, как обрабатывать, если в середине этого развертывания B обрабатывал платеж или что-то критическое. и k8s, и swarm остановят контейнер независимо от того, что происходит, и тормозят выполнение

bitgandtter 29.05.2018 19:40
Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Kubernetes - это портативная, расширяемая платформа с открытым исходным кодом для управления контейнерными рабочими нагрузками и сервисами, которая...
Как создать PHP Image с нуля
Как создать PHP Image с нуля
Сегодня мы создадим PHP Image from Scratch для того, чтобы легко развернуть базовые PHP-приложения. Пожалуйста, имейте в виду, что это разработка для...
0
4
205
1

Ответы 1

Вам нужна простая стратегия, при которой вы перестаете обслуживать новые запросы для B для того экземпляра, который собирается развернуть. Если он использует события с использованием rest, вы можете использовать балансировщик нагрузки, если у вас есть балансировщик нагрузки, то с помощью шаблона consul, consul вы можете отсоединить этот экземпляр от балансировщика нагрузки. Удерживайте некоторое время, скажем, 5 минут (что вам нужно оценить), а затем начните развертывание. Использование этого подхода необходимо, если вы не знаете, как узнать, выполнил ли текущий экземпляр всю обработку существующих событий. Если эти события потребляются с помощью MQ, вы можете вызвать конечную точку, которая отключит использование нового события. А затем используйте ту же стратегию ожидания и развертывания.

Другие вопросы по теме