Opomba. prevod: Servisna mreža je pojav, ki še nima stabilnega prevoda v ruščino (pred več kot 2 leti smo predlagali možnost "mreža za storitve", malo kasneje pa so nekateri kolegi začeli aktivno promovirati kombinacijo "servisno sito"). Nenehno govorjenje o tej tehnologiji je pripeljalo do situacije, ko sta marketinška in tehnična komponenta pretesno prepleteni. To čudovito gradivo enega od avtorjev izvirnega izraza je namenjeno zagotavljanju jasnosti za inženirje in druge.
Strip iz
Predstavitev
Če ste programski inženir, ki dela nekje v prostoru zalednih sistemov, se je izraz "storitvena mreža" v zadnjih nekaj letih verjetno že trdno zasidral v vaši glavi. Zahvaljujoč nenavadnemu naključju ta besedna zveza vse bolj prevzema industrijo, hype in promocijske ponudbe, povezane z njo, pa rastejo kot snežna kepa, ki leti navzdol in ne kaže znakov, da bi pojenjala.
Storitvena mreža se je rodila v mračnih, pristranskih vodah izvornega ekosistema v oblaku. Na žalost to pomeni, da se velik del polemik okoli tega giblje od "nizkokaloričnih pogovorov" do - če uporabimo tehnični izraz - popolne neumnosti. Toda če presekate ves hrup, boste ugotovili, da ima servisna mreža zelo resnično, definirano in pomembno funkcijo.
V tej objavi bom poskušal narediti prav to: ponuditi iskren, poglobljen, na inženirja osredotočen vodnik za storitveno mrežo. Ne bom samo odgovoril na vprašanje: "Kaj je?", - ampak tudi "Zakaj?"in "Zakaj zdaj?". Nazadnje bom poskušal orisati, zakaj je (po mojem mnenju) prav ta tehnologija povzročila tako noro razburjenje, kar je zanimiva zgodba sama po sebi.
Kdo sem
Pozdravljeni vsi skupaj! Ime mi je . Sem eden od ustvarjalcev — prvi servisni mesh projekt in projekt, ki je kriv za pojav izraza servisna mreža kot tak (žal fantje!). (Opomba prev.: Mimogrede, ob zori pojava tega izraza, pred več kot 2,5 leti, smo že prevedli zgodnje gradivo istega avtorja z naslovom "".) tudi glavo je startup, ki ustvarja kul storitvene mrežne stvari, kot sta Linkerd in .
Verjetno lahko uganete, da imam o tem vprašanju zelo pristransko in subjektivno mnenje. Vendar bom poskušal čim bolj zmanjšati pristranskost (z izjemo enega razdelka: "Zakaj se toliko govori o servisni mreži?", - v katerem bom še vedno delil svoje vnaprejšnje ideje). Potrudil se bom tudi, da bo ta vodnik čim bolj objektiven. Za konkretne primere se bom v prvi vrsti zanašal na Linkerdove izkušnje, pri čemer bom izpostavil razlike (če obstajajo), ki jih poznam pri implementaciji drugih tipov storitvenih mrež.
V redu, čas je, da preidemo na dobrote.
Kaj je servisna mreža?
Kljub vsemu navdušenju je struktura storitvene mreže precej preprosta. To je le kup posrednikov uporabniškega prostora, ki se nahajajo "zraven" storitev (o tem, kaj je "naslednje", bomo govorili kasneje), plus niz nadzornih procesov. Pooblaščenci se skupaj imenujejo podatkovna ravnina, in pokličejo se nadzorni procesi krmilna ravnina. Podatkovna ravnina prestreže klice med storitvami in z njimi počne "vse vrste različnih stvari"; Nadzorna ravnina torej usklajuje vedenje posrednika in vam omogoča dostop, tj. operaterja do API-ja, ki omogoča upravljanje in merjenje omrežja kot celote.
Kakšen proxy je to? To je proxy TCP, ki podpira raven 7 (tj. »ob upoštevanju« sloja 7 modela OSI) kot sta HAProxy in NGINX. Izberete lahko proxy po svojih željah; Linkerd uporablja Rust proxy, ki je preprosto poimenovan . Sestavili smo ga posebej za servisno mrežo. Druge mreže imajo raje druge posrednike (Envoy je običajna izbira). Vendar pa je izbira proxyja le stvar izvedbe.
Kaj počnejo ti proxy strežniki? Očitno posredujejo klice v in iz storitev (strogo gledano delujejo kot posredniki in obratni posredniki, obravnavajo tako dohodne kot odhodne klice). In izvajajo nabor funkcij, ki se osredotoča na klice med storitve. Ta osredotočenost na promet med storitvami je tisto, po čemer se mrežni proxy storitve razlikuje od, recimo, prehodov API ali vhodnih proxyjev (slednji se osredotočajo na klice, ki prihajajo v gručo iz zunanjega sveta). (Opomba. prevod: Za primerjavo obstoječih krmilnikov Ingress za Kubernetes, med katerimi mnogi uporabljajo že omenjeni Envoy, glejte .)
Tako smo uredili podatkovno ravnino. Nadzorna ravnina je enostavnejša: je nabor komponent, ki zagotavlja vse mehanike, ki jih podatkovna ravnina potrebuje za usklajeno delovanje, vključno z odkrivanjem storitev, izdajanjem potrdil TLS, metričnim združevanjem itd. Podatkovna ravnina obvešča nadzorno ravnino o njegovo vedenje; nadzorna ravnina pa ponuja API, ki vam omogoča spreminjanje in spremljanje vedenja podatkovne ravnine kot celote.
Spodaj je diagram nadzorne ravnine in podatkovne ravnine v Linkerdu. Kot lahko vidite, nadzorna ravnina vključuje več različnih komponent, vključno z instanco Prometheus, ki zbira metrike iz proxy strežnikov, kot tudi druge komponente, kot je destination (odkrivanje storitve), identity (certifikacijski organ, CA) in public-api (končne točke za splet in CLI). Nasprotno pa je podatkovna ravnina preprost linkerd-proxy poleg primerka aplikacije. To je le logični diagram; Pri razmestitvi v resničnem svetu boste morda imeli tri replike vsake komponente nadzorne ravnine in na stotine ali tisoče posrednikov v podatkovni ravnini.
(Modri pravokotniki v tem diagramu simbolizirajo meje podov Kubernetes. Vidite lahko, da so vsebniki z linkerd-proxy v istem podu kot vsebniki aplikacij. Ta shema je znana kot bočna prikolica kontejner.)
Storitvena mrežna arhitektura ima več pomembnih posledic. Prvič, ker je naloga proxyja prestrezanje klicev med storitvami, je storitvena mreža smiselna samo, če je bila vaša aplikacija ustvarjena za določen nabor storitev. Mreža eno lahko uporaba z monoliti, vendar je to očitno odveč zaradi enega samega proxyja in po njegovi funkcionalnosti verjetno ne bo povpraševanja.
Druga pomembna posledica je, da servisna mreža zahteva ogromno število pooblaščencev. Pravzaprav Linkerd vsakemu primerku vsake storitve pripne proxy linkerd (druge izvedbe dodajo proxy vsakemu vozlišču/gostitelju/virtualnemu stroju. To je vseeno veliko). Takšna aktivna uporaba proxyjev sama po sebi prinaša številne dodatne zaplete:
- Posredniki v podatkovni ravnini morajo biti hitro, saj je za vsak klic nekaj klicev proxyju: eden na strani odjemalca, eden na strani strežnika.
- Tudi pooblaščenci bi morali biti majhna и lahka. Vsak bo porabil pomnilnik in vire procesorja, ta poraba pa bo rasla linearno z aplikacijo.
- Potrebovali boste mehanizem za uvajanje in posodabljanje velikega števila posrednikov. Ročno početje ni možnost.
Na splošno je storitveno omrežje videti takole (vsaj s ptičje perspektive): uvedete kup posrednikov uporabniškega prostora, ki "nekaj naredijo" z notranjim prometom med storitvami, in uporabite nadzorno ravnino za njihovo spremljanje in upravljanje.
Zdaj je čas, da si zastavimo vprašanje "Zakaj?"
Čemu služi servisna mreža?
Tistim, ki so prvič naleteli na zamisel o servisni mreži, bi lahko oprostili, da so se počutili nekoliko zaskrbljeni. Storitvena mrežna zasnova pomeni, da ne bo le povečala zakasnitve v aplikaciji, ampak bo tudi porabijo sredstva in bo dodal kup novih mehanizmov v infrastrukturi. Najprej nastavite storitveno mrežo, nato pa nenadoma ugotovite, da morate servisirati na stotine (če ne na tisoče) posrednikov. Vprašanje je, kdo bo to naredil prostovoljno?
Odgovor na to vprašanje ima dva dela. Prvič, transakcijske stroške, povezane z uvajanjem teh posrednikov, je mogoče znatno zmanjšati zaradi nekaterih sprememb, ki se zgodijo v ekosistemu (več o tem pozneje).
Drugič, takšna naprava je pravzaprav odličen način za vnos dodatne logike v sistem. Ne samo zato, ker lahko storitvena mreža doda veliko novih funkcij, ampak tudi zato, ker je to mogoče storiti brez poseganja v ekosistem. Pravzaprav celoten servisni mrežni model temelji na tej predpostavki: v večstoritvenem sistemu, ne glede na vse delajo individualne storitve, promet med njimi je idealna točka za dodajanje funkcionalnosti.
Na primer, v Linkerdu (kot v večini mrež) je funkcionalnost osredotočena predvsem na klice HTTP, vključno s HTTP/2 in gRPC*. Funkcionalnost je precej bogata - razdelimo jo lahko v tri razrede:
- Funkcije, povezane z zanesljivost. Ponavljajoče se zahteve, časovne omejitve, kanarček (razdelitev/preusmeritev prometa) itd.
- Funkcije, povezane z spremljanje. Združevanje stopenj uspešnosti, zamud in obsegov zahtevkov za vsako storitev ali posamezno smer; izdelava topoloških kart storitev itd.
- Funkcije, povezane z varnost. Medsebojni TLS, nadzor dostopa itd.
* Z Linkerdovega vidika se gRPC praktično ne razlikuje od HTTP/2: samo uporablja protobuf v koristnem tovoru. Z vidika razvijalca sta stvari seveda različni.
Mnogi od teh mehanizmov delujejo na ravni zahteve (torej "proxy L7"). Na primer, če storitev Foo opravi klic HTTP storitvi Bar, lahko povezovalni posrednik na strani Foo izvede inteligentno uravnoteženje obremenitve in usmeri klice iz primerkov Foo v Bar na podlagi opažene zakasnitve; lahko ponovi zahtevo, če je potrebno (in če je idempotenten); lahko zabeleži kodo odziva in časovno omejitev itd. Podobno lahko linkerd-proxy na strani vrstice zavrne zahtevo, če ni dovoljena ali je omejitev zahteve presežena; lahko zabeleži zamudo s svoje strani itd.
Posredniki lahko "nekaj naredijo" tudi na ravni povezave. Linkerd-proxy na strani Foo lahko na primer sproži povezavo TLS, linkerd-proxy na strani Bar pa jo lahko prekine, obe strani pa lahko drug drugemu preverita potrdila TLS*. To ne zagotavlja samo šifriranja med storitvami, ampak tudi kriptografsko varen način za identifikacijo storitev: Foo in Bar lahko "dokažeta", da sta to, za kar se predstavljata.
* »Vzajemni prijatelj« pomeni, da je tudi potrdilo odjemalca preverjeno (vzajemni TLS). Pri »klasičnem« TLS-u, na primer med brskalnikom in strežnikom, se praviloma preverja certifikat samo ene strani (strežnika).
Ne glede na to, ali delujejo na ravni zahteve ali povezave, je pomembno poudariti, da so vse storitvene mrežne funkcije operativni značaj. Linkerd ne more preoblikovati semantike tovora – na primer dodajanja polj fragmentu JSON ali spreminjanja protobuf. O tej pomembni funkciji bomo govorili kasneje, ko bomo govorili o ESB in vmesni programski opremi.
To je nabor funkcij, ki jih ponuja storitvena mreža. Postavlja se vprašanje: zakaj jih ne bi implementirali neposredno v aplikacijo? In zakaj bi se sploh ukvarjal s proxyjem?
Zakaj je servisna mreža dobra ideja
Medtem ko so zmogljivosti storitvene mreže vznemirljive, njena temeljna vrednost pravzaprav ni v njenih lastnostih. Na koncu mi Lahko jih implementirajte neposredno v aplikacijo (kasneje bomo videli, da je bil to izvor servisne mreže). Če poskusimo povzeti v enem stavku, je vrednost servisne mreže: zagotavlja funkcije, ki so ključne za izvajanje sodobne strežniške programske opreme na dosleden način v celotnem skladu in neodvisno od kode aplikacije.
Analizirajmo ta predlog.
«Funkcije, ki so ključne za izvajanje sodobne strežniške programske opreme" Če ustvarjate transakcijsko strežniško aplikacijo, ki je povezana z javnim internetom, sprejema zahteve iz zunanjega sveta in nanje odgovarja v kratkem času – na primer spletno aplikacijo, strežnik API in veliko večino drugih sodobnih aplikacij. - in če ga implementirate kot nabor storitev, ki sinhrono sodelujejo med seboj, in če nenehno nadgrajujete to programsko opremo, dodajate nove funkcije in če ste prisiljeni vzdrževati ta sistem v delovnem stanju med postopkom spreminjanja - v tem primeru, čestitamo, ustvarjate sodobno strežniško programsko opremo. In vse te odlične funkcije, naštete zgoraj, se dejansko izkažejo za kritične za vas. Aplikacija mora biti zanesljiva, varna in imeti morate možnost opazovanja, kaj počne. To so točno tista vprašanja, ki jih servisna mreža pomaga rešiti.
(V redu, prejšnji odstavek še vedno vključuje moje prepričanje, da je ta pristop sodoben način ustvarjanja strežniške programske opreme. Drugi raje razvijajo monolite, »reaktivne mikrostoritve« in druge stvari, ki ne spadajo v zgornjo definicijo. Ti ljudje imajo verjetno svoje mnenje je drugačno od mojega. Po drugi strani pa menim, da se "motijo" - čeprav v vsakem primeru servisna mreža zanje ni zelo uporabna).
«Uniforma za celotno skladovnico" Funkcionalnost, ki jo zagotavlja storitvena mreža, ni le kritična za misijo. Veljajo za vse storitve v aplikaciji, ne glede na to, v katerem jeziku so napisane, kakšen okvir se uporabljajo, kdo jih je napisal, kako so bile nameščene in morebitne druge podrobnosti njihovega razvoja in uporabe.
«Neodvisno od aplikacijske kode" Nazadnje, storitvena mreža ne zagotavlja samo dosledne funkcionalnosti v celotnem skladu, ampak to počne na način, ki ne zahteva urejanja aplikacije. Temeljna osnova funkcionalnosti storitvenega omrežja, vključno z nalogami za konfiguracijo, posodabljanje, delovanje, vzdrževanje itd., je v celoti na ravni platforme in je neodvisna od aplikacije. Aplikacija se lahko spremeni, ne da bi to vplivalo na storitveno mrežo. Storitvena mreža se lahko spremeni brez sodelovanja aplikacije.
Skratka, storitvena mreža ne zagotavlja le vitalne funkcionalnosti, ampak to počne tudi na globalen, enoten in od aplikacij neodvisen način. In tako, čeprav je funkcionalnost storitvenega omrežja mogoče implementirati v storitveno kodo (na primer kot knjižnico, vključeno v vsako storitev), ta pristop ne bo zagotovil enotnosti in neodvisnosti, ki sta tako dragoceni v primeru storitvenega omrežja.
In vse kar morate storiti je, da dodate kup posrednikov! Obljubim, da bomo zelo kmalu preučili operativne stroške, povezane z dodajanjem teh posrednikov. Toda najprej se ustavimo in poglejmo to idejo neodvisnosti z različnih vidikov. ljudje.
Komu pomaga servisna mreža?
Ne glede na to, kako neprijetno je, da tehnologija postane pomemben del ekosistema, jo morajo ljudje sprejeti. Koga torej zanima servisna mreža? Komu koristi njegova uporaba?
Če razvijate sodobno strežniško programsko opremo, si lahko svojo ekipo v grobem predstavljate kot skupino lastniki storitevki skupaj razvijajo in izvajajo poslovno logiko ter lastniki platforme, razvoj interne platforme, na kateri te storitve delujejo. V majhnih organizacijah so to lahko isti ljudje, a ko podjetje raste, postanejo te vloge bolj izrazite in celo razdeljene na podvloge ... (Tukaj je treba povedati veliko o spreminjajoči se naravi devopsov, organizacijski vpliv mikrostoritev itd.) n. Toda za zdaj vzemimo te opise kot dane).
S tega vidika so lastniki platforme očitni upravičenci storitvenega omrežja. Navsezadnje je končni cilj ekipe platforme ustvariti notranjo platformo, na kateri lahko lastniki storitev izvajajo poslovno logiko in to na način, ki zagotavlja, da so čim bolj neodvisni od mračnih podrobnosti njenega delovanja. Storitvena mreža ne ponuja le zmogljivosti, ki so ključne za doseganje tega cilja, temveč tudi na način, ki lastnikom storitev ne nalaga odvisnosti.
Koristi imajo tudi lastniki storitev, čeprav na bolj posreden način. Cilj lastnika storitve je čim bolj produktiven pri izvajanju logike poslovnega procesa in manj ko se mora obremenjevati z operativnimi težavami, tem bolje. Namesto da bi se morali ukvarjati z izvajanjem, recimo, politik ponovnega poskusa ali TLS, se lahko osredotočijo samo na poslovne cilje in upajo, da bo platforma poskrbela za ostalo. To je za njih velika prednost.
Organizacijske vrednosti takšne delitve med lastniki platform in storitev ni mogoče preceniti. Mislim, da prispeva glavno prispevek k vrednosti storitve mesh.
To lekcijo smo se naučili, ko nam je zgodnji oboževalec Linkerda povedal, zakaj so izbrali servisno mrežo: ker jim je omogočila, da so »minimalno zmanjšali govorjenje«. Tukaj je nekaj podrobnosti: fantje iz enega velikega podjetja so svojo platformo preselili na Kubernetes. Ker je aplikacija obravnavala občutljive podatke, so želeli šifrirati vso komunikacijo v gručah. Vendar je bila situacija zapletena zaradi prisotnosti na stotine storitev in na stotine razvojnih ekip. Možnost, da bi stopili v stik z vsemi in jih prepričali, da v svoje načrte vključijo podporo za TLS, jih ni prav nič veselila. Po namestitvi Linkerda so prenesli Odgovornost od razvijalcev (z vidika katerih so bile to nepotrebne težave) do platformerjev, za katere je bila to prioriteta na najvišji ravni. Z drugimi besedami, Linkerd jim je rešil ne toliko tehnični problem kot organizacijski.
Skratka, servisna mreža je bolj rešitev, ne tehnična, ampak družbeno-tehnični Težave. (Hvala vam za uvedbo tega izraza.)
Bo servisna mreža rešila vse moje težave?
ja Mislim, ne!
Če pogledate tri zgoraj opisane razrede funkcij – zanesljivost, varnost in opazljivost – postane jasno, da storitvena mreža ni popolna rešitev za nobeno od teh težav. Medtem ko lahko Linkerd znova izda zahteve (če ve, da so idempotentne), se ne more odločiti, kaj naj vrne uporabniku, če je storitev trajno odpovedala – te odločitve mora sprejeti aplikacija. Linkerd lahko vodi statistiko uspešnih zahtevkov, vendar ne more vpogledati v storitev in zagotoviti njene interne metrike - aplikacija mora imeti takšna orodja. In čeprav je Linkerd sposoben organizirati mTLS, polne varnostne rešitve zahtevajo veliko več.
Podmnožica funkcij na teh področjih, ki jih ponuja storitvena mreža, se nanaša na značilnosti platforme. S tem mislim na funkcije, ki:
- Neodvisno od poslovne logike. Način, na katerega so izdelani histogrami klicev med Foo in Bar, je popolnoma neodvisen od zakaj Foo pokliče Bar.
- Težko ga je pravilno izvajati. V Linkerdu so ponovni poskusi parametrirani z vsemi vrstami modnih stvari, kot so proračuni za ponovne poskuse (ponovite proračune), saj bo nesofisticiran, neposreden pristop k izvajanju takšnih stvari zagotovo povzročil nastanek tako imenovanega “plaza prošenj” (ponoviti nevihto) in druge težave, značilne za porazdeljene sisteme.
- Najbolj učinkovito, če se nanese enakomerno. Mehanizem TLS je smiseln le, če se uporablja povsod.
Ker so te funkcije implementirane na ravni posrednika (in ne na ravni aplikacije), jih storitvena mreža zagotavlja na platforme, ne aplikacije. Tako ni pomembno, v katerem jeziku so storitve napisane, kakšen okvir uporabljajo, kdo jih je napisal in zakaj. Proxyji delujejo izven vseh teh podrobnosti in temeljna osnova te funkcionalnosti, vključno z nalogami za konfiguracijo, posodabljanje, delovanje, vzdrževanje itd., je izključno na ravni platforme.
Primeri zmogljivosti storitvenega omrežja
Če povzamemo, storitvena mreža ni popolna rešitev za zanesljivost, opazljivost ali varnost. Obseg teh področij zahteva sodelovanje lastnikov storitev, ekip Ops/SRE in drugih subjektov podjetja. Storitvena mreža zagotavlja le »rezino« na ravni platforme za vsako od teh področij.
Zakaj je storitvena mreža postala priljubljena prav zdaj?
Do zdaj se verjetno sprašujete: v redu, če je storitvena mreža tako dobra, zakaj nismo začeli uvajati milijonov posrednikov v skladu pred desetimi leti?
Na to vprašanje obstaja banalen odgovor: pred desetimi leti so vsi gradili monolite in nihče ni potreboval servisne mreže. To je res, vendar po mojem mnenju ta odgovor zgreši bistvo. Še pred desetimi leti se je koncept mikrostoritev kot obetavnega načina za izgradnjo obsežnih sistemov široko razpravljal in uporabljal v podjetjih, kot so Twitter, Facebook, Google in Netflix. Splošno mnenje – vsaj v delih industrije, s katerimi sem prišel v stik – je bilo, da so mikrostoritve »pravi način« za gradnjo velikih sistemov, četudi je to prekleto težko.
Seveda, čeprav so pred desetimi leti obstajala podjetja, ki so upravljala mikrostoritve, niso prilepila posrednikov povsod, kjer so lahko, da bi oblikovala storitveno mrežo. Vendar, če natančno pogledate, so storili nekaj podobnega: veliko teh podjetij je zahtevalo uporabo posebne interne knjižnice za omrežno komunikacijo (včasih imenovane debela odjemalska knjižnica, mastna odjemalska knjižnica).
Netflix je imel Hysterix, Google je imel Stubbyja, Twitter je imel knjižnico Finagle. Finagle je bil na primer obvezen za vsako novo storitev na Twitterju. Obdeloval je tako odjemalsko kot strežniško stran povezav, omogočal ponavljajoče se zahteve, podpiral usmerjanje zahtev, uravnoteženje obremenitve in merjenje. Zagotovil je dosledno raven zanesljivosti in opazljivosti v celotnem nizu Twitterja, ne glede na to, kaj je storitev počela. Seveda je deloval le za jezike JVM in je temeljil na modelu programiranja, ki ga je bilo treba uporabiti za celotno aplikacijo. Vendar pa je bila njegova funkcionalnost skoraj enaka funkciji servisne mreže. (Pravzaprav je bila prva različica Linkerda preprosto Finagle, zavit v proxy obliko.)
Tako pred desetimi leti niso obstajale samo mikrostoritve, ampak tudi posebne proto-service-mesh knjižnice, ki so reševale iste probleme, kot jih danes rešuje service mesh. Vendar sama servisna mreža takrat še ni obstajala. Morala je biti še ena menjava, preden se je pojavila.
In tu se skriva globlji odgovor, skrit v drugi spremembi, ki se je zgodila v zadnjih 10 letih: stroški uvajanja mikrostoritev so dramatično padli. Zgoraj omenjena podjetja, ki so pred desetimi leti uporabljala mikrostoritve – Twitter, Netflix, Facebook, Google – so bila podjetja ogromnega obsega in ogromnih virov. Niso imeli le potrebe, ampak so imeli tudi možnost zgraditi, uvesti in upravljati velike aplikacije, ki temeljijo na mikrostoritvah. Energija in trud, ki so ga inženirji Twitterja vložili v prehod z monolitnega pristopa na pristop mikrostoritev, sta neverjetna. (Po pravici povedano velja tudi dejstvo, da je uspelo.) Tovrstni infrastrukturni manevri so bili takrat za manjša podjetja nemogoči.
Hitro naprej v sedanjost. Danes obstajajo zagonska podjetja, kjer je razmerje med mikrostoritvami in razvijalci 5:1 (ali celo ), še več, z njimi se uspešno spopadajo! Če lahko startup s 5 osebami zlahka upravlja 50 mikrostoritev, potem je nekaj očitno znižalo stroške njihove implementacije.
1500 mikrostoritev v Monzu; vsaka linija je predpisano omrežno pravilo, ki dovoljuje promet
Dramatično znižanje stroškov delovanja mikrostoritev je rezultat enega procesa: vse večja priljubljenost zabojnikov и orkestratorji. Prav to je globok odgovor na vprašanje, kaj je prispevalo k nastanku storitvenega mesha. Ista tehnologija je naredila privlačne storitvene mreže in mikrostoritve: Kubernetes in Docker.
Zakaj? No, Docker rešuje en velik problem – problem pakiranja. S pakiranjem aplikacije in njenih (neomrežnih) odvisnosti med izvajanjem v vsebnik Docker spremeni aplikacijo v zamenljivo enoto, ki jo lahko gostite in izvajate kjer koli. Hkrati močno poenostavi delovanje večjezični Sklad: Ker je vsebnik atomska izvedbena enota, za namene uvajanja in delovanja ni pomembno, kaj je notri, pa naj bo to aplikacija JVM, Node, Go, Python ali Ruby. Samo zaženeš ga in to je to.
Kubernete vse popelje na višjo raven. Zdaj, ko je na voljo na tone "stvari za zagon" in na tone strojev, na katerih jih lahko poganjamo, obstaja potreba po orodju, ki jih lahko poveže med seboj. V širšem smislu daste Kubernetesu veliko vsebnikov in veliko strojev, ki jih preslika enega proti drugemu (seveda je to dinamičen in nenehno spreminjajoč se proces: novi vsebniki se premikajo po sistemu, stroji se zaženejo in ustavijo , itd. Vendar Kubernetes vse to upošteva ).
Ko je Kubernetes konfiguriran, se časovni stroški za uvedbo in delovanje ene storitve malo razlikujejo od stroškov za uvedbo in delovanje desetih storitev (pravzaprav so skoraj enaki za 100 storitev). Dodajte temu vsebnike kot mehanizem za pakiranje, ki spodbuja večjezično izvajanje, in imeli boste množico novih aplikacij, implementiranih v obliki mikrostoritev, napisanih v različnih jezikih – natanko takšno okolje, za katerega je storitvena mreža tako zelo primerna.
Tako smo prišli do odgovora na vprašanje, zakaj je zamisel o storitveni mreži zdaj postala priljubljena: homogenost, ki jo Kubernetes zagotavlja za storitve, neposredno velja za operativne izzive, s katerimi se sooča storitvena mreža. Proxyje zapakirate v vsebnike, Kubernetesu daste nalogo, da jih prilepi kamor koli lahko, in voila! Kot rezultat, dobite storitveno mrežo, medtem ko vse mehanike njene umestitve upravlja Kubernetes. (Vsaj s ptičje perspektive. Seveda je v tem procesu veliko odtenkov.)
Če povzamemo: razlog, da so storitvene mreže postale priljubljene zdaj in ne pred desetimi leti, je ta, da sta Kubernetes in Docker ne le znatno povečala potrebujejo v njem poenostavil implementacijo aplikacij kot sklopov večjezičnih mikrostoritev, a tudi občutno zmanjšal stroški za njegovo delovanje, zagotavljanje mehanizmov za uvajanje in podporo flot proxy prikolic.
Zakaj se toliko govori o servisni mreži?
Opozorilo: V tem delu uporabljam vse vrste predpostavk, ugibanj, izmišljotin in notranjih informacij.
Poiščite »service mesh« in naleteli boste na tono reciklirane nizkokalorične vsebine, čudne projekte in kalejdoskop popačenj, vreden odmevne komore. Vsaka modna nova tehnologija to počne, vendar je v primeru servisne mreže problem še posebej pereč. Zakaj?
No, del tega je moja krivda. Trdo delam za promocijo Linkerda in storitvenega omrežja ob vsaki priložnosti, ki jo dobim prek neštetih objav v blogih in člankov, kot je ta. Ampak nisem tako močan. Da bi resnično odgovorili na to vprašanje, se moramo malo pogovoriti o splošni situaciji. In nemogoče je govoriti o tem, ne da bi omenili en projekt: je odprtokodna storitvena mreža, ki so jo skupaj razvili Google, IBM in Lyft.
(Tri podjetja imajo zelo različne vloge: zdi se, da je vpletenost Lyfta samo po imenu; so avtorji Envoya, vendar ne uporabljajo ali sodelujejo pri razvoju Istia. IBM je vključen in uporablja razvoj Istia. Google je dejavno vključen v razvoj Istia razvoj, vendar ga dejansko ne uporablja, kolikor vem.)
Projekt Istio je znan po dveh stvareh. Prvič, tu je ogromen marketinški napor, ki ga zlasti Google vlaga v njegovo promocijo. Ocenjujem, da je večina ljudi, ki danes poznajo koncept storitvene mreže, prvič izvedela zanj prek Istia. Druga stvar je, kako slabo je bil sprejet Istio. V tej zadevi sem očitno zainteresirana stran, vendar poskušam ostati čim bolj objektiven, še vedno ne morem pomagati , ni zelo izrazit (čeprav ne edinstven: na misel pride systemd, ...) za odprtokodni projekt.
(V praksi se zdi, da ima Istio težave ne le s kompleksnostjo in UX, ampak tudi z zmogljivostjo. Na primer, med V študiji tretje osebe so raziskovalci odkrili situacije, v katerih je bila zakasnitev repa Istia 100-krat višja od Linkerdove, pa tudi situacije s pomanjkanjem virov, kjer je Linkerd še naprej uspešno deloval, medtem ko je Istio popolnoma prenehal delovati.)
Če pustimo ob strani moje teorije o tem, zakaj se je to zgodilo, verjamem, da je izjemno navdušenje okoli mreže storitev razloženo z Googlovim sodelovanjem. In sicer kombinacija naslednjih treh dejavnikov:
- Googlova vsiljiva promocija Istia;
- ustrezen odklonilen, kritičen odnos do projekta;
- nedavni meteorski porast priljubljenosti Kubernetesa, spomini na katerega so še sveži.
Skupaj se ti dejavniki združijo in ustvarijo omamno okolje brez kisika, v katerem je zmožnost razumnega presojanja oslabljena in ostanejo samo čudne sorte. .
Z Linkerdovega vidika je to ... kar bi opisal kot mešan blagoslov. Mislim, super je, da je storitvena mreža vstopila v mainstream na način, kot leta 2016, ko se je Linkerd prvič začel, in res je bilo težko pridobiti ljudi, da bodo pozorni na projekt. Zdaj tega problema ni! Toda slaba novica je, da je krajina storitvene mreže danes tako zmedena, da je skoraj nemogoče razumeti, kateri projekti dejansko spadajo v kategorijo storitvene mreže (kaj šele razumeti, kateri je najprimernejši za določen primer uporabe). To je vsekakor prekinitev dogovora za vse (in vsekakor obstajajo primeri, ko je Istio ali drug projekt bolj primeren kot Linkerd, saj slednji še vedno ni univerzalna rešitev).
Na Linkerdovi strani je bila naša strategija ignorirati hrup, se še naprej osredotočati na reševanje resničnih problemov skupnosti in v bistvu počakati, da se navdušenje umiri. Končno se bo razburjenje poleglo in bomo lahko mirno nadaljevali z delom.
Medtem pa bomo vsi morali malo potrpeti.
Ali bo servisna mreža uporabna zame, skromnega programskega inženirja?
Naslednji vprašalnik vam bo pomagal odgovoriti na to vprašanje:
Ali se ukvarjate samo z implementacijo poslovne logike? V tem primeru vam servisna mreža ne bo koristila. Seveda vas bo to morda zanimalo, vendar v idealnem primeru servisna mreža ne bi smela neposredno vplivati na nič v vašem okolju. Še naprej delajte na tem, za kar ste plačani.
Ali podpirate platformo v podjetju, ki uporablja Kubernetes? Da, v tem primeru potrebujete servisno mrežo (razen če seveda uporabljate K8s samo za zagon monolitne ali paketne obdelave - ampak potem bi rad vprašal, zakaj potrebujete K8s). Verjetno boste na koncu imeli veliko mikrostoritev, ki so jih napisali različni ljudje. Vsi medsebojno delujejo in so povezani v zaplet odvisnosti med izvajanjem, zato morate najti način, kako se spopasti z vsem tem. Uporaba Kubernetesa vam omogoča, da izberete storitveno mrežo »zase«. Če želite to narediti, se seznanite z njihovimi zmožnostmi in funkcijami ter odgovorite na vprašanje, ali je kateri od razpoložljivih projektov primeren za vas (priporočam, da začnete raziskovanje z Linkerdom).
Ste platformno podjetje v podjetju, ki NE uporablja Kubernetes, ampak uporablja mikrostoritve? V tem primeru vam bo servisna mreža koristna, vendar njena uporaba ne bo trivialna. Seveda lahko posnemati delo storitveno mrežo z namestitvijo množice posrednikov, vendar je pomembna prednost Kubernetesa model uvajanja: ročno vzdrževanje teh posrednikov bo zahtevalo veliko več časa, truda in stroškov.
Ste odgovorni za platformo v podjetju, ki dela z monoliti? V tem primeru verjetno ne potrebujete servisne mreže. Če delate z monoliti (ali celo zbirkami monolitov), ki imajo dobro definirane in redko spreminjajoče se vzorce interakcij, vam bo storitvena mreža lahko malo ponudila. Zato ga lahko preprosto ignoriraš in upaš, da bo izginilo kot slabe sanje...
Zaključek
Verjetno storitvenega mesha še vedno ne bi smeli imenovati "najbolj razglašena tehnologija na svetu" - ta dvomljiva čast verjetno pripada Bitcoinu ali AI. Verjetno je med prvih pet. Toda če prerežete plasti hrupa, postane jasno, da storitvena mreža prinaša resnične koristi tistim, ki gradijo aplikacije na Kubernetesu.
Rad bi, da preizkusite Linkerd - namestite ga v gručo Kubernetes (ali celo Minikube na prenosnem računalniku) , in sami vidite, o čem govorim.
FAQ
— Če prezrem servisno mrežo, ali bo izginila?
— Moram vas razočarati: servisna mreža je z nami že dolgo.
- Vendar NOČEM uporabljati servisne mreže!
- No, saj ni potrebno! Preberite moj zgornji vprašalnik, da boste razumeli, ali bi se morali seznaniti vsaj z njegovimi osnovami.
— Ali ni to dobra stara ESB/vmesna oprema z novo omako?
— Storitvena mreža se ukvarja z operativno logiko, ne s semantično. poslovni avtobus (). Ohranjanje te ločitve pomaga servisni mreži preprečiti isto usodo.
— Kako se storitvena mreža razlikuje od prehodov API?
— Na to temo obstaja milijon člankov. Samo poguglajte.
— Envoy je storitvena mreža?
- Ne, Envoy ni storitvena mreža, je proxy strežnik. Uporablja se lahko za organizacijo storitvenega omrežja (in še veliko več - je posrednik za splošne namene). Vendar sama po sebi ni servisna mreža.
— Network Service Mesh je storitveno omrežje?
- Ne. Kljub imenu, to ni servisna mreža (kako se vam zdijo marketinški čudeži?).
— Ali bo storitvena mreža pomagala pri mojem reaktivnem asinhronem sistemu, ki temelji na čakalni vrsti sporočil?
- Ne, servisna mreža vam ne bo pomagala.
— Katero servisno mrežo naj uporabim?
- , brez pameti.
- Članek je zanič! / Avtor vabljen!
— Delite povezavo do njega z vsemi prijatelji, da si ga bodo lahko ogledali!
Zahvala
Kot ste morda uganili iz naslova, je ta članek navdihnila fantastična razprava Jaya Krepsa "" Jaya sem spoznal pred desetimi leti, ko sem ga intervjuval na Linked Inu in od takrat me navdihuje.
Čeprav se rad imenujem "Linkerd razvijalec", je v resnici bolj vzdrževalec datoteke README.md v projektu. Danes se dela na Linkerdu , , ljudi in tega projekta ne bi bilo brez sodelovanja čudovite skupnosti sodelavcev in uporabnikov.
In končno, posebna zahvala ustvarjalcu Linkerda, (primus med pares), ki se je skupaj z mano pred mnogimi leti brezglavo potopil v vso to zmešnjavo s servisnimi mrežami.
PS od prevajalca
Preberite tudi na našem blogu:
- «»;
- «»;
- «»;
- «»;
- «".
Vir: www.habr.com