Festat kanë përfunduar, dhe ne kthehemi me postimin tonë të dytë nga seria mbi Istio Service Mesh.
Sot tema është – Circuit Breaker, që në përkthimin në shqip do të thotë «prerës automatik», e njohur ndryshe si «mbrojtës automatik». Në Istio, ky prerës nuk ndalon një qark të shkurtër ose të ngarkuar, por ndalon kontejnerët e defektuar.
Si duhet të funksionojë idealisht
Kur mikroshërbimet menaxhohen nga Kubernetes, për shembull, brenda platformës OpenShift, ato automatikisht shkallëzohen lart e poshtë në varësi të ngarkesës. Duke qenë se mikroshërbimet funksionojnë në pod-e, në një pikë finale mund të ketë disa instanca të kontejnerizuar të mikroshërbimit, dhe Kubernetes do të rruazojë kërkesat dhe balancojë ngarkesën mes tyre. Dhe – në mënyrë ideale – të gjitha këto should të funksionojnë shkëlqyeshëm.
Ne kujtojmë se mikroshërbimet janë të vogla dhe efemere. Efemërsia, që këtu do të thotë thjeshtësinë e lindjes dhe zhdukjes, shpesh nënvlerësohet. Lindja dhe vdekja e një instance tjetër të mikroshërbimit në pod është një gjë mjaft e pritshme, OpenShift dhe Kubernetes e menaxhojnë mirë këtë, dhe gjithçka funksionon mrekullisht – por përsëri në teori.
Si funksionon në të vërtetë
Tani imagjinoni se një instancë e caktuar e mikroshërbimit, dmth kontejneri, ka dalë nga funksioni: ose nuk përgjigjet (gabimi 503), ose – që është më e pakëndshme – reagon, por shumë ngadalë. Me fjalë të tjera, ai është duke pësuar ngadalësim ose nuk përgjigjet në kërkesa, por nga pool-i ai nuk hiqet automatikisht. Çfarë duhet të bëjmë në këtë rast? Të përsërisim përpjekjen? Ta heqim nga skema e rruazimit? Dhe çfarë do të thotë «shumë ngadalë» – sa është kjo në numra, dhe kush i përcakton ato? Ndoshta thjesht t’i japim një pauzë dhe të provojmë më vonë? Nëse po, sa vonë?
Çfarë është Pool Ejection në Istio
Dhe këtu vjen në ndihmë Istio me automatet e tij të mbrojtjes Circuit Breaker, që përkohësisht heqin kontejnerët e defektuar nga pool-i i burimeve të rruazimit dhe balancimit të ngarkesës, duke realizuar procedurën e Pool Ejection.
Duke përdorur strategjinë e zbulimit të devijimeve (outlier detection), Istio detecton pod-e të këqija, që dallohet nga grupi përgjithshëm, dhe i heq ato nga pool-i i burimeve për një kohë të caktuar, e quajtur «dritarja e gjumit» (sleep window).
Për të ilustruar se si funksionon në Kubernetes në platformën OpenShift, le të fillojmë me një tërheqje të mikroshërbimeve që funksionojnë mirë nga shembulli në depo. . Këtu kemi dy podë, v1 dhe v2, në secilin prej të cilëve funksionon një kontejner. Kur rregullat e rrugës Istio nuk përdoren, Kubernetes në mënyrë të paracaktuar aplikon një rrugëzim ciklik të balancuar barabartë:
Po përgatitemi për dështimin
Para se të bëjmë Pool Ejection, duhet të krijojmë një rregull të rrugës Istio. Supozoni se duam të shpërndajmë kërkesat midis podëve në një raport 50/50. Për më tepër, do të rrisim numrin e konteinerëve v2 nga një në dy, kështu:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Tani vendosim rregullin e rrugës për të shpërndarë trafikun midis podëve në një raport 50/50.
Ja si duket rezultati i aplikimit të këtij rregulli:
Mund të argumentoni se në këtë ekran nuk është 50/50, por 14:9, por me kalimin e kohës situata do të rregullohet.
Po shkaktojmë dështimin
Tani do të çaktivizojmë një nga dy konteinerët v2, në mënyrë që të kemi një kontejner të mirë v1, një kontejner të mirë v2 dhe një kontejner të dështuar v2:
Po riparojmë dështimin
Pra, kemi një kontejner të dështuar, dhe është koha për Pool Ejection. Me një konfigurim shumë të thjeshtë, do të përjashtojmë këtë kontejner të dështuar nga çdo skemë rrugëzimi për 15 sekonda me shpresën se ai do të rikthehet në një gjendje normale (ose do të riaktivizohet, ose do të rikuperojë performancën). Këtu është si duket ky konfigurim dhe rezultatet e tij:
Siç shihet, kontejneri i dështuar v2 nuk përdoret më për rrugëzimin e kërkesave, pasi u hoq nga pool. Por pas 15 sekondash ai do të rikthehet automatikisht në pool. Në thelb, sapo e tregonim se si funksionon Pool Ejection.
Po fillojmë të ndërtojmë arkitekturën
Pool Ejection në kombinim me funksionalitetet e monitorimit Istio lejon fillimin e ndërtimit të një kornize për zëvendësimin automatik të konteinerëve të dëmtuar, për të reduktuar, madje edhe për të eliminuar, kohëzgjatjet dhe dështimet.
NASA ka një moto të njohur – Dështimi Nuk Është Një Opcioni, që mendohet se është shkruar nga menaxheri i fluturimeve . Në shqip mund të përkthehet si "Dështimi nuk është një opsion", dhe kuptimi këtu është se gjithçka mund të funksionojë nëse keni mjaft vullnet. Megjithatë, në jetën reale, dështimet nuk ndodhin thjesht; ato janë të pashmangshme, kudo dhe në gjithçka. Si të përballeni me to në rastin e mikroshërbimeve? Sipas mendimit tonë, më mirë është të mos mbështeteni në forcën e vullnetit, por në mundësitë e konteinerëve. , , dhe .
Istio, siç e përmendëm më sipër, implementon një koncept të provuar dhe të suksesshëm në botën fizike, atë të automatikëve të fikjes. Dhe si një automatik elektrik ndalon një pjesë problematike të zinxhirit, ashtu edhe Circuit Breaker në Istio ndërpret lidhjen midis rrjedhës së kërkesave dhe konteinerit problematik, kur diçka shkon keq me pikën përfundimtare, për shembull, kur serveri ka rënë ose ka filluar të ngadalësohet.
Dhe në rastin e dytë, problemet janë akoma më të shumta, pasi ngadalësimi i një konteineri jo vetëm që shkakton një kaskadë vonesash në shërbimet që i drejtohen atij, dhe si pasojë, ul rendimentin e sistemit në tërësi, por gjithashtu gjeneron përsëritje të kërkesave ndaj një shërbimi që tashmë është ngadalësuar, gjë që vetëm e rëndon situatën.
Circuit Breaker në teori
Circuit Breaker është një proxy që kontrollon rrjedhën e kërkesave në pikën përfundimtare. Kur kjo pikë ndalon së punuari ose – në varësi të cilësimeve të caktuara – fillon të ngadalësohet, proxy ndërpret lidhjen me konteinerin. Trafiku pas kësaj redirektohet në konteinerë të tjerë, thjesht për shkak të balancimit të ngarkesës. Lidhja mbetet e shkëputur (open) për një periudhë të caktuar, le të say dy minuta, dhe pastaj konsiderohet e gjysmë-shkëputur (half-open). Përpjekja për të dërguar kërkesën e ardhshme përcakton gjendjen e mëtejshme të lidhjes. Nëse gjithçka shkon mirë me shërbimin, lidhja kthehet në gjendjen funksionale dhe bëhet sërish e mbyllur (closed). Nëse me shërbimin ka ende diçka të keqe, lidhja ndërpritet sërish dhe hapet një tjetër periudhë pritjeje. Kjo është si duket një diagram i thjeshtë i ndryshimeve të gjendjeve të Circuit Breaker:
Është e rëndësishme të theksohet se e gjithë kjo ndodh në nivelin e arhitektures sistemore. Prandaj, në një moment, do t'ju duhet të mësoni aplikacionet tuaja të punojnë me Circuit Breaker, për shembull, duke ofruar një vlerë të paracaktuar në përgjigje ose, nëse është e mundur, të injoroni ekzistencën e shërbimit. Për këtë përdoret modeli bulkhead, por ai del jashtë kornizës së këtij artikulli.
Circuit Breaker në praktikë
Për shembull, ne do të nisnim në OpenShift dy versione të mikroshërbimit tonë të rekomandimeve. Versioni 1 do të funksionojë normalisht, ndërsa në v2 ne do të integrojmë një vonesë për të imituar ngadalësimin në server. Për të parë rezultatet, përdoret mjeti :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Gjithçka duket se funksionon, por me çmimin e çfarë? Në dukje, kemi 100 % disponueshmëri, por shikoni me kujdes – maksimalja e kohës së transaksionit arrin deri në 12 sekonda. Kjo është një ngushticë e dukshme dhe duhet të zgjerohet.
Për këtë, ne do të eliminonim thirrjet ndaj konteinerëve të ngadaltë me ndihmën e Istio. Këtu është si duket konfigurimi përkatës duke përdorur Circuit Breaker:
Rreshti i fundit me parametrin httpMaxRequestsPerConnection sinjalizon se lidhja duhet të shpërndahen me përpjekjen për të krijuar një lidhje të re – të dytë – përveç asaj ekzistuese. Duke qenë se kontenieri ynë imiton një shërbim që ngadalëson, këto situata do të ndodhin herë pas here, dhe atëherë Istio do të kthejë një gabim 503, ndërsa ja çfarë do të tregojë siege:
Mirë, tani kemi Circuit Breaker, çfarë ndodh më pas?
Pra, ne zbatuam shkëputjen automatike, pa prekur fare kodin burimor të shërbimeve. Duke përdorur Circuit Breaker dhe procedurën e përshkruar më lart Pool Ejection, ne mund t'i largojmë nga grupi i burimeve kontenierët ngadalësues deri sa ata të rikuperohen, dhe të kontrollojmë cilësinë e tyre me një periudhë të caktuar - në shembullin tonë, kjo është dy minuta (parametri sleepWindow).
Vini re se aftësia e aplikacionit për t'u përgjigjur ndaj gabimit 503 akoma përcaktohet në nivelin e kodit të tij burimor. Ekzistojnë shumë strategji për punën me Circuit Breaker, të cilat zbatohen në varësi të situatës.
Në postimin e ardhshëm: do të flasim për gjurmimin dhe monitorimin, të cilat janë tashmë të integruara ose lehtësisht të shtohen në Istio, si dhe se si të futim gabime në sistem në mënyrë të qëllimshme.
Burimi: habr.com
