Die vakansie is verby en ons is terug met ons tweede pos in die Istio Service Mesh-reeks.
Vandag se onderwerp is Circuit Breaker, wat in Russiese elektriese ingenieurswese vertaal word "stroombreker", in algemene spreektaal - "stroombreker". Slegs in Istio ontkoppel hierdie masjien nie 'n kortgeslote of oorlaaide stroombaan nie, maar foutiewe houers.
Hoe dit ideaal moet werk
Wanneer mikrodienste deur Kubernetes bestuur word, byvoorbeeld binne die OpenShift-platform, skaal hulle outomaties op en af na gelang van die vrag. Aangesien mikrodienste in peule loop, kan daar veelvuldige gevalle van 'n houer-mikrodiens op een eindpunt wees, en Kubernetes sal versoeke en laaibalans tussen hulle stuur. En – ideaal gesproke – moet dit alles perfek werk.
Ons onthou dat mikrodienste klein en kortstondig is. Efemeraliteit, wat hier die gemak van verskyning en verdwyning beteken, word dikwels onderskat. Die geboorte en dood van nog 'n geval van 'n mikrodiens in 'n pod is nogal verwagte dinge, OpenShift en Kubernetes hanteer dit goed, en alles werk uitstekend - maar weer in teorie.
Hoe dit regtig werk
Stel jou nou voor dat 'n spesifieke geval van 'n mikrodiens, dit wil sê 'n houer, onbruikbaar geword het: óf dit reageer nie (fout 503), óf, wat meer onaangenaam is, dit reageer, maar te stadig. Met ander woorde, dit raak foutief of reageer nie op versoeke nie, maar dit word nie outomaties uit die swembad verwyder nie. Wat moet in hierdie geval gedoen word? Om weer te probeer? Moet ek dit uit die roeteerskema verwyder? En wat beteken “te stadig” – hoeveel is dit in getalle, en wie bepaal hulle? Miskien net 'n blaaskans gee en later weer probeer? Indien wel, hoeveel later?
Wat is swembaduitwerping in Istio
En hier kom Istio tot die redding met sy Circuit Breaker-beskermingsmasjiene, wat foutiewe houers tydelik uit die roetering en lasbalansering-hulpbronpoel verwyder, wat die Pool-uitwerpingsprosedure implementeer.
Deur 'n uitskieter-opsporingstrategie te gebruik, bespeur Istio peulkurwes wat buite lyn is en verwyder dit uit die hulpbronpoel vir 'n voorafbepaalde tyd, wat 'n slaapvenster genoem word.
Om te wys hoe dit in Kubernetes op die OpenShift-platform werk, kom ons begin met 'n skermkiekie van normaal werkende mikrodienste uit die voorbeeld in die bewaarplek . Hier het ons twee peule, v1 en v2, wat elkeen een houer laat loop. Wanneer Istio-roeteerreëls nie gebruik word nie, gebruik Kubernetes as verstek eweredig gebalanseerde round-robin-roetering:
Maak gereed vir 'n ongeluk
Voordat jy Pool Ejection doen, moet jy 'n Istio-roeteerreël skep. Kom ons sê ons wil versoeke tussen peule versprei in 'n 50/50 verhouding. Daarbenewens sal ons die aantal v2-houers van een na twee verhoog, soos volg:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Nou stel ons 'n roetereël sodat verkeer tussen peule in 'n 50/50-verhouding versprei word.
Hier is hoe die resultaat van hierdie reël lyk:
Jy kan fout vind met die feit dat hierdie skerm nie 50/50 is nie, maar 14:9, maar mettertyd sal die situasie verbeter.
Maak 'n fout
Kom ons deaktiveer nou een van die twee v2-houers sodat ons een gesonde v1-houer, een gesonde v2-houer en een foutiewe v2-houer het:
Die regstelling van die fout
So, ons het 'n foutiewe houer, en dit is tyd vir Pool Ejection. Deur 'n baie eenvoudige opstelling te gebruik, sal ons hierdie mislukte houer vir 15 sekondes van enige roeteerskemas uitsluit in die hoop dat dit na 'n gesonde toestand sal terugkeer (óf herbegin óf herstel werkverrigting). Dit is hoe hierdie konfigurasie lyk en die resultate van sy werk:
Soos u kan sien, word die mislukte v2-houer nie meer vir roeteversoeke gebruik nie, want dit is uit die swembad verwyder. Maar na 15 sekondes sal dit outomaties terugkeer na die swembad. Eintlik het ons net gewys hoe Pool Ejection werk.
Kom ons begin argitektuur bou
Pool Ejection, gekombineer met Istio se moniteringsvermoëns, laat jou toe om 'n raamwerk te begin bou vir die outomatiese vervanging van foutiewe houers om stilstand en mislukkings te verminder, indien nie uit te skakel nie.
NASA het een luide leuse - mislukking is nie 'n opsie nie, waarvan die skrywer as die vlugdirekteur beskou word . Dit kan in Russies vertaal word as "Misluk is nie 'n opsie nie," en die betekenis hier is dat alles laat werk kan word as jy genoeg wil het. In die werklike lewe gebeur mislukkings egter nie net nie, dit is onvermydelik, oral en in alles. En hoe om dit te hanteer in die geval van mikrodienste? Na ons mening is dit beter om nie op wilskrag te vertrou nie, maar op die vermoëns van houers, , En .
Istio, soos ons hierbo geskryf het, implementeer die konsep van stroombrekers, wat homself goed bewys het in die fisiese wêreld. En net soos 'n elektriese stroombreker 'n probleemgedeelte van 'n stroombaan afskakel, maak Istio se sagteware Circuit Breaker die verbinding tussen 'n stroom versoeke en 'n probleemhouer oop wanneer iets fout is met die eindpunt, byvoorbeeld wanneer die bediener neergestort het of begin het om vertraag.
Boonop is daar in die tweede geval net meer probleme, aangesien die remme van een houer nie net 'n kaskade van vertragings veroorsaak in die dienste wat toegang daartoe verkry nie en as gevolg daarvan die werkverrigting van die stelsel as geheel verminder, maar ook herhaaldelike versoeke aan 'n reeds stadiglopende diens, wat die situasie net vererger.
Stroombreker in teorie
Circuit Breaker is 'n instaanbediener wat die vloei van versoeke na 'n eindpunt beheer. Wanneer hierdie punt ophou werk of, afhangende van die instellings gespesifiseer, begin stadiger word, verbreek die proxy die verbinding met die houer. Verkeer word dan na ander houers herlei, bloot as gevolg van vragbalansering. Die verbinding bly oop vir 'n gegewe slaapvenster, sê twee minute, en word dan as halfoop beskou. 'n Poging om die volgende versoek te stuur, bepaal die verdere toestand van die verbinding. As alles in orde is met die diens, keer die verbinding terug na werkende toestand en word dit weer gesluit. As daar steeds iets fout is met die diens, word die verbinding ontkoppel en die slaapvenster word weer geaktiveer. Hier is hoe 'n vereenvoudigde stroombreker-toestanddiagram lyk:
Dit is belangrik om hier te let dat dit alles gebeur op die vlak van, so te sê, stelselargitektuur. Daarom sal jy op 'n stadium jou toepassings moet leer om met Circuit Breaker te werk, byvoorbeeld deur 'n verstekwaarde in reaksie te verskaf of, indien moontlik, die bestaan van die diens te ignoreer. Hiervoor word 'n skotpatroon gebruik, maar dit val buite die bestek van hierdie artikel.
Stroombreker in praktyk
Ons sal byvoorbeeld twee weergawes van ons aanbevelingsmikrodiens op OpenShift laat loop. Weergawe 1 sal goed werk, maar in v2 sal ons 'n vertraging inbou om verlangsamings op die bediener te simuleer. Gebruik die instrument om die resultate te sien :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Dit lyk of alles werk, maar teen watter koste? Met die eerste oogopslag het ons 100% beskikbaarheid, maar kyk van naderby – die maksimum transaksieduur is soveel as 12 sekondes. Dit is duidelik 'n bottelnek en moet uitgebrei word.
Om dit te doen, sal ons Istio gebruik om oproepe na stadige houers uit te skakel. Dit is hoe die ooreenstemmende konfigurasie lyk met behulp van Circuit Breaker:
Die laaste reël met die httpMaxRequestsPerConnection-parameter dui aan dat die verbinding met ontkoppel moet word wanneer daar probeer word om 'n ander - 'n tweede - verbinding bykomend tot die bestaande een te skep. Aangesien ons houer 'n stadige diens simuleer, sal sulke situasies periodiek ontstaan, en dan sal Istio 'n 503-fout terugstuur, maar dit is wat beleg sal wys:
OK, ons het Circuit Breaker, wat is volgende?
Dus, ons het outomatiese afskakeling geïmplementeer sonder om enigsins aan die bronkode van die dienste self te raak. Deur gebruik te maak van Circuit Breaker en die Pool Ejection-prosedure wat hierbo beskryf is, kan ons remhouers uit die hulpbronpoel verwyder totdat hulle na normaal terugkeer, en hul status teen 'n gespesifiseerde frekwensie nagaan - in ons voorbeeld is dit twee minute (sleepWindow-parameter).
Let daarop dat 'n toepassing se vermoë om op 'n 503-fout te reageer steeds op die bronkodevlak gestel is. Daar is baie strategieë vir die gebruik van Circuit Breaker, afhangende van die situasie.
In die volgende pos: Ons sal praat oor die opsporing en monitering wat reeds ingebou is of maklik by Istio gevoeg is, asook hoe om doelbewus foute in die stelsel in te voer.
Bron: will.com