TOC

Spring Cloud Bus

Frühlingswolkenbus

1. Überblick

In diesem Artikel werden wir uns das neue Spring Cloud Bus-Projekt ansehen. Spring Cloud Bus verwendet einen einfachen Nachrichtenbroker, um verteilte Systemknoten zu verbinden. Die primäre Verwendung besteht darin, Konfigurationsänderungen oder andere Verwaltungsinformationen zu übermitteln. Wir können es uns als verteilteActuator vorstellen.

Das Projekt verwendet AMQP-Broker als Transport, aber Apache Kafka oder Redis können anstelle von RabbitMQ verwendet werden. Andere Transporte werden noch nicht unterstützt.

Im Verlauf dieses Tutorials werden wir RabbitMQ als Haupttransportmittel verwenden - das wir natürlich bereits ausführen werden.

2. Voraussetzungen

Bevor wir beginnen, wird empfohlen, "Quick Intro to Spring Cloud Configuration" bereits abgeschlossen zu haben. Wir werden einen vorhandenen Cloud-Konfigurationsserver und -Client verwenden, um diese zu erweitern und automatische Benachrichtigungen über Konfigurationsänderungen hinzuzufügen.

2.1. RabbitMQ

Beginnen wir mit RabbitMQ, das wir alsRabbitMQ as a docker image empfehlen. Dies ist recht einfach einzurichten. Damit RabbitMQ lokal ausgeführt werden kann, müssen Sieinstall Docker ausführen und die folgenden Befehle ausführen, sobald Docker erfolgreich installiert wurde: 

docker pull rabbitmq:3-management

Mit diesem Befehl wird das RabbitMQ-Docker-Image zusammen mit dem standardmäßig installierten und aktivierten Verwaltungs-Plugin abgerufen.

Als nächstes können wir RabbitMQ ausführen: 

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

Sobald wir den Befehl ausgeführt haben, können wir zum Webbrowser gehen undhttp://localhost:15672 öffnen, wodurch das Anmeldeformular für die Verwaltungskonsole angezeigt wird. Der Standardbenutzername lautet:‘guest'; Passwort:‘guest'. RabbitMQ lauscht auch auf Port 5672.

3. Aktor zum Cloud Config Client hinzufügen

Wir sollten sowohl einen Cloud-Konfigurationsserver als auch einen Cloud-Konfigurationsclient haben. Um Konfigurationsänderungen zu aktualisieren, ist jedes Mal ein Neustart des Clients erforderlich - was nicht ideal ist.

Beenden wir den Konfigurationsclient und kommentieren die Controller-Klasse vonConfigClientmit@RefreshScope: 

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

Zuletzt aktualisieren wir diepom.xml-Datei und fügen Actuator hinzu: 


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

Die neueste Version finden Sie unterhere.

Standardmäßig sind alle vom Aktor hinzugefügten sensiblen Endpunkte gesichert. Dies schließt den Endpunkt von‘/refresh'ein. Der Einfachheit halber deaktivieren wir die Sicherheit, indem wirbootstrap.properties aktualisieren: 

management.security.enabled=false

Starten wir zuerst den Client und aktualisieren die Benutzerrolle von vorhandenen‘Developer' auf‘Programmer' in der Eigenschaftendatei auf GitHub. Der Konfigurationsserver zeigt sofort aktualisierte Werte an. Der Kunde wird dies jedoch nicht tun. Damit der Client neue Dateien sieht, müssen wir nur eine leere POST-Anforderung an den Endpunkt von‘/refresh'enden, der vom Aktor hinzugefügt wurde: 

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

Wir erhalten die JSON-Datei mit den aktualisierten Eigenschaften zurück: 

[
  "user.role"
]

Schließlich können wir überprüfen, ob die Benutzerrolle aktualisiert wurde: 

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

Die Benutzerrolle wurde erfolgreich und durch Aufrufen des Endpunkts von‘/refresh'aktualisiert. Client aktualisierte Konfiguration ohne Neustart.

4. Frühlingswolkenbus

Mit Actuator können wir Clients aktualisieren. In der Cloud-Umgebung müssten wir jedoch zu jedem einzelnen Client gehen und die Konfiguration neu laden, indem wir auf den Endpunkt des Aktors zugreifen.

Um dieses Problem zu lösen, können wir Spring Cloud Bus verwenden.

4.1. Klient

Wir müssen den Cloud-Konfigurations-Client aktualisieren, damit er RabbitMQ Exchange abonnieren kann: 


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

Die neueste Version finden Sie unterhere.

Um Änderungen am Konfigurationsclient abzuschließen, müssen wir nur RabbitMQ-Details zu einerapplication.yml-Datei hinzufügen: 

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

Bitte beachten Sie, dass wir den Standard-Benutzernamen und das Standard-Passwort verwenden. Dies muss für reale Produktionsanwendungen aktualisiert werden. Für dieses Tutorial ist das in Ordnung.

Jetzt hat der Client einen anderen Endpunkt‘/bus/refresh'. Das Aufrufen dieses Endpunkts bewirkt Folgendes:

  • Rufen Sie die neueste Konfiguration vom Konfigurationsserver ab und aktualisieren Sie die mit@RefreshScope angegebene Konfiguration

  • Senden Sie eine Nachricht an AMQP exchange, um über das Aktualisierungsereignis zu informieren

  • Alle abonnierten Knoten aktualisieren auch ihre Konfiguration

Auf diese Weise müssen wir nicht zu einzelnen Knoten gehen und die Konfigurationsaktualisierung auslösen.

4.2. Server

Zuletzt fügen wir dem Konfigurationsserver zwei Abhängigkeiten hinzu, um Konfigurationsänderungen vollständig zu automatisieren. 


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

Die neueste Version finden Sie unterhere. 


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

Die neueste Version finden Sie inhere.

Wir werdenspring-cloud-config-monitor verwenden, um Konfigurationsänderungen und Broadcast-Ereignisse mit RabbitMQ als Transport zu überwachen.

Wir müssen nurapplication.properties aktualisieren und RabbitMQ-Details angeben: 

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

4.3. GitHub Webhook

Alles ist jetzt eingestellt. Sobald der Server über Konfigurationsänderungen benachrichtigt wird, sendet er diese als Nachricht an RabbitMQ. Der Client hört Nachrichten ab und aktualisiert seine Konfiguration, wenn ein Konfigurationsänderungsereignis übertragen wird. Wie aber wird ein Server nun über die Modifikation verfügen?

Wir müssen einen GitHub Webhook konfigurieren. Gehen wir zu GitHub und öffnen Sie unser Repository mit den Konfigurationseigenschaften. Wählen wir nunSettings undWebhook aus. Klicken Sie auf die SchaltflächeAdd webhook.

Die Payload-URL ist die URL für den Endpunkt unseres Konfigurationsservers‘/monitor'. In unserem Fall lautet die URL ungefähr so:

http://root:[.cf_email # [E-Mail geschützt] #_ IP: 8888 / Monitor]

Wir müssen nurContent type im Dropdown-Menü inapplication/json. ändern. Als nächstes lassen Sie bitteSecret leer und klicken Sie auf die SchaltflächeAdd webhook - danach sind wir alle fertig.

5. Testen

Stellen wir sicher, dass alle Anwendungen ausgeführt werden. Wenn wir zurückgehen und den Client überprüfen, werdenuser.role als‘Programmer' unduser.password als 'd3v3L' angezeigt: 

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

Zuvor mussten wir den Endpunkt von‘/refresh'verwenden, um Konfigurationsänderungen neu zu laden. Öffnen Sie die Eigenschaftendatei, ändern Sieuser.role zurück inDeveloper und übertragen Sie die Änderungen: 

user.role=Programmer

Wenn wir den Client jetzt überprüfen, werden wir sehen: 

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

Der Konfigurationsclient hat seine Konfiguration aktualisiert, ohne neu zu starten und ohne explizite Aktualisierung fast gleichzeitig. Wir können zu GitHub zurückkehren und den kürzlich erstellten Webhook öffnen. Ganz unten befinden sich die letzten Lieferungen. Wir können eine oben in der Liste auswählen (vorausgesetzt, dies war die erste Änderung - es wird ohnehin nur eine geben) und JSON untersuchen, das an den Konfigurationsserver gesendet wurde.

Wir können auch Konfigurations- und Serverprotokolle überprüfen und Einträge sehen: 

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

6. Fazit

In diesem Artikel haben wir den vorhandenen Spring Cloud-Konfigurationsserver und -Client übernommen und den Aktorendpunkt hinzugefügt, um die Clientkonfiguration zu aktualisieren. Als Nächstes verwendeten wir Spring Cloud Bus, um Konfigurationsänderungen zu übermitteln und Client-Updates zu automatisieren. Wir haben auch GitHub Webhook konfiguriert und das gesamte Setup getestet.

Wie immer kann der während der Diskussion verwendete Codeover on GitHub gefunden werden.

Related