Napomena za prijevod.: Service mesh — pojam koji još uvijek nema ustaljen prevod na hrvatski jezik (prije više od 2 godine predložili smo izraz «mreža za servise», a nešto kasnije neki kolege su počeli aktivno promovirati izraz «servisno sito»). Stalni razgovori o ovoj tehnologiji doveli su do situacije u kojoj su se marketinški i tehnički aspekti pretjerano isprepleli. Ovaj izvrsni materijal od jednog od autora originalnog termina ima za cilj unijeti jasnoću za inženjere i ne samo za njih.
Strip od
Uvod
Ako ste inženjer-programer koji radi negdje u području backend sustava, termin «service mesh» vjerojatno je već čvrsto ukorijenjen u vašem umu posljednjih nekoliko godina. Zbog neobičnog spleta okolnosti, ova fraza sve više osvaja industriju, a hype i s njom povezane reklamne ponude nagomilavaju se poput snježne kugle koja se spušta niz padinu i ne pokazuje nikakve znakove usporavanja.
Service mesh je nastala u mutnim, pristranim vodama ekosustava cloud native. Nažalost, to znači da značajan dio rasprava povezanih s njom varira od «niskokalorične brbljavosti» do — koristeći tehnički termin — otvorene gluposti. No, ako se odstrani sav šum, može se otkriti da service mesh ima sasvim stvarnu, definite i važnu funkciju.
U ovoj publikaciji pokušat ću upravo to: predstaviti pošteni, duboki, inženjerski orijentirani vodič o service mesh. Namjeravam odgovoriti ne samo na pitanje: «Što je to?», — nego i «Zašto?», kao i «Zašto baš sada?». Na kraju, pokušat ću dočarati zašto je (po mom mišljenju) ova tehnologija izazvala toliku ludnicu, što je samo po sebi zanimljiva priča.
Tko sam ja?
Pozdrav svima! Zovem se . Ja sam jedan od osnivača — prvog projekta service mesh i projekta koji je odgovoran za pojavu termina service mesh kao takvog (oprosti, dečki!). (Prim. prev.: Usput, na samom početku pojave ovog termina, prije više od 2,5 godine, već smo prevodili rani materijal istog autora pod nazivom «».) Također vodim — startup koji se bavi stvaranjem tako fantastičnih service mesh stvari kao što su Linkerd i .
Vjerojatno pretpostavljate da imam pristrano i subjektivno mišljenje o ovoj temi. Međutim, potrudit ću se da minimiziram tendencioznost (osim u jednom dijelu: „Zašto se toliko razgovara o service mesh-u?”, — u kojem ću ipak podijeliti svoje pristrane ideje). Također ću učiniti sve što je u mojoj moći da ovo vodstvo bude što objektivnije. U konkretnim primjerima većinom ću se oslanjati na iskustvo Linkerd-a, istovremeno ukazujući na poznate razlike (ako ih ima) u implementaciji drugih tipova service mesh-a.
U redu, vrijeme je za poslastice.
Što je service mesh?
Unatoč cijelom hajpu, strukturalno je service mesh prilično jednostavan. To je samo skup userspace-proxies smještenih „blizu” servisa (o tome ćemo malo razgovarati o tome što znači „blizu”), uz skup upravljačkih procesa. Proxiji zajedno nazivamo data plane, a upravljačke procese nazivamo control plane. Data plane presreće pozive između servisa i radi s njima „različite stvari”; control plane, соответственно, koordinira ponašanje proxija i osigurava vaš pristup API-ju, omogućavajući vam da manipulirate mrežom i mjerenja kao cjelinu.
Što su ti proxiji? To su TCP-proxiji kategorije „Layer 7-aware” (tj. „svjesni” 7. razine OSI modela) poput HAProxy-a i NGINX-a. Možete odabrati proxija po svom ukusu; Linkerd koristi proxija napisanog u Rustu, ne previše maštovito nazvanog . Iznad svega, izradili smo ga posebno za service mesh. Ostali mesh-evi preferiraju druge proxije (Envoy je čest izbor). No, izbor proxija je samo pitanje implementacije.
Što ti proxy serveri rade? Očigledno, proxy primaju pozive do i od servisa (strogo govoreći, izvršavaju funkciju proxy-a i obratnog proxy-a, obrađujući dolazne i odlazne pozive). A oni implementiraju set funkcija usmjerenih na pozive između servisa. Ovaj fokus na promet između servisa razlikuje service mesh-proxije od, recimo, API gateway-a ili ingress-proxija (potonji se fokusiraju na pozive dolazne u klaster iz vanjskog svijeta). (Napomena za prijevod.: usporedba postojećih Ingress kontrolera za Kubernetes, od kojih mnogi koriste već spomenuti Envoy, pogledajte u .)
Dakle, razjasnili smo data plane. Control plane je jednostavniji: to je skup komponenti koje osiguravaju svu mehaniku potrebnu da data plane funkcionira usklađeno, uključujući otkrivanje usluga, izdavanje TLS certifikata, agregaciju metrika itd. Data plane obavještava control plane o svom ponašanju; zauzvrat, control plane pruža API koji omogućuje promjenu i praćenje ponašanja data plane kao jedinstvene cjeline.
Ispod je prikazana shema control plane i data plane u Linkerd-u. Kao što se može vidjeti, control plane uključuje nekoliko različitih komponenti, uključujući primjer Prometheus-a koji prikuplja metrike s proxy servera, kao i druge komponente, poput destination (otkrivanje usluga), identity (centar za certificiranje, CA) i public-api (endpoints za web i CLI). Nasuprot tome, data plane sastoji se od jednostavnog linkerd-proxy uz primjer aplikacije. To je samo logička shema; u stvarnim okruženjima prilikom implementacije možete imati tri replikacije svake komponente control plane i stotine ili tisuće proxy-a u data plane.
(Plavi pravokutnici u ovoj shemi simboliziraju granice podova Kubernetes-a. Vidljivo je da se kontejneri s linkerd-proxy nalaze u istom pod-u s kontejnerima aplikacije. Ova shema poznata je kao sidecar-kontejner..)
Arhitektura service mesh ima nekoliko važnih posljedica. Prvo, s obzirom na to da je zadatak proxy-a da presreće pozive između usluga, service mesh ima smisla samo ako je vaša aplikacija stvorena na određenim skupovima usluga. Mesh možete može se koristiti s monolitima, ali to je očito suvišno za jedan jedini proxy, a njezina funkcionalnost vjerojatno neće biti tražena.
Druga važna posljedica je ta što service mesh zahtijeva ogromnu količinu proxy-a. U stvarnosti, Linkerd priključuje linkerd-proxy na svaki primjerak svake usluge (druge implementacije dodaju proxy na svaki čvor/domenu/virtualnu mašinu. U svakom slučaju, to je znatna količina). Ova aktivna upotreba proxy-ja nosi određene dodatne komplikacije:
- Proxy u data plane moraju biti brzi, s obzirom na to da se za svaki poziv odnosi nekoliko upita prema proxy-ju: jedan na strani klijenta, jedan na strani poslužitelja.
- Također, proxy moraju biti mali i lagani.. Svaka će trošiti resurse memorije i CPU-a, a ta potrošnja će linearno rasti s aplikacijom.
- Trebat će vam mehanizam za implementaciju i ažuriranje velike količine proxy-a. Raditi to ručno nije opcija.
Općenito, service mesh izgleda ovako (barem iz ptičje perspektive): postavljate hrpu userspace-proxy-a koji 'nešto rade' s unutarnjim, međuservisnim prometom, a koristite control plane za praćenje i upravljanje njima.
Došlo je vrijeme za pitanje 'Zašto?'
Zašto je potreban service mesh?
Onima koji se prvi put susreću s idejom service mesh može biti oprošteno ako osjećaju laganu tremu. Konstrukcija service mesh znači da ne samo da će povećati latenciju u aplikaciji, nego će također trošiti resurse i dodati hrpu novih mehanizama u infrastrukturu. Prvo instalirate service mesh, a zatim iznenada otkrijete da treba održavati stotine (ako ne i tisuće) proxy-a. Pitamo se, tko će dobrovoljno to učiniti?
Odgovor na ovo pitanje sastoji se od dva dijela. Prvo, operativni troškovi povezani s implementacijom tih proxy-a mogu se značajno smanjiti zahvaljujući nekim promjenama koje se događaju u ekosustavu (više o tome kasnije).
Drugo, takva struktura zapravo je odličan način za uvođenje dodatne logike u sustav. I ne samo zato što se putem service mesh može dodati mnoštvo novih funkcija, nego i zato što se to može učiniti bez ometanja ekosustava. Zapravo, cijela model service mesh temelji se na ovoj pretpostavci: u multiservisnom sustavu, bez obzira na to što rade odvojeni servisi, promet između njih savršena je točka za dodavanje funkcionalnosti.
Na primjer, u Linkerd (kao i u većini mesh-ova) funkcionalnost je uglavnom usmjerena na HTTP pozive, uključujući HTTP/2 i gRPC*. Funkcionalnost je prilično bogata - može se podijeliti u tri klase:
- Funkcije povezane s pouzdanosti.Ponovni zahtjevi, vremenska ograničenja, kanarinski pristup (podjela/preusmjeravanje prometa) itd.
- Funkcije povezane s monitoringom.Agregacija metričkih pokazatelja uspješnosti, latencija i volumeni zahtjeva za svaku uslugu ili pojedinačne smjerove; izrada topoloških karata servisa itd.
- Funkcije povezane s sigurnošću.Mutual TLS, kontrola pristupa itd.
* S gledišta Linkerd gRPC se praktički ne razlikuje od HTTP/2: samo se u korisnom opterećenju koristi protobuf. S gledišta programera, ove dvije stvari, naravno, se razlikuju.
Mnogi od ovih mehanizama rade na razini zahtjeva (otuda i „L7-proxy”). Na primjer, ako usluga Foo šalje HTTP-poziv usluzi Bar, linkerd-proxy s strane Foo može provesti inteligentno uravnoteženje opterećenja i usmjeravati pozive s Foo na instance Bar ovisno o zabilježenoj latenciji; može ponoviti zahtjev ako je potrebno (i ako je idempotentan); može zabilježiti kod odgovora i vrijeme čekanja, itd. Na sličan način linkerd-proxy s strane Bar može odbiti zahtjev ako nije odobren ili je prekoračen limit zahtjeva; može zabilježiti latenciju s svoje strane, itd.
Proxy mogu „nešto raditi” i na razini veze. Na primjer, linkerd-proxy s strane Foo može inicirati TLS-ovu vezu, a linkerd-proxy s strane Bar može je prekinuti, i obje strane mogu provjeravati TLS-certifikate jedna druge*. To osigurava ne samo enkripciju između usluga, već i kriptografski siguran način identifikacije usluga: Foo i Bar mogu „dokumentirati” da su oni to za što se predstavljaju.
* „Jedna drugoj” znači da se također provjerava certifikat klijenta (mutual TLS). U „klasičnom” TLS-u, na primjer, između preglednika i poslužitelja, obično se provjerava certifikat samo jedne strane (poslužitelja).
Bez obzira na to rade li na razini zahtjeva ili veza, važno je naglasiti da sve funkcionalnosti service mesh imaju operativni karakter. Linkerd nije sposoban transformirati semantiku korisnog opterećenja — na primjer, dodavati polja u JSON-fragment ili vršiti izmjene u protobuf. O ovom važnom aspektu ćemo govoriti kasnije, kada budemo raspravljali o ESB i middleware.
Ovo je skup funkcionalnosti koje nudi service mesh. Postavlja se pitanje: zašto ih ne implementirati izravno u aplikaciji? I zašto se uopće zamarati proxyjem?
Zašto je service mesh dobra ideja
Iako mogućnosti service mesh hvataju maštu, njena osnovna vrijednost zapravo leži ne u funkcijama. Na kraju krajeva, mi možemo provedi ih izravno u aplikaciju (kasnije ćemo vidjeti da je to bio izvor service mesh). Ako pokušate izraziti ovu misao jednom rečenicom, vrijednost service mesh-a je sljedeća: osigurava funkcije koje su od kritične važnosti za rad modernog poslužiteljskog softvera, dosljedne za cijeli stog i neovisne o kodu aplikacije.
Analizirajmo ovu rečenicu.
«Funkcije koje su od kritične važnosti za rad modernog poslužiteljskog softveraAko razvijate transakcijsku poslužiteljsku aplikaciju povezanu s javnim internetom, koja prima zahtjeve iz vanjskog svijeta i odgovara na njih u kratkom vremenu — na primjer, web-aplikaciju, API-poslužitelj, ili većinu drugih modernih aplikacija — i ako je implementirate kao skup usluga koje međusobno sinkrono komuniciraju, i ako stalno modernizirate ovaj softver dodajući nove mogućnosti, i ako ste prisiljeni održavati ovu sistemu operativnom tijekom modifikacije — u tom slučaju, čestitam, bavite se razvojem modernog poslužiteljskog softvera. I sve te divne funkcije koje su navedene iznad zapravo su kritično važne za vas. Aplikacija mora biti pouzdana, sigurna, i morate imati mogućnost nadgledanja onoga što radi. Upravo ta pitanja pomaže riješiti service mesh.
(U redu, u prethodni paragraf se ipak provukla moja uvjerenja da je ovaj pristup moderan način izrade poslužiteljskog softvera. Drugi preferiraju razvijati monolite, 'reaktivne mikroservise' i druge stvari koje ne spadaju pod gornju definiciju. Ti ljudi zasigurno imaju svoje mišljenje koje je drugačije od mog. Svoje strane, smatram da 'nisu u pravu' — iako u svakom slučaju service mesh za njih nije previše korisna).
«Dosljedno za cijeli stogFunkcije koje pruža service mesh nisu samo kritično važne. One se primjenjuju na sve usluge u aplikaciji, neovisno o jeziku na kojem su napisane, kojoj se frameworku koriste, tko ih je napisao, kako su implementirane i svih ostalih nijansi njihove izrade i primjene.
«Neovisno o kodu aplikacijeNa kraju, service mesh ne samo da nudi jedinstvene funkcionalnosti za cijelu stog — ona to čini na način koji ne zahtijeva izmjene aplikacije. Temeljna osnova funkcionalnosti service mesh, uključujući zadatke vezane uz konfiguraciju, ažuriranje, operativnost, održavanje itd., nalazi se isključivo na razini platforme i neovisna je o aplikaciji. Aplikacija se može mijenjati bez utjecaja na service mesh. S druge strane, service mesh se može mijenjati bez ikakvog sudjelovanja aplikacije.
Ukratko, service mesh ne samo da osigurava vitalne funkcije, već to čini globalno, dosljedno i neovisno o aplikaciji. Stoga, iako se funkcionalnost service mesh može implementirati u kodu servisa (na primjer, u obliku biblioteke uključene u svaki servis), ovaj pristup neće osigurati uniformnost i neovisnost, što su od neprocjenjive vrijednosti za service mesh.
I sve što je potrebno je dodati gomilu proxy-a! Obvezuju se, vrlo brzo ćemo razmotriti operativne troškove vezane uz dodavanje tih proxy-a. No prvo, hajde da se zaustavimo i pogledamo ovu ideju o neovisnosti iz perspektive različitih ljudi.
Kome pomaže service mesh?
Kako god to bilo nezgodno, da bi neka tehnologija postala važan dio ekosustava, mora je prihvatiti ljude. Tako tko je zapravo zainteresiran za service mesh? Tko profitira od njegove upotrebe?
Ako razvijate moderno serversko softversko rješenje, možete približno zamisliti svoj tim kao grupu vlasnika servisa, koji zajedno razvijaju i implementiraju poslovnu logiku, i vlasnika platforme, koji se bave razvojem interne platforme na kojoj ti servisi rade. U manjim organizacijama mogu biti iste osobe, ali s rastom kompanije, ove uloge obično postaju jasnije i čak se dijele na podrole... (Ovdje se može puno reći o promjenjivoj prirodi devops-a, organizacijskom utjecaju mikroservisa itd. No, za sada prihvatimo ove opise kao danost).
Iz ove perspektive, očiti korisnici usluge mesh su vlasnici platforme. Na kraju krajeva, cilj tima na platformi je izgraditi unutarnju platformu na kojoj vlasnici usluga mogu implementirati poslovnu logiku i to na način koji osigurava njihovu maksimalnu neovisnost od mračnih detalja njezine eksploatacije. Usluga mesh ne samo da nudi mogućnosti koje su kritični za postizanje ovog cilja: ona to čini na način koji, zauzvrat, ne nameće ovisnosti vlasnicima usluga.
Vlasnici usluga također imaju koristi, iako na neizravniji način. Cilj vlasnika usluge je biti što produktivniji u implementaciji logike poslovnog procesa, a što manje moraju brinuti o pitanjima eksploatacije, to bolje. Umjesto da se bave implementacijom, recimo, politika ponovljenih zahtjeva ili TLS-a, oni se mogu isključivo fokusirati na poslovne zadatke i nadati se da će platforma brinuti o svemu ostalom. Ovo je velika prednost za njih.
Organizacijsku vrijednost takve podjele između vlasnika platformi i usluga teško je precijeniti. Mislim da ona doprinosi glavnog vrijednosti usluge mesh.
To smo naučili kada nam je jedan od prvih obožavatelja Linkerd-a rekao zašto su odabrali uslugu mesh: jer im je omogućila da "svedu razgovor na minimum". Evo nekoliko detalja: ljudi iz jedne velike tvrtke migrirali su svoju platformu u Kubernetes. Kako je aplikacija radila s povjerljivim informacijama, htjeli su šifrirati sve komunikacije u klasterima. Međutim, situacija se komplicirala s prisutnošću stotina usluga i stotina timova razvojnih inženjera. Perspektiva kontaktiranja svih i uvjeravanje da uključe podršku za TLS u svoje planove nije ih nimalo obradovala. Instaliranjem Linkerd-a, prenijeli su odgovornost s razvojnih inženjera (za koje su to bili dodatni opravci) na vlasnike platforme, za koje je to bio prioritet najvišeg nivoa. Drugim riječima, Linkerd je za njih rješavao više organizacijski, nego tehnički problem.
Ukratko, usluga mesh je, prije svega, rješenje ne tehničkog, već socio-tehničkog problema. (Hvala na upoznavanju s ovim terminom.)
Hoće li mi usluga mesh riješiti sve probleme?
Da. U smislu, ne!
Ako pogledamo tri klase funkcija koje su navedene iznad: pouzdanost, sigurnost i promatranje, postaje jasno da service mesh nije potpuno rješenje za niti jedan od tih problema. Iako Linkerd može slati ponovne zahtjeve (ako zna da su idempotentni), ne može donositi odluke o tome što korisniku vratiti ako servis potpuno padne — takve odluke mora donositi aplikacija. Linkerd može pratiti statistiku uspješnih zahtjeva, no ne može zaviriti u servis i pružiti njegove unutarnje metrike — takva vrsta alata treba biti u aplikaciji. I iako Linkerd može organizirati mTLS, potpuna rješenja u osiguranju sigurnosti zahtijevaju mnogo više.
Podskup funkcija u tim područjima, koje nudi service mesh, odnosi se na funkcije platforme. Pod tim mislim na funkcije koje:
- Nisu povezane s poslovnom logikom. Način na koji se grade histogrami poziva između Foo i Bar potpuno je neovisan o tome, zašto Foo poziva Bar.
- Teško je to ispravno implementirati. U Linkerd-u ponovne pokušaje parametriziraju razne složene stvari poput proračuna ponovnih pokušaja (retry budgets), budući da jednostavan pristup u implementaciji takvih stvari zasigurno dovodi do pojave takozvanih "lavina zahtjeva" (retry storm) i drugih problema karakterističnih za distribuirane sustave.
- Najefikasniji su kada se primjenjuju dosljedno. Mehanizam TLS ima smisla samo kada se koristi svugdje.
Budući da su te funkcije implementirane na razini proxy-a (a ne na razini aplikacije), service mesh ih pruža na razini platforme, a ne aplikacije. Tako da nije važno na kojem jeziku su servisi napisani, koji framework koriste, tko ih je napisao i zašto. Proxy-evi rade izvan svih tih detalja, a osnovna osnova te funkcionalnosti, uključujući zadatke oko konfiguracije, ažuriranja, eksploatacije, održavanja itd., leži isključivo na razini platforme.
Primjeri mogućnosti service mesh
Zaključno, želim reći da service mesh nije potpuno rješenje za pouzdanost, promatranje ili sigurnost. Opseg ovih područja zahtijeva neizostavno sudjelovanje vlasnika usluga, Ops/SRE timova i drugih subjekata unutar tvrtke. Service mesh pruža samo „rez“ na razini platforme za svako od ovih područja.
Zašto je service mesh postala popularna baš sada?
Vjerojatno se sada pitate: dobro, ako je service mesh tako dobra, zašto nismo počeli implementirati milijune proxyja u stogu prije deset godina?
Ima jedno trivijalno objašnjenje za ovo pitanje: prije deset godina svi su gradili monolite, a service mesh nikome nije bila potrebna. To je istina, ali po mom mišljenju, u tom odgovoru gubi se suština. Čak i prije deset godina, koncept mikroslužbi kao perspektivnog načina izgradnje velikih sustava široko se raspravljao i primjenjivao u tvrtkama poput Twittera, Facebooka, Googla i Netflixa. Opće mišljenje — barem u onim dijelovima industrije s kojima sam imao kontakt — bilo je da su mikroslužbe „ispravan način“ za izgradnju velikih sustava, čak i ako je to bilo strašno teško.
Naravno, iako su prije deset godina postojale tvrtke koje su koristile mikroslužbe, nisu jednostavno umetale proxyje gdje god su mogle, kako bi stvorile service mesh. Međutim, ako se bolje pogleda, radili su nešto slično: u mnogim od tih tvrtki bilo je propisano korištenje posebne interne biblioteke za mrežnu interakciju (ponekad nazvane bibliotekom debelog klijenta, fat client library).
Netflix je imao Hysterix, Google je imao Stubby, Twitter je imao biblioteku Finagle. Finagle, primjerice, bila je obavezna za svaku novu uslugu na Twitteru. Upravljala je i klijentom i serverom vezama, omogućavala ponovne zahtjeve, podržavala usmjeravanje zahtjeva, ravnotežu opterećenja i mjerenje. Osiguravala je dosljednu razinu pouzdanosti i promatranja za cijeli Twitterov stog, bez obzira na to čime se određena usluga bavila. Naravno, radila je samo za JVM jezike i temeljila se na programskom modelu koji se morao koristiti za cijelu aplikaciju. Međutim, njene funkcionalnosti bile su gotovo jednake onima u service mesh. (Prva verzija Linkerd zapravo je bila Finagle, omotana u oblik proxy-a.)
Prije deset godina postojali su ne samo mikroservisi, već i posebne proto-service-mesh biblioteke koje su rješavale iste probleme koje danas rješava service mesh. Međutim, service mesh tada nije postojala. Trebala se dogoditi još jedna promjena prije nego što se pojavila.
I ovdje leži dublji odgovor, skriven u još jednoj promjeni koja se dogodila u posljednjih 10 godina: došlo je do naglog smanjenja troškova implementacije mikroservisa. Tvrtke koje su koristile mikroservise prije deset godina - Twitter, Netflix, Facebook, Google - bile su tvrtke ogromne veličine i resursa. Nisu imale samo potrebu, već i mogućnost stvaranja, implementacije i održavanja velikih aplikacija temeljenih na mikroservisima. Energija i trud koje su inženjeri Twittera uložili u prelazak sa monolitnog na mikroservisni pristup jednostavno su nevjerojatni. (Iskreno, kao i to da je to uspjelo.) Takve infrastrukturalne manevre tada su bile nemoguće za manje tvrtke.
Pogledajmo sada. Danas postoje startupi gdje je omjer mikroservisa i developera 5:1 (ili čak ), i više od toga, uspješno se nose s njima! Ako startup od 5 ljudi može neupitno upravljati 50 mikroservisa, znači da je nešto očito smanjilo troškove njihove implementacije.
1500 mikroservisa u Monzu; svaka linija - propisano mrežno pravilo koje omogućuje promet
Naglo smanjenje troškova upravljanja mikroservisima rezultat je jednog procesa: rasta popularnosti kontejnera i orkestratora. To je duboki odgovor na pitanje što je pridonijelo pojavi service mesh-a. Ista tehnologija učinila je privlačnima i service mesh i mikroservise: Kubernetes i Docker.
Zašto? Pa, Docker rješava jedan veliki problem - problem pakiranja. Pakiranjem aplikacije i njenih (ne-mrežnih) runtime zavisnosti u kontejner, Docker pretvara aplikaciju u zamjenjivu jedinicu koju možete postaviti i pokrenuti bilo gdje. U isto vrijeme, značajno pojednostavljuje upravljanje višelingvnim stog: budući da je kontejner atomska jedinica izvršavanja, za svrhe implementacije i rada nije važno što se nalazi unutar njega, bilo da je to aplikacija na JVM-u, Nodeu, Gou, Pythonu ili Rubyu. Jednostavno ga pokrećete i to je to.
Kubernetes sve podiže na novu razinu. S obzirom na to da postoji hrpa 'izvršivih stavki' i mnogo strojeva na kojima ih možete pokrenuti, javlja se potreba za alatom koji može uskladiti jedno s drugim. U širem smislu, dajete Kubernetesu mnoštvo kontejnera i mnoštvo strojeva, a on ih usklađuje međusobno (naravno, to je dinamičan i stalno promjenjiv proces: novi kontejneri se kreću kroz sustav, strojevi se pokreću i zaustavljaju itd. Međutim, Kubernetes sve to uzima u obzir).
Nakon postavljanja Kubernetesa, vremenski troškovi implementacije i rada jedne usluge slabo se razlikuju od troškova kako za jednu, tako i za deset usluga (zapravo su praktički identični i za 100 usluga). Dodajte tome kontejnere kao mehanizam pakiranja koji potiče višejezičnu implementaciju i dobit ćete mnogo novih aplikacija realiziranih u obliku mikroservisa, napisanih na različitim jezicima — upravo onakvu okolinu za koju je service mesh vrlo pogodna.
Dakle, došli smo do odgovora na pitanje zašto je ideja service mesh postala popularna upravo sada: ujednačenost koju Kubernetes osigurava za usluge izravno se primjenjuje na operativne zadatke pred service mesh. Pakirate proxy u kontejnerima, predajete Kubernetesu zadatak da ih zalijepi gdje god može, i voila! Na kraju dobijate service mesh, dok je cijela mehanika njezine implementacije pod upravom Kubernetesa. (Barem iz ptičje perspektive. Naravno, u tom procesu postoji mnogo nijansi.)
U zaključku: razlog zašto je service mesh postala popularna upravo sada, a ne prije deset godina, je taj što su Kubernetes i Docker ne samo značajno povećali potrebne za to, olakšavajući implementaciju aplikacija kao skupova višejezičnih mikroservisa, već su i znatno smanjili troškove za njezin rad, osiguravajući mehanizme za implementaciju i podršku parku sidecar-proxy.
Zašto se toliko priča o service mesh?
Upozorenje: u ovom odjeljku se oslanjam na razne pretpostavke, nagađanja, izmišljotine i unutarnje informacije.
Kada pretražujete izraz „service mesh“, naići ćete na hrpu preraditi niskokaloričnog sadržaja, čudnih projekata i kaleidoskopa iskrivljenja dostojnih eho komore. Ova pojava je svojstvena svakoj novoj i popularnoj tehnologiji, ali u slučaju service mesha, problem je posebno izražen. Zašto?
Pa, djelomično je to moja krivica. Uložio sam sve napore da promoviram Linkerd i service mesh kad god je to bilo moguće, putem bezbrojnih objava u blogovima i članaka poput ovog. No, nisam toliko moćan. Da bih doista odgovorio na ovo pitanje, potrebno je malo razgovarati o općoj situaciji. A o tome se ne može govoriti a da se ne spomene jedan projekt: — open-source service mesh razvijan u suradnji Googlea, IBM-a i Lyft-a.
(Ova tri poduzeća imaju potpuno različite uloge: sudjelovanje Lyft-a izgleda kao da se svodi na samo ime; oni su autori Envoy-a, ali ne koriste Istio niti sudjeluju u njegovom razvoju. IBM sudjeluje u razvoju Istio i koristi ga. Google aktivno sudjeluje u razvoju Istio, ali, koliko mogu reći, zapravo ga ne koristi.)
Projekt Istio ističe se s dvije značajke. Prvo, to su ogromni marketinški napori koje Google, posebno, ulaže u njegovo promoviranje. Prema mojim procjenama, većina ljudi koji su upoznati s koncepcijom service mesha trenutno su prvi put čuli za nju zahvaljujući Istio-u. Druga značajka je koliko je Istio loše prihvaćen. U ovom pogledu sam, očigledno, zainteresirana strana, ali pokušavajući ostati što objektivniji, ne mogu a da ne , nije baš karakterističan (iako nije ni jedinstven: na pamet mi pada systemd, …) za open source projekt.
(U praksi, čini se da Istio ima probleme ne samo s kompleksnošću i UX-om, već i s performansama. Na primjer, tijekom , koju je izvršila treća strana, stručnjaci su otkrili situacije u kojima su repovi kašnjenja (tail latency) Istio bili 100 puta veći od sličnog pokazatelja za Linkerd, kao i situacije s nedostatkom resursa, gdje je Linkerd nastavio uspješno funkcionirati, dok je Istio potpuno prestajao raditi.)
Ostavljajući po strani svoje teorije o tome zašto se to dogodilo, smatram da je prekomjerno uzbuđenje oko service mesh-a objašnjeno upravo sudjelovanjem Googlea. Točnije, kombinacijom sljedeća tri faktora:
- nametljiva promocija Istio od strane Googlea;
- odgovarajuće neodobravanje i kritički stav prema projektu;
- nedavni nagli porast popularnosti Kubernetesa, čije se uspomene još uvijek svježe.
Zajedno, ti faktori stvaraju neku vrstu omamljivačkog, bezkisličnog okruženja u kojem sposobnost racionalnog prosudbe oslabi, a preostaje samo čudesna vrsta .
Iz perspektive Linkerda, to bih opisao kao dvojbeno dobro. Mislim, divno je da je service mesh ušao u mainstream — što nije bilo 2016. godine, kada se Linkerd tek pojavio i bilo je zaista teško privući pažnju oko projekta. Sada takav problem ne postoji! No, loše je što je situacija s service mesh-om danas toliko zamršena da je gotovo nemoguće shvatiti koji projekti se doista svrstavaju u kategoriju service mesh (da ne spominjemo razumijevanje koji od njih najbolje odgovara određenom slučaju korištenja). To sigurno ometaju sve (i, definitivno, u nekim slučajevima Istio ili drugi projekt mogu bolje odgovarati od Linkerda, s obzirom da ovaj posljednji nije univerzalno rješenje).
Iz perspektive Linkerda, naša strategija bila je ignorirati buku, nastaviti se fokusirati na rješavanje stvarnih problema zajednice i, u osnovi, čekati da uzbuđenje prođe. Na kraju, hype će splasnuti, i moći ćemo mirno nastaviti raditi.
No, svi ćemo morati malo izdržati.
Hoće li mi service mesh koristiti, skromnom softverskom inženjeru?
Ovaj će upitnik pomoći odgovoriti na to pitanje:
Bavite li se isključivo implementacijom poslovne logike? U tom slučaju, service mesh vam neće biti koristan. Naravno, možete se njime zanimati, ali idealno, service mesh ne bi trebala izravno utjecati na bilo što u vašem okruženju. Nastavite raditi ono za što ste plaćeni.
Pružate li podršku platformi u tvrtki koja koristi Kubernetes? Da, u tom slučaju service mesh vam je potrebna (naravno, ako ne koristite K8s samo za pokretanje monolita ili serijske obrade — ali tada bih vas želeo pitati zašto vam je K8s). Verovatno ćete se naći u situaciji s brojnim mikroservisima koje su napisali različiti ljudi. Svi oni međusobno komuniciraju i povezani su u klupko runtime zavisnosti, a vi trebate pronaći način kako se nositi s tim. Korišćenje Kubernetesa omogućava vam da odaberete service mesh koji odgovara vašim potrebama. Za to se upoznajte s njihovim mogućnostima i karakteristikama i odgovorite na pitanje, odgovara li vam neki od dostupnih projekata (preporučujem da započnete istraživanje s Linkerd).
Radite na platformi u kompaniji koja NE koristi Kubernetes, ali koristi mikroservise? U tom slučaju će vam service mesh biti od koristi, ali njeno korišćenje neće biti jednostavno. Naravno, možete imitirati funkcionalnost service mesh-a postavljanjem velikog broja proxy-a, ali važna prednost Kubernetesa je upravo model implementacije: održavanje tih proxy-a ručno će zahtevati mnogo više vremena, truda i troškova.
Da li ste odgovorni za platformu u kompaniji koja radi s monolitima? U tom slučaju, service mesh vam verovatno nije potrebna. Ako radite s monolitima (ili čak s setovima monolitnih aplikacija) koji imaju jasno definisane i retko menjane obrasce interakcije, tada service mesh malo može ponuditi. Tako da je možete jednostavno ignorisati i nadati se da će nestati kao loš san…
Zaključak
Verovatno, service mesh ipak ne treba nazvati "najvećom hype tehnologijom na svetu" — tu sumnjivu čast verovatno pripada Bitcoin-u ili AI. Možda je u prvih pet. No, ako se probijete kroz slojeve buke i šuma, postaje jasno da service mesh donosi pravu korist onima koji kreiraju aplikacije u Kubernetesu.
Želeo bih da pokušate Linkerd — njegova instalacija u Kubernetes klaster (ili čak u Minikube na laptopu) , i sami ćete moći videti o čemu govorim.
FAQ
— Ako budem ignorisao service mesh, hoće li nestati?
— Nažalost, service mesh je s nama na duže staze.
— Ali NE ŽELIM koristiti service mesh!
— Pa, ne morate! Samo pročitajte moj upitnik iznad da biste razumeli treba li se upoznati barem s njenim osnovama.
— Zar to nije stari dobri ESB/middleware pod novim imenom?
— Servisna mreža se bavi operativnom logikom, a ne značenjem. servisne sabirnice poduzeća (). Održavanje ovog razdvajanja pomaže servisnoj mreži da izbjegne istu sudbinu.
— Po čemu se servisna mreža razlikuje od API-gateways?
— Postoji milijun članaka na tu temu. Samo pretražite Google.
— Je li Envoy servisna mreža?
— Ne, Envoy nije servisna mreža, to je proxy poslužitelj. Može se koristiti za organizaciju servisne mreže (i mnogo više — to je univerzalni proxy). No sam po sebi nije servisna mreža.
— Je li Network Service Mesh servisna mreža?
— Ne. Unatoč nazivu, to nije servisna mreža (kakva čuda marketinga?).
— Hoće li servisna mreža pomoći mojem reaktivnom asinkronom sustavu na temelju poruka?
— Ne, servisna mreža vam neće pomoći.
— Koju servisnu mrežu da koristim?
— , to je očito.
— Članak je loš! / Autora na sapun!
— Molim vas, podijelite link na njega sa svim prijateljima kako bi se uvjerili!
Zahvale
Kako ste mogli pogoditi po nazivu, ovaj članak je inspiriran fantastičnim traktatom Jay Krepsa «». Upoznao sam Jay’a prije deset godina kada sam bio na intervjuu u LinkedInu, i od tada me inspirira.
Iako se volim nazivati „razvijačem Linkerda“, stvarnost je takva da sam prije održavatelj datoteke README.md u projektu. Na Linkerdu danas radi , , I na kraju, posebna zahvalnost osnivaču Linkerda,
Oliveru Gouldu , koji je zajedno sa mnom prije mnogo godina uronio u cijelu ovu zbrku sa servisnom mrežom.Traefik 2.0: ažuriranje servisne mreže s podrškom za TCP i novim web sučeljem
P.S. od prevodioca
Pročitajte i na našem blogu:
- «»;
- «»;
- «»;
- «»;
- «».
Izvor: habr.com
