Praznici su gotovi i vraćamo se s našim drugim postom u seriji Istio Service Mesh.
Današnja tema je Circuit Breaker, što prevedeno na rusku elektrotehniku znači "prekidač strujnog kruga", u uobičajenom jeziku - "prekidač strujnog kruga". Samo u Istio ovaj stroj ne odvaja kratko spojeni ili preopterećeni krug, već neispravne spremnike.
Kako bi ovo trebalo idealno funkcionirati
Kada mikroservisima upravlja Kubernetes, na primjer unutar OpenShift platforme, oni se automatski povećavaju i smanjuju ovisno o opterećenju. Budući da se mikroservisi izvode u podovima, može postojati više instanci mikroservisa u kontejnerima na jednoj krajnjoj točki, a Kubernetes će usmjeravati zahtjeve i balansirati opterećenje između njih. I - idealno - sve bi to trebalo raditi savršeno.
Sjećamo se da su mikroservisi mali i prolazni. Efemernost, koja ovdje znači lakoću pojavljivanja i nestajanja, često se podcjenjuje. Rođenje i smrt još jedne instance mikroservisa u pod-u su sasvim očekivane stvari, OpenShift i Kubernetes to dobro rješavaju, i sve radi odlično – ali opet u teoriji.
Kako to stvarno radi
Sada zamislite da je određena instanca mikroservisa, odnosno kontejnera, postala neupotrebljiva: ili ne reagira (greška 503), ili, što je još neugodnije, reagira, ali presporo. Drugim riječima, postaje neispravan ili ne odgovara na zahtjeve, ali se ne uklanja automatski iz bazena. Što treba učiniti u ovom slučaju? Da pokušam ponovo? Trebam li ga ukloniti iz sheme usmjeravanja? A što znači presporo – koliko je to u brojkama i tko ih određuje? Možda samo odmorite i pokušate ponovno kasnije? Ako da, koliko kasnije?
Što je Pool Ejection u Istiu
I ovdje Istio dolazi u pomoć sa svojim strojevima za zaštitu od prekidača, koji privremeno uklanjaju neispravne spremnike iz skupa resursa za usmjeravanje i balansiranje opterećenja, implementirajući proceduru izbacivanja skupa.
Koristeći strategiju otkrivanja odstupanja, Istio otkriva krivulje koje su izvan linije i uklanja ih iz skupa resursa na određeno vrijeme, koje se naziva prozor mirovanja.
Da pokažemo kako to funkcionira u Kubernetesu na OpenShift platformi, počnimo sa snimkom zaslona mikroservisa koji normalno rade iz primjera u repozitoriju . Ovdje imamo dvije mahune, v1 i v2, od kojih svaka pokreće jedan spremnik. Kada se Istio pravila usmjeravanja ne koriste, Kubernetes zadano postavlja ravnomjerno uravnoteženo kružno usmjeravanje:
Spremati se za sudar
Prije izbacivanja bazena morate izraditi Istio pravilo usmjeravanja. Recimo da želimo distribuirati zahtjeve između grupa u omjeru 50/50. Osim toga, povećat ćemo broj v2 spremnika s jednog na dva, ovako:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Sada postavljamo pravilo usmjeravanja tako da se promet raspoređuje između grupa u omjeru 50/50.
Evo kako izgleda rezultat ovog pravila:
Možete zamjeriti tome što ovaj ekran nije 50/50, nego 14:9, no s vremenom će se situacija popraviti.
Izrada kvara
Sada onemogućimo jedan od dva v2 spremnika tako da imamo jedan zdravi v1 spremnik, jedan zdravi v2 spremnik i jedan neispravan v2 spremnik:
Popravljanje kvara
Dakle, imamo neispravan spremnik i vrijeme je za izbacivanje iz bazena. Koristeći vrlo jednostavnu konfiguraciju, isključit ćemo ovaj neuspjeli spremnik iz svih shema usmjeravanja na 15 sekundi u nadi da će se vratiti u ispravno stanje (ili ponovno pokrenuti ili vratiti performanse). Ovako izgleda ova konfiguracija i rezultati njenog rada:
Kao što vidite, neuspjeli spremnik v2 više se ne koristi za zahtjeve za usmjeravanje jer je uklonjen iz skupa. Ali nakon 15 sekundi automatski će se vratiti u bazen. Zapravo, upravo smo pokazali kako funkcionira Pool Ejection.
Počnimo graditi arhitekturu
Pool Ejection, u kombinaciji s Istio-ovim mogućnostima nadzora, omogućuje vam da počnete graditi okvir za automatsku zamjenu neispravnih spremnika kako biste smanjili, ako ne i eliminirali, zastoje i kvarove.
NASA ima jedan glasan moto - Neuspjeh nije opcija, čiji se autor smatra direktorom leta . Na ruski se može prevesti kao "Neuspjeh nije opcija", a značenje ovdje je da se sve može učiniti da funkcionira ako imate dovoljno volje. Međutim, u stvarnom životu neuspjesi se ne događaju samo, oni su neizbježni, svugdje i u svemu. I kako se nositi s njima u slučaju mikroservisa? Po našem mišljenju, bolje je osloniti se ne na snagu volje, već na mogućnosti spremnika, , I .
Istio, kao što smo gore napisali, implementira koncept prekidača koji se dobro pokazao u fizičkom svijetu. I baš kao što električni prekidač isključuje problematični dio strujnog kruga, Istiov softver Circuit Breaker otvara vezu između toka zahtjeva i spremnika problema kada nešto nije u redu s krajnjom točkom, na primjer, kada se poslužitelj sruši ili počne uspori.
Štoviše, u drugom slučaju postoji samo više problema, budući da kočnice jednog spremnika ne samo da uzrokuju kaskadu kašnjenja usluga koje mu pristupaju i, kao rezultat toga, smanjuju performanse sustava u cjelini, već također generiraju ponovljene zahtjeva ionako usporenoj usluzi, što samo pogoršava situaciju .
Prekidač strujnog kruga u teoriji
Circuit Breaker je proxy koji kontrolira protok zahtjeva do krajnje točke. Kada ova točka prestane raditi ili, ovisno o navedenim postavkama, počne usporavati, proxy prekida vezu sa spremnikom. Promet se zatim preusmjerava na druge spremnike, jednostavno zbog balansiranja opterećenja. Veza ostaje otvorena određeni prozor mirovanja, recimo dvije minute, a zatim se smatra poluotvorenom. Pokušaj slanja sljedećeg zahtjeva određuje daljnje stanje veze. Ako je sve u redu s uslugom, veza se vraća u radno stanje i ponovno se zatvara. Ako još uvijek nešto nije u redu s uslugom, veza se prekida i prozor mirovanja ponovno je omogućen. Evo kako izgleda pojednostavljeni dijagram stanja prekidača:
Ovdje je važno napomenuti da se sve to događa na razini, da tako kažemo, arhitekture sustava. Dakle, u nekom trenutku ćete morati naučiti svoje aplikacije da rade sa Circuit Breaker, kao što je pružanje zadane vrijednosti kao odgovor ili, ako je moguće, ignoriranje postojanja usluge. Za to se koristi uzorak pregrade, ali to je izvan dosega ovog članka.
Prekidač u praksi
Na primjer, pokrenut ćemo dvije verzije naše mikroservise preporuke na OpenShiftu. Verzija 1 radit će dobro, ali u v2 ćemo ugraditi odgodu za simulaciju usporavanja na poslužitelju. Za pregled rezultata upotrijebite alat :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Čini se da sve radi, ali po koju cijenu? Na prvi pogled imamo 100% dostupnost, no pogledajte malo bolje - maksimalno trajanje transakcije je čak 12 sekundi. Ovo je očito usko grlo i treba ga proširiti.
Da bismo to učinili, koristit ćemo Istio za eliminiranje poziva sporim spremnicima. Ovako izgleda odgovarajuća konfiguracija pomoću prekidača strujnog kruga:
Posljednji redak s parametrom httpMaxRequestsPerConnection signalizira da se veza s treba prekinuti kada se pokušava stvoriti druga - druga - veza uz postojeću. Budući da naš spremnik simulira sporu uslugu, takve će se situacije pojavljivati povremeno, a zatim će Istio vratiti pogrešku 503, ali ovo će pokazati siege:
OK, imamo prekidač, što je sljedeće?
Dakle, implementirali smo automatsko gašenje bez da smo uopće dirali izvorni kod samih usluga. Korištenjem prekidača strujnog kruga i gore opisane procedure izbacivanja bazena, možemo ukloniti spremnike kočnica iz skupa resursa dok se ne vrate u normalu i provjeravati njihov status određenom učestalošću - u našem primjeru to su dvije minute (parametar sleepWindow).
Imajte na umu da je sposobnost aplikacije da odgovori na pogrešku 503 još uvijek postavljena na razini izvornog koda. Postoje mnoge strategije za korištenje prekidača, ovisno o situaciji.
U sljedećem postu: Razgovarat ćemo o praćenju i nadzoru koji su već ugrađeni ili se lako dodaju u Istio, kao io tome kako namjerno unijeti greške u sustav.
Izvor: www.habr.com