Bilješka. prev.: Servisna mreža je fenomen koji još nema stabilan prijevod na ruski (prije više od 2 godine predložili smo opciju "mreža za usluge", a nešto kasnije neki kolege počeli su aktivno promovirati kombinaciju "servisno sito"). Stalna priča o ovoj tehnologiji dovela je do situacije u kojoj su marketinška i tehnička komponenta pretijesno isprepletene. Ovaj prekrasan materijal jednog od autora izvornog pojma namijenjen je pružanju jasnoće inženjerima i drugima.
Strip iz
Uvod
Ako ste softverski inženjer koji radi negdje u prostoru pozadinskih sustava, pojam "servisna mreža" vjerojatno vam je već postao čvrsto ukorijenjen u umu tijekom proteklih nekoliko godina. Zahvaljujući čudnoj podudarnosti, ovaj izraz sve više preuzima industriju, a hype i promotivne ponude povezane s njim rastu poput grudve snijega koja leti nizbrdo i ne pokazuju znakove usporavanja.
Servisni mesh rođen je u mutnim, pristranim vodama izvornog ekosustava oblaka. Nažalost, to znači da se velik dio kontroverzi oko toga kreće od "niskokaloričnih razgovora" do - da upotrijebimo tehnički izraz - čiste besmislice. Ali ako presječete svu tu buku, vidjet ćete da servisna mreža ima vrlo stvarnu, definiranu i važnu funkciju.
U ovom ću postu pokušati učiniti upravo to: pružiti iskren, detaljan vodič za uslužnu mrežu usmjeren na inženjere. Neću samo odgovoriti na pitanje: "Što je?", - ali također "Zašto?"I "Zašto sada?". Na kraju ću pokušati opisati zašto je (po mom mišljenju) baš ova tehnologija izazvala tako ludu pometnju, što je samo po sebi zanimljiva priča.
Tko sam ja
Bok svima! Moje ime je . Ja sam jedan od kreatora — prvi servisni mesh projekt i projekt koji je zaslužan za pojavu termina servisna mreža kao takav (oprostite momci!). (Napomena prev.: Inače, u praskozorje pojave ovog termina, prije više od 2,5 godine, već smo preveli rani materijal istog autora pod naslovom “".) Ja također glavu je startup koji stvara cool service mesh stvari kao što su Linkerd i .
Vjerojatno pogađate da o ovom pitanju imam vrlo pristrano i subjektivno mišljenje. Međutim, pokušat ću svesti pristranost na minimum (s izuzetkom jednog odjeljka: "Zašto se toliko priča o servisnoj mreži?", - u kojem ću ipak podijeliti svoje unaprijed stvorene ideje). Također ću dati sve od sebe da ovaj vodič bude što objektivniji. Za konkretne primjere prvenstveno ću se osloniti na Linkerdovo iskustvo, dok ću ukazati na razlike (ako ih ima) za koje znam u implementaciji drugih tipova uslužnih mreža.
U redu, vrijeme je da prijeđemo na poslastice.
Što je servisna mreža?
Unatoč svim hype, struktura servisne mreže je prilično jednostavna. Ovo je samo hrpa proxyja korisničkog prostora smještenih "pored" servisa (razgovarat ćemo malo o tome što je "sljedeće" kasnije), plus skup kontrolnih procesa. Opunomoćenici se zajednički nazivaju podatkovni plan, a procesi upravljanja se nazivaju upravljački avion. Podatkovna ravnina presreće pozive između usluga i radi "sve vrste različitih stvari" s njima; Kontrolna ravnina, prema tome, koordinira ponašanje proxyja i omogućuje vam pristup, tj. operatera, na API, omogućujući manipuliranje i mjerenje mreže kao cjeline.
Kakav je ovo proxy? Ovo je TCP proxy koji podržava sloj 7 (tj. "uzimajući u obzir" sloj 7 OSI modela) poput HAProxy i NGINX. Možete odabrati proxy po svom ukusu; Linkerd koristi Rust proxy, jednostavno nazvan . Sastavili smo ga posebno za servisnu mrežu. Druge mreže preferiraju druge proxyje (Envoy je čest izbor). Međutim, odabir proxyja samo je stvar implementacije.
Što rade ti proxy poslužitelji? Očito, oni proxy pozive prema i od usluga (strogo govoreći, oni djeluju kao proxy i obrnuti proxy, rukujući i dolaznim i odlaznim pozivima). I implementiraju skup značajki koji se fokusira na pozive između usluge. Ovaj fokus na promet između usluga ono je što razlikuje servisni mesh proxy od, recimo, API pristupnika ili ulaznih proxyja (potonji se fokusiraju na pozive koji dolaze u klaster iz vanjskog svijeta). (Bilješka. prev.: Za usporedbu postojećih Ingress kontrolera za Kubernetes, od kojih mnogi koriste već spomenuti Envoy, pogledajte .)
Dakle, sredili smo podatkovnu ravninu. Kontrolna ravnina je jednostavnija: to je skup komponenti koje pružaju svu mehaniku koja je podatkovnoj ravni potrebna za rad na koordiniran način, uključujući otkrivanje usluge, izdavanje TLS certifikata, metričku agregaciju, itd. Podatkovna ravnina obavještava kontrolnu razinu o njegovo ponašanje; zauzvrat, kontrolna ravnina pruža API koji vam omogućuje promjenu i praćenje ponašanja podatkovne ravnine kao cjeline.
Ispod je dijagram kontrolne ravnine i podatkovne ravnine u Linkerdu. Kao što možete vidjeti, kontrolna ravnina uključuje nekoliko različitih komponenti, uključujući Prometheus instancu koja prikuplja metriku s proxy poslužitelja, kao i druge komponente kao što su destination (otkrivanje usluge), identity (certifikacijsko tijelo, CA) i public-api (krajnje točke za web i CLI). Nasuprot tome, podatkovna ravnina je jednostavan linkerd-proxy pored instance aplikacije. Ovo je samo logički dijagram; U implementaciji u stvarnom svijetu, možete imati tri replike svake komponente kontrolne ravnine i stotine ili tisuće proxyja u podatkovnoj ravnini.
(Plavi pravokutnici u ovom dijagramu simboliziraju granice Kubernetes podova. Možete vidjeti da su spremnici s linkerd-proxyjem u istom podu kao i spremnici aplikacije. Ova je shema poznata kao bočna prikolica kontejner.)
Servisna mrežasta arhitektura ima nekoliko važnih implikacija. Prvo, budući da je zadatak proxyja presresti pozive između usluga, servisna mreža ima smisla samo ako je vaša aplikacija stvorena za određeni skup usluga. Mreža može se koristiti s monolitima, ali ovo je očito suvišno radi jednog jedinog proxyja, a njegova funkcionalnost vjerojatno neće biti tražena.
Druga važna posljedica je da servisna mreža zahtijeva ogroman broj opunomoćenika. Zapravo, Linkerd prilaže linkerd-proxy svakoj instanci svake usluge (druge implementacije dodaju proxy svakom čvoru/domaćinu/virtualnom stroju. To je ionako puno). Takvo aktivno korištenje proxyja samo po sebi nosi niz dodatnih komplikacija:
- Proxy u podatkovnoj ravnini moraju biti brzo, budući da za svaki poziv postoji nekoliko poziva proxyju: jedan na strani klijenta, jedan na strani poslužitelja.
- Trebali bi biti i opunomoćenici mali и lagana. Svaki će trošiti memoriju i CPU resurse, a ta će potrošnja rasti linearno s aplikacijom.
- Trebat će vam mehanizam za implementaciju i ažuriranje velikog broja proxyja. Učiniti to ručno nije opcija.
Općenito, servisna mreža izgleda ovako (barem iz ptičje perspektive): postavljate hrpu proksija korisničkog prostora koji "nešto rade" s internim, međuservisnim prometom i koristite kontrolnu ravninu za nadzor i upravljanje njima.
Sada je vrijeme da postavimo pitanje "Zašto?"
Čemu služi servisna mreža?
Onima koji su se prvi put susreli s idejom servisne mreže moglo bi se oprostiti što su se osjećali malo strepeći. Dizajn servisne mreže znači da neće samo povećati latenciju u aplikaciji, već će također konzumirati resursi i će dodati hrpa novih mehanizama u infrastrukturi. Prvo postavite uslužnu mrežu, a onda se odjednom nađete u potrebi da servisirate stotine (ako ne i tisuće) proxyja. Pitanje je tko će to dobrovoljno učiniti?
Odgovor na ovo pitanje ima dva dijela. Prvo, transakcijski troškovi povezani s implementacijom ovih proxy poslužitelja mogu se značajno smanjiti zahvaljujući nekim promjenama koje se događaju u ekosustavu (više o tome kasnije).
Drugo, ovakav uređaj je zapravo odličan način za uvođenje dodatne logike u sustav. Ne samo zato što servisna mreža može dodati puno novih funkcija, već i zato što se to može učiniti bez uplitanja u ekosustav. Zapravo, cijeli servisni mesh model temelji se na ovoj premisi: u multiservisnom sustavu, bez obzira na sve napraviti pojedinačne usluge, promet između njih je idealna točka za dodavanje funkcionalnosti.
Na primjer, u Linkerdu (kao iu većini mreža) funkcionalnost je prvenstveno usmjerena na HTTP pozive, uključujući HTTP/2 i gRPC*. Funkcionalnost je prilično bogata - može se podijeliti u tri klase:
- Značajke povezane s pouzdanost. Ponovljeni zahtjevi, istek vremena, kanarički pristup (podjela/preusmjeravanje prometa) itd.
- Značajke povezane s praćenje. Agregacija stopa uspješnosti, kašnjenja i količine zahtjeva za svaku uslugu ili pojedinačne upute; izrada topoloških mapa usluga itd.
- Značajke povezane s sigurnost. Uzajamni TLS, kontrola pristupa itd.
* S Linkerdovog stajališta, gRPC se praktički ne razlikuje od HTTP/2: samo koristi protobuf u sadržaju. Sa stajališta programera, te su dvije stvari, naravno, različite.
Mnogi od ovih mehanizama rade na razini zahtjeva (dakle "L7 proxy"). Na primjer, ako Foo servis upućuje HTTP poziv Bar servisu, linkerd-proxy na Foo strani može izvesti inteligentno balansiranje opterećenja i usmjeravati pozive od Foo do Bar instanci na temelju opažene latencije; može ponoviti zahtjev ako je potrebno (i ako je idempotentan); može zabilježiti kod odgovora i vremensko ograničenje, itd. Slično, linkerd-proxy na strani trake može odbiti zahtjev ako nije dopušten ili je ograničenje zahtjeva premašeno; može zabilježiti kašnjenje sa svoje strane, itd.
Proxiji mogu "učiniti nešto" i na razini veze. Na primjer, linkerd-proxy na strani Foo može pokrenuti TLS vezu, a linkerd-proxy na strani Bara je može prekinuti, a obje strane mogu međusobno provjeravati TLS certifikate*. Ovo ne pruža samo enkripciju između usluga, već i kriptografski siguran način identificiranja usluga: Foo i Bar mogu "dokazati" da su oni za koje se predstavljaju.
* "Mutual of a friend" znači da je certifikat klijenta također provjeren (mutual TLS). U "klasičnom" TLS-u, npr. između preglednika i poslužitelja, obično se provjerava certifikat samo jedne strane (poslužitelja).
Bez obzira rade li na razini zahtjeva ili veze, važno je naglasiti da sve servisne mesh funkcije jesu operativni lik. Linkerd ne može transformirati semantiku korisnog opterećenja - na primjer, dodavanjem polja JSON fragmentu ili unošenjem promjena u protobuf. O ovoj važnoj značajci ćemo govoriti kasnije kada budemo govorili o ESB-u i međuprogramu.
Ovo je skup značajki koje servisna mreža nudi. Postavlja se pitanje: zašto ih ne implementirati izravno u aplikaciju? I zašto se uopće mučiti s proxyjem?
Zašto je servisna mreža dobra ideja
Iako su mogućnosti uslužnog mesha uzbudljive, njegova temeljna vrijednost zapravo ne leži u njegovim značajkama. Na kraju mi Limenka implementirajte ih izravno u aplikaciju (kasnije ćemo vidjeti da je to bilo podrijetlo servisne mreže). Da pokušamo to sažeti u jednu rečenicu, vrijednost servisne mreže je: pruža značajke ključne za pokretanje modernog poslužiteljskog softvera na dosljedan način u cijelom nizu i neovisno o kodu aplikacije.
Analizirajmo ovaj prijedlog.
«Značajke ključne za pokretanje modernog poslužiteljskog softvera" Ako kreirate aplikaciju transakcijskog poslužitelja koja je povezana s javnim internetom, prihvaća zahtjeve iz vanjskog svijeta i odgovara na njih u kratkom vremenu - na primjer, web aplikacija, API poslužitelj i velika većina drugih modernih aplikacija - i ako ga implementirate kao skup usluga koje sinkrono komuniciraju jedna s drugom, i ako stalno nadograđujete ovaj softver, dodajete nove značajke, i ako ste prisiljeni održavati ovaj sustav u ispravnom stanju tijekom procesa izmjene - u ovom slučaju, čestitamo, stvarate moderan poslužiteljski softver. A sve ove gore navedene sjajne značajke zapravo su ključne za vas. Aplikacija mora biti pouzdana, sigurna i morate moći promatrati što radi. Upravo su to pitanja koja servisni mesh pomaže riješiti.
(OK, prethodni odlomak i dalje uključuje moje uvjerenje da je ovaj pristup moderan način stvaranja poslužiteljskog softvera. Drugi radije razvijaju monolite, "reaktivne mikroservise" i druge stvari koje ne potpadaju pod gornju definiciju. Ti ljudi vjerojatno imaju svoje mišljenje je drugačije od mog. S druge strane, ja mislim da su oni "u krivu" - iako im servisna mreža u svakom slučaju nije baš korisna).
«Uniforma za cijelu hrpu" Funkcionalnost koju pruža servisna mreža nije samo kritična za misiju. Primjenjuju se na sve usluge u aplikaciji, bez obzira na to na kojem su jeziku napisane, koji okvir koriste, tko ih je napisao, kako su raspoređene i bilo koje druge suptilnosti njihova razvoja i korištenja.
«Neovisno o aplikacijskom kodu" Naposljetku, servisna mreža ne samo da pruža dosljednu funkcionalnost u cijelom nizu, već to čini na način koji ne zahtijeva uređivanje aplikacije. Temeljna osnova funkcionalnosti servisne mreže, uključujući zadatke za konfiguraciju, ažuriranje, rad, održavanje itd., u potpunosti se nalazi na razini platforme i neovisna je o aplikaciji. Aplikacija se može promijeniti bez utjecaja na servisnu mrežu. S druge strane, servisna mreža se može mijenjati bez sudjelovanja aplikacije.
Ukratko, servisna mreža ne samo da pruža vitalnu funkcionalnost, već to čini i na globalan, jednoobrazan način neovisan o aplikaciji. I tako, iako se funkcionalnost mreže usluge može implementirati u servisni kod (na primjer, kao biblioteka uključena u svaku uslugu), ovaj pristup neće pružiti jednoobraznost i neovisnost koja je toliko vrijedna u slučaju mreže usluge.
I sve što trebate učiniti je dodati hrpu proxyja! Obećavam da ćemo vrlo brzo razmotriti operativne troškove povezane s dodavanjem ovih proxy poslužitelja. Ali prvo zastanimo i pogledajmo ovu ideju neovisnosti iz različitih perspektiva. ljudi.
Kome pomaže servisna mreža?
Koliko god to bilo nezgodno, da bi tehnologija postala važan dio ekosustava, ljudi je moraju prihvatiti. Dakle, koga zanima servisna mreža? Tko ima koristi od njegove upotrebe?
Ako razvijate moderni poslužiteljski softver, svoj tim možete grubo zamisliti kao grupu vlasnici uslugakoji zajedno razvijaju i implementiraju poslovnu logiku i vlasnici platforme, razvijajući internu platformu na kojoj ove usluge rade. U malim organizacijama to mogu biti isti ljudi, ali kako tvrtka raste, te uloge postaju sve izraženije, pa čak i podijeljene na poduloge... (Ovdje se može puno reći o promjenjivoj prirodi devopsa, organizacijski utjecaj mikroservisa itd.) n. Ali za sada uzmimo ove opise kao dane).
S ove točke gledišta, očigledni korisnici mesha usluga su vlasnici platformi. Na kraju krajeva, krajnji cilj platformskog tima je stvoriti internu platformu na kojoj vlasnici usluga mogu implementirati poslovnu logiku i to na način koji osigurava da budu što neovisniji od mutnih detalja njenog rada. Ne samo da servisna mreža nudi mogućnosti ključne za postizanje ovog cilja, već to čini na način koji zauzvrat ne nameće ovisnost 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 mora brinuti o operativnim problemima, to bolje. Umjesto da se moraju baviti implementacijom, recimo, pravila ponovnog pokušaja ili TLS-a, mogu se usredotočiti isključivo na poslovne ciljeve i nadati se da će se platforma pobrinuti za ostalo. To im je velika prednost.
Organizacijska vrijednost takve podjele između vlasnika platformi i usluga ne može se precijeniti. Mislim da ona doprinosi glavni doprinos vrijednosti mreže usluge.
Naučili smo ovu lekciju kada nam je jedan rani obožavatelj Linkerda rekao zašto su odabrali uslužnu mrežu: jer im je omogućio da "svedu govornicu na minimum". Evo nekih detalja: dečki iz jedne velike tvrtke migrirali su svoju platformu na Kubernetes. Budući da je aplikacija obrađivala osjetljive informacije, htjeli su šifrirati svu komunikaciju u klasterima. Međutim, situaciju je zakomplicirala prisutnost stotina servisa i stotina razvojnih timova. Mogućnost da kontaktiraju sve i uvjere ih da uključe TLS podršku u svoje planove nije ih nimalo usrećila. Nakon instaliranja Linkerda, izvršili su prijenos odgovornost od developera (s čijeg je gledišta ovo bila nepotrebna muka) do platformera, kojima je to bio prioritet na najvišoj razini. Drugim riječima, Linkerd im je riješio ne toliko tehnički koliko organizacijski problem.
Ukratko, servisna mreža je više rješenje, ne tehničko, ali socio-tehnički Problemi. (Hvala vam za uvođenje ovog pojma.)
Hoće li servisna mreža riješiti sve moje probleme?
Da. Mislim, ne!
Ako pogledate tri gore navedene klase značajki - pouzdanost, sigurnost i vidljivost - postaje jasno da servisna mreža nije potpuno rješenje za bilo koji od ovih problema. Iako Linkerd može ponovno izdati zahtjeve (ako zna da su idempotentni), ne može donositi odluke o tome što vratiti korisniku ako usluga trajno zakaže - te odluke mora donijeti aplikacija. Linkerd može voditi statistiku uspješnih zahtjeva, ali ne može zaviriti u servis i pružiti njegovu internu metriku - aplikacija mora imati takve alate. Iako je Linkerd sposoban organizirati mTLS, potpuna sigurnosna rješenja zahtijevaju mnogo više.
Podskup značajki u ovim područjima koje nudi servisna mreža odnosi se na značajke platforme. Pod ovim mislim na funkcije koje:
- Neovisno o poslovnoj logici. Način na koji su konstruirani histogrami poziva između Foo i Bar potpuno je neovisan o zašto Foo zove Bar.
- Teško ga je pravilno implementirati. U Linkerdu su ponovni pokušaji parametrizirani raznim otmjenim stvarima poput proračuna za ponovne pokušaje (ponovo pokušaj proračune), budući da će nesofisticirani, direktni pristup provedbi takvih stvari sigurno dovesti do pojave tzv. „lavine zahtjeva“ (ponovno oluja) i drugi problemi karakteristični za distribuirane sustave.
- Najučinkovitije kada se nanese ravnomjerno. TLS mehanizam ima smisla samo ako se svugdje primjenjuje.
Budući da su te funkcije implementirane na proxy razini (a ne na razini aplikacije), servisna mreža ih pruža na platforma, a ne aplikacije. Dakle, nije važno na kojem su jeziku usluge napisane, koji okvir koriste, tko ih je napisao i zašto. Proxiji rade izvan svih ovih detalja, a temeljna osnova ove funkcionalnosti, uključujući zadatke za konfiguraciju, ažuriranje, rad, održavanje itd., leži isključivo na razini platforme.
Primjeri mrežnih mogućnosti usluge
Ukratko, servisna mreža nije potpuno rješenje za pouzdanost, vidljivost ili sigurnost. Opseg ovih područja zahtijeva sudjelovanje vlasnika usluga, Ops/SRE timova i drugih subjekata tvrtke. Servisna mreža pruža samo "isječak" na razini platforme za svako od ovih područja.
Zašto je servisna mreža postala popularna upravo sada?
Do sada se vjerojatno pitate: u redu, ako je uslužna mreža tako dobra, zašto nismo počeli postavljati milijune proxyja u stog prije deset godina?
Na ovo pitanje postoji banalan odgovor: prije deset godina svi su gradili monolite, a nitko nije trebao servisnu mrežu. To je istina, ali po mom mišljenju ovaj odgovor nema poantu. Još prije deset godina, koncept mikroservisa kao obećavajućeg načina za izgradnju velikih sustava naširoko se raspravljao i primjenjivao u tvrtkama kao što su Twitter, Facebook, Google i Netflix. Općenito mišljenje - barem u dijelovima industrije s kojima sam ja došao u kontakt - bilo je da su mikroservisi "pravi način" za izgradnju velikih sustava, čak i ako je to prokleto teško.
Naravno, iako su prije deset godina postojale tvrtke koje su upravljale mikrouslugama, one nisu zalijepile proxije svugdje gdje su mogle da formiraju servisnu mrežu. Međutim, ako bolje pogledate, učinili su nešto slično: mnoge od tih tvrtki zahtijevale su upotrebu posebne interne knjižnice za mrežnu komunikaciju (ponekad se naziva debela klijentska biblioteka, debela knjižnica klijenta).
Netflix je imao Hysterix, Google je imao Stubbyja, Twitter je imao biblioteku Finagle. Finagle je, primjerice, bio obavezan za svaku novu uslugu na Twitteru. Obrađivao je i klijentsku i poslužiteljsku stranu veza, dopuštao ponovljene zahtjeve, podržavao usmjeravanje zahtjeva, balansiranje opterećenja i mjerenje. Pružao je dosljedan sloj pouzdanosti i vidljivosti na cijelom Twitter stogu, bez obzira na to što usluga radi. Naravno, radio je samo za JVM jezike i temeljio se na modelu programiranja koji se morao koristiti za cijelu aplikaciju. Međutim, njegova je funkcionalnost bila gotovo ista kao i servisna mreža. (Zapravo, prva verzija Linkerda bila je jednostavno Finagle umotan u proxy oblik.)
Dakle, prije deset godina nisu postojale samo mikroservisi, već i posebne proto-service-mesh biblioteke koje su rješavale iste probleme koje servisni mesh rješava danas. Međutim, sama servisna mreža tada nije postojala. Morala je proći još jedna smjena prije nego što se pojavila.
I tu leži dublji odgovor, skriven u još jednoj promjeni koja se dogodila u proteklih 10 godina: troškovi implementacije mikroservisa dramatično su pali. Gore spomenute tvrtke koje su koristile mikroservise prije deset godina - Twitter, Netflix, Facebook, Google - bile su tvrtke golemih razmjera i golemih resursa. Ne samo da su imali potrebu, već i sposobnost za izgradnju, implementaciju i rad s velikim aplikacijama temeljenim na mikrouslugama. Energija i trud koji su inženjeri Twittera uložili u prelazak s monolitnog pristupa na pristup mikroservisima su nevjerojatni. (Da budemo pošteni, takva je i činjenica da je uspio.) Ovakvi infrastrukturni manevri tada su manjim tvrtkama bili nemogući.
Brzo naprijed u sadašnjost. Danas postoje startupovi u kojima je omjer mikroservisa i programera 5:1 (ili čak ), štoviše, s njima se uspješno nose! Ako startup od 5 ljudi može lako upravljati s 50 mikroservisa, onda je nešto očito smanjilo trošak njihove implementacije.
1500 mikroservisa u Monzu; svaka linija je propisano mrežno pravilo koje dopušta promet
Dramatično smanjenje troškova rada mikroservisa rezultat je jednog procesa: rastuća popularnost kontejnera и orkestratori. Upravo je to dubinski odgovor na pitanje što je pridonijelo nastanku uslužnog mesha. Ista tehnologija učinila je privlačnim i servisne mreže i mikroservise: Kubernetes i Docker.
Zašto? Pa, Docker rješava jedan veliki problem - problem pakiranja. Pakiranjem aplikacije i njezinih (ne-mrežnih) ovisnosti o vremenu izvođenja u spremnik, Docker pretvara aplikaciju u izmjenjivu jedinicu koja se može ugostiti i pokrenuti bilo gdje. Istodobno, uvelike pojednostavljuje rad višejezičan Stog: Budući da je spremnik atomska jedinica izvršenja, za implementaciju i operativne svrhe, nije važno što je unutra, bilo da je to JVM, Node, Go, Python ili Ruby aplikacija. Samo ga pokrenete i to je to.
Kubernetes podiže sve na višu razinu. Sada kada postoje tone "stvari za pokretanje" i tone strojeva na kojima se mogu pokrenuti, postoji potreba za alatom koji ih može međusobno povezati. U širem smislu, dajete Kubernetesu puno spremnika i mnogo strojeva, a on ih mapira jedne protiv drugih (naravno, ovo je dinamičan i stalno promjenjiv proces: novi se spremnici kreću po sustavu, strojevi se pokreću i zaustavljaju , itd. Međutim, Kubernetes sve to uzima u obzir ).
Nakon što je Kubernetes konfiguriran, vremenski trošak za implementaciju i rad jedne usluge malo se razlikuje od cijene za implementaciju i rad deset usluga (zapravo, gotovo je isti za 100 usluga). Dodajte ovome spremnike kao mehanizam za pakiranje koji potiče višejezičnu implementaciju i imat ćete mnoštvo novih aplikacija implementiranih u obliku mikroservisa napisanih na različitim jezicima - upravo ona vrsta okruženja za koje je uslužna mreža tako prikladna.
Dakle, došli smo do odgovora na pitanje zašto je ideja servisne mreže sada postala popularna: homogenost koju Kubernetes pruža za usluge izravno se odnosi na operativne izazove s kojima se servisna mreža suočava. Zapakirate proxy u spremnike, date Kubernetesu zadatak da ih zalijepi gdje god može i voila! Kao rezultat toga, dobivate servisnu mrežu, dok svim mehanikama njezine implementacije upravlja Kubernetes. (Barem iz ptičje perspektive. Naravno, postoji mnogo nijansi u ovom procesu.)
Da sažmemo: razlog zbog kojeg su servisne mreže postale popularne sada, a ne prije deset godina, jest taj što su Kubernetes i Docker ne samo značajno povećali potreba u njemu, pojednostavivši implementaciju aplikacija kao skupova višejezičnih mikroservisa, ali i značajno reducirajući troškovi za njegov rad, pružajući mehanizme za postavljanje i podršku proxy flota prikolica.
Zašto se toliko priča o uslužnoj mreži?
Oprez: U ovom dijelu koristim se svim vrstama pretpostavki, nagađanja, izmišljotina i povlaštenih informacija.
Potražite "uslužna mreža" i naići ćete na tonu recikliranog niskokalorijskog sadržaja, čudne projekte i kaleidoskop izobličenja dostojnog eho komore. Svaka otmjena nova tehnologija to čini, ali u slučaju servisne mreže problem je posebno akutan. Zašto?
Pa, dio toga je i moja krivnja. Naporno sam radio na promicanju Linkerda i servisne mreže svaku priliku koju sam dobio kroz bezbroj postova na blogu i članaka poput ovog. Ali ja nisam tako moćan. Da bismo stvarno odgovorili na ovo pitanje, moramo malo progovoriti o cjelokupnoj situaciji. I nemoguće je govoriti o tome a ne spomenuti jedan projekt: je servisna mreža otvorenog koda koju su zajednički razvili Google, IBM i Lyft.
(Tri tvrtke imaju vrlo različite uloge: čini se da je uključenost Lyfta samo po imenu; oni su autori Envoya, ali ne koriste niti sudjeluju u razvoju Istia. IBM je uključen i koristi Istio. Google je aktivno uključen u Istio razvoj , ali ga zapravo ne koristi koliko ja mogu reći.)
Projekt Istio poznat je po dvije stvari. Prvo, tu je ogroman marketinški napor koji Google, posebno, ulaže u njegovu promociju. Procijenio bih da je većina ljudi koji su danas svjesni koncepta servisne mreže prvi put saznala za njega kroz Istio. Druga je stvar koliko je Istio loše primljen. Ja sam u ovom pitanju očito zainteresirana strana, ali pokušavajući ostati maksimalno objektivan, ipak ne mogu pomoći , ne baš prepoznatljiv (iako ne jedinstven: pada mi na pamet systemd, ...) za projekt otvorenog koda.
(Čini se da u praksi Istio ima problema ne samo sa složenošću i UX-om, već i s izvedbom. Na primjer, tijekom U studiji treće strane, istraživači su pronašli situacije u kojima je Istio repna latencija bila 100 puta veća od Linkerdove, kao i situacije s nedostatkom resursa u kojima je Linkerd nastavio uspješno funkcionirati dok je Istio potpuno prestao raditi.)
Ostavljajući po strani moje teorije o tome zašto se to dogodilo, vjerujem da se silno uzbuđenje oko mreže usluge objašnjava Googleovim sudjelovanjem. Naime, kombinacija sljedeća tri faktora:
- Googleova nametljiva promocija Istia;
- odgovarajući neodobravajući, kritički stav prema projektu;
- nedavni meteorski porast popularnosti Kubernetesa, sjećanja na koji su još uvijek svježa.
Zajedno se ti čimbenici kombiniraju kako bi stvorili zapanjujuću okolinu bez kisika u kojoj je sposobnost racionalnog prosuđivanja oslabljena i ostaje samo čudna raznolikost. .
Iz Linkerdove perspektive, ovo je...ono što bih opisao kao mješoviti blagoslov. Mislim, sjajno je što je service mesh ušao u mainstream na način na koji nije 2016. kada je Linkerd tek počeo i bilo je stvarno teško navesti ljude da obrate pozornost na projekt. Sada više nema tog problema! Ali loša je vijest da je mrežni krajolik usluge danas toliko zbunjujući da je gotovo nemoguće razumjeti koji projekti zapravo pripadaju kategoriji mrežne usluge (a kamoli razumjeti koji je najprikladniji za određeni slučaj upotrebe). Ovo je definitivno rješenje za sve (i definitivno postoje neki slučajevi u kojima je Istio ili neki drugi projekt prikladniji od Linkerda, budući da potonji još uvijek nije univerzalno rješenje).
S Linkerdove strane, naša je strategija bila ignorirati buku, nastaviti se fokusirati na rješavanje stvarnih problema zajednice i u biti čekati da se pompa stiša. U konačnici, hype će splasnuti i možemo mirno nastaviti raditi.
U međuvremenu ćemo se svi morati malo strpiti.
Hoće li servisna mreža biti korisna meni, skromnom softverskom inženjeru?
Sljedeći upitnik pomoći će vam da odgovorite na ovo pitanje:
Bavite li se samo implementacijom poslovne logike? U tom slučaju servisna mreža neće vam biti korisna. To je, naravno, moglo bi vas zanimati, ali u idealnom slučaju servisna mreža ne bi trebala izravno utjecati na bilo što u vašem okruženju. Nastavite raditi na onome za što ste plaćeni.
Podržavate li platformu u tvrtki koja koristi Kubernetes? Da, u ovom slučaju potrebna vam je servisna mreža (osim, naravno, ako ne koristite K8s samo za pokretanje monolitne ili skupne obrade - ali tada bih želio pitati zašto vam trebaju K8s). Vjerojatno ćete završiti s mnogo mikroservisa koje su napisali različiti ljudi. Svi oni međusobno djeluju i povezani su u klupko ovisnosti o vremenu izvođenja, a vi morate pronaći način da se nosite sa svime time. Korištenje Kubernetesa omogućuje vam da odaberete servisnu mrežu "za sebe". Da biste to učinili, upoznajte se s njihovim mogućnostima i značajkama i odgovorite na pitanje je li neki od dostupnih projekata prikladan za vas (preporučam da svoje istraživanje započnete s Linkerdom).
Jeste li platformska tvrtka u tvrtki koja NE koristi Kubernetes, ali koristi mikroservise? U ovom slučaju, servisna mreža će vam biti korisna, ali njena upotreba neće biti trivijalna. Naravno, možete oponašati rad servisne mreže postavljanjem hrpe proxyja, ali važna prednost Kubernetesa je model postavljanja: ručno održavanje ovih proxyja zahtijevat će puno više vremena, truda i troškova.
Jeste li odgovorni za platformu u tvrtki koja radi s monolitima? U ovom slučaju vjerojatno vam ne treba servisna mreža. Ako radite s monolitima (ili čak zbirkama monolita) koji imaju dobro definirane i rijetko promjenjive obrasce interakcije, tada će vam servisna mreža imati malo toga za ponuditi. Tako da ga jednostavno možete ignorirati i nadati se da će nestati kao ružan san...
Zaključak
Vjerojatno se servisni mesh još uvijek ne bi trebao nazivati "najrazvikanijom tehnologijom na svijetu" - ova sumnjiva čast vjerojatno pripada Bitcoinu ili umjetnoj inteligenciji. Vjerojatno je među prvih pet. Ali ako presječete slojeve buke, postaje jasno da servisna mreža donosi stvarne prednosti onima koji grade aplikacije na Kubernetesu.
Želio bih da isprobate Linkerd - instalirate ga na Kubernetes klaster (ili čak Minikube na laptopu) , a vidite i sami o čemu pričam.
FAQ
— Ako zanemarim servisnu mrežu, hoće li nestati?
— Moram vas razočarati: servisna mreža je s nama već dugo.
- Ali NE ŽELIM koristiti servisnu mrežicu!
- Pa nije potrebno! Samo pročitajte moj upitnik iznad kako biste shvatili trebate li se barem upoznati s njegovim osnovama.
— Nije li ovo stari dobri ESB/middleware s novim umakom?
— Servisna mreža bavi se operativnom logikom, a ne semantičkom. poslovni autobus (). Održavanje ovog odvajanja pomaže servisnoj mreži da izbjegne istu sudbinu.
— Kako se servisna mreža razlikuje od API pristupnika?
— Postoji milijun članaka o ovoj temi. Samo proguglajte.
— Envoy je servisna mreža?
- Ne, Envoy nije servisni mesh, on je proxy poslužitelj. Može se koristiti za organiziranje servisne mreže (i mnogo više - to je proxy opće namjene). Ali sama po sebi nije servisna mreža.
— Network Service Mesh je servisna mreža?
- Ne. Unatoč nazivu, ovo nije servisna mreža (kako vam se sviđaju marketinška čuda?).
— Hoće li servisna mreža pomoći s mojim reaktivnim asinkronim sustavom temeljenim na redu čekanja poruka?
- Ne, servisna mrežica vam neće pomoći.
— Koju servisnu mrežu trebam koristiti?
- , nema pameti.
- Članak je sranje! / Autor je dobrodošao!
— Podijelite poveznicu sa svim svojim prijateljima kako bi je mogli vidjeti!
Blagodarnosti
Kao što ste mogli pogoditi iz naslova, ovaj je članak inspiriran fantastičnom traktatom Jaya Krepsa "" Upoznao sam Jaya prije deset godina kada sam ga intervjuirao na Linked Inu i od tada mi je inspiracija.
Iako sebe volim nazivati "Linkerd programerom", stvarnost je da sam više održavatelj datoteke README.md na projektu. Danas se radi na Linkerdu , , ljudi, a ovaj se projekt ne bi dogodio bez sudjelovanja prekrasne zajednice suradnika i korisnika.
I na kraju, posebna zahvala kreatoru Linkerda, (primus inter pares), koji je zajedno sa mnom prije mnogo godina bezglavo zaronio u svu ovu frku sa servisnom mrežicom.
PS od prevoditelja
Pročitajte i na našem blogu:
- «»;
- «»;
- «»;
- «»;
- «".
Izvor: www.habr.com