TOC

Spring Cloud Bus

Spring Cloud Bus

1. обзор

В этой статье мы рассмотрим новый проект Spring Cloud Bus. Spring Cloud Bus использует облегченный брокер сообщений для связи узлов распределенной системы. Основное использование - широковещательная рассылка изменений конфигурации или другой управляющей информации. Мы можем думать об этом как о распределенномActuator.

В проекте в качестве транспорта используется брокер AMQP, но вместо RabbitMQ можно использовать Apache Kafka или Redis. Другие транспорты пока не поддерживаются.

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

2. Предпосылки

Прежде чем мы начнем, рекомендуется уже заполнить «Quick Intro to Spring Cloud Configuration». Мы собираемся использовать существующие сервер и клиент облачной конфигурации, чтобы расширить их и добавить автоматические уведомления об изменениях конфигурации.

2.1. RabbitMQ

Начнем с RabbitMQ, который мы рекомендуем использовать какRabbitMQ as a docker image. Это довольно просто настроить - чтобы RabbitMQ работал локально, нам нужноinstall Docker и выполнить следующие команды после успешной установки Docker: 

docker pull rabbitmq:3-management

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

Далее мы можем запустить RabbitMQ: 

docker run -d --hostname my-rabbit --name some-rabbit -p 15672:15672 -p 5672:5672 rabbitmq:3-management

Выполнив команду, мы можем перейти в веб-браузер и открытьhttp://localhost:15672, который покажет форму входа в консоль управления. Имя пользователя по умолчанию:‘guest'; пароль:‘guest'. RabbitMQ также будет прослушивать порт 5672.

3. Добавление привода в клиент Cloud Config

У нас должен быть запущен сервер облачной конфигурации и клиент облачной конфигурации. Для обновления изменений конфигурации каждый раз требуется перезагрузка клиента, что не идеально.

Давайте остановим клиент конфигурации и аннотируем класс контроллераConfigClient с помощью@RefreshScope: 

@SpringBootApplication
@RestController
@RefreshScope
public class SpringCloudConfigClientApplication {
    // Code here...
}

Наконец, давайте обновим файлpom.xml и добавим Actuator: 


    org.springframework.boot
    spring-boot-actuator
    1.5.5.RELEASE

Последнюю версию можно найтиhere.

По умолчанию все чувствительные конечные точки, добавленные приводом, защищены. Это включает конечную точку‘/refresh'. Для простоты отключим безопасность, обновивbootstrap.properties: 

management.security.enabled=false

Давайте сначала запустим клиент и обновим роль пользователя с существующего‘Developer' до‘Programmer' в файле свойств на GitHub. Сервер конфигурации сразу покажет обновленные значения; однако клиент этого не сделает. Чтобы клиент видел новые файлы, нам просто нужно отправить пустой запрос POST в конечную точку‘/refresh', который был добавлен исполнительным механизмом: 

$> curl -X POST http://localhost:8080/refresh

Мы вернем файл JSON с обновленными свойствами: 

[
  "user.role"
]

Наконец, мы можем проверить, была ли обновлена ​​роль пользователя: 

$> curl http://localhost:8080/whoami/Mr_Pink
Hello Mr_Pink! You are a(n) Programmer and your password is 'd3v3L'.

Роль пользователя была успешно обновлена ​​путем вызова конечной точки‘/refresh'. Клиент обновил конфигурацию без перезапуска.

4. Spring Cloud Bus

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

Чтобы решить эту проблему, мы можем использовать Spring Cloud Bus.

4.1. клиент

Нам нужно обновить клиент облачной конфигурации, чтобы он мог подписаться на обмен RabbitMQ: 


    org.springframework.cloud
    spring-cloud-starter-bus-amqp
    1.3.1.RELEASE

Последнюю версию можно найтиhere.

Чтобы завершить изменения конфигурации клиента, нам просто нужно добавить детали RabbitMQ в файлapplication.yml: 

---
spring:
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest

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

Теперь у клиента будет другая конечная точка‘/bus/refresh'. Вызов этой конечной точки вызовет:

  • получить последнюю конфигурацию с сервера конфигурации и обновить ее конфигурацию с пометкой@RefreshScope

  • отправить сообщение в биржу AMQP с информацией о событии обновления

  • все подписанные узлы также обновят свою конфигурацию

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

4.2. сервер

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


    org.springframework.cloud
    spring-cloud-config-monitor
    1.3.1.RELEASE

Последнюю версию можно найтиhere. 


    org.springframework.cloud
    spring-cloud-starter-stream-rabbit
    1.2.1.RELEASE

Самую последнюю версию можно найтиhere.

Мы будем использоватьspring-cloud-config-monitor для отслеживания изменений конфигурации и широковещательных событий, используя RabbitMQ в качестве транспорта.

Нам просто нужно обновитьapplication.properties и предоставить сведения о RabbitMQ: 

spring.rabbitmq.host=localhost
spring.rabbitmq.port=5672
spring.rabbitmq.username=guest
spring.rabbitmq.password=guest

4.3. GitHub Webhook

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

Нам нужно настроить GitHub Webhook. Давайте зайдем на GitHub и откроем наш репозиторий, содержащий свойства конфигурации. Теперь давайте выберемSettings иWebhook. Нажмите кнопкуAdd webhook.

URL-адрес полезной нагрузки - это URL-адрес конечной точки нашего сервера конфигурации‘/monitor'. В нашем случае URL будет примерно таким:

http://root:[.cf_email # [электронная почта защищена] #_ IP: 8888 / монитор]

Нам просто нужно изменитьContent type в раскрывающемся меню наapplication/json.. Затем оставьте полеSecret пустым и нажмите кнопкуAdd webhook - после этого все готово.

5. тестирование

Убедимся, что все приложения работают. Если мы вернемся и проверим клиент, он покажетuser.role как‘Programmer' иuser.password как «d3v3L»: 

$> curl http://localhost:8080/whoami/Mr_Pink
Hello Mr_Pink! You are a(n) Programmer and your password is 'd3v3L'.

Раньше нам приходилось использовать конечную точку‘/refresh' для перезагрузки изменений конфигурации. Давайте откроем файл свойств, изменимuser.role обратно наDeveloper и внесем изменения: 

user.role=Programmer

Если мы проверим клиента сейчас, мы увидим: 

$> curl http://localhost:8080/whoami/Mr_Pink
Hello Mr_Pink! You are a(n) Developer and your password is 'd3v3L'.

Клиент конфигурации обновил свою конфигурацию без перезапуска и без явного обновления почти одновременно. Мы можем вернуться к GitHub и открыть недавно созданный Webhook. В самом низу находятся Недавние поставки. Мы можем выбрать один в верхней части списка (при условии, что это было первое изменение - в любом случае оно будет только одно) и изучить JSON, который был отправлен на сервер конфигурации.

Мы также можем проверить конфигурации и журналы сервера, и мы увидим записи: 

o.s.cloud.bus.event.RefreshListener: Received remote refresh request. Keys refreshed []

6. Заключение

В этой статье мы взяли существующий весенний облачный конфигурационный сервер и клиент и добавили конечную точку привода для обновления конфигурации клиента. Затем мы использовали Spring Cloud Bus для трансляции изменений конфигурации и автоматизации обновлений клиента. Мы также настроили GitHub Webhook и протестировали всю настройку.

Как всегда, код, использованный во время обсуждения, можно найтиover on GitHub.

Related