streamalism.org

1. Oversikt

I denne veiledningen vil vi dekke Spring Cloud Netflix Hystrix - feiltoleransebiblioteket. Vi bruker biblioteket og implementerer Circuit Breaker-mønsteret, som beskriver en strategi mot fiasko som faller på forskjellige nivåer i en applikasjon.

Prinsippet er analogt med elektronikk: Hystrix ser på metoder for å mislykkes i anrop til relaterte tjenester. Hvis det oppstår en slik feil, vil den åpne kretsen og videresende samtalen til en reservemetode.

Biblioteket tåler feil opp til en terskel. Utover det forlater det kretsen åpen. Hvilket betyr at den vil videresende alle påfølgende samtaler til reservemetoden for å forhindre fremtidige feil. Dette skaper en tidsbuffer for den relaterte tjenesten for å gjenopprette fra sin sviktende tilstand.

2. REST-produsent

For å lage et scenario som demonstrerer Circuit Breaker-mønsteret, trenger vi en tjeneste først. Vi vil kalle den "REST Producer" siden den gir data for den Hystrix-aktiverte "REST Consumer", som vi oppretter i neste trinn.

La oss lage et nytt Maven-prosjekt ved hjelp av spring-boot-starter-web avhengighet:

 org.springframework.boot spring-boot-starter-web 2.2.6.RELEASE 

Selve prosjektet er med vilje holdt enkelt. Den består av et kontrollergrensesnitt med ett @RequestMapping kommentert GET-metode returnerer bare a Streng, en @RestController implementering av dette grensesnittet og @SpringBootApplication.

Vi begynner med grensesnittet:

offentlig grensesnitt GreetingController {@GetMapping ("/ greeting / {username}") String greeting (@PathVariable ("username") String username); }

Og implementeringen:

@RestController offentlig klasse GreetingControllerImpl implementerer GreetingController {@Override public String greeting (@PathVariable ("username") String username) {return String.format ("Hello% s! \ N", username); }}

Deretter skriver vi ned hovedapplikasjonsklassen:

@SpringBootApplication offentlig klasse RestProducerApplication {public static void main (String [] args) {SpringApplication.run (RestProducerApplication.class, args); }}

For å fullføre denne delen er det eneste som er igjen å gjøre å konfigurere en applikasjonsport som vi skal lytte på. Vi bruker ikke standardport 8080 fordi porten skal være reservert for applikasjonen som er beskrevet i neste trinn.

Videre definerer vi et applikasjonsnavn for å kunne slå opp produsenten vår fra klientapplikasjonen som vi vil introdusere senere.

La oss deretter spesifisere en port av 9090 og et navn på hvile-produsent i vår application.properties fil:

server.port = 9090 spring.application.name = restprodusent

Nå kan vi teste produsenten vår ved hjelp av cURL:

$> krøll // localhost: 9090 / hilsen / Cid Hello Cid!

3. REST Forbruker med Hystrix

For vårt demonstrasjonsscenario implementerer vi en webapplikasjon som bruker REST-tjenesten fra forrige trinn RestTemplate og Hystrix. For enkelhets skyld vil vi kalle det "REST Consumer".

Derfor oppretter vi et nytt Maven-prosjekt med vår-sky-start-hystrix, spring-boot-starter-web og spring-boot-starter-thymeleaf som avhengigheter:

 org.springframework.cloud spring-cloud-starter-hystrix 1.4.7.RELEASE org.springframework.boot spring-boot-starter-web 2.2.6.RELEASE org.springframework.boot spring-boot-starter-thymeleaf 2.2.6. UTGIVELSE 

For at effektbryteren skal fungere, skanner Hystix @Komponent eller @Service kommenterte klasser for @HystixCommand merkede metoder, implementerer en proxy for den og overvåker samtalene.

Vi skal lage en @Service klasse først, som vil bli injisert til en @Kontrollør. Siden vi bygger en webapplikasjon med Thymeleaf, trenger vi også en HTML-mal for å fungere som visning.

Dette vil være vår injiserbare @Service implementering av en @HystrixCommand med en tilhørende reservemetode. Denne reserven må bruke samme signatur som originalen:

@Service public class GreetingService {@HystrixCommand (fallbackMethod = "defaultGreeting") public String getGreeting (String username) {return new RestTemplate () .getForObject ("// localhost: 9090 / greeting / {username}", String.class, username ); } privat streng standardhilsen (streng brukernavn) {return "Hei bruker!"; }}

RestConsumerApplication vil være vår viktigste applikasjonsklasse. De @EnableCircuitBreaker merknader vil skanne klassestien for eventuell kompatibel Circuit Breaker-implementering.

For å bruke Hystrix eksplisitt, må vi kommentere denne klassen med @EnableHystrix:

@SpringBootApplication @EnableCircuitBreaker offentlig klasse RestConsumerApplication {public static void main (String [] args) {SpringApplication.run (RestConsumerApplication.class, args); }}

Vi setter opp kontrolleren ved hjelp av vår HilsenService:

@Controller public class GreetingController {@Autowired private GreetingService greetingService; @GetMapping ("/ get-greeting / {username}") public String getGreeting (Model model, @PathVariable ("username") String username) {model.addAttribute ("greeting", greetingService.getGreeting (username)); returner "hilsen-visning"; }}

Og her er HTML-malen:

   Hilsen fra Hystrix 

For å sikre at applikasjonen lytter på en definert port, legger vi følgende i en application.properties fil:

server.port = 8080

For å se en Hystix-strømbryter i aksjon, starter vi forbrukeren og peker nettleseren vår til // localhost: 8080 / hilsen / Cid. Under normale omstendigheter vil følgende vises:

Hei Cid!

For å simulere en feil fra produsenten vår, stopper vi den, og når vi er ferdig med å oppdatere nettleseren, bør vi se en generell melding, returnert fra reservemetoden i vår @Service:

Hei bruker!

4. REST Forbruker med Hystrix og Feign

Nå skal vi endre prosjektet fra forrige trinn for å bruke Spring Netflix Feign som erklærende REST-klient, i stedet for Spring RestTemplate.

Fordelen er at vi senere er i stand til å enkelt omforme vårt Feign Client-grensesnitt for å bruke Spring Netflix Eureka til tjenesteoppdagelse.

For å starte det nye prosjektet vil vi lage en kopi av forbrukeren vår, og legge til produsenten vår og vår-sky-start-feign som avhengigheter:

 com.baeldung.spring.cloud spring-cloud-hystrix-rest-producer 1.0.0-SNAPSHOT org.springframework.cloud spring-cloud-starter-feign 1.1.5.RELEASE 

Nå kan vi bruke vår HilsenKontroller for å utvide en Feign-klient. Vi implementerer Hystrix tilbakeslag som en statisk indre klasse merket med @Komponent.

Alternativt kan vi definere en @Bønne kommentert metode som returnerer en forekomst av denne reserveklassen.

Navnet eiendommen til @FeignClient er obligatorisk. Den brukes til å slå opp applikasjonen enten ved å oppdage tjenester via en Eureka-klient eller via URL, hvis denne egenskapen er gitt:

@FeignClient (name = "rest-producer" url = "// localhost: 9090", fallback = GreetingClient.GreetingClientFallback.class) offentlig grensesnitt GreetingClient utvider GreetingController {@Component offentlig statisk klasse GreetingClientFallback implementerer GreetingController {@Override public String PathVariable ("brukernavn") String brukernavn) {return "Hei bruker!"; }}}

For mer informasjon om bruk av våren Netflix Eureka til tjenesteoppdagelse, se på denne artikkelen.

I RestConsumerFeignApplication, legger vi en ekstra kommentar for å muliggjøre Feign-integrering, faktisk @EnableFeignClients, til hovedapplikasjonsklassen:

@SpringBootApplication @EnableCircuitBreaker @EnableFeignClients public class RestConsumerFeignApplication {public static void main (String [] args) {SpringApplication.run (RestConsumerFeignApplication.class, args); }}

Vi skal endre kontrolleren til å bruke en automatisk kablet Feign-klient, i stedet for den tidligere injiserte @Service, for å hente hilsenen vår:

@Controller public class GreetingController {@Autowired private GreetingClient greetingClient; @GetMapping ("/ get-greeting / {username}") public String getGreeting (Model model, @PathVariable ("username") String username) {model.addAttribute ("greeting", greetingClient.greeting (username)); returner "hilsen-visning"; }}

For å skille dette eksemplet fra det forrige, endrer vi programlytteporten i application.properties:

server.port = 8082

Til slutt vil vi teste denne Feign-aktiverte forbrukeren som den fra forrige seksjon. Det forventede resultatet skal være det samme.

5. Cache Fallback With Hystrix

Nå skal vi legge Hystrix til vårt Spring Cloud-prosjekt. I dette skyprosjektet har vi en rangeringstjeneste som snakker med databasen og får rangeringer av bøker.

La oss anta at databasen vår er en ressurs som er etterspurt, og svarets ventetid kan variere i tid eller kanskje ikke være tilgjengelig i tider. Vi vil håndtere dette scenariet med Hystrix Circuit Breaker som faller tilbake til en cache for dataene.

5.1. Oppsett og konfigurasjon

La oss legge til vår-sky-start-hystrix avhengighet av vår vurderingsmodul:

 org.springframework.cloud spring-cloud-starter-hystrix 

Når rangeringer settes inn / oppdateres / slettes i databasen, replikerer vi det samme til Redis-hurtigbufferen med en Oppbevaringssted. For å lære mer om Redis, sjekk denne artikkelen.

La oss oppdatere RatingService å pakke databasens spørringsmetoder i en Hystrix-kommando med @HystrixCommand og konfigurer det med en tilbakebetaling for å lese fra Redis:

@HystrixCommand (commandKey = "ratingsByIdFromDB", fallbackMethod = "findCachedRatingById", ignoreExceptions = {RatingNotFoundException.class}) public Rating findRatingById (Long ratingId) {return Optional.ofNullable (ratingRepository.findOne (ratingId) (ratingId) () ny RatingNotFoundException ("Rating ikke funnet. ID:" + ratingId)); } offentlig vurdering findCachedRatingById (Long ratingId) {return cacheRepository.findCachedRatingById (ratingId); }

Merk at reservemetoden skal ha samme signatur som en pakket metode og må ligge i samme klasse. Nå når findRatingById mislykkes eller blir forsinket mer enn en gitt terskel, faller Hystrix tilbake til findCachedRatingById.

Siden Hystrix-funksjonene blir injisert transparent som AOP-råd, må vi justere rekkefølgen som rådene stables i, i tilfelle hvis vi har andre råd som Spring's transaksjonsråd. Her har vi justert vårens AOP-råd til å ha lavere forrang enn Hystrix AOP-råd:

@EnableHystrix @EnableTransactionManagement (ordre = Ordered.LOWEST_PRECEDENCE, mode = AdviceMode.ASPECTJ) offentlig klasse RatingServiceApplication {@Bean @Primary @Order (verdi = Ordered.HIGHEST_PRECEDENCE) offentlig HystrixCommandAspect hystrixAspectrix () kommando;) returnering) } // andre bønner, konfigurasjoner}

Her har vi justert vårens transaksjons-AOP-råd til å ha lavere forrang enn Hystrix AOP-råd.

5.2. Testing av Hystrix Fallback

Nå som vi har konfigurert kretsen, kan vi teste den ved å få ned H2-databasen vårt depot samhandler med. Men først, la oss kjøre H2-forekomsten som en ekstern prosess i stedet for å kjøre den som en innebygd database.

La oss kopiere H2-biblioteket (h2-1.4.193.jar) til en kjent katalog og start H2-serveren:

> java -cp h2-1.4.193.jar org.h2.tools.Server -tcp TCP-server som kjører på tcp: //192.168.99.1: 9092 (bare lokale tilkoblinger)

La oss nå oppdatere modulens datakilde-URL i rating-service.properties for å peke på denne H2-serveren:

spring.datasource.url = jdbc: h2: tcp: // localhost / ~ / rangeringer

Vi kan starte tjenestene våre som gitt i vår forrige artikkel fra Spring Cloud-serien, og teste rangeringer av hver bok ved å få ned den eksterne H2-forekomsten vi kjører.

Vi kunne se at når H2-databasen ikke er tilgjengelig, faller Hystrix automatisk tilbake til Redis for å lese rangeringene for hver bok. Kildekoden som demonstrerer denne brukssaken, finner du her.

6. Bruke omfang

Normalt en @HytrixCommand merket metode kjøres i en trådgruppekontekst. Men noen ganger må den kjøre i et lokalt omfang, for eksempel en @SessionScope eller a @RequestScope. Dette kan gjøres ved å gi argumenter for kommandototatet:

@HystrixCommand (fallbackMethod = "getSomeDefault", commandProperties = {@HystrixProperty (navn = "utførelse.isolation.strategy", verdi = "SEMAPHORE")})

7. Hystrix Dashboard

En fin valgfri funksjon i Hystrix er muligheten til å overvåke statusen på et dashbord.

For å aktivere det, vil vi sette spring-cloud-starter-hystrix-dashboard og spring-boot-starter-actuator i pom.xml av forbrukeren vår:

 org.springframework.cloud spring-cloud-starter-hystrix-dashboard 1.4.7.RELEASE org.springframework.boot spring-boot-starter-actuator 2.2.6.RELEASE 

Førstnevnte må aktiveres via kommentar a @Konfigurasjon med @EnableHystrixDashboard og sistnevnte aktiverer automatisk de nødvendige beregningene i webapplikasjonen vår.

Etter at vi har startet om applikasjonen på nytt, retter vi en nettleser mot // localhost: 8080 / hystrix, skriv inn beregnings-URL-adressen til en Hystrix-strøm og begynn å overvåke.

Til slutt bør vi se noe slikt:

Å overvåke en Hystrix-strøm er noe bra, men hvis vi må se på flere Hystrix-aktiverte applikasjoner, vil det bli upraktisk. For dette formålet tilbyr Spring Cloud et verktøy som heter Turbine, som kan samle strømmer som presenteres i ett Hystrix-dashbord.

Konfigurering av turbine er utenfor omfanget av denne oppskriften, men muligheten bør nevnes her. Så det er også mulig å samle disse strømmer via meldinger ved hjelp av Turbine stream.

8. Konklusjon

Som vi har sett så langt, er vi nå i stand til å implementere Circuit Breaker-mønsteret ved hjelp av Spring Netflix Hystrix sammen med begge vårene RestTemplate eller våren Netflix Feign.

Dette betyr at vi er i stand til å konsumere tjenester med tilbakeslag med standarddata, og vi kan overvåke bruken av disse dataene.

Som vanlig kan vi finne kildene på GitHub.