🥇Slučajevi upotrebe mrežaste mreže

Bilješka. prev.: 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, jeste li se pitali zašto je Istio nije na ovom popisu? .). Još jednom pokušavajući približiti DevOps zajednici bolje razumijevanje trendi hypea zvanog "service mesh", on navodi 16 karakterističnih mogućnosti koje takva rješenja pružaju.

Danas servisna mreža ― jedna od najvrućih tema u području softverskog inženjerstva (i to s pravom!). Mislim da ova tehnologija nevjerojatno obećava i volio bih da bude široko prihvaćena (naravno, kada ima smisla). Međutim, za većinu ljudi još uvijek je okružen aurom tajanstvenosti. Istovremeno, čak i oni koji dobro poznato kod njega je često teško artikulirati njegove prednosti i koje su to točno (uključujući i vaše istinske). U ovom ću članku pokušati 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 dati nekoliko komentara:

Nikada nisam radio s servisnim mrežama niti sam ih koristio izvan projekata započetih za vlastito obrazovanje. S druge strane, ja sam bio taj koji je 2015. napisao hrpu dokumentacije za Twitterov interni servisni mesh (tada se još nije ni zvao "servisni mesh") i sudjelovao u razvoju web stranice i dokumentacije za Linkerd, pa to nešto znači.
Moj popis je približan i nepotpun. Mogu postojati meni nepoznati slučajevi upotrebe, a nove opcije će se vjerojatno pojaviti tijekom vremena kako se tehnologija bude razvijala i njezina popularnost raste.
U isto vrijeme, ne podržava svaka postojeća implementacija mreže usluge sve navedene slučajeve upotrebe. Stoga, moje izjave poput "servisna mreža može..." treba čitati kao "pojedinačne, a možda i sve popularne servisne mreže mogu...".
Redoslijed primjera ne čini nikakvu razliku.

Uži izbor:

otkrivanje usluge;
enkripcija;
autentifikacija i autorizacija;
uravnoteženje opterećenja;
prekid strujnog kruga;
automatsko skaliranje;
rasporedi kanarinaca;
plavo-zeleni rasporedi;
provjera zdravlja;
rasterećenje;
zrcaljenje prometa;
izolacija;
ograničenje brzine zahtjeva, ponovni pokušaji i isteci vremena;
telemetrija;
revizija;
vizualizacija.

1. Otkrivanje usluge

TL;DR: Povežite se s drugim uslugama na mreži koristeći jednostavna imena.

Usluge bi trebale biti u mogućnosti automatski "pronaći" jedna drugu koristeći odgovarajuća imena - na primjer, service.api.production, pets/staging ili cassandra. Okruženja u oblaku su elastična, a jedno ime može sakriti mnoge instance usluge. Jasno je da je u takvoj situaciji fizički nemoguće kodirati sve IP adrese.

Osim toga, kada jedan servis pronađe drugi, trebao bi moći slati zahtjeve tom servisu bez straha da će oni završiti na ulazu njegove pokvarene instance. Drugim riječima, mreža usluge mora nadzirati zdravlje svih instanci usluge i održavati popis hostova što je moguće ažuriranijim.

Svaka servisna mreža drugačije implementira mehanizam otkrivanja servisa. Trenutno je najčešći način delegiranje vanjskim procesima kao što je Kubernetes DNS. U prošlosti smo na Twitteru u tu svrhu koristili sustav imenovanja Finagle. Osim toga, servisna mrežna tehnologija omogućuje pojavu prilagođenih mehanizama imenovanja (iako još nisam vidio nijednu SM implementaciju s takvom funkcionalnošću).

2. Šifriranje

TL;DR: Riješite se nekriptiranog 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. Vatrozidi to odlično rade. Ali što se događa ako haker ipak uđe unutra? Hoće li s unutarservisnim prometom moći raditi što god hoće? Nadajmo se da se to ipak neće dogoditi. Kako biste spriječili ovaj scenarij, trebali biste implementirati mrežu bez povjerenja u kojoj je sav promet između usluga šifriran. Većina modernih uslužnih mreža to postiže međusobnim TLS (međusobni 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 uslužnu mrežu neobavezan. Svaka usluga može brinuti o vlastitom TLS-u, ali to znači da ćete morati pronaći način za generiranje certifikata, njihovu distribuciju među hostovima servisa i uključiti kod u aplikaciju koja će učitati te certifikate iz datoteka. Da, ne zaboravite obnavljati ove certifikate u redovitim intervalima. Servisne mreže automatiziraju mTLS sa sustavima poput SPIFFE, koji pak automatiziraju proces izdavanja i rotiranja certifikata.

3. Autentifikacija i autorizacija

TL;DR: Utvrdite tko je podnositelj zahtjeva i definirajte što mu je dopušteno učiniti prije nego što zahtjev uopće stigne do usluge.

Službe često žele znati koji izvršava zahtjev (autentikaciju), te na temelju tih podataka odlučuje da danom entitetu je dopušteno učiniti (autorizacija). U ovom slučaju, zamjenica "tko" može sakriti:

Druge usluge. To se zove "provjera autentičnosti" vršnjak" Na primjer, usluga web želi pristupiti usluzi db. Servisne mreže obično rješavaju takve probleme koristeći mTLS: certifikati u ovom slučaju djeluju kao neophodni identifikatori.
Neki ljudski korisnici. To se zove "provjera autentičnosti" zahtjev" Na primjer, korisnik haxor69 želi kupiti novu lampu. Servisne mreže pružaju različite mehanizme, npr. JSON web žetoni.
Mnogi od nas su to učinili u kodu aplikacije. Dolazi zahtjev, gledamo po stolu users, pronađite korisnika i usporedite lozinku, zatim provjerite stupac permissions itd. U slučaju servisne mreže, to se događa prije nego što zahtjev uopće stigne do usluge.

Nakon što smo ustanovili od koga je zahtjev došao, moramo utvrditi što taj entitet smije raditi. Neke servisne mreže omogućuju vam da postavite osnovna pravila (o tome tko što može raditi) kao YAML datoteke ili u naredbenom retku, dok druge nude integraciju s okvirima kao što su Otvoreni agent za politiku. Konačni cilj je da vaše usluge prihvate bilo koji zahtjev, pod sigurnom pretpostavkom da dolazi iz pouzdanog izvora и ova radnja je dopuštena.

4. Balansiranje opterećenja

TL;DR: Raspodjelite opterećenje na instance usluge prema određenom obrascu.

“Usluga” unutar odjeljka usluge vrlo se često sastoji od mnogo identičnih instanci. Na primjer, danas usluga cache sastoji se od 5 primjeraka, a sutra se njihov broj može povećati na 11. Zahtjevi upućeni na cache, moraju se distribuirati u skladu s određenom svrhom. Na primjer, minimizirajte latenciju ili povećajte vjerojatnost dolaska do radne instance. Najčešće korišteni algoritam je Round-robin, ali postoje i mnogi drugi - na primjer, ponderirana metoda (ponderirano) upite (možete odabrati željene ciljeve), zvon (prsten) raspršivanje (upotrebom dosljednog raspršivanja preko uzvodnih hostova) ili metoda najmanjeg zahtjeva (prednost se daje instanci s najmanje zahtjeva).

Klasični balanseri imaju druge funkcije, kao što su HTTP predmemoriranje i DDoS zaštita, ali nisu baš relevantni za promet istok-zapad (odnosno, za promet koji teče unutar podatkovnog centra - pribl. prijevod) (tipičan opseg servisne mreže). Naravno, nije potrebno koristiti servisnu mrežu za balansiranje opterećenja, ali vam omogućuje postavljanje i kontrolu pravila balansiranja za svaku uslugu iz centraliziranog kontrolnog sloja, čime se eliminira potreba za pokretanjem i konfiguracijom 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 usluga ne može nositi s prometom, servisna mreža nudi nekoliko opcija za rješavanje ovog problema (o ostalima će se raspravljati u odgovarajućim odjeljcima). Prekid strujnog kruga je najteža opcija za isključivanje usluge iz prometa. Međutim, samo po sebi to nema smisla - potreban je rezervni plan. Može se osigurati protutlak (povratni pritisak) uslugama koje postavljaju zahtjeve (samo ne zaboravite konfigurirati mrežu svoje usluge za to!), ili, na primjer, bojanje stranice statusa u crveno i preusmjeravanje korisnika na drugu verziju stranice s "padajućim kitom" ("Twitter je dolje”).

Servisne mreže ne samo da vam omogućuju definiranje kada uslijedit će gašenje i da ovo će uslijediti. U ovom slučaju, "kada" može uključivati bilo koju kombinaciju navedenih parametara: ukupan broj zahtjeva za određeno razdoblje, broj paralelnih veza, zahtjeve na čekanju, aktivne ponovne pokušaje itd.

Vjerojatno ne želite zloupotrijebiti prekidanje strujnog kruga, ali lijepo 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 navedenim kriterijima.

Servisne mreže nisu planeri, pa to i ne čine provesti skaliranje sebe. Međutim, oni mogu pružiti informacije na temelju kojih će planeri temeljiti svoje odluke. Budući da mrežne mreže usluga imaju pristup cjelokupnom prometu između usluga, imaju opsežne informacije o tome što se događa: koje usluge imaju problema, koje su usluge vrlo malo opterećene (kapacitet koji im je dodijeljen je uzalud) itd.

Na primjer, Kubernetes skalira usluge na temelju upotrebe CPU-a i memorije mahuna (pogledajte naše izvješće "Automatsko skaliranje i upravljanje resursima u Kubernetesu" - cca. prev.), ali ako odlučite skalirati na temelju bilo koje druge metrike (u našem slučaju, povezane s prometom), trebat će vam posebna metrika. Upravljanje kao ovo pokazuje kako to učiniti s Izaslanik, Istio и Prometej, ali sam proces je prilično kompliciran. Željeli bismo da servisna mreža to pojednostavi dopuštajući nam da jednostavno postavimo uvjete poput "povećaj broj instanci usluge auth, ako broj zahtjeva na čekanju prijeđe prag unutar jedne minute."

7. Canary raspoređivanja

TL;DR: testirajte nove značajke ili verzije usluge na podskupu korisnika.

Recimo da razvijate SaaS proizvod i namjeravate izbaciti njegovu cool novu verziju. Isprobali ste ga u inscenaciji i odlično je funkcionirao. Ali još uvijek postoje određene nedoumice oko njezina ponašanja u stvarnim uvjetima. Drugim riječima, morate testirati novu verziju na stvarnim problemima bez riskiranja povjerenja korisnika. Canary implementacije su izvrsne za ovo. Omogućuju vam demonstraciju nove značajke podskupu korisnika. Ovaj podskup se može 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 dopuštajući vam da navedete kriterije koji određuju tko će vidjeti koju verziju aplikacije i prema tome usmjeravaju promet. Međutim, ništa se ne mijenja za same usluge. Verzija 1.0 usluge vjeruje da svi zahtjevi dolaze od korisnika koji bi je 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 radi stabilno i vaši "pokusni kunići" daju zeleno svjetlo.

8. Plavo-zeleni rasporedi

TL;DR: Ubacite cool novu značajku, ali budite spremni da odmah vratite sve.

smisao plavo-zeleni rasporedi je pokrenuti novu "plavu" uslugu, lansirajući je paralelno sa starom, "zelenom". Ako sve ide glatko i nova usluga radi dobro, tada se stara može postupno onemogućiti. (Jao, jednog dana će ova nova "plava" usluga ponoviti sudbinu "zelene" i nestati...) Plavo-zelene implementacije razlikuju se od kanarinskih po tome što nova funkcija pokriva svi odjednom korisnici (ne dio); Ovdje je poanta imati spremnu "sigurnu luku" u slučaju da nešto pođe po zlu.

Servisne mreže nude vrlo praktičan način testiranja "plave" usluge i trenutnog prebacivanja na radnu "zelenu" u slučaju problema. Da ne spominjemo činjenicu da usput pružaju mnogo informacija (pogledajte "Telemetrija" u nastavku) o radu "plavog", što pomaže razumjeti je li spreman za puni rad.

Bilješka. prev.: Možete pročitati više o različitim strategijama implementacije u Kubernetesu (uključujući spomenute Canary, blue/green i druge) u ovaj članak.

9. Zdravstveni pregled

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

Provjera zdravlja (provjera zdravlja) pomaže odlučiti jesu li instance usluge spremne prihvatiti i obraditi promet. Na primjer, u slučaju HTTP usluga, provjera zdravlja može izgledati kao GET zahtjev krajnjoj točki /health... Odgovor 200 OK značit će da je instanca zdrava, bilo koja druga - da nije spremna primati promet. Servisne mreže omogućuju vam da odredite način na koji će se provjeravati funkcionalnost i učestalost kojom će se ta provjera provoditi. Te se informacije zatim mogu koristiti u druge svrhe - na primjer, za uravnoteženje opterećenja i prekidanje strujnog kruga.

Stoga provjera zdravlja nije samostalan slučaj upotrebe, već se obično koristi za postizanje drugih ciljeva. Također, ovisno o rezultatima provjera ispravnosti, mogu biti potrebne radnje koje su izvan drugih ciljeva mreže usluge: na primjer, ažuriranje stranice statusa, stvaranje problema na GitHubu ili ispunjavanje JIRA tiketa. A servisna mreža nudi praktičan mehanizam za automatizaciju svega toga.

10. Rasterećenje

TL;DR: Preusmjerite promet kao odgovor na privremeni porast upotrebe.

Ako je određena usluga preopterećena prometom, možete privremeno preusmjeriti dio tog prometa na drugu lokaciju (tj. "izbaciti", "prebaciti" (šupa) on tamo). Na primjer, u pričuvnu uslugu ili podatkovni centar, ili u stalni tisak tema. Kao rezultat toga, usluga će nastaviti obrađivati neke zahtjeve umjesto da se sruši i potpuno zaustavi obradu svega. Rasterećenje je bolje od prekida strujnog kruga, ali još uvijek nije preporučljivo zlorabiti ga. Pomaže u sprječavanju kaskadnih kvarova koji uzrokuju rušenje nizvodnih usluga.

11. Paralelizacija/zrcaljenje prometa

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

Ponekad postoji potreba za slanjem zahtjeva (ili određenog izbora zahtjeva) na nekoliko usluga odjednom. Tipičan primjer je slanje dijela produkcijskog prometa na staging uslugu. Glavni proizvodni web poslužitelj šalje zahtjev nizvodnoj usluzi products.production i samo njemu. A servisna mreža inteligentno kopira ovaj zahtjev i šalje ga products.staging, čega web poslužitelj nije ni svjestan.

Još jedan povezani slučaj upotrebe mrežaste mreže koji se može implementirati povrh paralelizacije prometa je regresijsko testiranje. To uključuje slanje istih zahtjeva različitim verzijama usluge i provjeru ponašaju li se sve verzije isto. Još nisam naišao na implementaciju servisne mreže s integriranim sustavom regresijskog testiranja poput Diffy, ali sama ideja djeluje obećavajuće.

12. Izolacija

TL; DR: Razdvojite svoju mrežnu mrežu usluge na mini-mreže.

Također poznat kao segmentacijaIzolacija je umijeće dijeljenja servisne mreže na logički različite segmente koji ne znaju ništa jedni o drugima. Izolacija je poput stvaranja virtualnih privatnih mreža. Temeljna je razlika u tome što i dalje možete uživati u svim prednostima mreže usluge (kao što je otkrivanje usluge), 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 organizacijske. Možda ćete htjeti podmrežiti svoje usluge na temelju strukture vaše tvrtke i osloboditi programere kognitivnog opterećenja da moraju imati na umu cijelu mrežu usluga.

13. Ograničenje brzine zahtjeva, ponovni pokušaji i isteci vremena

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

Sve ove stvari mogle bi se smatrati zasebnim slučajevima upotrebe, ali odlučio sam ih kombinirati zbog jedne zajedničke značajke: one preuzimaju zadatke upravljanja životnim ciklusom zahtjeva koje obično obrađuju knjižnice aplikacija. Ako razvijate web poslužitelj u Ruby on Rails (nije integriran s 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 te usluge moći obraditi i tvrdo kodirati ove parametre pomoću posebne biblioteke. Osim toga, aplikacija će morati odlučiti kada je vrijeme za odustajanje i pustiti da zahtjev nestane (na temelju vremenskog ograničenja). A kako bi se promijenio bilo koji od gore navedenih parametara, web poslužitelj mora biti zaustavljen, ponovno konfiguriran i ponovo pokrenut.

Prebacivanje ovih zadataka na uslužnu mrežu ne samo da znači da programeri usluga neće morati razmišljati o njima, već i da ih se može promatrati na globalniji način. Ako se koristi složen lanac usluga, recimo A -> B -> C -> D -> E, mora se uzeti u obzir cijeli životni ciklus zahtjeva. Ako je zadatak produljiti vremensko ograničenje u usluzi C, logično je to učiniti odjednom, a ne u dijelovima: ažuriranjem servisnog koda i čekanjem da se zahtjev za povlačenjem prihvati i CI sustav implementira ažuriranu uslugu.

14. Telemetrija

TL;DR: Prikupite sve potrebne (i ne sasvim) informacije od usluga.

Telemetrija je opći pojam koji uključuje metriku, distribuirano praćenje i zapisnike. Servisne mreže nude mehanizme za prikupljanje i obradu sve tri vrste podataka. Tu se stvari malo zamućuju jer je broj mogućih opcija prevelik. Za prikupljanje metrike postoji Prometej i drugi alati koji se mogu koristiti za prikupljanje trupaca tečno, Loki, vektor itd. (na primjer ClickHouse s našim brvnara za K8s - cca. prev.), 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 može li projekt Otvorite telemetriju osigurati određenu konvergenciju.

U ovom slučaju, prednost servisne mrežne tehnologije je u tome što bočni kontejneri mogu, u načelu, prikupljati sve gore navedene podatke iz svojih servisa. Drugim riječima, na raspolaganju vam je jedan sustav za prikupljanje telemetrije, a servisna mreža sve te podatke može obraditi na razne načine. Na primjer:

zadnji zapisnici određene usluge u CLI-u;
pratiti količinu zahtjeva s mrežne nadzorne ploče usluge;
prikupiti distribuirane tragove i proslijediti ih sustavu poput Jaegera.

Pažnja, subjektivna procjena: Općenito govoreći, telemetrija je područje u kojem su nepoželjne jake smetnje iz servisne mreže. 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 Frankensteinove skupove koji pokušavaju zamijeniti specijalizirane sustave, od kojih su se neki već dokazali i dobro proučeni.

15. Revizija

TL;DR: Oni koji zaborave lekcije iz povijesti osuđeni su ponavljati ih.

Revizija je umijeće promatranja važnih događaja u sustavu. U slučaju servisne mreže, to bi moglo značiti praćenje tko je uputio zahtjeve određenim krajnjim točkama za određene usluge ili koliko se puta dogodio neki sigurnosni događaj u prošlom mjesecu.

Jasno je da je revizija vrlo blisko povezana s telemetrijom. Razlika je u tome što se telemetrija obično povezuje sa stvarima poput produktivnosti i tehničkog integriteta, dok se revizija može odnositi na pravna i druga pitanja koja nadilaze striktno tehničku sferu (primjerice, usklađenost s GDPR - Općom uredbom EU o zaštiti podataka).

16. Vizualizacija

TL;DR: Živio React.js - neiscrpan izvor otmjenih sučelja.

Možda postoji bolji izraz, ali ja ga ne znam. Jednostavno mislim na grafički prikaz servisne mreže ili neke od njezinih komponenti. Ove vizualizacije mogu uključivati pokazatelje poput prosječnih latencija, informacije o konfiguraciji prikolice, rezultate provjere stanja i upozorenja.

Rad u okruženju usmjerenom na pružanje usluga uključuje puno veće kognitivno opterećenje u usporedbi s Njegovim Veličanstvom Monolitom. Stoga treba pod svaku cijenu smanjiti kognitivni pritisak. Jednostavno grafičko sučelje za servisni mesh s mogućnošću klika na gumb i dobivanja željenog rezultata moglo bi biti odlučujuće za rast popularnosti ove tehnologije.

Nisu bili uključeni u popis

Prvotno sam namjeravao uključiti još nekoliko slučajeva upotrebe na popis, ali sam onda odlučio to ne učiniti. Evo ih, zajedno s razlozima moje odluke:

Multi-podatkovni centar. Po mom mišljenju, ovo nije toliko slučaj upotrebe koliko usko i specifično područje primjene uslužnih mreža ili nekog skupa funkcija poput otkrivanja usluge.
Ulazak i izlazak. Ovo je povezano područje, ali sam se ograničio (možda umjetno) na slučaj upotrebe "promet istok-zapad". Ulazak i izlazak zaslužuju poseban članak.

Zaključak

To je sve za sada! Opet, ovaj popis je vrlo proizvoljan i najvjerojatnije nepotpun. Ako mislite da sam nešto propustio ili pogriješio, kontaktirajte me na Twitteru (@luckerkins). Molimo poštujte pravila pristojnosti.

PS od prevoditelja

Naslovna ilustracija za članak temelji se na slici iz članka “Što je Service Mesh (i kada ga koristiti)?"(autor Gregory MacKinnon). Prikazuje kako su se neke funkcionalnosti iz aplikacija (u zelenoj boji) preselile u servisnu mrežu koja omogućuje međusobne veze (u plavoj boji).

Pročitajte i na našem blogu:

Izvor: www.habr.com