Likizo zimekwisha na tumerudi na chapisho letu la pili katika mfululizo wa Istio Service Mesh.
Mada ya leo ni Mzunguko wa Mzunguko, ambayo ilitafsiriwa katika uhandisi wa umeme wa Kirusi ina maana "mzunguko wa mzunguko", kwa lugha ya kawaida - "mzunguko wa mzunguko". Ni katika Istio pekee mashine hii haikatai mzunguko mfupi au uliojaa kupita kiasi, lakini vyombo vyenye hitilafu.
Jinsi hii inapaswa kufanya kazi kikamilifu
Wakati huduma ndogo ndogo zinasimamiwa na Kubernetes, kwa mfano ndani ya jukwaa la OpenShift, hupanda na kushuka kiotomatiki kulingana na mzigo. Kwa sababu huduma ndogo huendeshwa kwenye maganda, kunaweza kuwa na visa vingi vya huduma ndogo iliyo na kontena kwenye sehemu moja ya mwisho, na Kubernetes itaelekeza maombi na salio la upakiaji kati yao. Na - kwa kweli - yote haya yanapaswa kufanya kazi kikamilifu.
Tunakumbuka kuwa huduma ndogo ni ndogo na za muda mfupi. Ephemerality, ambayo hapa ina maana urahisi wa kuonekana na kutoweka, mara nyingi hupunguzwa. Kuzaliwa na kifo cha mfano mwingine wa huduma ndogo kwenye ganda ni mambo yanayotarajiwa kabisa, OpenShift na Kubernetes hushughulikia hili vizuri, na kila kitu hufanya kazi vizuri - lakini tena kwa nadharia.
Jinsi inavyofanya kazi kweli
Sasa fikiria kwamba mfano maalum wa microservice, yaani, chombo, imekuwa isiyoweza kutumika: ama haijibu (kosa 503), au, ni nini kisichofurahi zaidi, hujibu, lakini polepole sana. Kwa maneno mengine, inakuwa glitchy au haijibu maombi, lakini haiondolewa moja kwa moja kutoka kwenye bwawa. Nini kifanyike katika kesi hii? Je, ungependa kujaribu tena? Ninapaswa kuiondoa kutoka kwa mpango wa uelekezaji? Na "polepole sana" inamaanisha nini - ni ngapi kwa idadi, na ni nani anayeamua? Labda ipe muda kidogo na ujaribu tena baadaye? Ikiwa ndivyo, ni kiasi gani baadaye?
Utoaji wa Dimbwi ni nini katika Istio
Na hapa Istio inakuja kuokoa na mashine zake za ulinzi za Circuit Breaker, ambazo huondoa kwa muda vyombo vyenye hitilafu kutoka kwenye bwawa la rasilimali za kusawazisha uelekezaji na upakiaji, kutekeleza utaratibu wa Kutoa Dimbwi.
Ikitumia mbinu ya ugunduzi wa nje, Istio hutambua maganda ya curve ambayo yako nje ya mstari na kuyaondoa kwenye hifadhi ya rasilimali kwa muda maalum, unaoitwa dirisha la usingizi.
Kuonyesha jinsi hii inavyofanya kazi katika Kubernetes kwenye jukwaa la OpenShift, wacha tuanze na picha ya skrini ya huduma ndogo zinazofanya kazi kawaida kutoka kwa mfano kwenye hazina. . Hapa tuna maganda mawili, v1 na v2, kila moja inaendesha chombo kimoja. Wakati sheria za uelekezaji za Istio hazitumiki, Kubernetes hutenganisha uelekezaji uliosawazishwa wa mzunguko wa robin:
Kujitayarisha kwa ajali
Kabla ya kufanya Utoaji wa Dimbwi, unahitaji kuunda sheria ya uelekezaji ya Istio. Wacha tuseme tunataka kusambaza maombi kati ya maganda kwa uwiano wa 50/50. Zaidi ya hayo, tutaongeza idadi ya kontena za v2 kutoka moja hadi mbili, kama hii:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Sasa tunaweka sheria ya uelekezaji ili trafiki isambazwe kati ya maganda kwa uwiano wa 50/50.
Hii ndio matokeo ya sheria hii inaonekana kama:
Unaweza kupata kosa na ukweli kwamba skrini hii sio 50/50, lakini 14: 9, lakini baada ya muda hali itaboresha.
Kufanya glitch
Sasa hebu tuzime mojawapo ya kontena mbili za v2 ili tuwe na kontena moja yenye afya ya v1, kontena moja lenye afya la v2 na kontena moja yenye hitilafu ya v2:
Kurekebisha hitilafu
Kwa hivyo, tuna kontena lenye hitilafu, na ni wakati wa Utoaji wa Dimbwi. Kwa kutumia usanidi rahisi sana, tutaondoa kontena hili ambalo halijafanikiwa kutoka kwa mipango yoyote ya uelekezaji kwa sekunde 15 kwa matumaini kwamba litarejea katika hali nzuri (ama kuanzisha upya au kurejesha utendaji). Hivi ndivyo usanidi huu unavyoonekana na matokeo ya kazi yake:
Kama unavyoona, kontena ya v2 iliyoshindwa haitumiki tena kwa maombi ya kuelekeza kwa sababu imeondolewa kwenye bwawa. Lakini baada ya sekunde 15 itarudi moja kwa moja kwenye bwawa. Kwa kweli, tumeonyesha jinsi Utoaji wa Dimbwi hufanya kazi.
Wacha tuanze kujenga usanifu
Utoaji wa Dimbwi, pamoja na uwezo wa ufuatiliaji wa Istio, hukuruhusu kuanza kujenga mfumo wa kubadilisha kiotomatiki vyombo vyenye hitilafu ili kupunguza, ikiwa sio kuondoa, muda wa kupungua na kushindwa.
β
NASA ina kauli mbiu moja kubwa - Kushindwa Sio Chaguo, mwandishi ambaye anachukuliwa kuwa mkurugenzi wa ndege. . Inaweza kutafsiriwa kwa Kirusi kama "Kushindwa sio chaguo," na maana hapa ni kwamba kila kitu kinaweza kufanywa kazi ikiwa una mapenzi ya kutosha. Hata hivyo, katika maisha halisi, kushindwa sio tu kutokea, ni kuepukika, kila mahali na katika kila kitu. Na jinsi ya kukabiliana nao katika kesi ya microservices? Kwa maoni yetu, ni bora kutegemea sio nguvu, lakini juu ya uwezo wa vyombo, , Na .
Istio, kama tulivyoandika hapo juu, hutumia dhana ya wavunjaji wa mzunguko, ambayo imejidhihirisha vizuri katika ulimwengu wa kimwili. Na kama vile kivunja mzunguko wa umeme huzima sehemu ya tatizo ya saketi, programu ya Istio Circuit Breaker hufungua muunganisho kati ya mtiririko wa maombi na kontena la tatizo wakati kuna kitu kibaya na sehemu ya mwisho, kwa mfano, seva ilipoanguka au kuanza kufanya kazi. Punguza mwendo.
Kwa kuongezea, katika kesi ya pili kuna shida zaidi tu, kwani breki za kontena moja sio tu husababisha ucheleweshaji wa huduma zinazoipata na, kwa sababu hiyo, kupunguza utendaji wa mfumo kwa ujumla, lakini pia hutoa mara kwa mara. maombi kwa huduma ambayo tayari inaendeshwa polepole, ambayo inazidisha hali hiyo.
Mvunjaji wa mzunguko katika nadharia
Circuit Breaker ni proksi inayodhibiti mtiririko wa maombi hadi mwisho. Wakati hatua hii inachaacha kufanya kazi au, kulingana na mipangilio iliyoelezwa, huanza kupungua, wakala huvunja uhusiano na chombo. Trafiki basi huelekezwa kwenye vyombo vingine, kwa sababu tu ya kusawazisha upakiaji. Uunganisho unabaki wazi kwa dirisha fulani la usingizi, sema dakika mbili, na kisha inachukuliwa kuwa nusu-wazi. Jaribio la kutuma ombi linalofuata huamua hali zaidi ya muunganisho. Ikiwa kila kitu ni sawa na huduma, uunganisho unarudi kwenye hali ya kazi na tena inakuwa imefungwa. Ikiwa bado kuna kitu kibaya na huduma, muunganisho umekatwa na dirisha la usingizi linawashwa tena. Hivi ndivyo mchoro wa hali iliyorahisishwa ya Circuit Breaker inaonekana kama:
Ni muhimu kutambua hapa kwamba yote haya hutokea kwa kiwango cha, kwa kusema, usanifu wa mfumo. Kwa hivyo wakati fulani itabidi ufundishe programu zako kufanya kazi na Circuit Breaker, kama vile kutoa thamani chaguo-msingi katika kujibu au, ikiwezekana, kupuuza kuwepo kwa huduma. Mchoro wa bulkhead hutumiwa kwa hili, lakini ni zaidi ya upeo wa makala hii.
Mvunjaji wa mzunguko katika mazoezi
Kwa mfano, tutaendesha matoleo mawili ya pendekezo letu la huduma ndogo kwenye OpenShift. Toleo la 1 litafanya kazi vizuri, lakini katika v2 tutaunda kwa kuchelewa ili kuiga kushuka kwa kasi kwenye seva. Ili kuona matokeo, tumia zana :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Kila kitu kinaonekana kufanya kazi, lakini kwa gharama gani? Kwa mtazamo wa kwanza, tuna upatikanaji wa 100%, lakini angalia kwa karibu - muda wa juu wa muamala ni kama sekunde 12. Hii ni wazi ni kizuizi na inahitaji kupanuliwa.
Ili kufanya hivyo, tutatumia Istio kuondoa simu za kupunguza kasi ya vyombo. Hivi ndivyo usanidi unaolingana unavyoonekana kwa kutumia Circuit Breaker:
Mstari wa mwisho na parameta ya httpMaxRequestsPerConnection inaashiria kwamba unganisho unapaswa kukatwa wakati wa kujaribu kuunda mwingine - wa pili - unganisho kwa kuongeza ile iliyopo. Kwa kuwa chombo chetu kinaiga huduma polepole, hali kama hizi zitatokea mara kwa mara, na kisha Istio itarudisha kosa 503, lakini hii ndio kuzingirwa kutaonyesha:
Sawa, tuna Mvunjaji wa Mzunguko, ni nini kinachofuata?
Kwa hivyo, tulitekeleza kuzima kiotomatiki bila kugusa msimbo wa chanzo wa huduma zenyewe hata kidogo. Kutumia Mvunjaji wa Mzunguko na utaratibu wa Kutolewa kwa Dimbwi ulioelezwa hapo juu, tunaweza kuondoa vyombo vya kuvunja kutoka kwenye bwawa la rasilimali hadi warudi kwa kawaida, na uangalie hali yao kwa mzunguko maalum - kwa mfano wetu, hii ni dakika mbili (parameter ya usingiziWindow).
Kumbuka kwamba uwezo wa programu kujibu hitilafu ya 503 bado umewekwa katika kiwango cha msimbo wa chanzo. Kuna mikakati mingi ya kutumia Circuit Breaker, kulingana na hali.
Katika chapisho linalofuata: Tutazungumza juu ya ufuatiliaji na ufuatiliaji ambao tayari umejengwa ndani au umeongezwa kwa urahisi kwenye Istio, na pia jinsi ya kuingiza makosa kwenye mfumo kwa kukusudia.
Chanzo: mapenzi.com