Восстановление трудоемкой задачи в кластере docker swarm

Question

Наше приложение содержит множество микросервисов (независимое приложение, большинство из которых основаны на java), которые развернуты в кластере docker, и каждая служба может масштабироваться во время выполнения, даже иногда весь стек может перезапускаться. тоже.

Однако при удалении или перезапуске определенной службы внутри правого контейнера могут выполняться некоторые трудоемкие задачи. Например:

1. Удаление / перезапуск контейнера при загрузке большой заливки.

2. Удаление / перезапуск контейнера при импорте данных из загруженный файл, который сохраняется в каталоге /tmp внутри контейнера.

3. Удаление / перезапуск контейнера при создании индекса для определенной таблицы данных.

4. ....

Мы должны вернуть их как можно скорее. Возьмите вышеприведенное соответствие в качестве примера:

1. Невозможно восстановить, используйте для повторной загрузки файла.

2. Необходимо восстановить, перезапустите импортировать задание из того места, где оно завершено.

3. То же, что и 2.

Похоже, нам нужна структура распространения, которая может сохранять статус всех задач , проверьте работоспособность каждой задачи, восстановите при необходимости.

Может быть предложено любое легкое решение?

Answer 1

Согласование задач между различными службами никогда не бывает легким IMO, и внедрение таких изменений, как это, может быть трудоемким и очень сложным для организации, в которой вы работаете, чтобы gr asp (я объясню позже).

Мы проходим этот процесс прямо сейчас, сначала мы попытались сделать это с помощью Spring Batch, но, как и вы, нам нужно, чтобы это было распределено по нескольким службам и было доступно, поэтому мы перешли к использованию пошаговых функций в AWS .

Вы все еще можете разрабатывать локально, но, используя немного пошаговых функций, я сделал это, реализовав довольно простой рабочий процесс для разработчиков, который включал использование их собственных частных компонентов на * 1021. * (Очереди SQS) с добавлением их переменной $USERNAME. Это должно быть так же просто, как установить некоторые переменные среды.

Но решение о том, какую инфраструктуру оркестровки использовать, должно зависеть от ряда факторов:

• У вас уже есть такая, которую вы можете использовать?
• Какой облачный провайдер, если / вы используете, у них есть решение?
• Каким опытом обладают ваши разработчики, например. если вы сильно заняты Python, возможно, вы захотите использовать решение Python и c.

Хотя реализация инфраструктуры оркестровки может быть сложной, на самом деле это не самая сложная часть, YMMV , Что мне показалось самым сложным, так это заставить бизнес принять решение о различных компромиссах. Возьмем, к примеру, восстановление, может быть, если в результате чего-то не получится, нужно повторить попытку через 5 минут, что довольно просто реализовать в пошаговой функции. Но это может означать, что задание длится дольше, чем в противном случае, прежде чем вы это реализуете, в то время как задания, которые не выполнялись, теперь выполняются со второй попытки. Я обнаружил, что нетехнические люди не понимают или не хотят этого понимать, и скажут вам, что все должно быстро выходить из строя и восстанавливаться одновременно, когда эти конфигурации конкурируют друг с другом. Кому принадлежит этот процесс тоже? Если это повлияет не только на вашу команду, это снова будет сложно, и у вас могут быть разные команды с конкурирующими приоритетами.