🥇Rastet e përdorimit të rrjetës së shërbimit

Shënim. përkth.: Autori i këtij artikulli (Luc Perkins) është një avokat zhvilluesish në organizatën CNCF, e cila është shtëpia e projekteve të tilla me burim të hapur si Linkerd, SMI (Service Mesh Interface) dhe Kuma (meqë ra fjala, a keni pyetur gjithashtu se pse është Istio jo në këtë listë .). Edhe një herë, duke u përpjekur t'i sjellë komunitetit DevOps një kuptim më të mirë të zhurmës së modës të quajtur "rrjeta e shërbimit", ai rendit 16 aftësi karakteristike që ofrojnë zgjidhje të tilla.

Sot rrjetë shërbimi ― një nga temat më të nxehta në fushën e inxhinierisë softuerike (dhe me të drejtë!). Unë mendoj se kjo teknologji është tepër premtuese dhe do të doja ta shihja atë të përhapet gjerësisht (kur ka kuptim, sigurisht). Megjithatë, ajo është ende e rrethuar nga një atmosferë misteri për shumicën e njerëzve. Në të njëjtën kohë, edhe ata që i njohur mirë me të, shpesh është e vështirë të formulosh avantazhet e tij dhe çfarë është saktësisht (duke përfshirë edhe tuajat me të vërtetë). Në këtë artikull do të përpiqem të korrigjoj situatën duke renditur të ndryshme raste te perdorimit "rrjeta shërbimi"*.

* Shënim përkth.: këtu dhe më tej në artikull pikërisht ky përkthim (“rrjeta e shërbimit”) do të përdoret për termin ende të ri shërbimi rrjetë.

Por fillimisht dua të bëj disa komente:

Unë kurrë nuk kam punuar me rrjeta shërbimi ose nuk i kam përdorur ato jashtë projekteve të nisura për edukimin tim. Nga ana tjetër, unë isha ai që shkrova një sërë dokumentacionesh për rrjetën e shërbimit të brendshëm të Twitter në 2015 (nuk quhej as "rrjetë shërbimi" në atë kohë) dhe mora pjesë në zhvillimin e faqes së internetit dhe dokumentacionit për Linkerd, pra kjo do të thotë diçka.
Lista ime është e përafërt dhe e paplotë. Mund të ketë raste të përdorimit të panjohura për mua dhe opsionet e reja ka të ngjarë të shfaqen me kalimin e kohës ndërsa teknologjia zhvillohet dhe popullariteti i saj rritet.
Në të njëjtën kohë, jo çdo zbatim ekzistues i rrjetës së shërbimit mbështet të gjitha rastet e përdorimit të listuara. Prandaj, deklaratat e mia si "rrjeta e shërbimit mund..." duhet të lexohen si "individuale, dhe ndoshta të gjitha implementimet e rrjetës së shërbimit të njohur mund...".
Rendi i shembujve nuk bën ndonjë ndryshim.

Lista e shkurtër:

zbulimi i shërbimit;
enkriptim;
vërtetimi dhe autorizimi;
balancimi i ngarkesës;
prishja e qarkut;
autoscaling;
vendosjet e kanarinave;
vendosjet blu-jeshile;
kontroll shëndetësor;
reduktimi i ngarkesës;
pasqyrimi i trafikut;
izolim;
kufizimi i normës së kërkesës, riprovimet dhe afatet kohore;
telemetri;
auditimi;
vizualizimi.

1. Zbulimi i shërbimit

TL;DR: Lidhu me shërbime të tjera në rrjet duke përdorur emra të thjeshtë.

Shërbimet duhet të jenë në gjendje të "gjejnë" automatikisht njëri-tjetrin duke përdorur emra adekuat - për shembull, service.api.production, pets/staging ose cassandra. Mjediset në renë kompjuterike janë elastike dhe një emër i vetëm mund të fshehë shumë raste të një shërbimi. Është e qartë se në një situatë të tillë është fizikisht e pamundur të kodosh të gjitha adresat IP.

Plus, kur një shërbim gjen një tjetër, ai duhet të jetë në gjendje të dërgojë kërkesa në atë shërbim pa frikë se ato do të përfundojnë në hyrjen e shembullit të tij të prishur. Me fjalë të tjera, rrjeta e shërbimit duhet të monitorojë shëndetin e të gjitha rasteve të shërbimit dhe të mbajë listën e hosteve sa më të përditësuar.

Çdo rrjetë shërbimi zbaton ndryshe mekanizmin e zbulimit të shërbimit. Për momentin, mënyra më e zakonshme është delegimi në procese të jashtme si Kubernetes DNS. Në të kaluarën në Twitter kemi përdorur një sistem emërtimi për këtë qëllim Finagle. Për më tepër, teknologjia e rrjetës së shërbimit bën të mundur shfaqjen e mekanizmave të emërtimit me porosi (edhe pse nuk kam parë ende ndonjë zbatim SM me një funksionalitet të tillë).

2. Kriptimi

TL;DR: Hiqni qafe trafikun e pakriptuar midis shërbimeve dhe bëjeni këtë proces të automatizuar dhe të shkallëzuar.

Është mirë të dini se sulmuesit nuk mund të depërtojnë në rrjetin tuaj të brendshëm. Firewall-et bëjnë një punë të shkëlqyer për këtë. Por çfarë ndodh nëse një haker hyn brenda? A do të jetë në gjendje të bëjë çfarë të dojë me trafikun brenda shërbimit? Le të shpresojmë që kjo të mos ndodhë në fund të fundit. Për të parandaluar këtë skenar, duhet të zbatoni një rrjet me besim zero në të cilin i gjithë trafiku ndërmjet shërbimeve është i koduar. Shumica e rrjetave moderne të shërbimit e arrijnë këtë nëpërmjet të përbashkët TLS (TLS reciproke, mTLS). Në disa raste, mTLS funksionon në re dhe grupime të tëra (mendoj se komunikimet ndërplanetare një ditë do të rregullohen në mënyrë të ngjashme).

Sigurisht, për rrjetën e shërbimit mTLS opsionale. Çdo shërbim mund të kujdeset për TLS-në e tij, por kjo do të thotë se do t'ju duhet të gjeni një mënyrë për të gjeneruar certifikata, për t'i shpërndarë ato nëpër hostet e shërbimit dhe për të përfshirë kodin në aplikacion që do t'i ngarkojë këto certifikata nga skedarët. Oh, dhe mos harroni të rinovoni këto certifikata në intervale të rregullta. Rrjetat e shërbimit automatizojnë mTLS me sisteme si SPIFFE, të cilat, nga ana tjetër, automatizojnë procesin e lëshimit dhe rotacionit të certifikatave.

3. Autentifikimi dhe autorizimi

TL;DR: Përcaktoni se kush është kërkuesi dhe përcaktoni se çfarë lejohet të bëjë përpara se kërkesa të arrijë në shërbim.

Shërbimet shpesh duan të dinë që kryen kërkesën (autentifikimin), dhe duke përdorur këtë informacion, vendos që një subjekti të caktuar lejohet të bëjë (autorizimin). Në këtë rast, përemri "kush" mund të fshehë:

Shërbime të tjera. Ky quhet "autentifikimi" bashkëmoshatar" Për shembull, shërbimi web dëshiron të hyjë në shërbim db. Rrjetat e shërbimit zakonisht zgjidhin probleme të tilla duke përdorur mTLS: certifikatat në këtë rast veprojnë si identifikues i nevojshëm.
Disa përdorues njerëzorë. Ky quhet "autentifikimi" kërkesë" Për shembull, përdoruesi haxor69 dëshiron të blejë një llambë të re. Rrjetat e shërbimit ofrojnë mekanizma të ndryshëm, p.sh. Shenjat e Internetit JSON.
Shumë prej nesh e kanë bërë këtë në kodin e aplikacionit. Një kërkesë vjen, ne shikojmë përmes tabelës users, gjeni përdoruesin dhe krahasoni fjalëkalimin, më pas kontrolloni kolonën permissions etj. Në rastin e rrjetës së shërbimit, kjo ndodh para se kërkesa të arrijë në shërbim.

Pasi të kemi përcaktuar se nga ka ardhur kërkesa, duhet të përcaktojmë se çfarë lejohet të bëjë ky subjekt. Disa rrjeta shërbimi ju lejojnë të vendosni politika bazë (rreth kush mund të bëjë çfarë) si skedarë YAML ose në vijën e komandës, ndërsa të tjera ofrojnë integrim me korniza si p.sh. Hap agjentin e politikave. Qëllimi përfundimtar është që shërbimet tuaja të pranojnë çdo kërkesë, duke supozuar në mënyrë të sigurt se ajo vjen nga një burim i besuar и ky veprim lejohet.

4. Balancimi i ngarkesës

TL;DR: Shpërndani ngarkesën nëpër instancat e shërbimit sipas një modeli specifik.

Një "Shërbim" brenda një seksioni shërbimi shumë shpesh përbëhet nga shumë raste identike. Për shembull, sot shërbimi cache përbëhet nga 5 kopje, dhe nesër numri i tyre mund të rritet në 11. Kërkesat dërgohen në cache, duhet të shpërndahet në përputhje me një qëllim të caktuar. Për shembull, për të minimizuar vonesën ose për të maksimizuar probabilitetin për të arritur në një shembull pune. Algoritmi më i përdorur është Round-robin, por ka shumë të tjerë - për shembull, metoda e ponderuar (i peshuar) pyetje (ju mund të zgjidhni objektivat e preferuar), zile (unazë) hashing (duke përdorur hashimin e qëndrueshëm nëpër hostet në rrjedhën e sipërme) ose metodën më të vogël të kërkesës (preferenca i jepet shembullit me më pak kërkesa).

Balancuesit klasikë kanë funksione të tjera, të tilla si memoria e fshehtë HTTP dhe mbrojtja DDoS, por ato nuk janë shumë të rëndësishme për trafikun lindje-perëndim (d.m.th., për trafikun që rrjedh brenda një qendre të dhënash - përafërsisht përkth.) (sfera tipike e rrjetës së shërbimit). Sigurisht, nuk është e nevojshme të përdorni një rrjetë shërbimi për balancimin e ngarkesës, por ju lejon të vendosni dhe kontrolloni politikat e balancimit për secilin shërbim nga një shtresë e centralizuar kontrolli, duke eliminuar kështu nevojën për të ekzekutuar dhe konfiguruar balancues të veçantë të ngarkesës në grupin e rrjetit. .

5. Thyerja e qarkut

TL;DR: Ndaloni trafikun në shërbimin problematik dhe kontrolloni dëmin në skenarët më të keq.

Nëse për ndonjë arsye shërbimi nuk mund të përballojë trafikun, rrjeta e shërbimit ofron disa opsione për zgjidhjen e këtij problemi (të tjerët do të diskutohen në seksionet përkatëse). Ndërprerja e qarkut është opsioni më i rëndë për shkëputjen e një shërbimi nga trafiku. Sidoqoftë, në vetvete nuk ka kuptim - nevojitet një plan rezervë. Mund të sigurohet presion prapa (prapashtypja) për shërbimet që bëjnë kërkesa (thjesht mos harroni të konfiguroni rrjetën tuaj të shërbimit për këtë!), ose, për shembull, ngjyrosni faqen e statusit në të kuqe dhe ridrejtoni përdoruesit në një version tjetër të faqes me një "balenë në rënie" ("Twitter është poshtë”).

Rrjetat e shërbimit jo vetëm që ju lejojnë të përcaktoni kur do të pasojë mbyllja dhe që kjo do të pasojë. Në këtë rast, "kur" mund të përfshijë çdo kombinim të parametrave të specifikuar: numrin total të kërkesave për një periudhë të caktuar, numrin e lidhjeve paralele, kërkesat në pritje, riprovat aktive, etj.

Ju ndoshta nuk doni të abuzoni me ndërprerjen e qarkut, por është mirë të dini se keni një plan rezervë në rast urgjence.

6. Autoscaling

TL;DR: Rritni ose ulni numrin e rasteve të shërbimit në varësi të kritereve të specifikuara.

Rrjetat e shërbimit nuk janë planifikues, kështu që nuk janë kryejnë duke shkallëzuar veten. Megjithatë, ata mund të japin informacion mbi të cilët planifikuesit do të bazojnë vendimet e tyre. Meqenëse rrjetat e shërbimit kanë akses në të gjithë trafikun ndërmjet shërbimeve, ato kanë informacion të gjerë për atë që po ndodh: cilat shërbime po përjetojnë probleme, cilat shërbime janë të ngarkuara shumë lehtë (kapaciteti i caktuar për to është i humbur), etj.

Për shembull, Kubernetes shkallëzon shërbimet bazuar në CPU-në dhe përdorimin e memories së pods (shih raportin tonë"Shkallëzimi automatik dhe menaxhimi i burimeve në Kubernetes" - përafërsisht. përkth.), por nëse vendosni të shkallëzoni bazuar në ndonjë metrikë tjetër (në rastin tonë, lidhur me trafikun), do t'ju duhet një metrikë e veçantë. Menaxhimi si kjo tregon se si ta bëjmë këtë me i dërguar, Istio и Prometeu, por vetë procesi është mjaft i ndërlikuar. Ne dëshirojmë që rrjeta e shërbimit ta thjeshtojë këtë duke na lejuar thjesht të vendosim kushte si "rritja e numrit të rasteve të shërbimit auth, nëse numri i kërkesave në pritje e kalon pragun brenda një minutë."

7. Dislokimet e kanarinave

TL;DR: Testoni veçoritë e reja ose versionet e shërbimit në një nëngrup përdoruesish.

Le të themi se po zhvillon një produkt të caktuar SaaS dhe synon të nxjerrësh një version të ri të lezetshëm të tij. Ju e testuat atë në skenë dhe funksionoi shkëlqyeshëm. Por ka ende disa shqetësime për sjelljen e saj në kushte reale. Me fjalë të tjera, ju duhet të testoni versionin e ri për probleme reale pa rrezikuar besimin e përdoruesit. Vendosjet e kanarinave janë të shkëlqyera për këtë. Ato ju lejojnë të demonstroni një veçori të re për një nëngrup përdoruesish. Ky nëngrup mund të përbëhet nga përdoruesit më besnikë ose nga ata që punojnë me versionin falas të produktit, ose nga përdoruesit që kanë shprehur dëshirën për të qenë "derra gini".

Rrjetat e shërbimit e zbatojnë këtë duke ju lejuar të specifikoni kriteret që përcaktojnë se kush do të shohë cilin version të aplikacionit dhe të drejtoni trafikun në përputhje me rrethanat. Megjithatë, asgjë nuk ndryshon për vetë shërbimet. Versioni 1.0 i shërbimit beson se të gjitha kërkesat vijnë nga përdoruesit që duhet ta shohin atë, dhe versioni 1.1 beson të njëjtën gjë për përdoruesit e tij. Ndërkohë, mund të ndryshoni përqindjen e trafikut midis versionit të vjetër dhe atij të ri, duke ridrejtuar një numër në rritje përdoruesish tek ai i ri, nëse funksionon në mënyrë të qëndrueshme dhe "eksperimentet" tuaja japin dritën.

8. Vendosjet blu-jeshile

TL;DR: Shpenzoni një veçori të re fantastike, por përgatituni të merrni menjëherë gjithçka.

kuptimi vendosjet blu-jeshile është krijimi i një shërbimi të ri "blu", duke e lëshuar atë paralelisht me atë të vjetër, "të gjelbër". Nëse gjithçka shkon mirë dhe shërbimi i ri funksionon mirë, atëherë i vjetri mund të çaktivizohet gradualisht. (Mjerisht, një ditë ky shërbim i ri "blu" do të përsërisë fatin e atij "të gjelbërt" dhe do të zhduket...) Vendosjet blu-jeshile ndryshojnë nga ato kanarina në atë që funksioni i ri mbulon të gjithë përnjëherë përdoruesit (jo pjesë); Çështja këtu është të kesh një "port të sigurt" gati në rast se diçka shkon keq.

Rrjetat e shërbimit ofrojnë një mënyrë shumë të përshtatshme për të testuar një shërbim "blu" dhe për të kaluar menjëherë në një "jeshile" të punës në rast problemesh. Për të mos përmendur faktin se gjatë rrugës ata ofrojnë shumë informacion (shih "Telemetry" më poshtë) për punën e "blu", gjë që ndihmon për të kuptuar nëse është gati për funksionim të plotë.

Shënim. përkth.: Mund të lexoni më shumë rreth strategjive të ndryshme të vendosjes në Kubernetes (duke përfshirë kanarinën e përmendur, blu/jeshile dhe të tjera) në Ky artikull.

9. Kontrolli shëndetësor

TL;DR: Mbani gjurmët se cilat instanca shërbimi janë funksionale dhe përgjigjuni atyre që nuk janë më funksionale.

Kontrolli shëndetësor (kontrolli shëndetësor) ndihmon për të vendosur nëse instancat e shërbimit janë gati për të pranuar dhe përpunuar trafikun. Për shembull, në rastin e shërbimeve HTTP, një kontroll shëndetësor mund të duket si një kërkesë GET në pikën përfundimtare /health. Përgjigju 200 OK do të thotë që shembulli është i shëndetshëm, çdo tjetër - që nuk është gati të marrë trafik. Rrjetat e shërbimit ju lejojnë të specifikoni si mënyrën se si do të kontrollohet funksionaliteti ashtu edhe frekuencën me të cilën do të kryhet ky kontroll. Ky informacion mund të përdoret më pas për qëllime të tjera - për shembull, për balancimin e ngarkesës dhe ndërprerjen e qarkut.

Kështu, kontrolli shëndetësor nuk është një rast përdorimi i pavarur, por zakonisht përdoret për të arritur qëllime të tjera. Gjithashtu, në varësi të rezultateve të kontrolleve shëndetësore, mund të kërkohen veprime të jashtme ndaj objektivave të tjerë të rrjetës së shërbimit: për shembull, përditësimi i faqes së statusit, krijimi i një problemi në GitHub ose plotësimi i një bilete JIRA. Dhe rrjeta e shërbimit ofron një mekanizëm të përshtatshëm për të automatizuar të gjitha këto.

10. Hedhja e ngarkesës

TL;DR: Ridrejto trafikun në përgjigje të rritjes së përkohshme të përdorimit.

Nëse një shërbim i caktuar është i mbingarkuar me trafik, ju mund të ridrejtoni përkohësisht një pjesë të këtij trafiku në një vend tjetër (d.m.th., "shkarkimi", "transferimi" (derdhje) atë atje). Për shembull, në një shërbim rezervë ose qendër të dhënash, ose në një të përhershëm Shtyp temë. Si rezultat, shërbimi do të vazhdojë të përpunojë disa kërkesa në vend që të prishë dhe të ndalojë përpunimin e gjithçkaje fare. Reduktimi i ngarkesës është i preferueshëm sesa prishja e qarkut, por gjithsesi nuk këshillohet të abuzohet me të. Ndihmon në parandalimin e dështimeve në kaskadë që shkaktojnë prishjen e shërbimeve të rrjedhës së poshtme.

11. Paralelizim/pasqyrim i trafikut

TL;DR: Dërgoni një kërkesë në disa vende menjëherë.

Ndonjëherë ka nevojë për të dërguar një kërkesë (ose një përzgjedhje të caktuar kërkesash) në disa shërbime menjëherë. Një shembull tipik është dërgimi i një pjese të trafikut të prodhimit në një shërbim inskenimi. Ueb serveri kryesor i prodhimit dërgon një kërkesë në shërbimin e poshtëm products.production dhe vetëm atij. Dhe rrjeta e shërbimit kopjon në mënyrë inteligjente këtë kërkesë dhe ia dërgon products.staging, për të cilin serveri i uebit as që është në dijeni.

Një tjetër rast i lidhur me përdorimin e rrjetës së shërbimit që mund të zbatohet në krye të paralelizimit të trafikut është testimi i regresionit. Ai përfshin dërgimin e kërkesave të njëjta në versione të ndryshme të shërbimit dhe kontrollimin nëse të gjitha versionet sillen njësoj. Unë nuk kam hasur ende në një zbatim rrjetë shërbimi me një sistem të integruar të testimit të regresionit si Diffy, por vetë ideja duket premtuese.

12. Izolimi

TL;DR: Ndani rrjetën tuaj të shërbimit në mini-rrjete.

Gjithashtu i njohur si segmentimIzolimi është arti i ndarjes së rrjetës së shërbimit në segmente logjikisht të dallueshme që nuk dinë asgjë për njëri-tjetrin. Izolimi është paksa si krijimi i rrjeteve private virtuale. Dallimi themelor është se ju ende mund të shijoni të gjitha përfitimet e një rrjetë shërbimi (si zbulimi i shërbimit), por me siguri të shtuar. Për shembull, nëse një sulmues është në gjendje të depërtojë në një shërbim në një nënrrjet, ai nuk do të jetë në gjendje të shohë se cilat shërbime janë duke u ekzekutuar në nënrrjeta të tjera ose të përgjojë trafikun e tyre.

Për më tepër, përfitimet mund të jenë edhe organizative. Ju mund të dëshironi të nënrrjetoni shërbimet tuaja bazuar në strukturën e kompanisë suaj dhe t'i lehtësoni zhvilluesit nga ngarkesa njohëse e detyrimit për të mbajtur në mendje një rrjet të tërë shërbimi.

13. Kufizoni normën e kërkesës, riprovimet dhe afatet

TL;DR: Nuk keni më nevojë të përfshini detyra të ngutshme të menaxhimit të kërkesave në bazën e kodeve.

Të gjitha këto gjëra mund të konsiderohen raste të veçanta përdorimi, por vendosa t'i kombinoj për shkak të një veçorie të përbashkët: ato marrin përsipër detyrat e menaxhimit të ciklit jetësor të kërkesave të trajtuara zakonisht nga bibliotekat e aplikacioneve. Nëse jeni duke zhvilluar një server në internet në Ruby on Rails (jo i integruar me një rrjetë shërbimi) që bën kërkesa për shërbime mbështetëse nëpërmjet gRPC, aplikacioni do të duhet të vendosë se çfarë të bëjë nëse N kërkesat dështojnë. Ju gjithashtu do të duhet të zbuloni se sa trafik do të jenë në gjendje të përpunojnë dhe kodojnë këto parametra këto shërbime duke përdorur një bibliotekë të veçantë. Plus, aplikacioni do të duhet të vendosë se kur është koha të heqë dorë dhe ta lërë kërkesën të dështojë (bazuar në kohëzgjatjen). Dhe për të ndryshuar ndonjë nga parametrat e mësipërm, serveri në internet do të duhet të ndalet, të rikonfigurohet dhe të fillojë përsëri.

Shkarkimi i këtyre detyrave në një rrjetë shërbimi jo vetëm që do të thotë që zhvilluesit e shërbimeve nuk do të duhet të mendojnë për to, por edhe se ato mund të shikohen në një mënyrë më globale. Nëse përdoret një zinxhir kompleks shërbimesh, le të themi A -> B -> C -> D -> E, i gjithë cikli i jetës së kërkesës duhet të merret parasysh. Nëse detyra është të zgjasni afatet në shërbimin C, është logjike ta bëni këtë menjëherë, dhe jo në pjesë: duke përditësuar kodin e shërbimit dhe duke pritur derisa kërkesa për tërheqje të pranohet dhe sistemi CI të vendosë shërbimin e përditësuar.

14. Telemetria

TL;DR: Mblidhni të gjithë informacionin e nevojshëm (dhe jo plotësisht) nga shërbimet.

Telemetria është një term i përgjithshëm që përfshin metrikë, gjurmim të shpërndarë dhe regjistra. Rrjetat e shërbimit ofrojnë mekanizma për mbledhjen dhe përpunimin e të tre llojeve të të dhënave. Këtu gjërat bëhen pak të paqarta sepse numri i opsioneve të mundshme është shumë i madh. Për të mbledhur metrikë ekziston Prometeu dhe mjete të tjera që mund të përdoren për të mbledhur trungje i rrjedhshëm, Loki, Vektor etj (për shembull ClickHouse me tonën shtëpi bari për K8 - përafërsisht. përkth.), për gjurmim të shpërndarë ekziston Jaeger e kështu me radhë. Çdo rrjetë shërbimi mund të mbështesë disa mjete dhe jo të tjera. Do të jetë interesante të shihet nëse projekti mundet Telemetria e hapur ofrojnë njëfarë konvergjence.

Në këtë rast, avantazhi i teknologjisë së rrjetës së shërbimit është se kontejnerët e karrigeve anësore mund, në parim, të mbledhin të gjitha të dhënat e mësipërme nga shërbimet e tyre. Me fjalë të tjera, ju keni në dispozicion një sistem të vetëm grumbullimi telemetrike dhe rrjeta e shërbimit mund të përpunojë të gjithë këtë informacion në mënyra të ndryshme. Për shembull:

regjistrat e bishtit nga një shërbim i caktuar në CLI;
monitoroni vëllimin e kërkesave nga pulti i rrjetës së shërbimit;
mbledhin gjurmët e shpërndara dhe i përcjell ato në një sistem si Jaeger.

Kujdes, gjykim subjektiv: Në përgjithësi, telemetria është një zonë në të cilën ndërhyrja e fortë nga rrjeta e shërbimit është e padëshirueshme. Mbledhja e informacionit bazë dhe gjurmimi i disa metrikave të arta në fluturim, si shkalla e suksesit të kërkesës dhe vonesa është në rregull, por le të shpresojmë që të mos shohim të shfaqen rafte Frankenstein që përpiqen të zëvendësojnë sisteme të specializuara, disa prej të cilave tashmë e kanë provuar veten dhe janë studiuar mirë .

15. Auditimi

TL;DR: Ata që harrojnë mësimet e historisë janë të dënuar t'i përsërisin ato.

Auditimi është arti i vëzhgimit të ngjarjeve të rëndësishme në një sistem. Në rastin e rrjetës së shërbimit, kjo mund të nënkuptojë gjurmimin se kush ka bërë kërkesa në pika përfundimtare specifike për shërbime specifike, ose sa herë ka ndodhur ndonjë ngjarje e lidhur me sigurinë në muajin e fundit.

Është e qartë se auditimi është i lidhur shumë ngushtë me telemetrinë. Dallimi është se telemetria zakonisht lidhet me gjëra të tilla si produktiviteti dhe integriteti teknik, ndërsa auditimi mund të lidhet me çështje ligjore dhe të tjera që shkojnë përtej sferës rreptësisht teknike (për shembull, pajtueshmëria me GDPR - Rregullorja e Përgjithshme e BE-së për mbrojtjen e të dhënave).

16. Pamje paraprake

TL;DR: Rroftë React.js - një burim i pashtershëm ndërfaqesh fantastike.

Mund të ketë një term më të mirë, por unë nuk e di. Unë thjesht nënkuptoj një paraqitje grafike të një rrjete shërbimi ose disa prej përbërësve të saj. Këto vizualizime mund të përfshijnë tregues si vonesat mesatare, informacionin e konfigurimit të karriges anësore, rezultatet e kontrollit shëndetësor dhe sinjalizimet.

Puna në një mjedis të orientuar drejt shërbimit përfshin një ngarkesë shumë më të lartë njohëse në krahasim me Madhërinë e Tij Monolith. Prandaj, presioni njohës duhet të reduktohet me çdo kusht. Një ndërfaqe e thjeshtë grafike për një rrjetë shërbimi me aftësinë për të klikuar mbi një buton dhe për të marrë rezultatin e dëshiruar mund të jetë vendimtar për rritjen e popullaritetit të kësaj teknologjie.

Nuk u përfshinë në listë

Fillimisht synova të përfshija disa raste të tjera të përdorimit në listë, por më pas vendosa të mos e bëja. Këtu janë ato, së bashku me arsyet e vendimit tim:

Qendra me shumë të dhëna. Sipas mendimit tim, ky nuk është aq një rast përdorimi, sa një zonë e ngushtë dhe specifike e aplikimit të rrjetave të shërbimit ose një grup funksionesh si zbulimi i shërbimit.
Hyrja dhe dalja. Kjo është një fushë e lidhur, por unë e kam kufizuar veten (ndoshta artificialisht) në rastin e përdorimit të "trafikut lindje-perëndim". Hyrja dhe dalja meritojnë një artikull të veçantë.

Përfundim

Kjo është e gjitha për tani! Përsëri, kjo listë është shumë arbitrare dhe ka shumë të ngjarë jo e plotë. Nëse mendoni se kam humbur diçka ose kam diçka të gabuar, ju lutem më kontaktoni në Twitter (@luckerkins). Ju lutemi respektoni rregullat e mirësjelljes.

PS nga përkthyesi

Ilustrimi i titullit për artikullin bazohet në një imazh nga artikulli "Çfarë është një rrjetë shërbimi (dhe kur të përdoret një)?"(nga Gregory MacKinnon). Ai tregon se si disa funksionalitete nga aplikacionet (me ngjyrë të gjelbër) janë zhvendosur në një rrjetë shërbimi që ofron ndërlidhje ndërmjet tyre (në blu).

Lexoni edhe në blogun tonë:

Burimi: www.habr.com