🥇Kesi za matumizi ya wavu wa huduma

Kumbuka. tafsiri.: Mwandishi wa makala haya (Luc Perkins) ni wakili wa msanidi programu katika shirika la CNCF, ambalo ni nyumbani kwa miradi ya Open Source kama vile Linkerd, SMI (Service Mesh Interface) na Kuma (kwa njia, umewahi kujiuliza kwa nini Istio iko sio kwenye orodha hii? .). Kwa mara nyingine tena akijaribu kuleta jumuiya ya DevOps ufahamu bora wa hype ya kisasa inayoitwa "service mesh", anaorodhesha uwezo wa tabia 16 ambao ufumbuzi kama huo hutoa.

Leo matundu ya huduma ― moja ya mada motomoto katika uwanja wa uhandisi wa programu (na ni sawa!). Nadhani teknolojia hii inaahidi sana na ningependa kuiona ikipitishwa sana (inapoeleweka, bila shaka). Walakini, bado imezungukwa na aura ya siri kwa watu wengi. Wakati huo huo, hata wale ambao maalumu nayo, mara nyingi ni ngumu kuelezea faida zake na ni nini haswa (pamoja na yako kweli). Katika nakala hii nitajaribu kurekebisha hali hiyo kwa kuorodhesha anuwai kesi za matumizi "matundu ya huduma"*.

* Kumbuka transl.: hapa na zaidi katika makala tafsiri hii hasa ("mesh ya huduma") itatumika kwa matundu ya huduma ya neno jipya bado.

Lakini kwanza nataka kutoa maoni machache:

Sijawahi kufanya kazi na meshes za huduma au kuzitumia nje ya miradi iliyoanzishwa kwa elimu yangu mwenyewe. Kwa upande mwingine, mimi ndiye niliyeandika rundo la nyaraka za matundu ya huduma ya ndani ya Twitter mnamo 2015 (haikuitwa hata "mesh ya huduma" wakati huo) na nilishiriki katika ukuzaji wa wavuti na hati za Kiungo, kwa hivyo hiyo inamaanisha kitu.
Orodha yangu ni ya kukadiria na haijakamilika. Kunaweza kuwa na kesi za utumiaji zisizojulikana kwangu, na chaguzi mpya zinaweza kutokea baada ya muda kadri teknolojia inavyoendelea na umaarufu wake unakua.
Wakati huo huo, sio kila utekelezaji wa matundu ya huduma uliopo inasaidia kesi zote za utumiaji zilizoorodheshwa. Kwa hivyo, taarifa zangu kama vile "mesh ya huduma inaweza..." inapaswa kusomwa kama "mtu binafsi, na labda utekelezaji wote maarufu wa mesh unaweza...".
Mpangilio wa mifano haufanyi tofauti yoyote.

Orodha fupi:

ugunduzi wa huduma;
usimbaji fiche;
uthibitishaji na idhini;
kusawazisha mzigo;
kuvunja mzunguko;
kupima otomatiki;
kupelekwa kwa canary;
kupelekwa kwa bluu-kijani;
kuangalia afya;
upotezaji wa mzigo;
uakisi wa trafiki;
insulation;
ombi la kupunguza kiwango, kujaribu tena na kuisha muda;
telemetry;
ukaguzi;
taswira.

1. Ugunduzi wa huduma

TL;DR: Unganisha kwa huduma zingine kwenye mtandao kwa kutumia majina rahisi.

Huduma zinapaswa kuwa na uwezo wa "kupata" moja kwa moja kwa kutumia majina ya kutosha - kwa mfano, service.api.production, pets/staging au cassandra. Mazingira ya wingu ni elastic, na jina moja linaweza kuficha matukio mengi ya huduma. Ni wazi kuwa katika hali kama hiyo haiwezekani kuweka anwani zote za IP kwa bidii.

Zaidi, wakati huduma moja inapata nyingine, inapaswa kuwa na uwezo wa kutuma maombi kwa huduma hiyo bila hofu kwamba yataishia kwenye ingizo la mfano wake uliovunjika. Kwa maneno mengine, mesh ya huduma lazima ifuatilie afya ya matukio yote ya huduma na kusasisha orodha ya waandaji.

Kila matundu ya huduma hutekelezea utaratibu wa ugunduzi wa huduma kwa njia tofauti. Kwa sasa, njia ya kawaida ni kukabidhi michakato ya nje kama vile DNS Kubernetes. Hapo awali kwenye Twitter tulitumia mfumo wa majina kwa madhumuni haya Finagle. Kwa kuongezea, teknolojia ya matundu ya huduma hufanya iwezekane kwa njia maalum za kumtaja (ingawa bado sijaona utekelezaji wowote wa SM na utendakazi kama huo).

2. Usimbaji fiche

TL;DR: Ondoa trafiki ambayo haijasimbwa kati ya huduma na ufanye mchakato huu uwe wa kiotomatiki na uongezeke.

Inafurahisha kujua kwamba washambuliaji hawawezi kupenya mtandao wako wa ndani. Firewalls hufanya kazi nzuri ya hii. Lakini nini kitatokea ikiwa mdukuzi ataingia ndani? Je, ataweza kufanya chochote anachotaka na trafiki ya ndani ya huduma? Hebu tumaini hili halitatokea baada ya yote. Ili kuzuia hali hii, unapaswa kutekeleza mtandao wa sifuri ambapo trafiki yote kati ya huduma imesimbwa kwa njia fiche. Meshes nyingi za kisasa za huduma hufanikisha hili kupitia pande zote TLS (TLS ya pande zote, mTLS). Katika baadhi ya matukio, mTLS hufanya kazi katika mawingu na makundi yote (nadhani mawasiliano kati ya sayari siku moja yatapangwa vivyo hivyo).

Kwa kweli, kwa matundu ya huduma ya mTLS hiari. Kila huduma inaweza kutunza TLS yake, lakini hii inamaanisha kuwa utahitaji kutafuta njia ya kutoa vyeti, kusambaza kwenye wapangishi wa huduma, na kujumuisha msimbo katika programu ambayo itapakia vyeti hivi kutoka kwa faili. Ndiyo, usisahau kufanya upya vyeti hivi mara kwa mara. Wavu za huduma hubadilisha mTLS kiotomatiki na mifumo kama SIFFE, ambayo, kwa upande wake, hurekebisha mchakato wa kutoa na kuzunguka vyeti.

3. Uthibitishaji na idhini

TL;DR: Tambua mwombaji ni nani na ueleze kile wanachoruhusiwa kufanya kabla ya ombi hata kufikia huduma.

Huduma mara nyingi hutaka kujua nani hufanya ombi (uthibitishaji), na kwa kutumia habari hii, huamua kwamba chombo fulani kinaruhusiwa kufanya (idhini). Katika kesi hii, kiwakilishi "nani" kinaweza kujificha:

Huduma zingine. Hii inaitwa "uthibitishaji" rika" Kwa mfano, huduma web anataka kufikia huduma db. Meshi za huduma kwa kawaida hutatua matatizo kama haya kwa kutumia mTLS: cheti katika kesi hii hufanya kama kitambulisho kinachohitajika.
Baadhi ya watumiaji wa binadamu. Hii inaitwa "uthibitishaji" ombi" Kwa mfano, mtumiaji haxor69 anataka kununua taa mpya. Matundu ya huduma hutoa njia mbalimbali, k.m. Ishara za Wavuti za JSON.
Wengi wetu tumefanya hivi katika nambari ya maombi. Ombi linakuja, tunaangalia meza users, pata mtumiaji na ulinganishe nenosiri, kisha uangalie safu permissions na kadhalika. Katika kesi ya mesh ya huduma, hii hutokea kabla ya ombi hata kufikia huduma.

Baada ya kubaini ombi lilitoka kwa nani, tunahitaji kubainisha ni nini huluki hii inaruhusiwa kufanya. Baadhi ya matundu ya huduma hukuruhusu kuweka sera za kimsingi (kuhusu nani anaweza kufanya nini) kama faili za YAML au kwenye safu ya amri, huku zingine zikitoa muunganisho na mifumo kama vile. Fungua Wakala wa Sera. Lengo kuu ni huduma zako kukubali ombi lolote, tukichukulia kuwa linatoka kwa chanzo kinachoaminika и kitendo hiki kinaruhusiwa.

4. Kusawazisha mzigo

TL; DR: Sambaza mzigo katika matukio ya huduma kulingana na muundo maalum.

"Huduma" ndani ya sehemu ya huduma mara nyingi huwa na matukio mengi yanayofanana. Kwa mfano, leo huduma cache lina nakala 5, na kesho idadi yao inaweza kuongezeka hadi 11. Maombi yaliyotumwa kwa cache, lazima isambazwe kwa mujibu wa madhumuni maalum. Kwa mfano, punguza muda wa kusubiri au uongeze uwezekano wa kupata tukio la kufanya kazi. Algorithm inayotumiwa zaidi ni Round-robin, lakini kuna wengine wengi - kwa mfano, njia ya uzito (uzito) maswali (unaweza kuchagua malengo unayopendelea), piga (pete) hashing (kwa kutumia hashing thabiti kwenye wapangishi wa juu) au njia ndogo ya ombi (upendeleo hutolewa kwa mfano na maombi machache zaidi).

Visawazishaji vya kawaida vina vitendaji vingine, kama vile uhifadhi wa HTTP na ulinzi wa DDoS, lakini hazifai sana kwa trafiki ya mashariki-magharibi (yaani, kwa trafiki inayopita ndani ya kituo cha data - takriban transl.) (wigo wa kawaida wa mesh ya huduma). Kwa kweli, sio lazima kutumia matundu ya huduma kwa kusawazisha mzigo, lakini hukuruhusu kuweka na kudhibiti sera za kusawazisha kwa kila huduma kutoka kwa safu ya udhibiti wa kati, na hivyo kuondoa hitaji la kuendesha na kusanidi vidhibiti tofauti vya mzigo kwenye safu ya mtandao. .

5. Kuvunja mzunguko

TL; DR: Komesha trafiki kwa huduma yenye matatizo na udhibiti uharibifu katika hali mbaya zaidi.

Ikiwa kwa sababu fulani huduma haiwezi kukabiliana na trafiki, mesh ya huduma hutoa chaguzi kadhaa za kutatua tatizo hili (mengine yatajadiliwa katika sehemu zinazofaa). Kuvunja mzunguko ni chaguo kali zaidi la kukata huduma kutoka kwa trafiki. Walakini, yenyewe haina maana - mpango wa chelezo unahitajika. Shinikizo la nyuma linaweza kutolewa (shinikizo la nyuma) kwa huduma zinazofanya maombi (usisahau tu kusanidi matundu ya huduma yako kwa hili!), au, kwa mfano, kuchorea ukurasa wa hali kuwa nyekundu na kuelekeza watumiaji kwa toleo lingine la ukurasa na "nyangumi anayeanguka" ("Twitter ni chini").

Matundu ya huduma hayakuruhusu tu kufafanua wakati kuzima kutafuata na kwamba hii itafuata. Katika kesi hii, "wakati" inaweza kujumuisha mchanganyiko wowote wa vigezo maalum: jumla ya idadi ya maombi kwa kipindi fulani, idadi ya miunganisho inayofanana, maombi yanayosubiri, majaribio ya kazi, nk.

Pengine hutaki kutumia vibaya uvunjaji wa mzunguko, lakini ni vyema kujua kwamba una mpango wa chelezo iwapo kutatokea dharura.

6. Autoscaling

TL;DR: Ongeza au punguza idadi ya matukio ya huduma kulingana na vigezo vilivyobainishwa.

Matundu ya huduma sio wapangaji ratiba, kwa hivyo hawafanyi hivyo kutekeleza kujiongeza. Hata hivyo, wanaweza kutoa taarifa ambayo wapangaji wataweka maamuzi yao. Kwa kuwa meshes za huduma zinapata trafiki yote kati ya huduma, zina habari nyingi juu ya kile kinachotokea: ni huduma gani zinakabiliwa na shida, ambazo huduma hubeba kidogo sana (uwezo uliotengwa kwao unapotea), nk.

Kwa mfano, Kubernetes hupima huduma kulingana na CPU ya maganda na matumizi ya kumbukumbu (tazama ripoti yetu"Kuongeza kasi kiotomatiki na usimamizi wa rasilimali katika Kubernetes"- takriban. tafsiri.), lakini ukiamua kupima kulingana na kipimo kingine chochote (kwa upande wetu, kinachohusiana na trafiki), utahitaji kipimo maalum. Usimamizi kama hii inaonyesha jinsi ya kufanya hivyo na mjumbe, Istio и Prometheus, lakini mchakato yenyewe ni ngumu sana. Tungependa matundu ya huduma kurahisisha hili kwa kuturuhusu kuweka masharti kama vile "kuongeza idadi ya matukio ya huduma auth, ikiwa idadi ya maombi yanayosubiri inazidi kizingiti ndani ya dakika moja."

7. Usambazaji wa Canary

TL;DR: Jaribu vipengele vipya au matoleo ya huduma kwenye kikundi kidogo cha watumiaji.

Wacha tuseme unatengeneza bidhaa ya SaaS na unakusudia kutoa toleo jipya lake. Uliijaribu kwenye jukwaa na ilifanya kazi vizuri. Lakini bado kuna wasiwasi fulani juu ya tabia yake katika hali halisi. Kwa maneno mengine, unahitaji kujaribu toleo jipya kwenye matatizo halisi bila kuhatarisha uaminifu wa mtumiaji. Usambazaji wa Canary ni mzuri kwa hili. Wanakuruhusu kuonyesha kipengele kipya kwa kikundi kidogo cha watumiaji. Kitengo hiki kidogo kinaweza kujumuisha watumiaji waaminifu zaidi au wale wanaofanya kazi na toleo lisilolipishwa la bidhaa, au watumiaji ambao wameonyesha nia ya kuwa "nguruwe".

Meshi za huduma hutekeleza hili kwa kukuruhusu kubainisha vigezo vinavyobainisha ni nani ataona ni toleo gani la programu, na kuelekeza trafiki ipasavyo. Walakini, hakuna kinachobadilika kwa huduma zenyewe. Toleo la 1.0 la huduma linaamini kuwa maombi yote yanatoka kwa watumiaji wanaopaswa kuiona, na toleo la 1.1 linaamini vivyo hivyo kwa watumiaji wake. Wakati huo huo, unaweza kubadilisha asilimia ya trafiki kati ya matoleo ya zamani na mapya, kuelekeza upya idadi inayoongezeka ya watumiaji hadi kwa toleo jipya ikiwa itafanya kazi kwa uthabiti na "nguruwe" wako kutoa idhini.

8. Upelekaji wa bluu-kijani

TL; DR: Toa kipengele kipya kizuri, lakini uwe tayari kurudisha kila kitu mara moja.

Maana kupelekwa kwa bluu-kijani ni kusambaza huduma mpya ya "bluu", kuizindua sambamba na ya zamani, "kijani". Ikiwa kila kitu kinakwenda vizuri na huduma mpya inafanya vizuri, basi ya zamani inaweza kuzima hatua kwa hatua. (Ole, siku moja huduma hii mpya ya "bluu" itarudia hatima ya "kijani" na kutoweka ...) Usambazaji wa bluu-kijani hutofautiana na canary kwa kuwa kazi mpya inashughulikia. kila mtu mara moja watumiaji (sio sehemu); Hoja hapa ni kuwa na "bandari salama" tayari ikiwa kitu kitaenda vibaya.

Meshes za huduma hutoa njia rahisi sana ya kujaribu huduma ya "bluu" na kubadili mara moja kwa "kijani" inayofanya kazi ikiwa kuna matatizo. Bila kutaja ukweli kwamba njiani hutoa habari nyingi (angalia "Telemetry" hapa chini) kuhusu kazi ya "bluu", ambayo husaidia kuelewa ikiwa iko tayari kwa uendeshaji kamili.

Kumbuka. tafsiri.: Unaweza kusoma zaidi kuhusu mikakati tofauti ya upelekaji katika Kubernetes (pamoja na canary iliyotajwa, bluu/kijani na zingine) katika Makala hii.

9. Uchunguzi wa afya

TL;DR: Fuatilia ni hali zipi za huduma zinazofanya kazi na ujibu zile ambazo hazifanyi kazi tena.

Uchunguzi wa afya (angalia afya) husaidia kuamua ikiwa hali za huduma ziko tayari kukubalika na kuchakata trafiki. Kwa mfano, katika huduma za HTTP, ukaguzi wa afya unaweza kuonekana kama ombi la GET hadi mwisho /health. Jibu 200 OK itamaanisha kuwa mfano huo ni wa afya, nyingine yoyote - kwamba haiko tayari kupokea trafiki. Meshes za huduma hukuruhusu kutaja njia zote mbili ambazo utendakazi utakaguliwa na frequency ambayo ukaguzi huu utafanywa. Taarifa hii inaweza kutumika kwa madhumuni mengine - kwa mfano, kwa kusawazisha mzigo na kuvunja mzunguko.

Kwa hivyo, ukaguzi wa afya sio kesi ya matumizi ya pekee, lakini kwa kawaida hutumiwa kufikia malengo mengine. Pia, kulingana na matokeo ya ukaguzi wa afya, vitendo vya nje (kuhusiana na malengo mengine ya mesh ya huduma) vinaweza kuhitajika: kwa mfano, kusasisha ukurasa wa hali, kuunda suala kwenye GitHub, au kujaza tikiti ya JIRA. Na matundu ya huduma hutoa utaratibu rahisi wa kubinafsisha haya yote.

10. Kumwaga mizigo

TL;DR: Elekeza upya trafiki kwa kukabiliana na ongezeko la muda la matumizi.

Ikiwa huduma fulani imejaa trafiki, unaweza kuelekeza kwa muda baadhi ya trafiki hii hadi eneo lingine (yaani, "tupa", "hamisha" (mwaga) huko). Kwa mfano, kwa huduma ya chelezo au kituo cha data, au kwa huduma ya kudumu vyombo vya habari mada. Kwa hivyo, huduma itaendelea kushughulikia baadhi ya maombi badala ya kuanguka na kuacha kuchakata kila kitu kabisa. Kumwaga mzigo ni vyema kuliko kuvunja mzunguko, lakini bado haifai kuitumia vibaya. Husaidia kuzuia hitilafu za kuporomoka zinazosababisha huduma za mkondo wa chini kuanguka.

11. Ulinganifu wa trafiki/kuakisi

TL;DR: Tuma ombi moja kwa sehemu kadhaa mara moja.

Wakati mwingine kuna haja ya kutuma ombi (au uteuzi fulani wa maombi) kwa huduma kadhaa mara moja. Mfano wa kawaida ni kutuma sehemu ya trafiki ya uzalishaji kwa huduma ya jukwaa. Seva kuu ya wavuti ya uzalishaji hutuma ombi kwa huduma ya chini ya mkondo products.production na kwake tu. Na matundu ya huduma hunakili ombi hili kwa busara na kutuma kwa products.staging, ambayo seva ya wavuti haijui hata.

Kesi nyingine inayohusiana ya utumiaji wa matundu ya huduma ambayo inaweza kutekelezwa juu ya usawa wa trafiki ni mtihani wa kurudi nyuma. Inajumuisha kutuma maombi sawa kwa matoleo tofauti ya huduma na kuangalia ikiwa matoleo yote yanafanya kazi sawa. Bado sijapata utekelezaji wa matundu ya huduma na mfumo wa upimaji wa urekebishaji uliojumuishwa kama Diffy, lakini wazo lenyewe linaonekana kuahidi.

12. Insulation

TL; DR: Vunja matundu ya huduma yako kuwa mitandao midogo.

Pia inajulikana kama mgawanyikoKutengwa ni sanaa ya kugawanya matundu ya huduma katika sehemu tofauti kimantiki ambazo hazijui chochote kuhusu kila mmoja. Kutengwa ni kidogo kama kuunda mitandao pepe ya kibinafsi. Tofauti kuu ni kwamba bado unaweza kufurahia manufaa yote ya matundu ya huduma (kama vile ugunduzi wa huduma), lakini kwa usalama ulioongezwa. Kwa mfano, ikiwa mshambulizi anaweza kupenya huduma kwenye subnet moja, hataweza kuona ni huduma gani zinazoendeshwa kwenye subnets nyingine au kuzuia trafiki yao.

Kwa kuongeza, faida zinaweza pia kuwa za shirika. Unaweza kutaka kuweka huduma zako kidogo kulingana na muundo wa kampuni yako na kuwaondolea wasanidi programu mzigo wa utambuzi wa kuzingatia matundu yote ya huduma.

13. Ombi la kupunguza kiwango, kujaribu tena na kuisha kwa muda

TL;DR: Huhitaji tena kujumuisha kazi za usimamizi wa ombi la nitty-gritty katika codebase yako.

Vitu hivi vyote vinaweza kuzingatiwa kama kesi tofauti za utumiaji, lakini niliamua kuvichanganya kwa sababu ya kipengele kimoja cha kawaida: huchukua jukumu la usimamizi wa mzunguko wa maisha ambayo kawaida hushughulikiwa na maktaba za programu. Ikiwa unatengeneza seva ya wavuti katika Ruby on Rails (haijaunganishwa na mesh ya huduma) ambayo hufanya maombi ya kurudisha nyuma huduma kupitia gRPC, maombi italazimika kuamua nini cha kufanya ikiwa maombi ya N yatashindwa. Pia utalazimika kujua ni kiasi gani cha trafiki huduma hizi zitaweza kuchakata na kuweka misimbo mikuu kwa vigezo hivi kwa kutumia maktaba maalum. Zaidi ya hayo, programu italazimika kuamua ni wakati gani wa kukata tamaa na kuruhusu ombi kuzima (kulingana na muda wa kuisha). Na ili kubadilisha vigezo vyovyote hapo juu, seva ya wavuti italazimika kusimamishwa, kusanidiwa na kuanza tena.

Kupakia kazi hizi kwenye wavu wa huduma haimaanishi tu kwamba wasanidi wa huduma hawatalazimika kuzihusu, lakini pia kwamba zinaweza kutazamwa kwa njia ya kimataifa zaidi. Ikiwa mlolongo changamano wa huduma unatumiwa, sema A -> B -> C -> D -> E, mzunguko mzima wa maisha ya ombi lazima uzingatiwe. Ikiwa kazi ni kupanua muda katika huduma C, ni mantiki kufanya hivi mara moja, na si kwa sehemu: kwa uppdatering msimbo wa huduma na kusubiri hadi ombi la kuvuta likubaliwe na mfumo wa CI unatumia huduma iliyosasishwa.

14. Telemetry

TL; DR: Kusanya taarifa zote muhimu (na sio kabisa) kutoka kwa huduma.

Telemetry ni neno la jumla linalojumuisha vipimo, ufuatiliaji uliosambazwa na kumbukumbu. Matundu ya huduma hutoa mbinu za kukusanya na kuchakata aina zote tatu za data. Hapa ndipo mambo yanakuwa na ukungu kidogo kwa sababu idadi ya chaguo zinazowezekana ni kubwa mno. Kukusanya vipimo kuna Prometheus na zana zingine zinazoweza kutumika kukusanya magogo mwenye ufasaha, Loki, Vector nk (kwa mfano ClickHouse na yetu nyumba ya magogo kwa K8s - takriban. tafsiri.), kwa ufuatiliaji uliosambazwa kuna Jaeger Nakadhalika. Kila matundu ya huduma yanaweza kusaidia zana zingine na sio zingine. Itakuwa ya kuvutia kuona kama mradi unaweza Fungua Telemetry kutoa muunganisho fulani.

Katika kesi hii, faida ya teknolojia ya matundu ya huduma ni kwamba vyombo vya kando vinaweza, kimsingi, kukusanya data zote hapo juu kutoka kwa huduma zao. Kwa maneno mengine, una mfumo mmoja wa ukusanyaji wa telemetry ulio nao, na mesh ya huduma inaweza kuchakata maelezo haya yote kwa njia mbalimbali. Kwa mfano:

magogo ya mkia kutoka kwa huduma fulani katika CLI;
kufuatilia kiasi cha maombi kutoka kwa dashibodi ya mesh ya huduma;
kukusanya athari zilizosambazwa na kuzisambaza kwa mfumo kama Jaeger.

Tahadhari, uamuzi wa kibinafsi: Kwa ujumla, telemetry ni eneo ambalo kuingiliwa kwa nguvu kutoka kwa mesh ya huduma haifai. Kukusanya taarifa za kimsingi na kufuatilia unaporuka baadhi ya vipimo vya dhahabu kama vile kiwango cha mafanikio ya ombi na muda wa kusubiri ni sawa, lakini hebu tumaini kwamba hatutaona mafungu ya Frankenstein yakiibuka ambayo yanajaribu kuchukua nafasi ya mifumo maalum, ambayo baadhi tayari imejithibitisha yenyewe na kujifunza vizuri. .

15. Ukaguzi

TL; DR: Wale wanaosahau masomo ya historia wamehukumiwa kuyarudia.

Ukaguzi ni sanaa ya kutazama matukio muhimu katika mfumo. Kwa upande wa matundu ya huduma, hii inaweza kumaanisha kufuatilia ni nani aliyetuma maombi kwenye vituo maalum vya huduma mahususi, au ni mara ngapi baadhi ya tukio linalohusiana na usalama lilitokea katika mwezi uliopita.

Ni wazi kuwa ukaguzi unahusiana sana na telemetry. Tofauti ni kwamba telemetry kwa kawaida huhusishwa na mambo kama vile tija na uadilifu wa kiufundi, ilhali ukaguzi unaweza kuhusiana na masuala ya kisheria na mengine ambayo huenda zaidi ya nyanja ya kiufundi kabisa (kwa mfano, kufuata GDPR - Kanuni ya Jumla ya EU kuhusu ulinzi wa data).

16. Taswira

TL;DR: Long live React.js - chanzo kisichokwisha cha violesura maridadi.

Kunaweza kuwa na neno bora zaidi, lakini sijui. Ninamaanisha tu uwakilishi wa picha wa matundu ya huduma au baadhi ya vipengele vyake. Taswira hizi zinaweza kujumuisha viashirio kama vile muda wa wastani wa kusubiri, maelezo ya usanidi wa gari la kando, matokeo ya ukaguzi wa afya na arifa.

Kufanya kazi katika mazingira yenye mwelekeo wa huduma kunahusisha mzigo wa juu zaidi wa utambuzi ikilinganishwa na Ukuu wake Monolith. Kwa hiyo, shinikizo la utambuzi linapaswa kupunguzwa kwa gharama zote. Kiolesura rahisi cha kielelezo cha matundu ya huduma na uwezo wa kubofya kitufe na kupata matokeo yanayohitajika inaweza kuwa ya kuamua kwa ukuaji wa umaarufu wa teknolojia hii.

Hawakujumuishwa kwenye orodha

Hapo awali nilikusudia kujumuisha kesi chache zaidi za utumiaji kwenye orodha, lakini niliamua kutofanya hivyo. Hizi hapa, pamoja na sababu za uamuzi wangu:

Kituo cha data nyingi. Kwa maoni yangu, hii sio kesi ya utumiaji kama eneo finyu na maalum la utumiaji wa matundu ya huduma au seti fulani ya vitendakazi kama ugunduzi wa huduma.
Kuingia na kutoka. Hili ni eneo linalohusiana, lakini nimejiwekea kikomo (labda bandia) kwa kesi ya utumiaji ya "trafiki ya mashariki-magharibi". Ingress na egress wanastahili makala tofauti.

Hitimisho

Ni hayo tu kwa sasa! Tena, orodha hii ni ya kiholela sana na ina uwezekano mkubwa kuwa haijakamilika. Iwapo unafikiri nimekosa kitu au nina jambo baya, tafadhali wasiliana nami kwenye Twitter (@luckerkins) Tafadhali heshimu sheria za adabu.

PS kutoka kwa mtafsiri

Kielelezo cha kichwa cha makala kinatokana na picha kutoka kwa kifungu "Mesh ya Huduma ni nini (na wakati wa kutumia moja)?"(na Gregory MacKinnon). Inaonyesha jinsi baadhi ya utendaji kutoka kwa programu (katika kijani) umehamia kwenye matundu ya huduma ambayo hutoa miunganisho kati yao (katika bluu).

Soma pia kwenye blogi yetu:

Chanzo: mapenzi.com