Spring Cloud Bus

1. Oversigt

I denne artikel skal vi se på det nye Spring Cloud Bus-projekt. Spring Cloud Bus bruger letvægts meddelelsesmægler til at linke distribuerede systemnoder. Den primære anvendelse er at udsende konfigurationsændringer eller andre ledelsesoplysninger. Vi kan tænke på det som en distribueret aktuator.

Projektet bruger AMQP-mægler som transport, men Apache Kafka eller Redis kan bruges i stedet for RabbitMQ. Andre transporter understøttes endnu ikke.

I løbet af denne vejledning vil vi bruge RabbitMQ som vores hovedtransport - som vi naturligvis allerede har kørt.

2. Forudsætninger

Før vi begynder, anbefales det, at vi allerede har gennemført “Quick Intro to Spring Cloud Configuration”. Vi tager en eksisterende cloud-konfigurationsserver og klient til at udvide dem og tilføje automatiske meddelelser om konfigurationsændringer.

2.1. RabbitMQ

Lad os starte med RabbitMQ, som vi anbefaler at køre som RabbitMQ som et dockerbillede. Dette er ret simpelt at konfigurere - for at få RabbitMQ til at køre lokalt, skal vi installere Docker og køre følgende kommandoer, når Docker er installeret med succes:

docker pull rabbitmq: 3-management

Denne kommando trækker RabbitMQ dockerbillede sammen med management plugin installeret og aktiveret som standard.

Dernæst kan vi køre RabbitMQ:

docker run -d --hostnavn min-kanin --navn noget-kanin -p 15672: 15672 -p 5672: 5672 kaninmq: 3-management

Når vi har udført kommandoen, kan vi gå til webbrowseren og åbne // localhost: 15672, som viser managementkonsolens loginformular. Standardbrugernavnet er: 'gæst'; adgangskode: 'gæst'. RabbitMQ vil også lytte på port 5672.

3. Tilføjelse af aktuator til Cloud Config Client

Vi skal have cloud config server og cloud config client begge kørende. For at opdatere konfigurationsændringer kræves en genstart af klienten hver gang - hvilket ikke er ideelt.

Lad os stoppe konfigurationsklienten og kommentere ConfigClient controller klasse med @RefreshScope:

@SpringBootApplication @RestController @RefreshScope offentlig klasse SpringCloudConfigClientApplication {// Kode her ...}

Lad os endelig opdatere pom.xml fil og tilføj aktuator:

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

Den seneste version kan findes her.

Som standard er alle følsomme slutpunkter tilføjet af aktuatoren sikret. Dette inkluderer '/Opdater' slutpunkt. For enkelheds skyld slukker vi sikkerhed ved at opdatere bootstrap.properties:

management.security.enabled = falsk

Derudover, startende med Spring Boot 2, eksponeres aktuatorendepunkter ikke som standard. For at gøre dem tilgængelige for adgang skal vi tilføje dette i et ansøgning.yml:

ledelse: slutpunkter: web: eksponering: inkluderer: "*"

Lad os starte klienten først og opdatere brugerrollen fra eksisterende 'Udvikler' til 'Programmer' i egenskabsfilen på GitHub. Config-server viser straks opdaterede værdier; klienten vil dog ikke. For at få klienten til at se nye filer, skal vi bare sende en tom POST-anmodning til '/Opdater' slutpunkt, som blev tilføjet af aktuator:

$> krølle -X POST // localhost: 8080 / aktuator / opdatering

Vi får JSON-filen tilbage med opdaterede egenskaber:

["user.role"]

Endelig kan vi kontrollere, om brugerrollen blev opdateret:

$> krølle // localhost: 8080 / whoami / Mr_Pink Hej Mr_Pink! Du er (n) programmør, og din adgangskode er 'd3v3L'.

Brugerrollen blev opdateret med succes og ved at ringe '/Opdater' slutpunkt. Klientopdateret konfiguration uden genstart.

4. Spring Cloud Bus

Ved at bruge aktuator kan vi opdatere klienter. I skymiljøet skal vi dog gå til hver enkelt klient og genindlæse konfiguration ved at få adgang til aktuatorendepunktet.

For at løse dette problem kan vi bruge Spring Cloud Bus.

4.1. Klient

Vi skal opdatere cloud config-klienten, så den kan abonnere på RabbitMQ-udveksling:

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

Den seneste version kan findes her.

For at fuldføre konfigurationsklientændringer er vi nødt til at tilføje RabbitMQ-detaljer og aktivere cloudbus i en ansøgning.yml fil:

--- forår: rabbitmq: vært: localhost port: 5672 brugernavn: gæsteadgangskode: gæstesky: bus: aktiveret: sand opdatering: aktiveret: sand 

Bemærk, at vi bruger standard brugernavn og adgangskode. Dette skal opdateres til det virkelige liv, produktionsapplikationer. Til denne vejledning er dette fint.

Nu vil klienten have et andet slutpunkt '/ Bus-opdatering'. At kalde dette slutpunkt vil medføre:

  • få den seneste konfiguration fra konfigurationsserveren og opdater dens konfiguration, der er kommenteret af @RefreshScope
  • send en besked til AMQP-udveksling, der informerer om opdateringshændelsen
  • alle tilmeldte noder opdaterer også deres konfiguration

På denne måde behøver vi ikke gå til individuelle noder og udløse konfigurationsopdatering.

4.2. Server

Lad os endelig tilføje to afhængigheder til konfigurationsserveren for at automatisere konfigurationsændringer fuldt ud.

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

Den seneste version kan findes her.

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

Den seneste version kan findes her.

Vi bruger spring-cloud-config-monitor til at overvåge konfigurationsændringer og udsendelseshændelser ved hjælp af RabbitMQ som transport.

Vi skal bare opdatere application.properties og give RabbitMQ detaljer:

spring.rabbitmq.host = localhost spring.rabbitmq.port = 5672 spring.rabbitmq.username = gæst spring.rabbitmq.password = gæst

4.3. GitHub Webhook

Alt er indstillet nu. Når serveren får besked om konfigurationsændringer, sender den dette som en besked til RabbitMQ. Klienten vil lytte til meddelelser og opdatere sin konfiguration, når konfigurationsændringshændelsen transmitteres. Men hvordan en server vil nu om ændringen?

Vi er nødt til at konfigurere en GitHub Webhook. Lad os gå til GitHub og åbne vores lagerkonfigurationsegenskaber for lager. Lad os nu vælge Indstillinger og Webhook. Lad os klikke på Tilføj webhook knap.

URL til nyttelast er URL'en til vores konfigurationsserver '/overvåge' slutpunkt. I vores tilfælde vil URL'en være sådan:

// root: [email protected] _IP: 8888 / monitor

Vi skal bare ændre Indholdstype i rullemenuen til ansøgning / json. Gå derefter væk Hemmelighed tom og klik på Tilføj webhook knap - derefter er vi alle klar.

5. Testning

Lad os sørge for, at alle applikationer kører. Hvis vi går tilbage og kontrollerer klienten, vises det user.role som 'Programmer' og user.password som 'd3v3L‘:

$> krølle // localhost: 8080 / whoami / Mr_Pink Hej Mr_Pink! Du er (n) programmør, og din adgangskode er 'd3v3L'.

Tidligere måtte vi bruge '/Opdater' slutpunkt for at genindlæse konfigurationsændringer. Lad os åbne egenskabsfilen, ændre user.role tilbage til Udvikler og skub ændringerne:

user.role = Programmerer

Hvis vi tjekker klienten nu, ser vi:

$> krølle // localhost: 8080 / whoami / Mr_Pink Hej Mr_Pink! Du er udvikler (n), og din adgangskode er 'd3v3L'.

Config-klienten opdaterede sin konfiguration uden genstart og uden eksplicit opdatering næsten samtidigt. Vi kan gå tilbage til GitHub og åbne den nyligt oprettede Webhook. Nederst er der nylige leverancer. Vi kan vælge en øverst på listen (forudsat at dette var den første ændring - der vil kun være en alligevel) og undersøge JSON, der er sendt til konfigurationsserveren.

Vi kan også kontrollere konfigurations- og serverlogfiler, og vi vil se poster:

o.s.cloud.bus.event.RefreshListener: Modtaget anmodning om fjernopdatering. Taster opdateres []

6. Konklusion

I denne artikel tog vi eksisterende spring cloud config-server og klient og tilføjede aktuatorendepunkt for at opdatere klientkonfiguration. Dernæst brugte vi Spring Cloud Bus til at udsende konfigurationsændringer og automatisere klientopdateringer. Vi konfigurerede også GitHub Webhook og testede hele opsætningen.

Som altid kan koden, der blev brugt under diskussionen, findes på GitHub.


$config[zx-auto] not found$config[zx-overlay] not found