Introduktion til Spring Cloud Rest Client med Netflix Ribbon

1. Introduktion

Netflix Ribbon er et cloudbibliotek mellem Inter Process Communication (IPC). Ribbon leverer primært belastningsbalanceringsalgoritmer på klientsiden.

Bortset fra belastningsbalanceringsalgoritmerne på klientsiden giver Ribbon også andre funktioner:

  • Service Discovery Integration - Ribbon load balancers giver serviceopdagelse i dynamiske miljøer som en sky. Integration med Eureka og Netflix service discovery-komponent er inkluderet i båndbiblioteket
  • Fejltolerance - Ribbon API kan dynamisk bestemme, om serverne kører i et live miljø og kan registrere de servere, der er nede
  • Konfigurerbare regler for belastningsafbalancering - Båndstøtter RoundRobinRule, TilgængelighedFilteringsregel, WeightedResponseTimeRule ud af kassen og understøtter også definition af brugerdefinerede regler

Ribbon API fungerer ud fra konceptet kaldet “Named Client”. Mens vi konfigurerer Ribbon i vores applikationskonfigurationsfil, giver vi et navn til listen over servere, der er inkluderet til belastningsbalanceringen.

Lad os prøve det.

2. Afhængighedsstyring

Netflix Ribbon API kan føjes til vores projekt ved at tilføje nedenstående afhængighed til vores pom.xml:

 org.springframework.cloud spring-cloud-starter-netflix-bånd 

De seneste biblioteker kan findes her.

3. Eksempel på anvendelse

For at se hvordan Ribbon API fungerer, bygger vi en prøve-mikroserviceapplikation med Spring RestTemplate og vi forbedrer det med Netflix Ribbon API sammen med Spring Cloud Netflix API.

Vi bruger en af ​​Ribbon's load-balance strategier, WeightedResponseTimeRule, for at aktivere klientsides belastningsafbalancering mellem 2 servere, der er defineret under en navngivet klient i konfigurationsfilen, i vores applikation.

4. Båndkonfiguration

Ribbon API giver os mulighed for at konfigurere følgende komponenter i load balancer:

  • Herske - Logisk komponent, der specificerer den belastningsbalanceringsregel, vi bruger i vores applikation
  • Ping - En komponent, der specificerer den mekanisme, vi bruger til at bestemme serverens tilgængelighed i realtid
  • Serverliste - kan være dynamisk eller statisk. I vores tilfælde bruger vi en statisk liste over servere, og derfor definerer vi dem direkte i applikationens konfigurationsfil

Lad os skrive en enkel konfiguration til biblioteket:

offentlig klasse RibbonConfiguration {@Autowired IClientConfig ribbonClientConfig; @Bean public IPing ribbonPing (IClientConfig config) {returner ny PingUrl (); } @Bean public IRule ribbonRule (IClientConfig config) {return new WeightedResponseTimeRule (); }}

Bemærk hvordan vi brugte WeightedResponseTimeRule regel for at bestemme serveren og PingUrl mekanisme til at bestemme serverens tilgængelighed i realtid.

I henhold til denne regel tildeles hver server en vægt i henhold til dens gennemsnitlige svartid, mindre responstid giver mindre vægt. Denne regel vælger tilfældigt en server, hvor muligheden bestemmes af serverens vægt.

Og PingUrl vil pinge hver URL for at bestemme serverens tilgængelighed.

5. ansøgning.yml

Nedenfor er ansøgning.yml konfigurationsfil, vi oprettede til denne eksempelapplikation:

spring: application: name: spring-cloud-ribbon server: port: 8888 ping-server: ribbon: eureka: enabled: false listOfServers: localhost: 9092, localhost: 9999 ServerListRefreshInterval: 15000

I ovenstående fil specificerede vi:

  • Ansøgningens navn
  • Ansøgningens portnummer
  • Navngivet klient til listen over servere: “ping-server”
  • Deaktiveret Eureka service discovery-komponent ved at indstille eureka: aktiveret til falsk
  • Defineret listen over tilgængelige servere til belastningsbalancering, i dette tilfælde 2 servere
  • Konfigurerede serveropdateringshastigheden med ServerListRefreshInterval

6. RibbonClient

Lad os nu oprette det vigtigste programkomponentuddrag - hvor vi bruger RibbonClient for at aktivere belastningsafbalancering i stedet for sletten RestTemplate:

@SpringBootApplication @ RestController @ RibbonClient (name = "ping-a-server", configuration = RibbonConfiguration.class) public class ServerLocationApp {@LoadBalanced @Bean RestTemplate getRestTemplate () {returner ny RestTemplate (); } @Autowired RestTemplate restTemplate; @RequestMapping ("/ server-location") offentlig streng serverLocation () {returner this.restTemplate.getForObject ("// ping-server / locaus", String.class); } offentlig statisk ugyldig hoved (String [] args) {SpringApplication.run (ServerLocationApp.class, args); }}

Vi definerede en controller-klasse med kommentaren @RestController; vi kommenterede også klassen med @RibbonClient med et navn og en konfigurationsklasse.

Den konfigurationsklasse, vi definerede her, er den samme klasse, som vi definerede tidligere, hvor vi leverede den ønskede Ribbon API-konfiguration til denne applikation.

Bemærk, at vi også kommenterede RestTemplate med @LoadBalanced hvilket antyder, at vi ønsker, at dette skal være belastningsafbalanceret og i dette tilfælde med Ribbon.

7. Fejl i elastik i bånd

Som vi diskuterede tidligere i denne artikel, giver Ribbon API ikke kun algoritmer til belastningsbalancering på klientsiden, men det har også indbygget fiaskabilitet.

Som tidligere nævnt kan Ribbon API bestemme serverens tilgængelighed gennem konstant ping af servere med jævne mellemrum og har mulighed for at springe over de servere, der ikke er live.

Derudover implementerer det også Circuit Breaker-mønster for at filtrere serverne ud efter specificerede kriterier.

Circuit Breaker-mønsteret minimerer virkningen af ​​en serverfejl på ydeevnen ved hurtigt at afvise en anmodning til den server, der fejler uden at vente på en time-out. Vi kan deaktivere denne effektafbryder ved at indstille ejendommen niws.loadbalancer.availabilityFilteringRule.filterCircuitTripped til falsk.

Når alle servere er nede, er der således ingen server tilgængelig til at betjene anmodningen pingUrl () mislykkes, og vi modtager en undtagelse java.lang.IllegalStateException med en besked "Ingen forekomster er tilgængelige for at betjene anmodningen".

8. Konklusion

I denne artikel diskuterede vi Netflix Ribbon API og dets implementering i en simpel prøveapplikation.

Den komplette kildekode til eksemplet beskrevet ovenfor kan findes i GitHub-arkivet.


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