streamalism.org

1. Introduksjon

Netflix Ribbon er et skybibliotek for Inter Process Communication (IPC). Ribbon gir primært belastningsbalanseringsalgoritmer på klientsiden.

Bortsett fra belastningsbalanseringsalgoritmer på klientsiden, gir Ribbon også andre funksjoner:

• Service Discovery Integration - Båndbelastningsvektere gir serviceoppdagelse i dynamiske miljøer som en sky. Integrering med Eureka og Netflix service discovery-komponent er inkludert i båndbiblioteket
• Feiltoleranse - Ribbon API kan dynamisk avgjøre om serverne er i drift i et live miljø og kan oppdage de serverne som er nede
• Konfigurerbare regler for lastbalansering - Båndstøtter RoundRobinRule, TilgjengelighetFilteringsregel, WeightedResponseTimeRule out of the box og støtter også definering av tilpassede regler

Ribbon API fungerer ut fra konseptet kalt “Named Client”. Mens vi konfigurerer Ribbon i vår applikasjonskonfigurasjonsfil, gir vi et navn på listen over servere som er inkludert for lastbalanseringen.

La oss ta en tur.

2. Avhengighetsstyring

Netflix Ribbon API kan legges til prosjektet vårt ved å legge til avhengigheten nedenfor til vår pom.xml:

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

De siste bibliotekene finner du her.

3. Eksempel på applikasjon

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

Vi bruker en av Ribbon's lastbalanseringsstrategier, WeightedResponseTimeRule, for å aktivere belastningsbalansering mellom klientsiden mellom to servere, som er definert under en navngitt klient i konfigurasjonsfilen, i applikasjonen vår.

4. Båndkonfigurasjon

Ribbon API gjør det mulig for oss å konfigurere følgende komponenter i lastbalanseren:

• Regel - Logikkomponent som spesifiserer belastningsbalanseringsregelen vi bruker i applikasjonen vår
• Ping - En komponent som spesifiserer mekanismen vi bruker for å bestemme serverens tilgjengelighet i sanntid
• Serverliste - kan være dynamisk eller statisk. I vårt tilfelle bruker vi en statisk liste over servere, og derfor definerer vi dem direkte i programkonfigurasjonsfilen

La oss skrive en enkel konfigurasjon for biblioteket:

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

Legg merke til hvordan vi brukte WeightedResponseTimeRule regel for å bestemme serveren og PingUrl mekanisme for å bestemme serverens tilgjengelighet i sanntid.

I henhold til denne regelen får hver server en vekt i henhold til gjennomsnittlig responstid, mindre responstid gir mindre vekt. Denne regelen velger tilfeldig en server der muligheten bestemmes av serverens vekt.

Og PingUrl vil pinge hver URL for å bestemme serverens tilgjengelighet.

5. application.yml

Nedenfor er application.yml konfigurasjonsfilen vi opprettet for denne applikasjonen:

vår: applikasjon: navn: vår-sky-båndserver: port: 8888 ping-server: bånd: eureka: aktivert: falsk liste Av servere: lokal vert: 9092, lokal vert: 9999 ServerList

I filen ovenfor spesifiserte vi:

• Programnavn
• Portnummer på søknaden
• Navngitt klient for listen over servere: “ping-server”
• Deaktivert Eureka service discovery component, ved å angi eureka: aktivert til falsk
• Definerte listen over servere som er tilgjengelige for lastbalansering, i dette tilfellet to servere
• Konfigurerte serverens oppdateringsfrekvens med ServerListRefreshInterval

6. RibbonClient

La oss nå sette opp hovedutdraget til applikasjonskomponenten - der vi bruker RibbonClient for å aktivere lastbalansering i stedet for slette RestTemplate:

@SpringBootApplication @ RestController @ RibbonClient (name = "ping-a-server", configuration = RibbonConfiguration.class) public class ServerLocationApp {@ LoadBalanced @ Bean RestTemplate getRestTemplate () {return new RestTemplate (); } @Autowired RestTemplate restTemplate; @RequestMapping ("/ server-location") public String serverLocation () {return this.restTemplate.getForObject ("// ping-server / locaus", String.class); } public static void main (String [] args) {SpringApplication.run (ServerLocationApp.class, args); }}

Vi definerte en kontrollerklasse med merknaden @RestController; vi kommenterte også klassen med @RibbonClient med et navn og en konfigurasjonsklasse.

Konfigurasjonsklassen vi definerte her er den samme klassen som vi definerte tidligere, der vi ga ønsket Ribbon API-konfigurasjon for dette programmet.

Legg merke til at vi også kommenterte RestTemplate med @LoadBalanced som antyder at vi vil at dette skal være lastbalansert og i dette tilfellet med Ribbon.

7. Feil elastisitet i bånd

Som vi diskuterte tidligere i denne artikkelen, gir Ribbon API ikke bare algoritmer for belastningsbalansering på klientsiden, men det har også innebygd fleksibilitet.

Som nevnt tidligere kan Ribbon API bestemme serverens tilgjengelighet gjennom konstant pinging av servere med jevne mellomrom, og har muligheten til å hoppe over serverne som ikke er live.

I tillegg til det implementerer det også Circuit Breaker-mønster for å filtrere ut serverne basert på spesifiserte kriterier.

Circuit Breaker-mønsteret minimerer effekten av en serverfeil på ytelsen ved raskt å avvise en forespørsel til den serveren som mislykkes uten å vente på en time-out. Vi kan deaktivere denne effektbryterfunksjonen ved å stille inn eiendommen niws.loadbalancer.availabilityFilteringRule.filterCircuitTripped til falsk.

Når alle serverne er nede, er det altså ingen server tilgjengelig for å betjene forespørselen pingUrl () vil mislykkes, og vi får et unntak java.lang.IllegalStateException med en melding “Ingen forekomster er tilgjengelige for å betjene forespørselen”.

8. Konklusjon

I denne artikkelen diskuterte vi Netflix Ribbon API og implementeringen av den i en enkel eksempelapplikasjon.

Den komplette kildekoden for eksemplet som er beskrevet ovenfor, finner du i GitHub-depotet.