Tapos na ang bakasyon at nagbabalik kami sa aming pangalawang post sa serye ng Istio Service Mesh.
Ang paksa ngayon ay Circuit Breaker, na isinalin sa Russian electrical engineering ay nangangahulugang "circuit breaker", sa karaniwang parlance - "circuit breaker". Tanging sa Istio ang makina na ito ay hindi nagdidiskonekta ng isang shorted o overloaded na circuit, ngunit may mga sira na lalagyan.
Paano ito dapat gumana nang perpekto
Kapag ang mga microservice ay pinamamahalaan ng Kubernetes, halimbawa sa loob ng OpenShift platform, awtomatiko silang nag-scale up at down depende sa load. Dahil tumatakbo ang mga microservice sa mga pod, maaaring mayroong maraming instance ng isang containerized na microservice sa isang endpoint, at iruruta ng Kubernetes ang mga kahilingan at balanse sa pag-load sa pagitan ng mga ito. At - sa isip - lahat ng ito ay dapat gumana nang perpekto.
Naaalala namin na ang mga microservice ay maliit at panandalian. Ang ephemerality, na dito ay nangangahulugan ng kadalian ng paglitaw at pagkawala, ay madalas na minamaliit. Ang kapanganakan at pagkamatay ng isa pang halimbawa ng isang microservice sa isang pod ay lubos na inaasahang bagay, ang OpenShift at Kubernetes ay pinangangasiwaan ito nang maayos, at lahat ay gumagana nang mahusay - ngunit muli sa teorya.
Kung paano ito gumagana
Ngayon isipin na ang isang partikular na halimbawa ng isang microservice, iyon ay, isang lalagyan, ay naging hindi na magagamit: alinman sa hindi ito tumugon (error 503), o, kung ano ang mas hindi kanais-nais, ito ay tumugon, ngunit masyadong mabagal. Sa madaling salita, nagiging glitchy ito o hindi tumutugon sa mga kahilingan, ngunit hindi ito awtomatikong inaalis sa pool. Ano ang dapat gawin sa kasong ito? Upang muling subukan? Dapat ko bang alisin ito sa routing scheme? At ano ang ibig sabihin ng "masyadong mabagal" - ilan ito sa mga numero, at sino ang tumutukoy sa kanila? Baka bigyan lang ito ng pahinga at subukan muli sa ibang pagkakataon? Kung gayon, magkano mamaya?
Ano ang Pool Ejection sa Istio
At narito, sumagip si Istio kasama ang mga makinang pang-proteksyon ng Circuit Breaker nito, na pansamantalang nag-aalis ng mga sira na container mula sa routing at load balancing resource pool, na nagpapatupad ng pamamaraan ng Pool Ejection.
Gamit ang isang outlier na diskarte sa pag-detect, nakita ni Istio ang mga pod curve na wala sa linya at inaalis ang mga ito sa resource pool para sa isang paunang natukoy na tagal ng oras, na tinatawag na sleep window.
Upang ipakita kung paano ito gumagana sa Kubernetes sa OpenShift platform, magsimula tayo sa isang screenshot ng mga microservice na karaniwang gumagana mula sa halimbawa sa repository . Narito mayroon kaming dalawang pod, v1 at v2, bawat isa ay nagpapatakbo ng isang lalagyan. Kapag hindi ginagamit ang mga panuntunan sa pagruruta ng Istio, nagde-default ang Kubernetes sa pantay na balanseng pagruruta ng round-robin:
Paghahanda para sa isang pag-crash
Bago gawin ang Pool Ejection, kailangan mong gumawa ng Istio routing rule. Sabihin nating gusto naming ipamahagi ang mga kahilingan sa pagitan ng mga pod sa isang 50/50 ratio. Bukod pa rito, dadagdagan namin ang bilang ng mga v2 container mula isa hanggang dalawa, tulad nito:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Ngayon ay nagtatakda kami ng panuntunan sa pagruruta upang maipamahagi ang trapiko sa pagitan ng mga pod sa isang 50/50 ratio.
Ganito ang hitsura ng resulta ng panuntunang ito:
Maaari kang makahanap ng kasalanan sa katotohanan na ang screen na ito ay hindi 50/50, ngunit 14:9, ngunit sa paglipas ng panahon ay bubuti ang sitwasyon.
Gumagawa ng glitch
Ngayon, i-disable natin ang isa sa dalawang v2 container para magkaroon tayo ng isang malusog na v1 container, isang malusog na v2 container at isang may sira na v2 container:
Pag-aayos ng glitch
Kaya, mayroon kaming sira na lalagyan, at oras na para sa Pool Ejection. Gamit ang isang napakasimpleng config, ibubukod namin ang nabigong container na ito mula sa anumang mga routing scheme sa loob ng 15 segundo sa pag-asang babalik ito sa isang malusog na estado (i-restart o i-restore ang performance). Ito ang hitsura ng config na ito at ang mga resulta ng trabaho nito:
Gaya ng nakikita mo, hindi na ginagamit ang nabigong v2 container para sa mga kahilingan sa pagruruta dahil inalis na ito sa pool. Ngunit pagkatapos ng 15 segundo ay awtomatiko itong babalik sa pool. Actually, ipinakita lang namin kung paano gumagana ang Pool Ejection.
Simulan natin ang pagbuo ng arkitektura
Ang Pool Ejection, na sinamahan ng mga kakayahan sa pagsubaybay ni Istio, ay nagbibigay-daan sa iyong magsimulang bumuo ng isang framework para sa awtomatikong pagpapalit ng mga sira na lalagyan upang mabawasan, kung hindi man maalis, ang downtime at mga pagkabigo.
β
Ang NASA ay may isang malakas na motto - Failure Is Not an Option, ang may-akda nito ay itinuturing na direktor ng flight . Maaari itong isalin sa Russian bilang "Ang pagkabigo ay hindi isang opsyon," at ang kahulugan dito ay ang lahat ay maaaring gawin upang gumana kung mayroon kang sapat na kalooban. Gayunpaman, sa totoong buhay, ang mga kabiguan ay hindi basta-basta nangyayari, ito ay hindi maiiwasan, sa lahat ng dako at sa lahat ng bagay. At paano haharapin ang mga ito sa kaso ng mga microservice? Sa aming opinyon, mas mahusay na umasa hindi sa lakas ng loob, ngunit sa mga kakayahan ng mga lalagyan, , At .
Istio, tulad ng isinulat namin sa itaas, ay nagpapatupad ng konsepto ng mga circuit breaker, na napatunayang mabuti ang sarili sa pisikal na mundo. At tulad ng isang electrical circuit breaker na pinapatay ang isang seksyon ng problema ng isang circuit, binubuksan ng software ng Istio na Circuit Breaker ang koneksyon sa pagitan ng isang stream ng mga kahilingan at isang lalagyan ng problema kapag may mali sa endpoint, halimbawa, kapag nag-crash ang server o nagsimulang Magdahan-dahan.
Bukod dito, sa pangalawang kaso ay mayroon lamang higit pang mga problema, dahil ang mga preno ng isang lalagyan ay hindi lamang nagdudulot ng isang kaskad ng mga pagkaantala sa mga serbisyo sa pag-access dito at, bilang isang resulta, binabawasan ang pagganap ng system sa kabuuan, ngunit bumubuo rin ng paulit-ulit mga kahilingan sa isang mabagal nang tumatakbong serbisyo, na nagpapalala lamang sa sitwasyon .
Circuit Breaker sa teorya
Ang Circuit Breaker ay isang proxy na kumokontrol sa daloy ng mga kahilingan sa isang endpoint. Kapag huminto sa paggana ang puntong ito o, depende sa tinukoy na mga setting, nagsimulang bumagal, sinira ng proxy ang koneksyon sa lalagyan. Ire-redirect ang trapiko sa ibang mga container, dahil lang sa load balancing. Ang koneksyon ay nananatiling bukas para sa isang partikular na window ng pagtulog, sabihin ng dalawang minuto, at pagkatapos ay itinuturing na kalahating bukas. Ang pagtatangkang ipadala ang susunod na kahilingan ay tumutukoy sa karagdagang estado ng koneksyon. Kung ang lahat ay OK sa serbisyo, ang koneksyon ay babalik sa gumaganang kondisyon at muli ay sarado. Kung may mali pa rin sa serbisyo, madidiskonekta ang koneksyon at muling i-enable ang sleep window. Narito kung ano ang hitsura ng isang pinasimple na diagram ng estado ng Circuit Breaker:
Mahalagang tandaan dito na ang lahat ng ito ay nangyayari sa antas ng, wika nga, arkitektura ng system. Kaya sa isang punto ay kailangan mong turuan ang iyong mga aplikasyon na gumana sa Circuit Breaker, tulad ng pagbibigay ng default na halaga bilang tugon o, kung maaari, hindi papansinin ang pagkakaroon ng serbisyo. Ginagamit ang bulkhead pattern para dito, ngunit lampas ito sa saklaw ng artikulong ito.
Circuit Breaker sa pagsasanay
Halimbawa, tatakbo kami ng dalawang bersyon ng aming rekomendasyong microservice sa OpenShift. Ang Bersyon 1 ay gagana nang maayos, ngunit sa v2 ay bubuo kami sa isang pagkaantala upang gayahin ang mga pagbagal sa server. Upang tingnan ang mga resulta, gamitin ang tool :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Mukhang gumagana ang lahat, ngunit sa anong halaga? Sa unang tingin, mayroon kaming 100% availability, ngunit tingnang mabuti - ang maximum na tagal ng transaksyon ay hanggang 12 segundo. Ito ay malinaw na isang bottleneck at kailangang palawakin.
Para magawa ito, gagamitin namin ang Istio para alisin ang mga tawag sa mga mabagal na container. Ito ang hitsura ng kaukulang config gamit ang Circuit Breaker:
Ang huling linya na may parameter na httpMaxRequestsPerConnection ay nagpapahiwatig na ang koneksyon ay dapat na idiskonekta kapag sinusubukang lumikha ng isa pang - isang segundo - na koneksyon bilang karagdagan sa umiiral na isa. Dahil ginagaya ng aming container ang isang mabagal na serbisyo, pana-panahong lalabas ang mga ganitong sitwasyon, at pagkatapos ay magbabalik si Istio ng 503 error, ngunit ito ang ipapakita ng siege:
OK, mayroon kaming Circuit Breaker, ano ang susunod?
Kaya, ipinatupad namin ang awtomatikong pagsara nang hindi hinahawakan ang source code ng mga serbisyo mismo. Gamit ang Circuit Breaker at ang pamamaraan ng Pool Ejection na inilarawan sa itaas, maaari naming alisin ang mga lalagyan ng preno mula sa resource pool hanggang sa bumalik sila sa normal, at suriin ang kanilang status sa isang tinukoy na frequency - sa aming halimbawa, ito ay dalawang minuto (parameter ng sleepWindow).
Tandaan na ang kakayahan ng isang application na tumugon sa isang 503 error ay nakatakda pa rin sa antas ng source code. Mayroong maraming mga diskarte para sa paggamit ng Circuit Breaker, depende sa sitwasyon.
Sa susunod na post: Pag-uusapan natin ang tungkol sa pagsubaybay at pagsubaybay na naka-built-in na o madaling naidagdag sa Istio, pati na rin kung paano sinasadyang magpasok ng mga error sa system.
Pinagmulan: www.habr.com