У меня есть служба весенней загрузки, где значения конфигурации хранятся в git и выбираются с помощью сервера конфигурации. Развертывание выполняется в кластере Docker Swarm, где эта служба будет работать в нескольких контейнерах. Поэтому я должен иметь в виду, что когда вызывается конечная точка обновления привода, она обновляет все контейнеры для этой службы без проблем, а не просто случайный контейнер. Это довольно очевидный вопрос, я верю.
Я могу реализовать обновление значений конфигурации для службы по мере изменения конфигурации в git с помощью брокера сообщений. Однако, это заняло бы время, и времени сейчас не со мной.
Я придумала два быстрых решения и хотела бы получить вашу помощь, основываясь на вашем опыте в том, какое из них лучше другого. Имейте в виду, что оба работают, и я проверял их обоих.
Раствор 1
Создайте планировщик с помощью @Scheduled в Application.java и продолжайте пинговать конечную точку обновления привода каждые 5 секунд. Я думаю, что это действительно дорого и ресурсоемко в производстве.
Решение 2
Вызовите конечную точку обновления привода в самом методе контроллера. Таким образом, я вызвал обновление конечной точки по требованию и не продолжал опрашивать ее, как решение 1, и был расточительным. Это также гарантирует, что какой бы контейнер не был выбран для обслуживания запроса, он обновляет себя, так как вызов конечной точки обновления обновляет свойства, указанные только этим контейнером.
Есть ли у вас какие-либо предпочтения по отношению к другому? Видите ли вы плюсы и минусы этих решений? какой бы вы выбрали и почему?
Пожалуйста, дайте мне знать, что вы думаете.