Когда конфигурация вашего приложения неизбежно записывается прямо в код, каждый раз, когда вам нужно применить изменение, приложение должно быть перекомпилировано или / и повторно развернуто, для благополучия клиента или даже для людей, которые делают эту работу, избегайте этого. Большинство инженеров отделяют информацию о конфигурации от исходного приложения из-за недостаточной эффективности и гибкости.
Имеются пять обычных решений этой проблемы. В этой статье я предлагаю одно из таких решений, в основном самое простое, Spring Cloud Configuration Server.
Что такое Spring Cloud Configuration Server
Смотрим официальную документацию Spring.io:
Spring Cloud Config обеспечивает поддержку на стороне сервера и клиента для внешней конфигурации в распределенной системе. С помощью Config Server у вас есть центральное место для управления внешними свойствами приложений во всех средах.
На этом сервере всякий раз, когда вы применяете простое изменение конфигурации, экземпляры микросервисов будут автоматически обновлять себя с заданными новыми свойствами. Некоторые из его особенностей:
- Он поддерживает несколько бэкэндов для хранения данных конфигурации (Etcd, Eureka, Consul, ZooKeeper и тот, который мы сейчас объясняем);
- Может быть интегрирован с системой управления версиями GIT;
- С помощью простых аннотаций вы можете запустить и запустить сервер конфигурации;
- Несколько сред профилей для каждого микросервиса (обычно dev / QA / Prod);
Как микросервисы взаимодействуют с этим центральным хранилищем
Каждый раз, когда запускается один экземпляр службы, он извлекает все данные о свойствах с сервера конфигурации через конечную точку службы, предоставляемую репозиторием. Когда происходят какие-то изменения, службы уведомляются об обновлении своей копии данных приложения.
Создание нашего сервера конфигурации Spring Cloud
- Создайте новый весенний проект (Вы можете легко сделать это через Spring Initializer).
- Убедитесь, что добавлены следующие зависимости:
- весеннее облако-стартер-конфигурация
- Весна-облако-конфигурация-сервер
Spring Cloud - это огромная коллекция независимых проектов, используется множество сторонних библиотек и зависимостей, вам необходимо указать номер версии текущего весеннего облачного проекта, от которого вы в настоящее время зависите, в данном случае Hoxton.SR8 . Весь этот код помещен в репозиторий GIT, вы можете легко зайти туда и проверить, совпадают ли все зависимости с теми, которые вставлены в ваш pom.xml или gradle.build .
3. Отредактируйте application.yml, этот файл сообщит вашей облачной службе конфигурации Spring, какой порт слушать и где найти серверную часть, которая будет обслуживать данные конфигурации. Чтобы упростить настройку и понимание концепций / шагов, я решил сохранить эти свойства конфигураций в файловой системе, однако, как вы, вероятно, знаете, в распределенной среде это может стать немного подавляющим и сделать архитектуру излишне сложной, вам следует возможно, подумайте о том, чтобы сохранить эти данные в базе данных.
В свойстве search-locations будет указано расположение файлов конфигурации вашей службы (dev / QA / Prod), просто вставив минус после имени службы, а затем контекста файла, например:
- client1.yml - ›по умолчанию
- client1-dev.yml
- client1-qa.yml
- client1-prod.yml
Spring Cloud может легко автоматически сопоставлять сервисы с каждой средой, если они следуют этому соглашению об именах.
4. Что касается самой конфигурации службы, это примерно то же содержимое, что и в исходный application.yml службы, в этом случае мы настраиваем базу данных в памяти, например:
5. Единственный пропущенный шаг - это вставка аннотации конфигурации в основной класс приложения, @EnableConfigServer, мы помещаем ее, чтобы Spring мог знать, какой контекст должен быть запущен:
6. Теперь не хватает только собрать проект и запустить его:
- mvn чистая установка
- java -jar ‹project-path› цель / конфигурация-0.0.1-SNAPSHOT.jar
И Бум, у вас есть сервер весенней облачной конфигурации, вы можете протестировать его, просто запросив следующую конечную точку:
Конфигурация клиента
- Отредактируйте bootstrap.yml в папке ресурсов. Если у вас его нет, вы можете создать его и вставить следующий контент.
Этот файл используется для конфигурации загрузки, все остальные свойства должны быть помещены в application.yml.
И все, при запуске клиента вы должны увидеть что-то вроде:
Заключение
Надеюсь, это руководство поможет вам узнать еще один весенний инструмент, всегда приятно поделиться простотой и мощью этих инструментов, которые некоторые из нас еще не знают! Весь опубликованный код будет доступен на GIT, так что вы сможете глубже изучить код, представленный в качестве клиента, используемого для этого взаимодействия. Следите за новостями.
