Предположим, у вас есть микросервисная архитектура с топологией из двух сервисов A и B, на каждой из которых запущено по 3 экземпляра.
А это веб-служба, получающая веб-запросы, а Б - это приложение на основе cli, которое прослушивает события из очереди.
Теперь вы хотите развернуть новую версию B, но поскольку экземпляры B могут обрабатывать информацию в данный момент.
Как можно развернуть, заменив старые экземпляры на новые, не прерывая текущего выполнения?
Есть ли какой-нибудь инструмент, шаблоны или стратегия, которые справляются с этими сценариями?
Вы упомянули кубернеты в теге, пробовали ли вы прокручивать обновления в кубернетах? kubernetes.io/docs/tasks/run-application/…
Вы можете попробовать синюю / зеленую стратегию развертывания в кубернетах: github.com/ianlewis/kubernetes-bluegreen-deployment-tutorial!
да, rabbitmq и связанный с кодом код обрабатывают повторные попытки, и как на кубернетах, так и на swarm Rolling освобождают его доступный. Но вопрос больше связан с тем, как обрабатывать, если в середине этого развертывания B обрабатывал платеж или что-то критическое. и k8s, и swarm остановят контейнер независимо от того, что происходит, и тормозят выполнение


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