La ferioj finiĝis kaj ni revenas kun nia dua afiŝo en la serio Istio Service Mesh.
La hodiaŭa temo estas Circuit Breaker, kiu tradukita en la rusan elektroteknikon signifas "circuit breaker", en komuna lingvaĵo - "circuit breaker". Nur en Istio ĉi tiu maŝino ne malkonektas mallongigitan aŭ troŝarĝitan cirkviton, sed misajn ujojn.
Kiel ĉi tio devus funkcii ideale
Kiam mikroservoj estas administritaj de Kubernetes, ekzemple ene de la platformo OpenShift, ili aŭtomate skalas supren kaj malsupren laŭ la ŝarĝo. Ĉar mikroservoj funkcias en podoj, povas ekzisti pluraj okazoj de kontenerigita mikroservo sur unu finpunkto, kaj Kubernetes direktos petojn kaj ŝarĝan ekvilibron inter ili. Kaj - ideale - ĉio ĉi devus funkcii perfekte.
Ni memoras, ke mikroservoj estas malgrandaj kaj efemeraj. Efemereco, kiu ĉi tie signifas la facilecon aperi kaj malaperi, estas ofte subtaksata. La naskiĝo kaj morto de alia okazo de mikroservo en podo estas sufiĉe atendataj aferoj, OpenShift kaj Kubernetes bone traktas tion, kaj ĉio funkcias bonege - sed denove teorie.
Kiel ĝi vere funkcias
Nun imagu, ke specifa okazo de mikroservo, tio estas ujo, fariĝis neuzebla: aŭ ĝi ne respondas (eraro 503), aŭ, kio estas pli malagrabla, ĝi respondas, sed tro malrapide. Alivorte, ĝi fariĝas misa aŭ ne respondas al petoj, sed ĝi ne estas aŭtomate forigita de la naĝejo. Kion oni faru en ĉi tiu kazo? Ĉu reprovi? Ĉu mi forigu ĝin el la envojiga skemo? Kaj kion signifas "tro malrapida" - kiom ĝi estas en nombroj, kaj kiu determinas ilin? Eble nur doni al ĝi paŭzon kaj provi denove poste? Se jes, kiom poste?
Kio estas Pool Elĵeto en Istio
Kaj ĉi tie Istio venas al la rekupero kun ĝiaj Circuit Breaker-protektaj maŝinoj, kiuj provizore forigas misajn ujojn de la vojigo kaj ŝarĝo-ekvilibra rimeda naĝejo, efektivigante la Pool Ejection proceduron.
Uzante eksterordinaran detektostrategion, Istio detektas kurbkapsojn kiuj estas eksterliniaj kaj forigas ilin de la rimedaĵaro dum specifa kvanto de tempo, nomita dormfenestro.
Por montri kiel ĉi tio funkcias en Kubernetes sur la platformo OpenShift, ni komencu per ekrankopio de normale laborantaj mikroservoj el la ekzemplo en la deponejo. . Ĉi tie ni havas du podojn, v1 kaj v2, ĉiu kurante unu ujon. Kiam Istio-vojreguloj ne estas uzataj, Kubernetes defaŭlte al egale ekvilibra cirkla-subskribolista vojigo:
Pretiĝas por kraŝo
Antaŭ ol fari Pool Elĵeton, vi devas krei regulon de vojigo de Istio. Ni diru, ke ni volas distribui petojn inter balgoj en proporcio 50/50. Aldone, ni pliigos la nombron da v2-ujoj de unu al du, jene:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Nun ni starigas regulon pri vojigo, por ke trafiko estu distribuita inter podoj en proporcio 50/50.
Jen kiel aspektas la rezulto de ĉi tiu regulo:
Vi povas trovi kulpon pri tio, ke ĉi tiu ekrano ne estas 50/50, sed 14:9, sed kun la tempo la situacio pliboniĝos.
Farante fuŝaĵon
Nun ni malŝaltu unu el la du v2-ujoj, por ke ni havu unu sanan v1-ujon, unu sanan v2-ujon kaj unu misan v2-ujon:
Ripari la eraron
Do, ni havas misan ujon, kaj estas tempo por Pool Elĵeto. Uzante tre simplan agordon, ni ekskludos ĉi tiun malsukcesan ujon de iuj vojaj skemoj dum 15 sekundoj kun la espero, ke ĝi revenos al sana stato (aŭ rekomenci aŭ restarigi agadon). Jen kiel aspektas ĉi tiu agordo kaj la rezultoj de ĝia laboro:
Kiel vi povas vidi, la malsukcesa v2-ujo ne plu estas uzata por direkti petojn ĉar ĝi estis forigita el la naĝejo. Sed post 15 sekundoj ĝi aŭtomate revenos al la naĝejo. Efektive, ni ĵus montris kiel funkcias Pool Ejection.
Ni komencu konstrui arkitekturon
Pool Elĵeto, kombinita kun la monitoradkapabloj de Istio, permesas al vi komenci konstrui kadron por aŭtomate anstataŭigi misajn ujojn por redukti, se ne forigi, malfunkcion kaj fiaskojn.
NASA havas unu laŭtan moton - Fiasko Ne Estas Opcio, kies aŭtoro estas konsiderata kiel la flugdirektoro. . Ĝi povas esti tradukita en la rusan kiel "Fiasko ne estas eblo", kaj la signifo ĉi tie estas, ke ĉio povas funkcii se vi havas sufiĉe da volo. Tamen, en la reala vivo, fiaskoj ne nur okazas, ili estas neeviteblaj, ĉie kaj en ĉio. Kaj kiel trakti ilin en la kazo de mikroservoj? Laŭ nia opinio, estas pli bone fidi ne je volforto, sed sur la kapabloj de ujoj, , kaj .
Istio, kiel ni skribis supre, efektivigas la koncepton de ŝaltiloj, kiu pruvis sin bone en la fizika mondo. Kaj ekzakte kiel elektra ŝaltilo malŝaltas probleman sekcion de cirkvito, la programaro Circuit Breaker de Istio malfermas la ligon inter fluo de petoj kaj problemujo kiam io estas malĝusta kun la finpunkto, ekzemple, kiam la servilo kraŝis aŭ komencis. malrapidiĝu.
Krome, en la dua kazo estas nur pli da problemoj, ĉar la bremsoj de unu ujo ne nur kaŭzas kaskadon de prokrastoj en la servoj alirantaj ĝin kaj, kiel rezulto, reduktas la rendimenton de la sistemo entute, sed ankaŭ generas ripetajn. petoj al jam malrapida servo, kio nur pligravigas la situacion.
Circuit Breaker en teorio
Circuit Breaker estas prokurilo, kiu kontrolas la fluon de petoj al finpunkto. Kiam ĉi tiu punkto ĉesas funkcii aŭ, depende de la agordoj specifitaj, komencas malrapidiĝi, la prokurilo rompas la ligon kun la ujo. Trafiko tiam estas redirektita al aliaj ujoj, simple pro ŝarĝbalancado. La konekto restas malfermita por difinita dormfenestro, ekzemple du minutojn, kaj tiam estas konsiderata duonmalferma. Provo sendi la sekvan peton determinas la plian staton de la konekto. Se ĉio estas en ordo kun la servo, la konekto revenas al funkcia stato kaj denove fariĝas fermita. Se ankoraŭ estas io malĝusta kun la servo, la konekto estas malkonektita kaj la dormfenestro estas reebligita. Jen kiel aspektas simpligita Circuit Breaker-ŝtatdiagramo:
Gravas rimarki ĉi tie, ke ĉio ĉi okazas sur la nivelo de, por tiel diri, sistema arkitekturo. Do iam vi devos instrui viajn aplikaĵojn labori kun Circuit Breaker, kiel provizi defaŭltan valoron en respondo aŭ, se eble, ignori la ekziston de la servo. Por tio estas uzata fakmuro, sed ĝi estas ekster la amplekso de ĉi tiu artikolo.
Circuit Breaker en praktiko
Ekzemple, ni funkcios du versiojn de nia rekomenda mikroservo ĉe OpenShift. Versio 1 funkcios bone, sed en v2 ni konstruos prokraston por simuli malrapidiĝojn sur la servilo. Por vidi la rezultojn, uzu la ilon :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Ĉio ŝajnas funkcii, sed je kia kosto? Unuavide, ni havas 100% haveblecon, sed rigardu pli detale - la maksimuma transakcia daŭro estas eĉ 12 sekundoj. Ĉi tio klare estas botelkolo kaj devas esti vastigita.
Por fari tion, ni uzos Istio por forigi vokojn al malrapidigi ujojn. Jen kiel aspektas la responda agordo uzante Circuit Breaker:
La lasta linio kun la parametro httpMaxRequestsPerConnection signalas, ke la konekto kun devus esti malkonektita kiam oni provas krei alian - duan - konekton krom la ekzistanta. Ĉar nia ujo simulas malrapidan servon, tiaj situacioj aperos periode, kaj tiam Istio resendos 503-eraron, sed jen kion sieĝo montros:
Bone, ni havas Circuit Breaker, kio sekvas?
Do, ni efektivigis aŭtomatan haltigon tute sen tuŝi la fontkodon de la servoj mem. Uzante Circuit Breaker kaj la proceduron de Pool Ejection priskribita supre, ni povas forigi bremsajn ujojn el la rimeda naĝejo ĝis ili revenos al normalo, kaj kontroli sian staton je specifa frekvenco - en nia ekzemplo, ĉi tio estas du minutoj (parametro dormfenestro).
Notu, ke la kapablo de aplikaĵo respondi al 503-eraro ankoraŭ estas agordita ĉe la fontkodnivelo. Estas multaj strategioj por uzi Circuit Breaker, depende de la situacio.
En la sekva afiŝo: Ni kovros la spuradon kaj monitoradon, kiu estas jam enkonstruita aŭ facile aldonita al Istio, kaj ankaŭ kiel intence enkonduki erarojn en la sistemon.
fonto: www.habr.com