Praznici su gotovi i vraćamo se s našom drugom objavom iz serije Istio Service Mesh.
Današnja tema je Circuit Breaker, što u prevodu na ruski elektrotehnika znači „prekidač strujnog kola“, u običnom jeziku – „prekidač kola“. Samo u Istiu ova mašina ne isključuje kratko ili preopterećeno kolo, već neispravne posude.
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 mikroservise izvode u podovima, može postojati više instanci kontejneriziranog mikroservisa na jednoj krajnjoj točki, a Kubernetes će usmjeravati zahtjeve i balansirati opterećenje između njih. I - u idealnom slučaju - sve ovo bi trebalo savršeno funkcionirati.
Sjećamo se da su mikroservise male i efemerne. Efemernost, koja ovdje znači lakoću pojavljivanja i nestajanja, često se potcjenjuje. 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 zaista funkcionira
Zamislite sada da je određena instanca mikroservisa, odnosno kontejnera postala neupotrebljiva: ili ne reaguje (greška 503), ili, što je još neugodnije, odgovara, ali presporo. Drugim riječima, postaje kvar ili ne odgovara na zahtjeve, ali se ne uklanja automatski iz bazena. Šta treba učiniti u ovom slučaju? Pokušati ponovo? Trebam li ga ukloniti iz šeme rutiranja? A šta znači "prespor" - koliko ih ima u brojevima i ko ih određuje? Možda samo malo odmorite i pokušajte ponovo kasnije? Ako da, koliko kasnije?
Što je Pool Ejection u Istiu
I tu Istio priskače u pomoć sa svojim zaštitnim mašinama za prekidače, koje privremeno uklanjaju neispravne kontejnere iz skupa resursa za usmjeravanje i balansiranje opterećenja, implementirajući proceduru izbacivanja bazena.
Koristeći strategiju otkrivanja outlier-a, Istio otkriva pod krive koje su van linije i uklanja ih iz skupa resursa na unaprijed određeno vrijeme, što se naziva prozor mirovanja.
Da pokažemo kako ovo funkcionira u Kubernetesu na OpenShift platformi, počnimo sa snimkom ekrana normalno funkcionalnih mikroservisa iz primjera u spremištu . Ovdje imamo dva pod-a, v1 i v2, od kojih svaki pokreće jedan kontejner. Kada se Istio pravila rutiranja ne koriste, Kubernetes podrazumevano postavlja ravnomerno uravnoteženo kružno rutiranje:
Spremam se za sudar
Prije izvođenja Pool Ejection, morate kreirati Istio pravilo rutiranja. Recimo da želimo distribuirati zahtjeve između podova u omjeru 50/50. Dodatno ćemo povećati broj v2 kontejnera sa jednog na dva, ovako:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Sada postavljamo pravilo rutiranja tako da se promet raspoređuje između podova u omjeru 50/50.
Evo kako izgleda rezultat ovog pravila:
Možete naći zamjerku što ovaj ekran nije 50/50, već 14:9, ali vremenom će se situacija popraviti.
Pravljenje kvara
Sada deaktivirajmo jedan od dva v2 kontejnera tako da imamo jedan zdrav v1 kontejner, jedan zdrav v2 kontejner i jedan neispravan v2 kontejner:
Popravljanje kvara
Dakle, imamo neispravan kontejner i vrijeme je za izbacivanje bazena. Koristeći vrlo jednostavnu konfiguraciju, isključit ćemo ovaj neuspjeli kontejner iz bilo koje šeme rutiranja na 15 sekundi u nadi da će se vratiti u zdravo stanje (ili ponovno pokretanje ili vraćanje performansi). Ovako izgleda ova konfiguracija i rezultati njenog rada:
Kao što možete vidjeti, neuspjeli v2 kontejner se više ne koristi za zahtjeve za usmjeravanje jer je uklonjen iz spremišta. Ali nakon 15 sekundi automatski će se vratiti u bazen. Zapravo, upravo smo pokazali kako Pool Ejection funkcionira.
Počnimo da gradimo arhitekturu
Pool Ejection, u kombinaciji sa Istio mogućnostima praćenja, omogućava vam da započnete izgradnju okvira za automatsku zamjenu neispravnih kontejnera kako biste smanjili, ako ne i eliminirali, zastoje i kvarove.
NASA ima jedan glasan moto - Neuspjeh nije opcija, čiji se autor smatra direktorom leta . Može se prevesti na ruski kao „Neuspjeh nije opcija“, a ovdje znači da se sve može natjerati da funkcionira ako imate dovoljno volje. Međutim, u stvarnom životu neuspesi se ne dešavaju samo, oni su neizbežni, svuda i u svemu. I kako se nositi s njima u slučaju mikroservisa? Po našem mišljenju, bolje je ne osloniti se na snagu volje, već na mogućnosti kontejnera, , i .
Istio, kao što smo gore napisali, implementira koncept prekidača koji se dobro dokazao u fizičkom svijetu. I baš kao što električni prekidač isključuje problemski dio kola, Istiov softver Circuit Breaker otvara vezu između toka zahtjeva i kontejnera problema kada nešto nije u redu s krajnjom točkom, na primjer, kada se server srušio ili počeo da radi uspori.
Štoviše, u drugom slučaju ima samo više problema, jer kočnice jednog kontejnera ne samo da uzrokuju kaskadu kašnjenja u uslugama koje mu pristupaju i, kao rezultat toga, smanjuju performanse sustava u cjelini, već i stvaraju ponovljene zahtjeva za već sporu uslugu, što samo pogoršava situaciju.
Prekidač u teoriji
Circuit Breaker je proxy koji kontrolira tok zahtjeva do krajnje točke. Kada ova tačka prestane da radi ili, u zavisnosti od navedenih postavki, počne da usporava, proxy prekida vezu sa kontejnerom. Promet se tada preusmjerava na druge kontejnere, jednostavno zbog balansiranja opterećenja. Veza ostaje otvorena tokom određenog perioda mirovanja, recimo dva minuta, a zatim se smatra poluotvorenom. Pokušaj slanja sljedećeg zahtjeva određuje dalje stanje veze. Ako je sve u redu sa servisom, veza se vraća u radno stanje i ponovo se zatvara. Ako i dalje nešto nije u redu sa uslugom, veza se prekida i prozor mirovanja se ponovo omogućava. Evo kako izgleda pojednostavljeni dijagram stanja prekidača:
Ovdje je važno napomenuti da se sve ovo dešava na nivou, da tako kažemo, sistemske arhitekture. Dakle, u nekom trenutku ćete morati da naučite svoje aplikacije da rade sa Circuit Breaker-om, kao što je davanje podrazumevane vrednosti kao odgovor ili, ako je moguće, ignorisanje postojanja usluge. Za to se koristi uzorak pregrade, ali to je izvan okvira ovog članka.
Prekidač u praksi
Na primjer, pokrenut ćemo dvije verzije našeg mikroservisa preporuke na OpenShift-u. Verzija 1 će raditi dobro, ali u v2 ćemo ugraditi kašnjenje da simuliramo usporavanje na serveru. Za pregled rezultata koristite alat :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Čini se da sve funkcionira, ali po koju cijenu? Na prvi pogled imamo 100% dostupnost, ali pogledajte pažljivije - maksimalno trajanje transakcije je čak 12 sekundi. Ovo je očigledno usko grlo i treba ga proširiti.
Da bismo to učinili, koristit ćemo Istio da eliminiramo pozive sporim kontejnerima. Ovako izgleda odgovarajuća konfiguracija pomoću prekidača:
Posljednji red s parametrom httpMaxRequestsPerConnection signalizira da se veza s kojom treba prekinuti kada pokušavate stvoriti drugu - drugu - vezu pored postojeće. Budući da naš kontejner simulira spor servis, takve situacije će se povremeno javljati, a onda će Istio vratiti grešku 503, ali ovo će pokazati opsada:
OK, imamo prekidač, što je sljedeće?
Dakle, implementirali smo automatsko gašenje bez dodirivanja izvornog koda samih servisa. Koristeći Prekidač i proceduru izbacivanja bazena opisanu gore, možemo ukloniti kočione kontejnere iz skupa resursa dok se ne vrate u normalu i provjeriti njihov status na određenoj frekvenciji - u našem primjeru, to je dva minuta (parametar SleepWindow).
Imajte na umu da je sposobnost aplikacije da odgovori na grešku 503 još uvijek postavljena na razini izvornog koda. Postoji mnogo strategija za korištenje prekidača, ovisno o situaciji.
U sljedećem postu: Govorit ćemo o praćenju i praćenju koje je već ugrađeno ili lako dodato u Istio, kao io tome kako namjerno uneti greške u sistem.
izvor: www.habr.com