Spring boot application.properties в распределенной среде?

Лично я бы попытался использовать сервер конфигурации: Централизованная конфигурация. В основном вы храните свои файлы конфигурации в репозитории git с относительно простым приложением Spring Boot поверх него, к которому могут подключаться другие ваши приложения Spring Boot и запрашивать конфигурацию.

Кроме того, в сочетании с приводом он также дает вам возможность изменять конфигурацию на лету без перезапуска приложения.

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

Для начала вы можете сохранить конфигурацию внутри приложения Spring Boot, конечно, не идеальным способом, но это очень просто. Вы можете поместить application-local.properties, application-production.properties и т. д. В папку ресурсов и запустить приложение весенней загрузки с активными профилями для нужной среды.

Другая, более продвинутая установка - это использование файла конфигурации, но сохранение его вне приложения. Здесь вы развернете этот файл конфигурации отдельно от приложения, и здесь возможно множество опций, включая общие файловые системы, автоматическое развертывание и т. д. Вы можете запустить приложение весенней загрузки с --spring.config.location=<path to configuration file>

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

Это, безусловно, самая продвинутая настройка - вы даже можете динамически изменять конфигурации и не перезапускать микросервисы весенней загрузки (Google для обновляемых bean-компонентов в конфигурации весенней загрузки). Более того, вы можете сохранить конфигурацию в репозитории git, и он автоматически сможет с ней работать.

Есть и другие решения, возможно, меньшая интеграция с приложениями весенней загрузки, но их можно рассмотреть, если вы уже используете их в своей организации: etcd, consul и так далее.

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

Все две стратегии:

• Каждый узел распределенной среды имеет собственное application.properties
• Все узлы распределенной среды используют одно приложение. Свойства - хороший вариант

это зависит от того, чего вы хотите достичь.

В первом случае я предлагаю следовать шаблону Single Host Per Service Pattern и предоставить ваше приложение весенней загрузки в качестве контейнера докеров, а затем развернуть его на оркестраторах, таких как AWS ECS, Kubernetes, Swarm и т. д., Даже если предоставить одну виртуальную машину для каждой службы. решение, но я полагаю, что это может быть слишком дорого.

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

Вторая стратегия дает вам аналогичный шаблон конфигурации многих PAAS, таких как Cloud Foundry и Openshift. Все реплики приложения будут использовать одну единую точку входа в конфигурацию.

В случае Spring с Spring Cloud вы можете выбрать Spring Cloud Configuration Server. В этом случае все приложение будет запрашивать конфигурацию у сервера, сервер может быть обнаружен встроенным клиентом, который попытается получить конфигурацию, или через систему службы обнаружения, такую ​​как Netflix Eureka или Consul.

Преимущество в этом случае заключается в том, что вы можете динамически масштабировать количество экземпляров сервера конфигурации, которые будут системой обнаружения для предоставления всей зарегистрированной реплики. В случае с сервером конфигурации вы можете воспользоваться многими хранилищами конфигурации, такими как файловая система, SVN, GIT или недавно JDBC. Что еще более важно, вы можете воспользоваться специальным @RefreshScope, который создаст ваш bean-компонент в качестве прокси, и разрешите ли вы обновлять конфигурацию в горячем режиме через конечную точку исполнительного механизма / исполнительный механизм / обновление с помощью последнего Spring Cloud (Finchley) или / обновления с помощью предыдущего Spring Cloud версии, даже Spring Cloud Bus можно использовать для распространения события обновления. Если вы используете zuul, маршруты будут обновляться в случае изменений и обновления, таким образом, вы можете использовать для реализации стратегии сине-зеленого развертывания или канареечного развертывания.

Я надеюсь, что это может быть полезно для вас