🥇Primeri uporabe servisne mreže

Opomba. prevod: Avtor tega članka (Luc Perkins) je zagovornik razvijalcev pri organizaciji CNCF, ki je dom odprtokodnih projektov, kot so Linkerd, SMI (Service Mesh Interface) in Kuma (mimogrede, ali ste se tudi vprašali, zakaj je Istio ni na tem seznamu? Spet poskuša skupnosti DevOps omogočiti boljše razumevanje trendovskega hype, imenovanega "service mesh", navaja 16 značilnih zmogljivosti, ki jih ponujajo takšne rešitve.

Danes servisna mreža ― ena najbolj vročih tem na področju programskega inženiringa (in prav je tako!). Mislim, da je ta tehnologija neverjetno obetavna in bi rad videl, da bi bila široko sprejeta (če je seveda smiselno). Vendar pa je za večino ljudi še vedno obdan z avro skrivnosti. Ob tem tudi tisti, ki dobro znan pri njem je pogosto težko formulirati njegove prednosti in kaj točno je (tudi vaše resnično). V tem članku bom poskušal popraviti situacijo z naštevanjem različnih primeri uporabe "servisne mreže"*.

* Opomba prevod: tukaj in v nadaljevanju v članku bo prav ta prevod (»servisna mreža«) uporabljen za še vedno nov izraz servisna mreža.

Toda najprej želim dati nekaj pripomb:

Nikoli nisem delal s servisnimi mrežami ali jih uporabljal zunaj projektov, ki sem jih začel za lastno izobraževanje. Po drugi strani pa sem bil jaz tisti, ki je leta 2015 napisal kopico dokumentacije za Twitterjev interni servisni mesh (takrat se še sploh ni imenoval "service mesh") in sodeloval pri razvoju spletne strani in dokumentacije za Linkerd, torej to nekaj pomeni.
Moj seznam je približen in nepopoln. Morda obstajajo meni neznani primeri uporabe in verjetno se bodo sčasoma pojavile nove možnosti, ko se bo tehnologija razvijala in njena priljubljenost naraščala.
Hkrati pa vsaka obstoječa izvedba mrežne mreže ne podpira vseh navedenih primerov uporabe. Zato je treba moje izjave, kot je "storitvena mreža lahko ..." brati kot "posamezne in morda vse priljubljene storitvene mreže implementacije lahko ...".
Vrstni red primerov ni pomemben.

Ožji seznam:

odkrivanje storitev;
šifriranje;
avtentikacija in avtorizacija;
uravnoteženje obremenitve;
prekinitev tokokroga;
samodejno skaliranje;
namestitve kanarčkov;
modro-zelene razporeditve;
zdravstveni pregled;
razbremenitev;
zrcaljenje prometa;
izolacija;
omejitev hitrosti zahtev, ponovni poskusi in časovne omejitve;
telemetrija;
revizija;
vizualizacija.

1. Odkrivanje storitve

TL;DR: povežite se z drugimi storitvami v omrežju s preprostimi imeni.

Storitve bi morale imeti možnost, da se samodejno »najdejo« z ustreznimi imeni - na primer service.api.production, pets/staging ali cassandra. Okolja v oblaku so elastična in eno samo ime lahko skrije veliko primerkov storitve. Jasno je, da je v takšni situaciji fizično nemogoče kodirati vse naslove IP.

Poleg tega, ko ena storitev najde drugo, mora biti sposobna pošiljati zahteve tej storitvi brez strahu, da bodo končale na vhodu njene pokvarjene instance. Z drugimi besedami, storitvena mreža mora spremljati zdravje vseh primerkov storitve in vzdrževati seznam gostiteljev čim bolj posodobljen.

Vsaka storitvena mreža izvaja mehanizem odkrivanja storitev drugače. Trenutno je najpogostejši način prenos na zunanje procese, kot je Kubernetes DNS. V preteklosti smo na Twitterju za ta namen uporabljali sistem poimenovanja Finagle. Poleg tega mrežna tehnologija storitev omogoča pojav mehanizmov poimenovanja po meri (čeprav še nisem videl nobene izvedbe SM s takšno funkcionalnostjo).

2. Šifriranje

TL;DR: Znebite se nešifriranega prometa med storitvami in naredite ta proces avtomatiziran in razširljiv.

Lepo je vedeti, da napadalci ne morejo prodreti v vaše notranje omrežje. Požarni zidovi to odlično opravijo. Toda kaj se zgodi, če heker pride notri? Ali bo lahko počel kar hoče s prometom znotraj storitev? Upajmo, da se to vendarle ne bo zgodilo. Če želite preprečiti ta scenarij, morate implementirati omrežje brez zaupanja, v katerem je ves promet med storitvami šifriran. Večina sodobnih servisnih mrež to doseže z medsebojnim TLS (medsebojni TLS, mTLS). V nekaterih primerih mTLS deluje v celih oblakih in grozdih (mislim, da bodo medplanetarne komunikacije nekoč urejene podobno).

Seveda za storitveno mrežo mTLS neobvezno. Vsaka storitev lahko skrbi za svoj lasten TLS, vendar to pomeni, da boste morali najti način za generiranje potrdil, njihovo distribucijo med gostitelji storitev in vključiti kodo v aplikacijo, ki bo ta potrdila naložila iz datotek. Da, ne pozabite redno obnavljati teh potrdil. Storitvena omrežja avtomatizirajo mTLS s sistemi, kot je SPIFFE, ki pa avtomatizirajo proces izdajanja in rotacije certifikatov.

3. Avtentikacija in avtorizacija

TL; DR: Ugotovite, kdo je prosilec, in določite, kaj sme narediti, preden zahteva sploh doseže storitev.

Storitve pogosto želijo vedeti ki izvede zahtevo (avtentikacijo) in na podlagi teh informacij odloči da dani subjekt sme narediti (pooblastilo). V tem primeru se zaimek "kdo" lahko skrije:

Druge storitve. To se imenuje "avtentikacija" vrstnik" Na primer storitev web želi dostopati do storitve db. Storitvene mreže običajno rešujejo takšne težave z uporabo mTLS: potrdila v tem primeru delujejo kot potrebni identifikator.
Nekateri človeški uporabniki. To se imenuje "avtentikacija" prošnja" Na primer uporabnik haxor69 želi kupiti novo svetilko. Servisne mreže zagotavljajo različne mehanizme, npr. JSON Spletni tokeni.
Mnogi od nas smo to storili v programski kodi. Pride zahteva, pogledamo skozi mizo users, poiščite uporabnika in primerjajte geslo, nato preverite stolpec permissions itd. V primeru storitvene mreže se to zgodi, preden zahteva sploh doseže storitev.

Ko ugotovimo, od koga je prišla zahteva, moramo ugotoviti, kaj lahko ta subjekt počne. Nekatere storitvene mreže vam omogočajo nastavitev osnovnih politik (o tem, kdo lahko počne kaj) kot datoteke YAML ali v ukazni vrstici, medtem ko druge ponujajo integracijo z ogrodji, kot je Odpri agenta politike. Končni cilj je, da vaše storitve sprejmejo vsako zahtevo, ob predpostavki, da prihaja iz zaupanja vrednega vira и to dejanje je dovoljeno.

4. Izravnavanje obremenitve

TL; DR: Razporedite obremenitev po primerkih storitve v skladu z določenim vzorcem.

»Storitev« v razdelku storitve je zelo pogosto sestavljena iz številnih enakih primerkov. Na primer, danes storitev cache obsega 5 izvodov, jutri pa se lahko njihovo število poveča na 11. Povpraševanje poslano na cache, morajo biti razdeljeni v skladu z določenim namenom. Na primer, zmanjšajte zakasnitev ali povečajte verjetnost, da pridete do delujočega primerka. Najpogosteje uporabljen algoritem je Round-robin, vendar obstaja veliko drugih - na primer utežena metoda (ponderirano) poizvedbe (lahko izberete želene cilje), zvonjenje (prstan) zgoščevanje (uporaba doslednega zgoščevanja v zgornjih gostiteljih) ali metoda najmanjše zahteve (prednost ima primerek z najmanj zahtevami).

Klasični balanserji imajo še druge funkcije, kot sta HTTP caching in DDoS zaščita, vendar niso zelo relevantni za promet vzhod-zahod (torej za promet, ki teče znotraj podatkovnega centra – pribl. prev.) (tipičen obseg servisne mreže). Seveda za izravnavo obremenitve ni treba uporabiti storitvene mreže, vendar vam omogoča, da nastavite in nadzirate politike uravnoteženja za vsako storitev iz centralizirane nadzorne plasti, s čimer odpravite potrebo po zagonu in konfiguraciji ločenih izravnalnikov obremenitve v omrežnem skladu. .

5. Prekinitev tokokroga

TL; DR: Zaustavite promet do problematične storitve in nadzorujte škodo v najslabšem primeru.

Če storitev iz nekega razloga ne more obvladati prometa, storitvena mreža ponuja več možnosti za rešitev te težave (o drugih bomo razpravljali v ustreznih razdelkih). Prekinitev tokokroga je najhujša možnost za izklop storitve iz prometa. Vendar samo po sebi ni smiselno - potreben je rezervni načrt. Lahko se zagotovi protitlak (protitlak) storitvam, ki postavljajo zahteve (samo ne pozabite za to konfigurirati storitveno mrežo!) ali na primer obarvanje strani s stanjem rdeče in preusmerjanje uporabnikov na drugo različico strani s »padajočim kitom« (»Twitter je navzdol”).

Storitvene mreže vam ne omogočajo le definiranja ko sledila bo zaustavitev in da to bo sledilo. V tem primeru lahko "kdaj" vključuje katero koli kombinacijo določenih parametrov: skupno število zahtev za določeno obdobje, število vzporednih povezav, čakajočih zahtev, aktivnih ponovnih poskusov itd.

Verjetno ne želite zlorabljati prekinitev tokokroga, vendar je lepo vedeti, da imate rezervni načrt za nujne primere.

6. Samodejno skaliranje

TL; DR: Povečajte ali zmanjšajte število primerkov storitve glede na podana merila.

Storitvene mreže niso načrtovalci, zato tudi ne izvajati skaliranje samega sebe. Vendar pa lahko zagotovijo informacije o tem, kateri načrtovalci bodo temeljili na svojih odločitvah. Ker imajo storitvena omrežja dostop do celotnega prometa med storitvami, imajo obsežne informacije o tem, kaj se dogaja: katere storitve imajo težave, katere storitve so zelo malo obremenjene (zmogljivost, ki jim je dodeljena, je izgubljena) itd.

Na primer, Kubernetes skalira storitve glede na uporabo procesorja in pomnilnika podov (oglejte si naše poročilo "Samodejno skaliranje in upravljanje virov v Kubernetesu« – pribl. prev.), če pa se odločite za skaliranje na podlagi katere koli druge metrike (v našem primeru povezane s prometom), boste potrebovali posebno metriko. Upravljanje Všečkaj to prikazuje, kako to storiti z Odposlanec, Istio и Prometej, vendar je sam postopek precej zapleten. Radi bi, da mreža storitev to poenostavi tako, da nam omogoči preprosto nastavitev pogojev, kot je »povečanje števila primerkov storitve auth, če število čakajočih zahtev preseže prag v eni minuti."

7. Razmestitve Canary

TL;DR: Preizkusite nove funkcije ali različice storitev na podskupini uporabnikov.

Recimo, da razvijate izdelek SaaS in nameravate uvesti njegovo kul novo različico. Preizkusili ste ga v uprizoritvi in delovalo je odlično. Še vedno pa obstajajo določeni pomisleki glede njenega obnašanja v realnih razmerah. Z drugimi besedami, novo različico morate preizkusiti na resničnih težavah, ne da bi tvegali zaupanje uporabnikov. Razmestitve Canary so odlične za to. Omogočajo vam, da predstavite novo funkcijo podskupini uporabnikov. To podmnožico lahko sestavljajo najbolj zvesti uporabniki ali tisti, ki delajo z brezplačno različico izdelka, ali uporabniki, ki so izrazili željo, da bi bili »pokusni zajčki«.

Storitvene mreže izvajajo to tako, da vam omogočajo, da določite merila, ki določajo, kdo bo videl katero različico aplikacije, in ustrezno usmerja promet. Nič pa se ne spremeni za same storitve. Različica 1.0 storitve meni, da vse zahteve prihajajo od uporabnikov, ki bi jo morali videti, različica 1.1 pa verjame enako za svoje uporabnike. Medtem lahko spremenite odstotek prometa med staro in novo različico, s čimer preusmerite vse večje število uporabnikov na novo, če deluje stabilno in vaši "poskusni zajčki" dajejo zeleno luč.

8. Modro-zelene postavitve

TL;DR: Predstavite kul novo funkcijo, vendar bodite pripravljeni, da takoj vzamete vse nazaj.

Pomen modro-zelene postavitve je uvesti novo »modro« storitev, ki jo bo lansirala vzporedno s staro, »zeleno«. Če gre vse gladko in nova storitev dobro deluje, lahko staro postopoma onemogočite. (Žal, nekega dne bo ta nova »modra« storitev ponovila usodo »zelene« in izginila ...) Modro-zelene uvedbe se od kanarčkov razlikujejo po tem, da nova funkcija pokriva vsi naenkrat uporabniki (ne del); Bistvo tukaj je, da imamo pripravljen »varni pristan«, če gre kaj narobe.

Storitvene mreže ponujajo zelo priročen način za testiranje "modre" storitve in takojšen preklop na delujočo "zeleno" v primeru težav. Da ne omenjam dejstva, da na poti zagotavljajo veliko informacij (glejte »Telemetrija« spodaj) o delu »modrega«, ki pomaga razumeti, ali je pripravljen za polno delovanje.

Opomba. prevod: Več o različnih strategijah uvajanja v Kubernetesu (vključno z omenjenim kanarčkom, modro/zelenim in drugimi) lahko preberete v ta članek.

9. Zdravstveni pregled

TL;DR: spremljajte, kateri primerki storitve delujejo, in se odzovite na tiste, ki ne delujejo več.

Zdravstveni pregled (zdravstveni pregled) pomaga pri odločanju, ali so primerki storitve pripravljeni sprejeti in obdelati promet. Na primer, v primeru storitev HTTP lahko pregled stanja izgleda kot zahteva GET do končne točke /health. Odgovori 200 OK bo pomenilo, da je primerek zdrav, kateri koli drug - da ni pripravljen na sprejem prometa. Storitvene mreže vam omogočajo, da določite način preverjanja funkcionalnosti in pogostost izvajanja tega preverjanja. Te informacije se lahko nato uporabijo za druge namene - na primer za uravnoteženje obremenitve in prekinitev tokokroga.

Tako preverjanje zdravja ni samostojen primer uporabe, ampak se običajno uporablja za doseganje drugih ciljev. Odvisno od rezultatov preverjanja stanja bodo morda potrebna tudi dejanja, ki niso povezana z drugimi cilji mreže storitev: na primer posodobitev strani s stanjem, ustvarjanje težave na GitHubu ali izpolnjevanje vstopnice JIRA. Storitvena mreža ponuja priročen mehanizem za avtomatizacijo vsega tega.

10. Razbremenitev

TL;DR: Preusmeri promet kot odgovor na začasno povečanje uporabe.

Če je določena storitev preobremenjena s prometom, lahko del tega prometa začasno preusmerite na drugo lokacijo (to je “izmet”, “prenos” (lopa) on tam). Na primer v rezervno storitev ali podatkovni center ali v stalno pritisnite tema. Posledično bo storitev še naprej obdelovala nekatere zahteve, namesto da bi se zrušila in popolnoma ustavila obdelavo vsega. Razbremenitev je boljša od prekinitve tokokroga, vendar je še vedno odsvetovana zloraba. Pomaga preprečiti kaskadne napake, ki povzročijo zrušitev nadaljnjih storitev.

11. Paralelizacija/zrcaljenje prometa

TL;DR: Pošljite eno zahtevo na več mest hkrati.

Včasih je treba zahtevo (ali določen izbor zahtev) poslati več storitvam hkrati. Tipičen primer je pošiljanje dela produkcijskega prometa v uprizoritveno storitev. Glavni produkcijski spletni strežnik pošlje zahtevo nadaljnji storitvi products.production in samo njemu. In storitvena mreža inteligentno kopira to zahtevo in jo pošlje v products.staging, česar se spletni strežnik niti ne zaveda.

Drug soroden primer uporabe mrežnega omrežja, ki ga je mogoče implementirati poleg paralelizacije prometa, je regresijsko testiranje. Vključuje pošiljanje istih zahtev različnim različicam storitve in preverjanje, ali se vse različice obnašajo enako. Nisem še naletel na implementacijo storitvene mreže z integriranim sistemom regresijskega testiranja, kot je Diffy, a sama ideja se zdi obetavna.

12. Izolacija

TL;DR: razdelite svojo storitveno mrežo na mini omrežja.

Poznan tudi kot segmentacijaIzolacija je umetnost razdelitve storitvene mreže na logično ločene segmente, ki drug o drugem ne vedo ničesar. Izolacija je nekoliko podobna ustvarjanju navideznih zasebnih omrežij. Bistvena razlika je v tem, da lahko še vedno uživate v vseh prednostih mrežne mreže storitev (kot je odkrivanje storitev), vendar z dodatno varnostjo. Na primer, če lahko napadalec prodre v storitev v enem podomrežju, ne bo mogel videti, katere storitve delujejo v drugih podomrežjih, ali prestreči njihovega prometa.

Poleg tega so lahko koristi tudi organizacijske. Morda boste želeli svoje storitve razdeliti v podomrežje glede na strukturo vašega podjetja in razvijalce razbremeniti kognitivne obremenitve, da morajo imeti v mislih celotno mrežo storitev.

13. Omejitev hitrosti zahtev, ponovni poskusi in časovne omejitve

TL; DR: Ni vam treba več vključiti drobnih nalog upravljanja zahtev v vašo kodno zbirko.

Vse te stvari bi lahko obravnavali kot ločene primere uporabe, vendar sem se odločil, da jih združim zaradi ene skupne lastnosti: prevzamejo naloge upravljanja življenjskega cikla zahtev, ki jih običajno obravnavajo knjižnice aplikacij. Če razvijate spletni strežnik v Ruby on Rails (ni integriran s storitveno mrežo), ki pošilja zahteve zalednim storitvam prek gRPC, se bo morala aplikacija odločiti, kaj storiti, če N zahtev ne uspe. Prav tako boste morali ugotoviti, koliko prometa bodo te storitve lahko obdelale in te parametre trdo kodirati s pomočjo posebne knjižnice. Poleg tega se bo morala aplikacija odločiti, kdaj je čas, da odneha in pustiti, da zahteva izzveni (glede na časovno omejitev). Če želite spremeniti katerega od zgornjih parametrov, bo treba spletni strežnik ustaviti, znova konfigurirati in znova zagnati.

Prenos teh nalog na storitveno mrežo ne pomeni le, da razvijalcem storitev ne bo treba razmišljati o njih, ampak tudi, da jih je mogoče gledati na bolj globalen način. Če se uporablja kompleksna veriga storitev, recimo A -> B -> C -> D -> E, je treba upoštevati celoten življenjski cikel zahteve. Če je naloga podaljšati časovne omejitve v storitvi C, je logično, da to storite naenkrat in ne po delih: s posodobitvijo storitvene kode in čakanjem, da je zahteva za vleko sprejeta in sistem CI uvede posodobljeno storitev.

14. Telemetrija

TL;DR: Zberite vse potrebne (in ne povsem) informacije iz storitev.

Telemetrija je splošen izraz, ki vključuje metrike, porazdeljeno sledenje in dnevnike. Storitvena omrežja ponujajo mehanizme za zbiranje in obdelavo vseh treh vrst podatkov. Tu se stvari nekoliko zameglijo, ker je število možnih možnosti preveliko. Za zbiranje meritev obstaja Prometej in druga orodja, ki se lahko uporabljajo za zbiranje dnevnikov tekoče, Loki, vektor itd (na primer ClickHouse z našim brunarica za K8s - pribl. prev.), za porazdeljeno sledenje obstaja Jaeger in tako naprej. Vsaka storitvena mreža lahko podpira nekatera orodja, druga pa ne. Zanimivo bo videti, ali projekt zmore Odprite Telemetrijo zagotoviti nekaj konvergence.

V tem primeru je prednost storitvene mrežne tehnologije v tem, da lahko kontejnerji s prikolico načeloma zbirajo vse zgoraj navedene podatke iz svojih storitev. Z drugimi besedami, na voljo imate en sistem za zbiranje telemetrije, servisna mreža pa lahko vse te informacije obdela na različne načine. Na primer:

zadnji dnevniki določene storitve v CLI;
spremljajte količino zahtev iz nadzorne plošče mrežne storitve;
zbira porazdeljene sledi in jih posreduje sistemu, kot je Jaeger.

Pozor, subjektivna presoja: Na splošno je telemetrija področje, kjer močne motnje storitvene mreže niso zaželene. Zbiranje osnovnih informacij in sprotno sledenje nekaterim zlatim meritvam, kot sta stopnja uspešnosti zahtev in zakasnitev, je v redu, vendar upajmo, da ne bomo videli Frankensteinovih skladov, ki poskušajo nadomestiti specializirane sisteme, od katerih so se nekateri že izkazali in dobro preučeni .

15. Revizija

TL;DR: Tisti, ki pozabijo lekcije zgodovine, so obsojeni, da jih ponavljajo.

Revizija je umetnost opazovanja pomembnih dogodkov v sistemu. V primeru storitvene mreže bi to lahko pomenilo sledenje, kdo je poslal zahteve določenim končnim točkam za določene storitve ali kolikokrat se je v zadnjem mesecu zgodil dogodek, povezan z varnostjo.

Jasno je, da je revizija zelo tesno povezana s telemetrijo. Razlika je v tem, da je telemetrija običajno povezana s stvarmi, kot sta produktivnost in tehnična celovitost, medtem ko se revizija lahko nanaša na pravna in druga vprašanja, ki presegajo strogo tehnično sfero (na primer skladnost z GDPR – Splošno uredbo EU o varstvu podatkov).

16. Vizualizacija

TL;DR: Naj živi React.js – neizčrpen vir modnih vmesnikov.

Morda obstaja boljši izraz, vendar ga ne poznam. Preprosto mislim na grafično predstavitev storitvene mreže ali nekaterih njenih komponent. Te vizualizacije lahko vključujejo indikatorje, kot so povprečne zakasnitve, informacije o konfiguraciji prikolice, rezultati preverjanja stanja in opozorila.

Delo v storitveno usmerjenem okolju vključuje veliko večjo kognitivno obremenitev v primerjavi z Njegovim Veličanstvom Monolitom. Zato je treba za vsako ceno zmanjšati kognitivni pritisk. Preprost grafični vmesnik za storitveno mrežo z možnostjo klika na gumb in pridobitve želenega rezultata bi lahko bil odločilen za rast priljubljenosti te tehnologije.

Niso bili vključeni na seznam

Prvotno sem nameraval na seznam vključiti še nekaj primerov uporabe, a sem se nato odločil, da tega ne bom storil. Tu so skupaj z razlogi za mojo odločitev:

Multi-podatkovni center. Po mojem mnenju to ni toliko primer uporabe kot ozko in specifično področje uporabe storitvenih mrež ali nekega nabora funkcij, kot je odkrivanje storitev.
Vstop in izstop. To je sorodno področje, vendar sem se (morda umetno) omejil na primer uporabe "promet vzhod-zahod". Vhod in izstop si zaslužita ločen članek.

Zaključek

To je vse za zdaj! Tudi ta seznam je zelo poljuben in najverjetneje nepopoln. Če menite, da sem kaj spregledal ali se kaj zmotil, me kontaktirajte na Twitterju (@luckerkins). Prosimo, da spoštujete pravila spodobnosti.

PS od prevajalca

Naslovna ilustracija članka temelji na sliki iz članka “Kaj je Service Mesh (in kdaj ga uporabiti)?« (avtor Gregory MacKinnon). Prikazuje, kako so se nekatere funkcionalnosti iz aplikacij (zeleno) preselile v storitveno mrežo, ki zagotavlja medsebojne povezave med njimi (modro).

Preberite tudi na našem blogu:

Vir: www.habr.com