Shën. përk.: autori i këtij artikulli (Luc Perkins) — avokati i zhvilluesve në organizatën CNCF, e cila është shtëpia e projekteve Open Source si Linkerd, SMI (Service Mesh Interface) dhe Kuma (për më tepër, a e keni menduar ndonjëherë pse në këtë listë nuk është Istio?..). Duke përpjekur përsëri të sjellë në komunitetin DevOps një kuptim më të mirë të trendit të njohur si «service mesh», ai paraqet 16 karakteristika dalluese që ofrojnë zgjidhje të tilla.
Sot — një nga temat më të nxehta në fushën e inxhinierisë software (dhe e meritojnë!). Unë e konsideroj këtë teknologji jashtëzakonisht premtuese dhe ëndërroj të bëhem dëshmitar i përhapjes së saj të gjërë (sigurisht, kur ka kuptim). Megjithatë, ajo ende është e rrethuar nga një aurë misteri për shumicën e njerëzve. Për këtë arsye, madje ata që janë mirë të njohur me të, shpesh e kanë të vështirë të formulojnë avantazhet e saj dhe se çfarë përfaqëson ajo (duke përfshirë edhe shërbëtorin tuaj modest). Në këtë artikull do të përpiqem të korrigjoj situatën duke renditur scenarë të ndryshëm të përdorimit të «rrjetit të shërbimeve»*. * Shën. e përkthyer: këtu dhe më tej në artikull do të përdoret kjo përkthim («rrjeti i shërbimeve») për termin ende të ri service mesh.
* Shënim: këtu dhe në vazhdim të artikullit do të përdoret ky përkthim («rrjeti shërbimesh») për termin ende të ri service mesh.
Porosinë fillimisht disa vërejtje:
- Nuk kam punuar kurrë me rrjetat e shërbimeve dhe nuk e kam përdorur jashtë projekteve që janë nisur për arsye edukative. Mega përveç kësaj, unë kam shkruar një sasi të madhe dokumentacioni për rrjetin e shërbimeve të kompanisë Twitter në vitin 2015 (atëherë nuk quhej ende "rrjet shërbimesh") dhe kam marrë pjesë në zhvillimin e faqes dhe dokumentacionit për , kështu që kjo do të thotë diçka.
- Lista ime është një shembull dhe nuk është e plotë. Mund të ketë skenarë përdorimi të panjohur për mua dhe me kalimin e kohës patjetër do të shfaqen variante të reja, ndërsa teknologjia zhvillohet dhe popullariteti i saj rritet.
- Megjithatë, jo çdo implementim ekzistues i rrjetit të shërbimeve mbështet të gjitha rastet e përmendura të përdorimit. Prandaj, shprehjet e mia si "rrjeti i shërbimeve mund..." duhet të lexohen si "implementime të veçanta, ndoshta edhe të gjitha implementimet e njohura të rrjetit të shërbimeve mund...".
- Rendi i shembujve nuk ka ndonjë rëndësi.
Lista përmbledhëse:
- zbulimi i shërbimeve;
- kriptimin;
- autentifikimi dhe autorizimi;
- balancimi i ngarkesës;
- pezullimi i qarkut;
- autoskalimi;
- distribuimi kanarinë;
- distribuimi blu-jeshile;
- kontrolli i shëndetit;
- reduktimi i ngarkesës;
- Mirrorimi i trafikut;
- izolimi;
- kufizimi i frekuencës së kërkesave, përpjekjet e përsëritura dhe kohët e pritur;
- telemetria;
- auditimi;
- visualizimi.
1. Zbulimi i shërbimeve
TL;DR: Bashkohuni me shërbime të tjera në rrjet nëpërmjet emrave të thjeshtë.
Shërbimet duhet të kenë mundësinë të "gjejnë" automatikisht njëra-tjetrën me emra adekuatë ― për shembull, service.api.production, pets/staging ose cassandra. Mjediset cloud dallohen për elasticitetin e tyre, dhe pas një emri mund të fshihen shumë instanca shërbimi. Është e qartë se në një situatë të tillë, nuk është fizikisht e mundur të kodifikohen të gjitha adresa IP.
Për më tepër, kur një shërbim gjen një tjetër, ai duhet të ketë mundësinë të dërgojë kërkesa në këtë shërbim, pa frikë se ato do të kalojnë në hyrjen e instancës së tij që nuk funksionon. Me fjalë të tjera, mesh-i i shërbimeve duhet të mbajë nën vëzhgim funksionalitetin e të gjitha instancave të shërbimeve dhe të mbajë një listë hostesh në gjendje sa më të azhurnuar.
Çdo service mesh implementon një mekanizëm të zbulimit të shërbimeve në mënyrën e vet. Aktualisht, mënyra më e zakonshme është delegimi te procese të jashtme si DNS Kubernetes. Në të kaluarën, në Twitter për këto qëllime kemi përdorur sistemin e emrave . Për më tepër, teknologjia service mesh e bën të mundur krijimin e mekanizmave të emrimit nga përdoruesit (ndonëse nuk kam hasur ende në asnjë implementim të SM me këtë funksionalitet).
2. Kriptimi
TL;DR: Largoni trafikun e pakriptuar midis shërbimeve dhe lejoni që ky proces të jetë automatizuar dhe i shkallëzueshëm.
Është mirë të dihet se sulmuesit nuk mund të depërtojnë në rrjetin tuaj të brendshëm. Firewall-et janë të shkëlqyera në këtë. Por çfarë do ndodhë nëse një haker arrin të depërtojë brenda? Ai do të mund të bëjë gjithçka që dëshiron me trafikun midis shërbimeve? Le të shpresojmë që kjo të mos ndodhë. Për të parandaluar një skenar të tillë, duhet të implementohet një rrjet me besim zero (zero-trust), në të cilin gjithë trafiku midis shërbimeve është i kripur. Shumica e rrjeteve moderne të shërbimeve e arrijnë këtë përmes ndërsjellësit. (mutual TLS, mTLS). Në disa raste, mTLS funksionon në tërë re dhe grupe (mendoj se komunikimet ndërplanetare do të organizohen njësoj ndonjëherë).
Sigurisht, për mTLS service mesh nuk është e detyrueshme. Çdo shërbim mund të kujdeset për TLS-në e vet, por kjo do të thotë se duhet të gjeni një mënyrë për të gjeneruar certifikata, për t'i shpërndarë ato në hostet e shërbimit, dhe për të përfshirë në aplikacion kodin që do t'i ngarkojë këto certifikata nga skedarët. Po, mos harroni as për përditësimin e këtyre certifikatave pas disa intervaleve kohe. Rrjetet e shërbimeve automatizojnë mTLS me sisteme si , të cilat, nga ana e tyre, automatizojnë procesin e lëshimit dhe rotacionit të certifikatave.
3. Autentikimi dhe autorizimi
TL;DR: Përcaktoni se kush është iniciatori i kërkesës dhe përcaktoni atë që i lejohet të bëjë përpara se kërkesa të arrijë shërbimin.
Shërbimet shpesh duan të dinë kush se kush bën kërkesën (autentikimi), dhe duke përdorur këtë informacion, vendosin çfarë çfarë i lejohet këtij subjekti të bëjë (autorizimi). Në këtë rast, pas përmendjes 'kush' mund të fshihen:
- Shërbime të tjera. Kjo quhet 'autentikimi i peer'-it». Për shembull, shërbimi
webdëshiron të ketë akses në shërbimdb. Rrjetet e shërbimeve zakonisht e zgjidhin një problem të tillë me mTLS: certifikatat në këtë rast shërbejnë si identifikues të nevojshëm. - Disa përdorues-njerëz. Kjo quhet "autentifikim i kërkesës». Për shembull, përdoruesi
haxor69dëshiron të blejë një llampë të re. Rrjetet e shërbimeve ofrojnë mekanizma të ndryshëm, për shembull, .Shumë nga ne i kemi bërë këto në kodin e aplikacionit. Vjen një kërkesë, ne shikojmë tabelën
përdoruesit, gjejmë përdoruesin dhe krahasojmë fjalëkalimin, pastaj kontrollojmë kolonënlejetetj. Në rastin e rrjetit të shërbimeve, kjo ndodh edhe përpara se kërkesa të arrijë në shërbim.
Pasi të kemi përcaktuar se nga ka ardhur kërkesa, është e nevojshme të përcaktojmë se çfarë i është lejuar këtij subjekti të bëjë. Disa rrjete shërbimesh lejojnë caktimin e politikave bazë (për atë se kush dhe çfarë mund të bëjë) në formën e skedarëve YAML ose në linjën e komandës, ndërsa të tjera ofrojnë integrim me edhe framework-e si . Qëllimi përfundimtar është që shërbimet tuaja të pranojnë çdo kërkesë, duke supozuar se ato vijnë nga një burim të besueshëm. dhe kyç kjo është e lejuar.
4. Balancimi i ngarkesës
TL;DR: Shpërndani ngarkesën ndërmjet instancave të shërbimit sipas një modeli të caktuar.
«Shërbimi» brenda sektit të shërbimeve shpesh përbëhet nga shumë instanca identike. Për shembull, sot shërbimi cache përbëhet nga 5 kopje, ndërsa nesër numri mund të rritet deri në 11. Kërkesat që dërgohen në cache, duhet të shpërndahen sipas një qëllimi të caktuar. Për shembull, minimalizimi i vonesës ose maksimizimi i mundësisë për t'u lidhur me një instancë funksionale. Më së shpeshti përdoret algoritmi i shërbimit në rreth (Round-robin), por ka edhe shumë të tjera - për shembull, metoda e peshave (weighted) të kërkesave (mund të zgjidhen objektivat e preferuara), hashing rrethor (ring) (përdorimi i hashing konsistent për hostet upstream) ose metoda e numrit më të vogël të kërkesave (preferencë jepet instancës me numrin më të vogël të kërkesave). hashimi (përdorimi i hashimit të njëtrajtshëm për hostet upstream) ose metoda e numrit minimal të kërkesave (preferenca i jepet instancës me numrin më të vogël të kërkesave).
Balancerët klasikë kanë edhe funksione të tjera, si cache-imi HTTP dhe mbrojtja nga DDoS, por ato nuk janë shumë të rëndësishme për trafik të tipit east-west (dmth. për trafikun brenda qendrës së të dhënave - shën. përkth.). Sigurisht, nuk është e domosdoshme të përdorësh service mesh për të balancuar ngarkesën, por ajo lejon përcaktimin dhe kontrollin e politikave të balancimit për çdo shërbim nga një shtresë qendrore menaxhimi, duke eliminuar kështu nevojën për të drejtuar dhe konfiguruar balancerë të veçantë në strukturën e rrjetit.
5. Prishja e zinxhirit (circuit breaking)
TL;DR: Ndalo trafikun për shërbimin problematik dhe kontrollo dëmet në skenarët më të këqij.
Nëse për ndonjë arsye shërbimi nuk përballon trafikun, service mesh ofron disa mundësi për të zgjidhur këtë problem (për të tjerat do të flitet në seksionet përkatëse). Prishja e zinxhirit është mundësia më e ashpër për të shkëputur shërbimin nga trafiku. Megjithatë, vetë ajo nuk ka kuptim - një plan rezervë është i nevojshëm. Mund të parashikohet një kundërpresion () në shërbimet që kryejnë kërkesa (vetëm mos harroni të konfiguroni mesh-in tuaj të shërbimeve për këtë!), ose, për shembull, ngjyrosja e faqes së statusit në të kuqe dhe ridrejtimi i përdoruesve në një variant tjetër të faqes me "breshkën që po bie" ("Twitter is down").
Mesh-in e shërbimeve lejon jo vetëm të përcaktojë, kur do të ketë një ndalim dhe çfarë çfarë do të pasojnë. Në këtë rast, "kur" mund të përfshijë çdo kombinim të parametrave të caktuar: numri total i kërkesave për një periudhë të caktuar, numri i lidhjeve paralel, kërkesat në pritje, përpjekjet aktive për riprovim etj.
Shumë të mund të dëshironit të abuzoni me ndalimin e qarkut, por është e këndshme të dini që ka një plan rezervë për situata ekstremale.
6. Autoskalimi
TL;DR: Rritni ose zvogëloni numrin e instancave të shërbimit në varësi të kritereve të caktuara.
Mesh-të e shërbimeve nuk janë planifikues, prandaj ato nuk kryejnë shkallëzimi në mënyrë të pavarur. Megjithatë, ata mund të ofrojnë informacion, mbi të cilin planifikuesit do të marrin vendime. Duke qenë se mesh-at e shërbimit kanë qasje në gjithë trafikun mes shërbimeve, ata disponojnë informacion të gjerë mbi atë që po ndodh: cilat shërbime kanë hasur probleme, cilat janë të ngarkuara shumë pak (kapacitetet e dedikuara për to shpenzohen kot) etj.
Për shembull, Kubernetes shkallëzon shërbimet në varësi të përdorimit të CPU dhe memories nga pod-et. (shihni raportin tonë "" – shënim i përkthyesit), por nëse vendosni të bëni shkallëzim duke u bazuar në ndonjë tregues tjetër (në rastin tonë — i lidhur me trafikun), do të nevojitet një metrikë e veçantë. Udhëzimi tregon se si ta bëni këtë me ndihmën e , dhe , por vetë procesi është mjaft i komplikuar. Ne do të dëshironim që mesh-i i shërbimit ta thjeshtonte këtë, duke lejuar të vendosnim thjesht kushte si "rrit numrin e instancave të shërbimit auth, nëse numri i kërkesave në pritje për t’u përmbushur e kalon pragun për një minutë".
7. Zhvillime kanarinë
TL;DR: Provoni funksionet ose versionet e reja të shërbimit te një nënshtresë të përdoruesve.
Për shembull, po zhvilloni një produkt SaaS dhe dëshironi të nxirrni një version të ri të mrekullueshëm. E keni testuar atë në staging, dhe ka funksionuar mrekullisht. Megjithatë, ju shqetëson sjellja e saj në kushte reale. Në fjalë të tjera, ju nevojitet të verifikoni versionin e ri me detyra reale, pa rrezikuar besimin e përdoruesve. Ndërmarrjet kanarinë janë ideale për këtë qëllim. Ato lejojnë demonstrimin e një funksioni të ri për një nënshtresë të caktuar përdoruesish. Kjo nënshtresë mund të përbëhet nga përdoruesit më të besueshëm ose ata që punojnë me versionin falas të produktit, ose përdoruesit që kanë shprehur dëshirën të jenë "krimbat e eksperimenteve".
Mesh-i shërbimeve e realizon këtë, duke lejuar përcaktimin e kritereve që përcaktojnë kush dhe cilën version të aplikacionit do ta shohë, dhe duke riorientuar trafikun në përputhje me këtë. Ndërsa për shërbimet vetë, asgjë nuk ndryshon. Versioni 1.0 i shërbimit konsideron se të gjitha kërkesat vijnë nga përdoruesit që duhet ta shohin atë, ndërsa versioni 1.1 mendon të njëjtën gjë për përdoruesit e tij. Ndërkohë, mund të ndryshoni përqindjen e trafikut mes versionit të vjetër dhe atij të ri, duke çuar një numër në rritje përdoruesish në të riun, nëse ai funksionon stabilisht dhe "testuesit" tuaj japin miratimin e tyre.
8. Zhvillime blu-jeshile
TL;DR: Nxirrni një funksion të ri, por jini gati ta ktheni menjëherë mbrapsht.
Kuptimi është të nxirni një shërbim të ri "blu", duke e nisin atë paralel me të vjetrin, "jeshil". Nëse gjithçka shkon mirë dhe shërbimi i ri tregojnë rezultate të mira, atëherë mund të çaktivizoni gradualisht të vjetrin. (Fatkeqësisht, ndonjëherë ky shërbim i ri "blu" do të pësojë fatin e "jeshilit" dhe do të zhduket…) Zhvillimet blu-jeshile ndryshojnë nga ato kanarinë, sepse funksioni i ri mbulon të gjithë përdoruesit (dhe jo një pjesë); ideja këtu është të kesh një «shim» të rezervuar në rast se diçka shkon keq.
Service mesh’ët ofrojnë një mënyrë shumë të përshtatshme për të testuar shërbimin «blu» dhe për tu kaluar menjëherë te shërbimi «jeshil» në rast të defekteve. Për më tepër, ata ofrojnë shumë informacione (shihni seksionin «Telemetria» më poshtë) rreth funksionimit të «blutë», që ndihmon të kuptohet nëse ai është i gatshëm për përdorim të plotë.
Shën. përk.: Më shumë rreth strategjive të ndryshme të ndarjes në Kubernetes (duke përfshirë ato që u përmendën canary, blue/green dhe të tjera) mund të lexoni në .
9. Kontroli i shëndetit
TL;DR: Mbani nën kontroll se cilat instanca të shërbimeve janë funksionale dhe reagon ndaj atyre që nuk janë më të tilla.
Kontroli i shëndetit (health check) ndihmon në marrjen e vendimit nëse instancat e shërbimit janë gati të pranojnë dhe të përpunojnë trafik. Për shembull, në rastin e shërbimeve HTTP, kontrolli i shëndetit mund të duket si një kërkesë GET në endpoint /health. Përgjigja 200 OK do të thotë se ekzemplari është i shëndetshëm, çdo gjë tjetër ― se ai nuk është gati për të pranuar trafik. Rrjetet e shërbimeve lejojnë të specifikohet si mënyra se si do të kontrollohet funksionaliteti, ashtu edhe frekuenca me të cilën do të kryhet kjo kontrollim. Kjo informacion mund të përdoret më pas për qëllime të tjera — për shembull, për balancimin e ngarkesës dhe thyerjen e qarqeve.
Pra, kontrolli i shëndetit nuk është një skenar i pavarur përdorimi, por zakonisht përdoret për arritjen e qëllimeve të tjera. Po ashtu, në përputhje me rezultatet e kontrollove të shëndetit, mund të kërkohen veprime të jashtme (në raport me qëllimet e tjera të rrjeteve të shërbimeve): për shembull, për të përditësuar faqen e gjendjes, për të krijuar një çështje në GitHub ose për të mbushur një biletë JIRA. Dhe rrjeti i shërbimeve ofron një mekanizëm të përshtatshëm për automatizimin e të gjitha këtyre.
10. Heqja e ngarkesës (load shedding)
TL;DR: Rredhni trafikun në përgjigje të një rritje të përkohshme në përdorim.
Nëse një shërbim është i mbipopulluar me trafik, ju mund të redhni përkohësisht një pjesë të këtij trafiku në një vend tjetër (dmth «të heqni», «të derdhni» (shed) e atje). Për shembull, në shërbimin rezervë ose qendrën e të dhënave, ose në një të përhershëm temë. Si rezultat, shërbimi do të vazhdojë të përpunojë një pjesë të kërkesave në vend që të bjerë dhe të ndalojë përpunimin e të gjithave. Rindarje e ngarkesës është më e preferueshme sesa ndarja e zinxhirit, por gjithsesi nuk duhet abuzuar me të. Ajo parandalon dështimet kaskadë, të cilat çojnë në rënien e shërbimeve downstream.
11. Pjesëtimi/nikimi i trafikut
TL;DR: Dërgoni një kërkesë menjëherë në disa vende.
Herë pas here, ndodh nevoja për të dërguar një kërkesë (ose një grup kërkesash) menjëherë në disa shërbime. Një shembull karakteristik është dërgimi i një pjese të trafikut të production në shërbimin staging. Serveri kryesor i web-it të production dërgon një kërkesë në shërbimin poshtë products.production dhe vetëm te ai. Ndërsa mesh-i i shërbimeve kopjon inteligjent këtë kërkesë dhe e dërgon te products.staging, për të cilin serveri i web-it madje nuk ka asnjë ide.
Një skenar tjetër të lidhur me përdorimin e mesh-it të shërbimeve, që mund të realizohet sipër pjesëtimit të trafikut, është . Ajo parashikon dërgimin e të njëjtave kërkesa në versione të ndryshme të shërbimit dhe kontrollin nëse të gjitha versionet funksionojnë njësoj. Deri tani nuk kam hasur një implementim të service mesh me një sistem të integruar të testimit regresiv siç është , por ideja vetë duket premtuese.
12. Izolimi
TL;DR: Ndajini service mesh tuaj në mini-rete.
I njohur gjithashtu si segmentimi, izolimi është arti i ndarjes së një rrjeti shërbimesh në segmente logjikisht të ndara, të cilat nuk dinë asgjë për njëra-tjetrën. Izolimi është pak si krijimi i rrjeteve private virtuale. Diferenca kryesore është se ju ende mund të përfitoni nga të gjitha avantazhet e service mesh (si zbulimi i shërbimeve), por me siguri shtesë. Për shembull, nëse një sulmues arrin të depërtojë në një shërbim në një nga nënrrjetat, ai nuk do të mund të shohë cilat shërbime janë aktive në nënrrjetat e tjera, ose të kapë trafikun e tyre.
Përveç kësaj, përfitimet mund të jenë edhe organizative. Mund të dëshironi t’i ndani shërbimet në pod-sisteme në varësi të strukturës së kompanisë dhe t’i lirojnë zhvilluesit nga ngarkesa kognitive, e shkaktuar nga nevoja për të mbajtur mend të gjithë mesh-në e shërbimeve.
13. Kufizimi i frekuencës së kërkesave, përpjekjet e përsëritura dhe kohët e pritjes
TL;DR: Nuk është më e nevojshme të përfshihen në bazën e kodit detyrat e domosdoshme lidhur me menaxhimin e kërkesave.
Të gjitha këto gjëra do të mund të konsideroheshin si raste të veçanta përdorimi, por vendosa t’i bashkoj ato për shkak të një karakteristike të përbashkët: ato ndihmojnë në menaxhimin e ciklit të jetës së kërkesave, zakonisht të trajtuara nga bibliotekat e aplikacioneve. Nëse po zhvilloni një server web në Ruby on Rails (i pa integruar me mesh-në e shërbimeve), i cili bën kërkesa ndaj shërbimeve backend përmes , aplikacioni do të duhet të vendosë vetë se çfarë të bëjë, nëse N kërkesa dështojnë. Gjithashtu do të duhet të kuptojë se sa trafik mund të përballojnë këto shërbime dhe t'i 'hardcodojë' këto parametrat duke përdorur një bibliotekë specifike. Përveç kësaj, aplikacioni do të duhet të vendosë kur është koha për të dorëzuar dhe lejuar kërkesën të skadojë (sipër timeout). Dhe për të ndryshuar ndonjë nga parametrat e mësipërm, serveri web do të duhet të ndalet, të rikonfigurohet dhe të riniset.
Transferimi i këtyre detyrave në rrjetin e shërbimeve do të thotë jo vetëm që zhvilluesit e shërbimeve nuk do të kenë nevojë të mendojnë për to, por gjithashtu se ato mund të merren parasysh në një mënyrë më globale. Nëse përdoret një zinxhir kompleks shërbimesh, le të themi, A -> B -> C -> D -> E, është e nevojshme të merren parasysh të gjithë cikli i jetës së kërkesës. Nëse qëllimi është të zgjatet timeout në shërbimin C, është logjike ta bësh këtë të gjithë njëherësh, dhe jo në pjesë: duke përmirësuar kodin e shërbimit dhe duke pritur që pull request të pranohet dhe sistemi CI të implementojë shërbimin e përditësuar.
14. Telemetria
TL;DR: Mblidhni të gjitha informacionet e nevojshme (dhe jo krejtësisht) nga shërbimet.
Telemetria është një term i përgjithshëm që përfshin metrika, gjurmimin e shpërndarë dhe loge. Meshat e shërbimeve ofrojnë mekanizma për mbledhjen dhe përpunimin e të tre llojeve të të dhënave. Këtu gjithçka bëhet paksa e paqartë, pasi numri i mundësive është shumë i madh. Për mbledhjen e metrikave ka dhe mjete të tjera, për mbledhjen e logeve mund të përdoren , , etj. (p.sh., ClickHouse me për K8s — shën. përkth.), për gjurmimin e shpërndarë ka etj. Çdo mesh shërbimi mund të mbështesë disa mjete dhe të mos mbështesë të tjera. Do të jetë interesante të shohim nëse projekti mund të sigurojë një konvergjencë të tillë.
Në këtë rast, avantazhi i teknologjisë mesh shërbimi është se kontejnerët sidecar mund, në parim, të mbledhin të gjitha të dhënat e lartpërmendura nga shërbimet e tyre. Në fjalë të tjera, ju merrni një sistem të vetëm për mbledhjen e telemetrisë, dhe mesh shërbimi mund të trajtojë të gjitha këto informacione në mënyra të ndryshme. Për shembull:
- ndjekja e logeve nga një shërbim të caktuar në CLI;
- ndjekja e volumit të kërkesave nga paneli i monitorimit të mesh shërbimit;
- të mbledhë gjurmët e shpërndara dhe t'i drejtojë ato në një sistem si Jaeger.
Kujdes, gjykim subjektiv: Kështu që, telemetria – është ajo fushë ku ndërhyrja e fortë e rrjetit të shërbimeve nuk është e këshillueshme. Grumbullimi i informacionit themelor dhe monitorimi në kohë reale i disa "metrikave të arta" si përqindja e kërkesave të suksesit dhe vonesave – është në rregull, por le të shpresojmë se nuk do të jemi dëshmitarë të krijimit të stack-eve të tilla si Frankenstein, që do të përpiqen të zëvendësojnë sistemet e specializuara, disa prej të cilave kanë treguar një performancë të shkëlqyer dhe janë studiuar mirë.
15. Auditi
TL;DR: Ai që harron mësimet e historisë, është i destinuar t'i përsërisë ato.
Auditi është arti i vëzhgimit të ngjarjeve të rëndësishme në sistem. Në rastin e rrjetit të shërbimeve, kjo mund të nënkuptojë monitorimin e kush bëri kërkesat ndaj endpoint-eve të caktuar të shërbimeve ose sa herë gjatë muajit të fundit ndodhi ndonjë ngjarje me rëndësi për sigurinë.
Është e qartë se auditi është shumë ngushtë i lidhur me telemetrinë. Ndërsa dallimi qëndron në faktin se telemetria zakonisht lidhet me gjëra si performanca dhe efikasiteti teknik, auditi mund të ketë lidhje me çështje ligjore dhe të tjera që e kalojnë fushën e ngushtë teknike (p.sh., përputhshmëria me rregulloret GDPR - Rregullorja e BE-së për Mbrojtjen e të Dhënave).
16. Vizualizimi
TL;DR: Rroftë React.js - një burim i pafund i ndërfaqeve të çuditshme.
ndoshta ka një term më të përshtatshëm, por unë nuk e di atë. Në fakt, kam parasysh paraqitjen grafike të service mesh ose disa komponentëve të saj. Këto vizualizime mund të përfshijnë tregues si vonesat mesatare, informacionin mbi konfigurimin e konteinerëve sidecar, rezultatet e kontrolleve të shëndetit dhe njoftimet.
Të punosh në një mjedis të orientuar nga shërbimet sjell një ngarkesë kognitive shumë më të madhe krahasuar me Madhërinë e Tij Monolit. Prandaj, presioni kognitiv duhet të ulët me çdo kusht. Një ndërfaqe grafike banale për service mesh me mundësinë për të klikuar një buton dhe marrë rezultatin e kërkuar mund të ketë kërkesën vendimtare për rritjen e popullaritetit të kësaj teknologjie.
Nuk u përfshinë në listë
Fillimisht kisha për qëllim të përfshija disa skenarë të tjerë të përdorimit në listë, por më pas vendosa të mos e bëj këtë. Këtu janë ata së bashku me arsyet e vendimit tim:
- Multi-data center. Në mendimin tim, kjo nuk është aq një skenar përdorimi, sa një fushë e ngushtë dhe specifike e aplikimit të сетave të shërbimeve ose një grup funksionesh siç është zbulimi i shërbimeve.
- Ingress dhe egress. Kjo është një fushë e lidhur, por unë e kufizova veten (ndoshta në mënyrë artificiale) me skenarin e përdorimit "trafiku east-west". Ingress dhe egress meritojnë një artikull të veçantë.
Përfundimi
Këtu përfundon për momentin! Përsëri, kjo listë është mjaft e kushtëzuar dhe, me siguri, e paplotë. Nëse mendoni se kam lënë diçka pas, ose kam gabuar në ndonjë gjë, më kontaktoni në Twitter (). Ju lutem, respektoni rregullat e sjelljes.
P.S. nga përkthyesi
Si bazë për ilustrimin kryesor të artikullit është marrë një imazh nga artikulli «» (autor — Gregory MacKinnon). Ajo tregon se si një pjesë e funksionalitetit nga aplikacionet (me ngjyrë të gjelbër) ka kaluar në service mesh, e cila siguron lidhjet midis tyre (me ngjyrë të kaltër).
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «».
Burimi: habr.com
