streamalism.org

1. Oversigt

Spring Cloud Consul-projektet giver nem integration med Consul til Spring Boot-applikationer.

Consul er et værktøj, der leverer komponenter til løsning af nogle af de mest almindelige udfordringer i en mikrotjenestearkitektur:

• Service Discovery - for automatisk at registrere og afregistrere netværksplaceringerne for serviceinstanser
• Health Checking - for at registrere, hvornår en tjenesteinstans er i gang
• Distribueret konfiguration - for at sikre, at alle serviceinstanser bruger den samme konfiguration

I denne artikel vil vi se, hvordan vi kan konfigurere en Spring Boot-applikation til at bruge disse funktioner.

2. Forudsætninger

Til at begynde med anbefales det at kigge hurtigt på Consul og alle dens funktioner.

I denne artikel skal vi bruge en konsulagent, der kører videre lokal vært: 8500. Se dette link for at få flere oplysninger om, hvordan du installerer Consul og kører en agent.

Først bliver vi nødt til at tilføje afhængighed af forår-sky-start-konsul-al til vores pom.xml:

 org.springframework.cloud spring-cloud-starter-consul-all 1.3.0.RELEASE 

3. Opdagelse af service

Lad os skrive vores første Spring Boot-ansøgning og oprette forbindelse til den løbende konsulagent:

@SpringBootApplication public class ServiceDiscoveryApplication {public static void main (String [] args) {new SpringApplicationBuilder (ServiceDiscoveryApplication.class) .web (true) .run (args); }}

Som standard forsøger Spring Boot at oprette forbindelse til konsulagenten kl lokal vært: 8500. For at bruge andre indstillinger skal vi opdatere ansøgning.yml fil:

forår: sky: konsul: vært: lokal vært port: 8500

Så hvis vi besøger konsulagentens websted i browseren kl // localhost: 8500, vi ser, at vores ansøgning blev korrekt registreret i Consul med identifikatoren fra "$ {Spring.application.name}: $ {profiler adskilt af komma}: $ {server.port}".

For at tilpasse denne identifikator skal vi opdatere ejendommen spring.cloud.discovery.instanceId med et andet udtryk:

spring: application: name: myApp cloud: consul: discovery: instanceId: $ {spring.application.name}: $ {random.value}

Hvis vi kører applikationen igen, ser vi, at den blev registreret ved hjælp af identifikatoren “MyApp” plus en tilfældig værdi. Vi har brug for dette til at køre flere forekomster af vores applikation på vores lokale maskine.

Langt om længe, for at deaktivere Service Discovery skal vi indstille ejendommen spring.cloud.consul.discovery.enabled til falsk.

3.1. Slå op på tjenester

Vi har allerede registreret vores ansøgning i Consul, men hvordan kan klienter finde serviceendepunkterne? Vi har brug for en discovery-klienttjeneste for at få en kørende og tilgængelig service fra Consul.

Foråret giver en API til DiscoveryClient for det, som vi kan aktivere med @EnableDiscoveryClient kommentar:

@SpringBootApplication @EnableDiscoveryClient offentlig klasse DiscoveryClientApplication {// ...}

Så kan vi injicere DiscoveryClient bønne ind i vores controller og få adgang til forekomsterne:

@RestController offentlig klasse DiscoveryClientController {@Autowired privat DiscoveryClient discoveryClient; offentlig Valgfri serviceUrl () {return discoveryClient.getInstances ("myApp") .stream () .findFirst () .map (si -> si.getUri ()); }}

Endelig definerer vi vores applikationsendepunkter:

@GetMapping ("/ discoveryClient") offentlig String discoveryPing () kaster RestClientException, ServiceUnavailableException {URI service = serviceUrl () .map (s -> s.resolve ("/ ping")). OrElseThrow (ServiceUnavailableException :: new); returnere restTemplate.getForEntity (service, String.class) .getBody (); } @GetMapping ("/ ping") offentlig String ping () {returner "pong"; }

Det “MyApp / ping” sti er forårets applikationsnavn med tjenesteendepunktet. Konsul leverer alle navngivne applikationer “MyApp”.

4. Sundhedskontrol

Konsul kontrollerer jævnligt tjenestens slutpunkter.

Som standard, Foråret implementerer sundhedsendepunktet for at vende tilbage 200 OK hvis appen er op. Hvis vi vil tilpasse slutpunktet, skal vi opdatere application.yml:

forår: sky: konsul: opdagelse: healthCheckPath: / my-health-check healthCheckInterval: 20s

Som et resultat vil konsul afstemme “/ My-health-check” slutpunkt hvert 20. sekund.

Lad os definere vores brugerdefinerede sundhedstjek for at returnere en FORBUDT status:

@GetMapping ("/ my-health-check") public ResponseEntity myCustomCheck () {String message = "Testing my healh check function"; returner ny ResponseEntity (besked, HttpStatus.FORBIDDEN); }

Hvis vi går til webstedet for konsulagenten, ser vi, at vores ansøgning mislykkes. For at løse dette skal “/ My-health-check” service skal returnere HTTP 200 OK statuskode.

5. Distribueret konfiguration

Denne funktion tillader synkronisering af konfigurationen mellem alle tjenester. Konsul vil se efter eventuelle konfigurationsændringer og derefter udløse opdateringen af ​​alle tjenester.

Først skal vi tilføje afhængighed af foråret-sky-start-konsul-konfiguration til vores pom.xml:

 org.springframework.cloud spring-cloud-starter-consul-config 1.3.0.RELEASE 

Vi er også nødt til at flytte indstillingerne for Consul og Spring applikationsnavn fra ansøgning.yml fil til bootstrap.yml fil, som foråret indlæses først.

Derefter skal vi aktivere Spring Cloud Consul Config:

spring: application: name: myApp cloud: consul: host: localhost port: 8500 config: enabled: true

Spring Cloud Consul Config vil se efter ejendommene i Consul på “/ Config / myApp”. Så hvis vi har en ejendom, der hedder “My.prop”, skal vi oprette denne ejendom på webstedet for konsulagenten.

Vi kan oprette ejendommen ved at gå til “KEY / VALUE” sektion og derefter indtaste “/ Config / myApp / my / prop” i "Opret nøgle" form og "Hej Verden" som værdi. Til sidst skal du klikke på "Skab" knap.

Husk, at hvis vi bruger Spring-profiler, er vi nødt til at tilføje profilerne ud for Spring-applikationsnavnet. For eksempel, hvis vi bruger dev profil, vil den sidste vej i konsul være “/ Config / myApp, dev”.

Lad os nu se, hvordan vores controller med de injicerede egenskaber ser ud:

@RestController offentlig klasse DistributedPropertiesController {@Value ("$ {my.prop}") Strengværdi; @Autowired private MyProperties egenskaber; @GetMapping ("/ getConfigFromValue") offentlig streng getConfigFromValue () {returværdi; } @GetMapping ("/ getConfigFromProperty") offentlig streng getConfigFromProperty () {returnere egenskaber.getProp (); }}

Og MyProperties klasse:

@RefreshScope @Configuration @ConfigurationProperties ("min") offentlige klasse MyProperties {private String prop; // standard getter, setter}

Hvis vi kører applikationen, feltet værdi og ejendomme har det samme "Hej Verden" værdi fra konsul.

5.1. Opdatering af konfigurationen

Hvad med at opdatere konfigurationen uden at genstarte Spring Boot-applikationen?

Hvis vi går tilbage til Consul-agentwebstedet, og vi opdaterer ejendommen “/ Config / myApp / my / prop” med en anden værdi som “Ny Hello World”derefter marken værdi vil ikke ændre sig, og feltet ejendomme vil være blevet opdateret til “Ny Hello World” som forventet.

Dette er fordi marken ejendomme er en MyProperties klasse har @RefreshScope kommentar. Alle bønner kommenteret med @RefreshScope kommentar opdateres efter konfigurationsændringer.

I det virkelige liv skal vi ikke have egenskaberne direkte i konsul, men vi skal gemme dem vedvarende et eller andet sted. Vi kan gøre dette ved hjælp af en Config Server.

6. Konklusion

I denne artikel har vi set, hvordan vi opsætter vores Spring Boot-applikationer til at arbejde med Consul til Service Discovery-formål, tilpasse reglerne for sundhedskontrol og dele en distribueret konfiguration.

Vi har også introduceret en række tilgange for klienterne til at påberåbe sig disse registrerede tjenester.

Som sædvanligt kan kilder findes på GitHub.