Eden od premikov, ki se v IT odvijajo pod zastavo digitalne preobrazbe, je razčlenitev velikih, monolitnih aplikacij na mikro storitve—majhne, ločene enote funkcionalnosti, ki delujejo v zabojnikih—programski paketi, ki vključujejo vso kodo storitve in odvisnosti, ki jih je mogoče izolirati in enostavno prestaviti z enega strežnika na drugega.
Takšne vsebniške arhitekture je enostavno razširiti in zagnati v oblaku, posamezne mikroservice pa je mogoče hitro razviti in ponoviti. Vendar komunikacija med temi mikro storitvami postaja vse bolj zapletena, ko se aplikacije povečujejo in hkrati zažene več primerkov iste storitve. Storitvena mreža je nastajajoča arhitekturna oblika, katere namen je dinamično povezati te mikro storitve na način, ki zmanjšuje administrativne in programske obremenitve.
Kaj je servisna mreža?
V najširšem smislu je servisna mreža, kot jo opisuje Red Hat, "način za nadzor, kako si različni deli aplikacije izmenjujejo podatke". Ta opis pa bi lahko zajemal veliko različnih stvari. Pravzaprav zveni podobno kot vmesna programska oprema, ki jo večina razvijalcev pozna iz aplikacij odjemalec-strežnik.
Storitvena mreža je edinstvena, saj je zasnovana tako, da se prilagodi edinstveni naravi porazdeljenih mikroservisnih okolij. V obsežni aplikaciji, zgrajeni iz mikro storitev, je lahko več primerov katere koli storitve, ki se izvajajo v različnih lokalnih ali oblačnih strežnikih. Vsi ti gibljivi deli očitno posameznim mikro storitvam otežujejo iskanje drugih storitev, s katerimi potrebujejo komunikacijo. Storitvena mreža samodejno skrbi za odkrivanje in povezovanje storitev za vsak trenutek, tako da človeškim razvijalcem in posameznim mikro storitvam ni treba.
Storitveno mrežo si oglejte kot enakovredno programsko opredeljenemu omrežju (SDN) za 7. stopnjo mrežnega modela OSI. Tako kot SDN ustvari abstrakcijski sloj, tako da skrbnikom omrežij ni treba obravnavati fizičnih omrežnih povezav, servisna mreža loči osnovno infrastrukturo aplikacije od abstraktne arhitekture, s katero komunicirate.
Zamisel o servisni mreži se je pojavila organsko, ko so se razvijalci začeli spopadati s problemi resnično ogromne porazdeljene arhitekture. Linkerd, prvi projekt na tem področju, se je rodil kot podružnica internega projekta na Twitterju. Istio, še ena priljubljena servisna mreža z večjimi korporacijskimi podporami, izvira iz Lyfta. (V trenutku bomo podrobneje pogledali oba projekta.)
Izravnava obremenitve servisne mreže
Ena ključnih funkcij, ki jo ponuja servisna mreža, je uravnoteženje obremenitve. Običajno uravnoteženje obremenitve obravnavamo kot omrežno funkcijo - želite preprečiti, da bi kateri koli strežnik ali omrežna povezava preobremenjen s prometom, zato svoje pakete ustrezno usmerite. Storitvene mreže naredijo nekaj podobnega na ravni aplikacije, kot opisuje Twain Taylor, in razumevanje, ki vam daje dober občutek, kaj mislimo, ko rečemo, da je servisna mreža kot programsko opredeljeno omrežje za aplikacijski sloj.
V bistvu je eno od nalog servisne mreže, da spremlja, kateri primerki različnih mikrostoritev, porazdeljenih po infrastrukturi, so "najbolj zdravi". Morda jih bo anketiral, da vidijo, kako jim gre, ali si zapisal, kateri primerki se počasi odzivajo na zahteve za storitve, in poznejše zahteve poslali drugim. Storitvena mreža lahko na podoben način opravi omrežne poti, opazi, kdaj sporočila predolgo pridejo do cilja, in vzame druge poti, da to nadomesti. Te upočasnitve so lahko posledica težav z osnovno strojno opremo ali preprosto preobremenjenost storitev z zahtevami ali delo z njihovo zmogljivostjo obdelave. Pomembno je, da servisna mreža lahko poišče še en primerek iste storitve in namesto nje potuje do nje ter tako kar najbolje izkoristi celotno zmogljivost aplikacije.
Servisna mreža v primerjavi s Kubernetesom
Če ste nekoliko seznanjeni z arhitekturami, ki temeljijo na vsebnikih, se morda sprašujete, kje se Kubernetes, priljubljena odprtokodna platforma za orkestracijo vsebnikov, prilega tej sliki. Navsezadnje ni bistvo Kubernetesa v tem, da upravlja, kako vaši zabojniki komunicirajo med seboj? Kot na svojem podjetniškem blogu poudarja ekipa Kublr, bi lahko Kubernetesov "servisni" vir razumeli kot zelo osnovno mrežo storitev, saj ponuja odkrivanje storitev in krožno uravnoteženje zahtev. Toda popolnoma predstavljene servisne mreže ponujajo veliko več funkcij, kot so upravljanje varnostnih pravilnikov in šifriranje, »prekinitev vezja« za začasno ustavitev zahtev v počasi odzivne primerke, uravnoteženje obremenitve, kot smo opisali zgoraj, in še veliko več.
Upoštevajte, da večina servisnih mrež dejansko zahteva sistem orkestracije, kot je Kubernetes. Servisne mreže ponujajo razširjeno funkcionalnost in ne zamenjavo.
Storitvena mreža in API prehodi
Vsaka mikrostoritev bo zagotovila vmesnik za programiranje aplikacij (API), ki služi kot sredstvo, s katerim druge storitve komunicirajo z njo. Ob tem se zastavlja vprašanje o razlikah med servisno mrežo in drugimi bolj tradicionalnimi oblikami upravljanja API, kot so prehodi API. Kot pojasnjuje IBM, prehod API stoji med skupino mikro storitev in "zunanjim" svetom ter po potrebi usmerja zahteve po storitvah, tako da prosilcu ni treba vedeti, da gre za aplikacijo, ki temelji na mikro storitvah. Storitvena mreža pa posreduje zahteve "znotraj" aplikacije mikroservisov, pri čemer se različne komponente v celoti zavedajo svojega okolja.
Še en način razmišljanja o tem, kot piše Justin Warren Forbes, je, da je servisna mreža za promet vzhod-zahod znotraj grozda, prehod API pa za promet sever-jug, ki gre v grozd in iz njega. Toda celotna ideja servisne mreže je še vedno zgodnja in v gibanju. Številne servisne mreže, vključno z Linkerd in Istio, zdaj ponujajo tudi funkcionalnost sever-jug.
Arhitektura storitvene mreže
Ideja storitvene mreže se je pojavila šele v zadnjih nekaj letih in obstaja več različnih pristopov k reševanju problema "storitvene mreže", tj. Upravljanje komunikacij za mikro storitve. Andrew Jenkins iz Aspen Mesh opredeljuje tri možne možnosti glede tega, kje bi lahko živela komunikacijska plast, ki jo ustvari servisna mreža:
- V knjižnica da vsaka od vaših mikro storitev uvozi
- V vozlišče agent ki zagotavlja storitve za vse vsebnike na določenem vozlišču
- V prikolico vsebnik, ki teče skupaj z vsebnikom aplikacije
Vzorec, ki temelji na stranski prikolici, je eden izmed najbolj priljubljenih vzorcev mrežnih mrež - toliko, da je na nek način na splošno postal sinonim za servisne mreže. Čeprav to ni strogo rečeno, je pristop s prikolico toliko oprijem, da bomo to arhitekturo obravnavali podrobneje.
Sidecar v servisni mreži
Kaj pomeni reči, da kontejner s prikolico "teče zraven" vašega vsebnika z aplikacijami? Red Hat ima precej dobro razlago. Vsak vsebnik mikroservisov v servisni mreži te vrste ima še en vsebnik proxy, ki mu ustreza. Vsa logika, potrebna za komunikacijo med storitvami, je povzeta iz mikrostoritve in postavljena v stranski voziček.
To se morda zdi zapleteno - navsezadnje dejansko podvojite število vsebnikov v svoji aplikaciji! Uporabljate pa tudi oblikovalski vzorec, ki je ključnega pomena za poenostavitev porazdeljenih aplikacij. Če ste vso to mrežno in komunikacijsko kodo postavili v ločen vsebnik, ste jo postavili kot del infrastrukture in razvijalce osvobodili izvajanja kot dela aplikacije.
V bistvu vam preostane mikro storitev, ki se lahko lasersko osredotoči na svojo poslovno logiko. Mikroservisu ni treba vedeti, kako komunicirati z vsemi drugimi službami v divjem in norem okolju, kjer delujejo. Vedeti mora le, kako komunicirati s prikolico, ki skrbi za ostalo.
Storitvene mreže: Linkerd, Envio, Istio, Consul
Torej, katere servisne mreže so na voljo za uporabo? No, tam ni ravno komercialnih komercialnih izdelkov. Večina storitvenih mrež je odprtokodnih projektov, ki jih je treba nekaj dokončati. Velika imena so:
- Linkerd (izgovarja se »linker-dee«) - izdan leta 2016 in s tem najstarejša od teh ponudb, je bil Linkerd izločen iz knjižnice, razvite na Twitterju. Še en močan hit v tem prostoru, Conduit, je bil vključen v projekt Linkerd in je osnova za Linkerd 2.0.
- Odposlanec - Odposlanec, ustvarjen v podjetju Lyft, zaseda del »podatkovne ravnine« storitvene mreže. Če želite zagotoviti popolno servisno mrežo, jo je treba povezati z "krmilno ravnino", na primer ...
- Istio - Istio, ki so ga razvili Lyft, IBM in Google, je nadzorni načrt za servisiranje pooblaščencev, kot je Envoy. Medtem ko sta Istio in Envoy privzeti par, jih je mogoče seznaniti z drugimi platformami.
- HashiCorp Consul - predstavljen s Consul 1.2, funkcijo, imenovano Connect, je dodala šifriranje storitve in pooblastilo na podlagi identitete distribuiranemu sistemu HashiCorp za odkrivanje in konfiguriranje storitev ter ga pretvorila v mrežo celotnih storitev.
Katera servisna mreža je primerna za vas? Primerjava presega obseg tega članka, vendar je treba omeniti, da so bili vsi zgornji izdelki dokazani v velikih in zahtevnih okoljih. Linkerd in Istio imata najobsežnejši nabor funkcij, vendar se vsi hitro razvijajo. Morda boste želeli preveriti razčlenitev funkcij Linkerda, Odposlanca in Istioa Georgea Mirande, čeprav ne pozabite, da je bil njegov članek napisan, preden sta Conduit in Linkerd združila moči.
Upoštevajte tudi, da je ta prostor nov in da se lahko kadar koli pojavijo novi konkurenti. Na primer, novembra 2018 je Amazon začel ponujati javni predogled mrežne storitve AWS. Glede na to, koliko trgov uporablja Amazonov javni oblak, bi moral imeti velik vpliv AWS App Mesh.
