🥇Slučajevi upotrebe servisne mreže

Bilješka. transl.: Autor ovog članka (Luc Perkins) je zagovornik programera u organizaciji CNCF, koja je dom takvih Open Source projekata kao što su Linkerd, SMI (Service Mesh Interface) i Kuma (usput, da li ste se također pitali zašto je Istio nije na ovoj listi?.). Još jednom pokušavajući da DevOps zajednicu bolje razumije trendy hype zvan "service mesh", on navodi 16 karakterističnih mogućnosti koje takva rješenja pružaju.

danas servisna mreža ― jedna od najtoplijih tema u oblasti softverskog inženjeringa (i to s pravom!). Mislim da je ova tehnologija neverovatno obećavajuća i voleo bih da bude široko prihvaćena (kada ima smisla, naravno). Međutim, za većinu ljudi još uvijek je okružen aurom misterije. Istovremeno, čak i oni koji dobro poznat sa njim je često teško artikulisati njegove prednosti i šta je tačno (uključujući i vaše zaista). U ovom članku pokušat ću ispraviti situaciju navodeći razne slučajevi upotrebe "servisne mreže"*.

* Bilješka prijevod: ovdje i dalje u članku upravo ovaj prijevod (“servisna mreža”) koristit će se za još uvijek novi termin servisna mreža.

Ali prvo želim da dam nekoliko komentara:

Nikada nisam radio sa servisnim mrežama niti ih koristio izvan projekata započetih za vlastito obrazovanje. S druge strane, ja sam 2015. godine napisao gomilu dokumentacije za Tviterovu internu servisnu mrežu (tada se nije ni zvala "servis mesh") i sudjelovao u razvoju web stranice i dokumentacije za Linkerd, pa to nešto znači.
Moja lista je približna i nepotpuna. Možda postoje slučajevi upotrebe koji su meni nepoznati, a nove opcije će se vjerovatno pojaviti tokom vremena kako se tehnologija bude razvijala i njena popularnost raste.
Istovremeno, ne podržava svaka postojeća implementacija servisne mreže sve navedene slučajeve upotrebe. Stoga, moje izjave poput “servis mesh može...” treba čitati kao “pojedinačne, a možda i sve popularne implementacije servisne mreže mogu...”.
Redoslijed primjera ne čini nikakvu razliku.

Kratka lista:

otkrivanje usluga;
enkripcija;
autentifikacija i autorizacija;
balansiranje opterećenja;
prekid strujnog kola;
automatsko skaliranje;
kanarinac raspoređivanja;
plavo-zeleno raspoređivanje;
provjera zdravlja;
rasterećenje;
zrcaljenje prometa;
izolacija;
ograničenje brzine zahtjeva, ponovni pokušaji i vremenska ograničenja;
telemetrija;
revizija;
vizualizacija.

1. Otkriće usluge

TL;DR: Povežite se na druge usluge na mreži koristeći jednostavne nazive.

Usluge bi trebale biti u mogućnosti da se automatski “pronađu” koristeći adekvatna imena - na primjer, service.api.production, pets/staging ili cassandra. Okruženje u oblaku je elastično, a jedno ime može sakriti mnoge instance usluge. Jasno je da je u takvoj situaciji fizički nemoguće hardkodirati sve IP adrese.

Osim toga, kada jedna usluga pronađe drugu, trebala bi biti u mogućnosti da šalje zahtjeve toj usluzi bez straha da će završiti na ulazu njene pokvarene instance. Drugim riječima, servisna mreža mora pratiti zdravlje svih servisnih instanci i održavati listu hostova što je moguće ažuriranom.

Svaka servisna mreža različito implementira mehanizam otkrivanja usluge. U ovom trenutku, najčešći način je delegiranje vanjskim procesima kao što je Kubernetes DNS. U prošlosti smo na Twitteru koristili sistem imenovanja u tu svrhu Finagle. Osim toga, servisna mreža omogućava pojavu prilagođenih mehanizama za imenovanje (iako još nisam vidio nijednu implementaciju SM s takvom funkcionalnošću).

2. Šifriranje

TL;DR: Riješite se nešifrovanog prometa između usluga i učinite ovaj proces automatiziranim i skalabilnim.

Lijepo je znati da napadači ne mogu prodrijeti u vašu internu mrežu. Zaštitni zidovi u tome odlično rade. Ali šta se dešava ako haker uđe unutra? Hoće li moći da radi šta hoće sa saobraćajem unutar službe? Nadajmo se da se to ipak neće dogoditi. Da biste spriječili ovaj scenarij, trebali biste implementirati mrežu bez povjerenja u kojoj je sav promet između usluga šifriran. Većina modernih servisnih mreža to postiže zajedničkim radom TLS (uzajamni TLS, mTLS). U nekim slučajevima, mTLS radi u cijelim oblacima i klasterima (mislim da će međuplanetarne komunikacije jednog dana biti uređene na sličan način).

Naravno, za mTLS servisnu mrežu opciono. Svaka usluga može se pobrinuti za vlastiti TLS, ali to znači da ćete morati pronaći način da generišete certifikate, distribuirate ih po hostovima servisa i uključite kod u aplikaciju koja će učitati te certifikate iz datoteka. Da, ne zaboravite da obnavljate ove sertifikate u redovnim intervalima. Servisne mreže automatizuju mTLS sa sistemima kao što su SPIFFE, koji zauzvrat automatizuju proces izdavanja i rotacije sertifikata.

3. Autentifikacija i autorizacija

TL;DR: Utvrdite tko je podnositelj zahtjeva i definirajte što im je dozvoljeno da rade prije nego što zahtjev uopće stigne do usluge.

Službe često žele da znaju ko izvršava zahtjev (autentifikaciju) i koristeći ove informacije odlučuje da datom subjektu je dozvoljeno da radi (ovlašćenje). U ovom slučaju, zamjenica "ko" može sakriti:

Ostale usluge. Ovo se zove "autentifikacija" peer" Na primjer, usluga web želi da pristupi servisu db. Servisne mreže obično rješavaju takve probleme koristeći mTLS: certifikati u ovom slučaju djeluju kao neophodan identifikator.
Neki ljudi ljudi. Ovo se zove "autentifikacija" zahtjev" Na primjer, korisnik haxor69 želi da kupi novu lampu. Servisne mreže pružaju različite mehanizme, npr. JSON web žetoni.
Mnogi od nas su to učinili u kodu aplikacije. Stiže zahtjev, gledamo kroz tabelu users, pronađite korisnika i uporedite lozinku, a zatim provjerite kolonu permissions itd. U slučaju servisne mreže, to se događa prije nego što zahtjev uopće stigne do usluge.

Nakon što utvrdimo od koga je došao zahtjev, moramo utvrditi šta je ovom entitetu dozvoljeno da radi. Neke servisne mreže vam omogućavaju da postavite osnovne politike (o tome ko može šta da radi) kao YAML datoteke ili na komandnoj liniji, dok druge nude integraciju sa okvirima kao što je Open Policy Agent. Krajnji cilj je da vaše usluge prihvate svaki zahtjev, pod pretpostavkom da dolazi iz pouzdanog izvora и ova radnja je dozvoljena.

4. Balansiranje opterećenja

TL;DR: Raspodijelite opterećenje na instance usluge prema specifičnom obrascu.

„Usluga“ unutar servisne sekcije vrlo se često sastoji od mnogo identičnih instanci. Na primjer, danas servis cache sastoji se od 5 primjeraka, a sutra njihov broj može porasti na 11. Zahtjevi se šalju na cache, moraju se distribuirati u skladu sa određenom svrhom. Na primjer, minimizirajte kašnjenje ili maksimizirajte vjerojatnost dolaska do radne instance. Algoritam koji se najčešće koristi je Round-robin, ali postoje mnogi drugi - na primjer, ponderirana metoda (ponderisano) upiti (možete odabrati željene ciljeve), zvono (prsten) heširanje (koristeći konzistentno heširanje na uzvodnim hostovima) ili metod najmanjeg zahtjeva (prednost se daje instanci s najmanje zahtjeva).

Klasični balanseri imaju i druge funkcije, kao što su HTTP keširanje i DDoS zaštita, ali nisu baš relevantni za saobraćaj istok-zapad (tj. za saobraćaj koji teče unutar data centra – pribl. prev.) (tipičan opseg servisne mreže). Naravno, nije potrebno koristiti servisnu mrežu za balansiranje opterećenja, ali vam omogućava da postavite i kontrolirate politike balansiranja za svaku uslugu iz centraliziranog kontrolnog sloja, čime se eliminira potreba za pokretanjem i konfiguriranjem zasebnih balansera opterećenja u mrežnom stogu. .

5. Prekid strujnog kruga

TL;DR: Zaustavite promet do problematične usluge i kontrolirajte štetu u najgorem slučaju.

Ako se iz nekog razloga servis ne može nositi sa prometom, servisna mreža nudi nekoliko opcija za rješavanje ovog problema (o ostalima će biti riječi u odgovarajućim odjeljcima). Prekid strujnog kola je najteža opcija za isključenje usluge iz saobraćaja. Međutim, samo po sebi to nema smisla - potreban je rezervni plan. Može se obezbediti povratni pritisak (povratni pritisak) servisima koji upućuju zahtjeve (samo ne zaboravite konfigurirati svoj servisni mesh za ovo!), ili, na primjer, obojite statusnu stranicu crvenom bojom i preusmjerite korisnike na drugu verziju stranice „Twitter ne radi“.

Servisne mreže ne dozvoljavaju samo da definišete kada slijedi gašenje i da ovo će uslijediti. U ovom slučaju, "kada" može uključiti bilo koju kombinaciju specificiranih parametara: ukupan broj zahtjeva za određeni period, broj paralelnih veza, zahtjeva na čekanju, aktivnih ponovnih pokušaja itd.

Verovatno ne želite da zloupotrebljavate prekid strujnog kola, ali lepo je znati da imate rezervni plan u slučaju nužde.

6. Automatsko skaliranje

TL;DR: Povećajte ili smanjite broj instanci usluge ovisno o specificiranim kriterijima.

Servisne mreže nisu planeri, pa nisu izvršiti skaliranje sebe. Međutim, oni mogu dati informacije o tome na čemu će planeri zasnivati svoje odluke. Budući da servisne mreže imaju pristup cijelom prometu između servisa, one imaju opsežne informacije o tome šta se dešava: koje usluge imaju probleme, koje su usluge vrlo malo opterećene (kapacitet koji im je dodijeljen je izgubljen) itd.

Na primjer, Kubernetes skalira usluge na osnovu CPU-a i upotrebe memorije podova (pogledajte naš izvještaj"Automatsko skaliranje i upravljanje resursima u Kubernetesu" - cca. prevod), ali ako se odlučite za skaliranje na osnovu bilo koje druge metrike (u našem slučaju koja se odnosi na promet), trebat će vam posebna metrika. Menadžment Volim ovo pokazuje kako se to radi sa izaslanik, Istio и Prometej, ali je sam proces prilično komplikovan. Željeli bismo da servisna mreža ovo pojednostavi dozvoljavajući nam da jednostavno postavimo uslove kao što su „povećati broj instanci usluge auth, ako broj zahtjeva na čekanju premaši prag u roku od jedne minute."

7. Canary implementacije

TL;DR: Testirajte nove funkcije ili verzije usluge na podskupu korisnika.

Recimo da razvijate SaaS proizvod i namjeravate uvesti njegovu novu kul verziju. Isprobali ste ga u inscenaciji i odlično je funkcionirao. Ali i dalje postoje određene zabrinutosti oko njenog ponašanja u stvarnim uslovima. Drugim riječima, morate testirati novu verziju na stvarnim problemima bez rizika od povjerenja korisnika. Canary implementacije su odlične za ovo. Oni vam omogućavaju da demonstrirate novu funkciju podskupu korisnika. Ovaj podskup može se sastojati od najvjernijih korisnika ili onih koji rade s besplatnom verzijom proizvoda, ili korisnika koji su izrazili želju da budu "pokusni kunići".

Servisne mreže implementiraju ovo tako što vam omogućavaju da odredite kriterije koji određuju ko će vidjeti koju verziju aplikacije i usmjeriti promet u skladu s tim. Međutim, ništa se ne mijenja za same usluge. Verzija 1.0 servisa vjeruje da svi zahtjevi dolaze od korisnika koji bi to trebali vidjeti, a verzija 1.1 vjeruje isto za svoje korisnike. U međuvremenu, možete promijeniti postotak prometa između stare i nove verzije, preusmjeravajući sve veći broj korisnika na novu ako ona radi stabilno i vaši "zamorci" daju zeleno svjetlo.

8. Plavo-zeleno raspoređivanje

TL;DR: Ubacite sjajnu novu funkciju, ali budite spremni da odmah sve vratite.

Značenje plavo-zelenih raspoređivanja je uvođenje nove “plave” usluge, pokretanjem paralelno sa starom, “zelenom”. Ako sve ide glatko i nova usluga dobro radi, onda se stari može postepeno onemogućiti. (Jao, jednog dana će ova nova "plava" usluga ponoviti sudbinu "zelenog" i nestati...) Plavo-zelene implementacije razlikuju se od kanarinskih po tome što nova funkcija pokriva svi odjednom korisnici (nije dio); Poenta je da imamo spremnu „sigurnu luku“ u slučaju da nešto krene po zlu.

Servisne mreže nude vrlo zgodan način testiranja "plave" usluge i trenutnog prebacivanja na "zelenu" koja radi u slučaju problema. Da ne spominjemo činjenicu da usput pružaju mnogo informacija (pogledajte „Telemetriju“ ispod) o radu „plavih“, što pomaže da se shvati da li je spreman za pun rad.

Bilješka. transl.: Možete pročitati više o različitim strategijama implementacije u Kubernetes-u (uključujući spomenutog kanarinca, plavo/zelenog i druge) u ovaj članak.

9. Zdravstveni pregled

TL;DR: Pratite koje instance usluge su funkcionalne i odgovorite na one koje više nisu funkcionalne.

Provjera zdravlja (provjera zdravlja) pomaže u odlučivanju da li su instance usluge spremne da prihvate i obrađuju promet. Na primjer, u slučaju HTTP usluga, provjera zdravlja može izgledati kao GET zahtjev do krajnje točke /health... Odgovor 200 OK će značiti da je instanca zdrava, bilo koja druga - da nije spremna za primanje saobraćaja. Servisne mreže vam omogućavaju da odredite i način na koji će se funkcionalnost provjeravati i učestalost kojom će se ova provjera provoditi. Ove informacije se zatim mogu koristiti u druge svrhe - na primjer, za balansiranje opterećenja i prekid strujnog kola.

Dakle, provjera zdravlja nije samostalan slučaj upotrebe, već se obično koristi za postizanje drugih ciljeva. Također, u zavisnosti od rezultata provjera zdravlja, mogu biti potrebne radnje izvan drugih ciljeva servisne mreže: na primjer, ažuriranje stranice statusa, kreiranje problema na GitHub-u ili popunjavanje JIRA tiketa. A servisna mreža nudi zgodan mehanizam za automatizaciju svega ovoga.

10. Skidanje opterećenja

TL;DR: Preusmjeravanje prometa kao odgovor na privremeni porast upotrebe.

Ako je određena usluga preopterećena prometom, možete privremeno preusmjeriti dio tog prometa na drugu lokaciju (odnosno, "izbaciti", "prenijeti" (šupa) njega tamo). Na primjer, u rezervnu uslugu ili podatkovni centar, ili u stalni Pulsar tema. Kao rezultat toga, usluga će nastaviti da obrađuje neke zahtjeve umjesto da se sruši i potpuno zaustavi obradu svega. Raskid opterećenja je poželjniji od prekidanja strujnog kola, ali se ipak ne preporučuje da se to zloupotrebljava. Pomaže u sprječavanju kaskadnih kvarova koji uzrokuju pad servisa.

11. Paralelizacija/zrcaljenje saobraćaja

TL;DR: Pošaljite jedan zahtjev na više mjesta odjednom.

Ponekad postoji potreba da se zahtjev (ili određeni izbor zahtjeva) pošalje na nekoliko servisa odjednom. Tipičan primjer je slanje dijela proizvodnog saobraćaja u scensku uslugu. Glavni proizvodni web server šalje zahtjev nizvodnom servisu products.production i samo njemu. A servisna mreža inteligentno kopira ovaj zahtjev i šalje ga products.staging, čega web server nije ni svjestan.

Još jedan srodni slučaj upotrebe servisne mreže koji se može implementirati povrh paralelizacije saobraćaja je regresijsko testiranje. To uključuje slanje istih zahtjeva različitim verzijama usluge i provjeru da li se sve verzije ponašaju isto. Još nisam naišao na implementaciju servisne mreže sa integrisanim sistemom za regresijsko testiranje kao što je Diffy, ali sama ideja izgleda obećavajuće.

12. Izolacija

TL;DR: Razbijte svoju mrežu usluga u mini mreže.

Također poznat kao segmentacijaIzolacija je umjetnost podjele servisne mreže na logički različite segmente koji ne znaju ništa jedan o drugom. Izolacija je poput stvaranja virtuelnih privatnih mreža. Osnovna razlika je u tome što i dalje možete uživati u svim prednostima servisne mreže (poput otkrivanja servisa), ali uz dodatnu sigurnost. Na primjer, ako napadač može prodrijeti u uslugu na jednoj podmreži, neće moći vidjeti koje usluge rade na drugim podmrežama niti presresti njihov promet.

Osim toga, koristi mogu biti i organizacione. Možda ćete htjeti podmrežati svoje usluge na osnovu strukture vaše kompanije i osloboditi programere kognitivnog opterećenja da moraju imati na umu cjelokupnu mrežu usluga.

13. Ograničavanje brzine zahtjeva, pokušaji i vremenska ograničenja

TL;DR: Više ne morate uključivati detaljne zadatke upravljanja zahtjevima u svoju bazu kodova.

Sve ove stvari bi se mogle smatrati zasebnim slučajevima upotrebe, ali sam odlučio da ih kombiniram zbog jedne zajedničke karakteristike: preuzimaju zadatke upravljanja životnim ciklusom zahtjeva kojima se obično bave biblioteke aplikacija. Ako razvijate web server u Ruby on Rails (nije integriran sa servisnom mrežom) koji šalje zahtjeve pozadinskim uslugama putem gRPC, aplikacija će morati odlučiti što učiniti ako N zahtjeva ne uspije. Također ćete morati saznati koliko će prometa ove usluge moći obraditi i hardkodirati ove parametre koristeći posebnu biblioteku. Osim toga, aplikacija će morati odlučiti kada je vrijeme za odustajanje i pustiti zahtjev da nestane (na osnovu isteka). A da bi se promijenio bilo koji od gore navedenih parametara, web server će morati biti zaustavljen, rekonfiguriran i ponovo pokrenut.

Prebacivanje ovih zadataka na servisnu mrežu ne samo da znači da programeri servisa neće morati da razmišljaju o njima, već i da ih se može posmatrati na globalniji način. Ako se koristi složeni lanac usluga, recimo A -> B -> C -> D -> E, mora se uzeti u obzir cijeli životni ciklus zahtjeva. Ako je zadatak produžiti vrijeme čekanja u servisu C, logično je to učiniti odjednom, a ne u dijelovima: ažuriranjem servisnog koda i čekanjem dok se zahtjev za povlačenjem ne prihvati i CI sistem implementira ažurirani servis.

14. Telemetrija

TL;DR: Prikupite sve potrebne (i ne baš) informacije od servisa.

Telemetrija je opšti pojam koji uključuje metriku, distribuirano praćenje i dnevnike. Servisne mreže nude mehanizme za prikupljanje i obradu sva tri tipa podataka. Ovdje stvari postaju malo mutne jer je broj mogućih opcija prevelik. Za prikupljanje metrike postoji Prometej i drugi alati koji se mogu koristiti za prikupljanje trupaca fluentd, Loki, vektor i drugi. (na primjer ClickHouse sa našim brvnara za K8s - cca. prevod), za distribuirano praćenje postoji strijelac i tako dalje. Svaka servisna mreža može podržavati neke alate, a druge ne. Bit će zanimljivo vidjeti da li projekat može Otvorite Telemetriju obezbediti izvesnu konvergenciju.

U ovom slučaju, prednost tehnologije servisne mreže je u tome što kontejneri za prikolice mogu, u principu, prikupiti sve gore navedene podatke iz svojih usluga. Drugim riječima, imate na raspolaganju jedan sistem za prikupljanje telemetrije, a servisna mreža može obraditi sve ove informacije na različite načine. Na primjer:

tail logs iz određene usluge u CLI;
pratiti obim zahtjeva sa kontrolne table servisne mreže;
prikupiti distribuirane tragove i proslijediti ih sistemu kao što je Jaeger.

Pažnja, subjektivna prosudba: Uopšteno govoreći, telemetrija je oblast u kojoj su jake smetnje od servisne mreže nepoželjne. Prikupljanje osnovnih informacija i praćenje u hodu nekih zlatnih metrika poput stope uspješnosti zahtjeva i kašnjenja je u redu, ali nadajmo se da nećemo vidjeti da se pojavljuju Frankenstein stekovi koji pokušavaju zamijeniti specijalizirane sisteme, od kojih su se neki već dokazali i dobro proučili .

15. Revizija

TL;DR: Oni koji zaborave lekcije istorije osuđeni su da ih ponavljaju.

Revizija je umjetnost promatranja važnih događaja u sistemu. U slučaju servisne mreže, to bi moglo značiti praćenje ko je uputio zahtjeve određenim krajnjim tačkama za određene usluge ili koliko puta se neki događaj vezan za sigurnost dogodio u posljednjem mjesecu.

Jasno je da je revizija veoma blisko povezana sa telemetrijom. Razlika je u tome što se telemetrija obično povezuje sa stvarima kao što su produktivnost i tehnička spremnost, dok se revizija može odnositi na pravna i druga pitanja koja nadilaze striktno tehničku sferu (na primjer, usklađenost sa GDPR - Općom uredbom EU o zaštiti podataka).

16. Pregled

TL;DR: Živio React.js - nepresušan izvor fensi interfejsa.

Možda postoji bolji termin, ali ja ga ne znam. Jednostavno mislim na grafički prikaz servisne mreže ili neke od njenih komponenti. Ove vizualizacije mogu uključivati indikatore kao što su prosječne latencije, informacije o konfiguraciji prikolice, rezultati provjere zdravlja i upozorenja.

Rad u okruženju orijentiranom na usluge uključuje mnogo veće kognitivno opterećenje u poređenju sa Njegovim Veličanstvom Monolitom. Stoga, kognitivni pritisak treba smanjiti po svaku cijenu. Jednostavan grafički interfejs za servisnu mrežu sa mogućnošću da kliknete na dugme i dobijete željeni rezultat mogao bi biti odlučujući za rast popularnosti ove tehnologije.

Nisu bili uključeni na listu

Prvobitno sam namjeravao uključiti još nekoliko slučajeva upotrebe na listu, ali sam onda odlučio da ne. Evo ih, zajedno sa razlozima moje odluke:

Multi-data centar. Po mom mišljenju, ovo nije toliko slučaj upotrebe koliko usko i specifično područje primjene servisnih mreža ili nekog skupa funkcija poput otkrivanja servisa.
Ulaz i izlaz. Ovo je povezano područje, ali sam se ograničio (možda vještački) na slučaj upotrebe "promet istok-zapad". Ulaz i izlaz zaslužuju poseban članak.

zaključak

To je sve za sada! Opet, ova lista je vrlo proizvoljna i najvjerovatnije nepotpuna. Ako mislite da sam nešto propustio ili pogriješio, kontaktirajte me na Twitteru (@luckerkins). Molimo da poštujete pravila pristojnosti.

PS od prevodioca

Naslovna ilustracija za članak bazirana je na slici iz članka “Šta je servisna mreža (i kada je koristiti)?(autor Gregory MacKinnon). Pokazuje kako se neke funkcionalnosti iz aplikacija (u zelenoj boji) preselile u servisnu mrežu koja pruža međusobne veze između njih (plavo).

Pročitajte i na našem blogu:

izvor: www.habr.com