Bilješka. transl.: Servisna mreža je fenomen koji još nema stabilan prijevod na ruski (prije više od 2 godine ponudili smo opciju "mreža za usluge", a nešto kasnije neke kolege su počele aktivno promovirati kombinaciju "servisno sito") . Stalna priča o ovoj tehnologiji dovela je do situacije u kojoj su marketinške i tehničke komponente previše usko isprepletene. Ovaj divan materijal jednog od autora originalnog termina ima za cilj da unese jasnoću inženjerima i ne samo.
Comic from
Uvod
Ako ste softverski inženjer koji radi negdje u oblasti pozadinskih sistema, pojam „servisne mreže“ vjerovatno se već čvrsto ukorijenio u vašem umu u posljednjih nekoliko godina. Zahvaljujući čudnoj podudarnosti, ova fraza sve više preuzima industriju, a hype i povezane promotivne ponude rastu kao grudva snijega, lete nizbrdo i ne pokazuju znakove usporavanja.
Servisna mreža je rođena u mutnim, tendencioznim vodama prirodnog ekosistema oblaka. Nažalost, to znači da se veliki dio kontroverzi oko toga kreće od „niskokaloričnih čavrljanja“ do — da upotrebimo tehnički izraz — očitog sranja. Ali ako filtrirate svu buku, možete otkriti da servisna mreža ima vrlo stvarnu, definitivnu i važnu funkciju.
U ovom postu pokušat ću učiniti upravo to: pružiti iskren, dubinski, inženjerski orijentisan vodič za servisnu mrežu. Odgovorit ću na više od pitanja: "Šta je to?", - ali takođe "Zašto?"I "Zašto sada?". Na kraju, pokušaću da opišem zašto je (po mom mišljenju) upravo ova tehnologija izazvala tako ludi hype, što je samo po sebi zanimljiva priča.
Ko sam ja
Zdravo svima! Moje ime je . Ja sam jedan od kreatora - prvi servisni mesh projekat i projekat koji je kriv za pojavu termina servisna mreža kao takav (izvinite momci!). (Napomena prev.: Inače, u osvit pojave ovog pojma, prije više od 2,5 godine, već smo preveli rani materijal istog autora pod nazivom "".) Ja takođe vodim je startup koji gradi cool servisne mreže kao što su Linkerd i .
Vjerovatno možete pretpostaviti da imam vrlo pristrasno i subjektivno mišljenje o ovom pitanju. Međutim, pokušat ću svesti pristrasnost 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 se potruditi da ovaj vodič bude što objektivniji. U konkretnim primjerima, uglavnom ću se osloniti na iskustvo Linkerd-a, uz ukazivanje na razlike (ako ih ima) za koje znam u implementaciji drugih vrsta servisnih mreža.
U redu, vrijeme je da pređemo na poslastice.
Šta je servisna mreža?
Usprkos svom hypeu, servisna mreža je strukturno prilično jednostavna. To je samo gomila proksija korisničkog prostora koji se nalazi "pored" usluga (o "blizu" ćemo malo kasnije), plus skup kontrolnih procesa. Zastupnici se zajednički nazivaju data plan, a kontrolni procesi se pozivaju kontrolni avion. Ravan podataka presreće pozive između usluga i radi "sve drugačije" s njima; kontrolna ravan, odnosno, koordinira ponašanje proxyja i omogućava vam pristup, tj. operatera, do API-ja, omogućavajući da se mrežom manipuliše i mjeri kao cjelina.
Šta je ovo proxy? Ovo je TCP proxy iz kategorije "Layer 7-aware". (tj. "uzimajući u obzir" 7. sloj OSI modela) kao što su 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 proksije (Envoy je uobičajen izbor). Međutim, odabir proxyja je samo stvar implementacije.
Šta rade ovi proxy serveri? Očigledno, oni proksiju pozive ka uslugama i sa njih (strogo govoreći, djeluju kao proksiji i obrnuti proksiji, rukujući i dolaznim i odlaznim pozivima). I implementiraju skup funkcija koji se fokusira na pozive između usluge. Ovaj fokus na promet između usluga je ono što razlikuje servisni mesh proxy od, recimo, API gateway-a ili ulaznih proksija (posljednji se fokusira na pozive koji dolaze u klaster iz vanjskog svijeta). (Bilješka. transl.: Za poređenje postojećih Kubernetes Ingress kontrolera, od kojih mnogi koriste već spomenuti Envoy, pogledajte .)
Dakle, shvatili smo ravan podataka. Kontrolna ravan je jednostavnija: to je skup komponenti koje pružaju svu mehaniku koja je potrebna za koordiniran rad ravni podataka, uključujući otkrivanje usluge, izdavanje TLS certifikata, agregaciju metrike, itd. Ravan podataka obavještava kontrolnu ravan o njegovo ponašanje; zauzvrat, kontrolna ravan pruža API koji vam omogućava da promijenite i pratite ponašanje ravni podataka u cjelini.
Ispod je dijagram kontrolne ravni i ravni podataka u Linkerdu. Kao što vidite, kontrolna ravan uključuje nekoliko različitih komponenti, uključujući Prometheus instancu koja prikuplja metriku sa proxy servera, kao i druge komponente kao što su destination (otkrivanje usluge), identity (certifikacijsko tijelo, CA) i public-api (krajnje tačke za web i CLI). Nasuprot tome, ravan podataka je jednostavan linkerd-proxy pored instance aplikacije. Ovo je samo logički dijagram; u primeni u stvarnom svetu, možda imate tri replike svake komponente kontrolne ravni i stotine ili hiljade proksija u ravni podataka.
(Plavi okviri na ovom dijagramu predstavljaju granice Kubernetes podova. Možete vidjeti da su kontejneri sa linkerd-proxy u istom pod kao i kontejneri aplikacije. Ova šema je poznata kao bocni kontejner.)
Arhitektura servisne mreže ima nekoliko važnih implikacija. Prvo, budući da je posao proxyja da presreće pozive između usluga, servisna mreža ima smisla samo ako je vaša aplikacija napravljena za skup usluga. mesh moći koristiti sa monolitima, ali ovo je očigledno suvišno zbog jednog proxyja, a njegova funkcionalnost vjerovatno neće biti tražena.
Druga važna posljedica je da servisna mreža zahtijeva ogroman broj punomoćnika. U stvari, Linkerd povezuje linkerd-proxy sa svakom instancom svake usluge (druge implementacije dodaju proxy svakom hostu/hostu/VM-u. To je ionako mnogo). Takva aktivna upotreba proxyja sama po sebi nosi niz dodatnih komplikacija:
- Proksiji u podatkovnoj ravni bi trebali biti brzo, jer za svaki poziv postoji nekoliko poziva proxyju: jedan na strani klijenta, jedan na strani servera.
- Takođe, punomoćnici moraju biti mala и lagana. Svaki će trošiti memorijske i CPU resurse, a ova potrošnja će rasti linearno s primjenom.
- Trebat će vam mehanizam za postavljanje i ažuriranje velikog broja proksija. To učiniti ručno nije opcija.
Općenito, servisna mreža izgleda ovako (barem iz ptičje perspektive): postavljate gomilu proksija korisničkog prostora koji "rade nešto" s internim, međuservisnim prometom, i koristite kontrolnu ravninu za nadgledanje i upravljanje njima.
Vrijeme je za pitanje "Zašto?"
Čemu služi servisna mreža?
Za one koji su se prvi put susreli s idejom servisne mreže, oprostivo je biti malo zadivljen. Dizajn servisne mreže znači da ne samo da će povećati kašnjenje aplikacije, već će i povećati konzumirati resurse i će dodati gomila novih mehanizama u infrastrukturi. Prvo postavite servisnu mrežu, a onda se odjednom nađete u potrebi da opslužujete stotine (ako ne i hiljade) proxy servera. Pitanje je ko će se za ovo dobrovoljno prijaviti?
Odgovor na ovo pitanje ima dva dijela. Prvo, troškovi transakcije povezani sa implementacijom ovih proksija mogu se značajno smanjiti zbog nekih promjena koje se dešavaju u ekosistemu (više o tome kasnije).
Drugo, takav uređaj je zapravo odličan način da se unese dodatna logika u sistem. I to ne samo zato što se mnogo novih funkcija može dodati pomoću servisne mreže, već i zato što se to može učiniti bez uplitanja u ekosistem. Zapravo, cijeli model servisne mreže zasnovan je na ovom postulatu: u multiservisnom sistemu, bez obzira na sve napraviti pojedinačne usluge, saobraćaj između njih je idealna točka za dodavanje funkcionalnosti.
Na primjer, u Linkerdu (kao iu većini mreža) funkcionalnost je prvenstveno fokusirana na HTTP pozive, uključujući HTTP/2 i gRPC*. Funkcionalnost je prilično bogata - može se podijeliti u tri klase:
- Povezane karakteristike pouzdanost. Zahtjevi za ponovni pokušaj, vremenska ograničenja, kanarski pristup (podjela saobraćaja/preusmjeravanje) itd.
- Povezane karakteristike praćenje. Agregacija stopa uspješnosti, kašnjenja i obima zahtjeva za svaku uslugu ili pojedinačne destinacije; izrada topoloških karata usluga itd.
- Povezane karakteristike sigurnost. Uzajamni TLS, kontrola pristupa, itd.
* Sa Linkerdove tačke gledišta, gRPC se praktično ne razlikuje od HTTP/2: on samo koristi protobuf u korisnom učitavanju. Sa stanovišta programera, ove dvije stvari su, naravno, različite.
Mnogi od ovih mehanizama rade na nivou zahteva (dakle "L7 proxy"). Na primjer, ako usluga Foo uputi HTTP poziv servisu Bar, linkerd-proxy na Foo-ovoj strani može inteligentno balansirati opterećenje i usmjeriti pozive od Foo do Bar instanci na osnovu uočene latencije; može ponoviti zahtjev ako je potrebno (i ako je idempotentan); on može snimiti kod odgovora i vremensko ograničenje i tako dalje. Slično, linkerd-proxy na strani Bar može odbiti zahtjev ako nije dozvoljen ili ako je ograničenje zahtjeva premašeno; može popraviti kašnjenje sa svoje strane, itd.
Proksiji mogu „učiniti nešto“ i na nivou veze. Na primjer, linkerd-proxy na Foo strani može pokrenuti TLS vezu, a linkerd-proxy na strani Bar može je prekinuti, a obje strane mogu međusobno verifikovati TLS certifikate*. Ovo obezbeđuje ne samo enkripciju između usluga, već i kriptografski siguran način za identifikaciju usluga: Foo i Bar mogu "dokazati" da su oni za koje kažu da jesu.
* "Prijatelj prijatelja" znači da je i sertifikat klijenta verifikovan (mutual TLS). U "klasičnom" TLS-u, na primjer, između pretraživača i servera obično se provjerava certifikat samo jedne strane (servera).
Bilo da rade na nivou zahtjeva ili veze, važno je naglasiti da su sve karakteristike servisne mreže operativni karakter. Linkerd ne može transformirati semantiku korisnog opterećenja, kao što je dodavanje polja u JSON fragment ili unošenje promjena u protobuf. O ovoj važnoj osobini ćemo govoriti kasnije kada budemo govorili o ESB-u i middleware-u.
Ovo je skup funkcija koje nudi servisna mreža. Postavlja se pitanje: zašto ih ne implementirati direktno u aplikaciju? I zašto se uopće petljati sa proxyjem?
Zašto je servisna mreža dobra ideja
Iako su mogućnosti servisne mreže zadivljujuće, njena glavna vrijednost zapravo ne leži u karakteristikama. Na kraju mi Can implementirajte ih direktno u aplikaciju (kasnije ćemo vidjeti da je ovo porijeklo servisne mreže). Da to kažem u jednoj rečenici, vrijednost servisne mreže je: pruža funkcionalnost kritičnu za pokretanje modernog serverskog softvera na konzistentan način na cijelom steku, agnostički kod aplikacije.
Hajde da analiziramo ovaj predlog.
«Funkcije ključne za pokretanje modernog serverskog softvera". Ako gradite transakcijsku serversku aplikaciju povezanu na javni internet koja prihvata zahtjeve iz vanjskog svijeta i odgovara na njih u kratkom vremenu - na primjer, web aplikaciju, API server i veliku većinu drugih modernih aplikacija - i ako ga implementirate kao skup servisa koji sinhrono interaguju jedni s drugima, i ako stalno nadograđujete ovaj softver, dodajete nove funkcije i ako ste prisiljeni održavati ovaj sistem u radnom stanju tokom procesa modifikacije - u ovom slučaju, čestitamo, kreirate moderan serverski softver. I sve te sjajne karakteristike koje su gore navedene zapravo se ispostavljaju kao ključne za vas. Aplikacija mora biti pouzdana, sigurna i morate biti u mogućnosti vidjeti šta radi. Upravo ta pitanja servisna mreža pomaže u rješavanju.
(U redu, moje ubjeđenje da je ovaj pristup moderan način izgradnje serverskog softvera uvuklo se u prethodni pasus. Drugi radije razvijaju monolite, "reaktivne mikroservise" i druge stvari koje ne potpadaju pod gore datu definiciju. Ovi ljudi vjerovatno imaju mišljenje koje se razlikuje od mog, a zauzvrat vjerujem da su "pogrešni" - iako im u svakom slučaju servisna mreža nije od velike koristi).
«Uniforma za ceo snop". Karakteristike koje pruža servisna mreža nisu samo kritične. Primjenjuju se na sve servise u aplikaciji, bez obzira na tome na kom jeziku su napisani, koji okvir koriste, ko ih je napisao, kako su raspoređeni i sve ostale suptilnosti njihovog razvoja i upotrebe.
«Nezavisan od koda aplikacije". Konačno, servisna mreža ne samo da pruža dosljednu funkcionalnost u cijelom steku, već to čini na način koji ne zahtijeva uređivanje aplikacije. Osnovna osnova funkcionalnosti servisne mreže, uključujući zadatke konfigurisanja, ažuriranja, rada, održavanja, itd., je čisto na nivou platforme i nezavisna je od aplikacije. Aplikacija se može promijeniti bez utjecaja na servisnu mrežu. Zauzvrat, servisna mreža se može promijeniti bez ikakve intervencije aplikacije.
Ukratko, servisna mreža ne samo da pruža vitalnu funkcionalnost, već to čini na globalan, uniforman način i način nezavisan od aplikacije. I tako, dok se funkcionalnost mreže servisa može implementirati u kodu usluge (na primjer, kao biblioteka uključena u svaki servis), ovaj pristup neće osigurati uniformnost i nezavisnost koji su toliko vrijedni u slučaju servisna mreža.
I sve što treba da uradite je da dodate gomilu proksija! Obećavam, vrlo brzo ćemo razmotriti operativne troškove povezane s dodavanjem ovih proksija. Ali prvo, hajde da zastanemo i pogledamo ovu ideju nezavisnosti iz perspektive raznih ljudi.
Kome pomaže servisna mreža?
Koliko god to bilo nezgodno, da bi tehnologija postala važan dio ekosistema, ljudi je moraju prihvatiti. Dakle, ko je zainteresovan za servisnu mrežu? Ko ima koristi od njegove upotrebe?
Ako razvijate moderan serverski softver, možete otprilike zamisliti svoj tim kao grupu vlasnicima uslugakoji zajedno razvijaju i implementiraju poslovnu logiku, i vlasnici platformiuključeni u razvoj interne platforme na kojoj ove usluge rade. U malim organizacijama to mogu biti isti ljudi, ali kako kompanija raste, te uloge postaju sve izraženije, pa čak i podijeljene na poduloge... (Ovdje se može puno reći o promjenjivoj prirodi devopsa, organizacioni uticaj mikroservisa, itd.) n. Ali za sada, uzmimo ove opise zdravo za gotovo).
Sa ove tačke gledišta, jasni korisnici servisne mreže su vlasnici platforme. Na kraju krajeva, krajnji cilj platformskog tima je kreiranje interne platforme na kojoj vlasnici servisa mogu implementirati poslovnu logiku i to na način koji im garantuje maksimalnu nezavisnost od mračnih detalja njenog rada. Servisna mreža ne samo da nudi mogućnosti ključne za postizanje ovog cilja, već to čini na način koji, zauzvrat, ne nameće nikakve zavisnosti od vlasnika usluga.
Vlasnici usluga također imaju koristi, iako na indirektniji način. Cilj vlasnika servisa je da bude što produktivniji u implementaciji logike poslovnog procesa, a što manje mora da brine o operativnim problemima, to bolje. Umjesto nametanja, recimo, politika ponovnog pokušaja ili TLS-a, oni se mogu fokusirati isključivo na posao i nadati se da će se platforma pobrinuti za ostalo. Za njih je ovo velika prednost.
Organizaciona vrijednost takve podjele između vlasnika platformi i usluga ne može se precijeniti. Mislim da ona doprinosi glavni doprinos vrijednosti servisne mreže.
Naučili smo ovu lekciju kada nam je jedan rani obožavatelj Linkerda rekao zašto su odabrali servisnu mrežu: jer im je to omogućilo da „pričaju na minimumu“. Evo nekoliko detalja: momci iz jedne velike kompanije migrirali su svoju platformu na Kubernetes. Budući da je aplikacija radila s osjetljivim informacijama, željeli su šifrirati sve komunikacije u klasterima. Međutim, situaciju je zakomplikovalo prisustvo stotina servisa i stotina razvojnih timova. Mogućnost da kontaktiraju sve i ubijede ih da uključe podršku za TLS u svoje planove nije ih nimalo zadovoljila. Instaliranjem Linkerda, oni su migrirali odgovornost od programera (sa čije tačke gledišta je to bila nepotrebna muka) do platformera, kojima je ovo bio prioritet najvišeg nivoa. Drugim riječima, Linkerd je za njih rješavao ne toliko tehnički koliko organizacijski problem.
Ukratko, servisna mreža prije nije tehničko rješenje, već socio-tehničke Problemi. (Hvala ti za uvođenje ovog pojma.
Hoće li servisna mreža riješiti sve moje probleme?
Da. Mislim, ne!
Gledajući tri klase karakteristika koje su gore navedene - pouzdanost, sigurnost i uočljivost - postaje jasno da servisna mreža nije potpuno rješenje ni za jedan od ovih problema. Iako Linkerd može slati ponovljene zahtjeve (ako zna da su idempotentni), nije u poziciji da donosi odluke o tome šta će vratiti korisniku ako se usluga konačno ugasila – takve odluke mora donijeti aplikacija. Linkerd može voditi statistiku o uspješnim zahtjevima, ali nije u mogućnosti da pogleda u uslugu i pruži njene interne metrike - aplikacija bi trebala imati takav set alata. I dok je Linkerd sposoban da hostuje mTLS, punopravna bezbednosna rešenja zahtevaju mnogo više.
Podskup karakteristika u ovim oblastima koje nudi servisna mreža se odnosi na karakteristike platforme. Pod ovim mislim na funkcije koje:
- Nezavisno od poslovne logike. Način na koji se konstruišu histogrami poziva između Foo i Bar potpuno je nezavisan od toga da li zašto Foo zove Bar.
- Teško za ispravnu implementaciju. U Linkerdu, ponovni pokušaji se parametrizuju sa svim vrstama otmjenih stvari kao što su budžeti za ponovni pokušaj. (ponovo probaj budžete), budući da će prostodušan pristup implementaciji ovakvih stvari sigurno dovesti do pojave tzv. "lavine zahtjeva" (ponovni pokušaj oluje) i drugi problemi specifični za distribuirane sisteme.
- Najefikasniji kada se primjenjuje dosljedno. TLS mehanizam ima smisla samo ako se svugdje primjenjuje.
Budući da su ove karakteristike implementirane na proxy sloju (a ne na sloju aplikacije), servisna mreža ih izlaže na platforme, a ne aplikacije. Dakle, nije bitno na kom su jeziku servisi napisani, koji okvir koriste, ko ih je napisao i zašto. Proksiji rade izvan svih ovih detalja, a osnovna osnova ove funkcionalnosti, uključujući zadatke konfigurisanja, ažuriranja, rada, održavanja, itd., leži isključivo na nivou platforme.
Primjeri mogućnosti servisne mreže
Ukratko, servisna mreža nije potpuno rješenje za pouzdanost, uočljivost ili sigurnost. Obim ovih oblasti podrazumeva obavezno učešće vlasnika usluga, Ops/SRE timova i drugih zainteresovanih strana kompanije. Servisna mreža pruža samo "slice" na nivou platforme za svako od ovih područja.
Zašto je servisna mreža postala popularna upravo sada?
Verovatno se sada pitate: OK, ako je servisna mreža tako dobra, zašto nismo počeli da primenjujemo milione proksija na steku pre deset godina?
Na ovo pitanje postoji banalan odgovor: prije deset godina svi su gradili monolite, a servisna mreža nikome nije bila potrebna. To je tačno, ali po mom mišljenju, ovaj odgovor promašuje poentu. Još prije deset godina, koncept mikroservisa kao obećavajućeg načina za kreiranje sistema velikih razmjera bio je naširoko raspravljan i primjenjivan u kompanijama kao što su Twitter, Facebook, Google i Netflix. Opća percepcija - barem u dijelovima industrije s kojima sam bio u kontaktu - bila je da su mikroservise "pravi način" za izgradnju velikih sistema, čak i ako je to bilo prokleto teško.
Naravno, iako su prije deset godina postojale kompanije koje su koristile mikroservise, one nisu stavljale proxy svuda gdje su mogle da formiraju mrežu usluga. Međutim, ako bolje pogledate, uradili su nešto slično: mnoge od ovih kompanija naložile su korištenje posebne interne biblioteke za umrežavanje (koja se ponekad naziva biblioteka debelih klijenata, biblioteka debelih klijenata).
Netflix je imao Hysterix, Google je imao Stubby, Twitter je imao Finagle biblioteku. Finagle je, na primjer, bio obavezan za svaku novu uslugu na Twitteru. Obrađivao je i klijentsku i serversku stranu veza, dozvoljavao je ponovljene zahtjeve, podržavao usmjeravanje zahtjeva, balansiranje opterećenja i mjerenje. Pružao je dosljedan sloj pouzdanosti i vidljivosti na cijelom Twitter steku, bez obzira na to šta servis radi. Naravno, radio je samo za JVM jezike i bio je zasnovan na modelu programiranja koji se morao koristiti za cijelu aplikaciju. Međutim, njegova funkcionalnost je bila gotovo ista kao i servisne mreže. (Zapravo, prva verzija Linkerda bila je samo Finagle umotan u proxy oblik.)
Dakle, prije deset godina nisu postojale samo mikroservise, već i posebne proto-service-mesh biblioteke koje su rješavale iste probleme koje servisna mreža rješava danas. Međutim, sama servisna mreža tada nije postojala. Morala je biti još jedna smjena prije nego što se pojavi.
I tu leži dublji odgovor, skriven u još jednoj promjeni koja se dogodila u proteklih 10 godina: došlo je do oštrog pada troškova implementacije mikroservisa. Gore spomenute kompanije koje su koristile mikrousluge prije deset godina – Twitter, Netflix, Facebook, Google – bile su kompanije ogromnog obima i ogromnih resursa. Ne samo da su imali potrebu, već su imali i mogućnost izgradnje, implementacije i rada velikih aplikacija zasnovanih na mikroservisima. Energija i trud koji su inženjeri Twittera uložili u prelazak sa monolitnog na pristup mikroservisima je nevjerovatan. (Iskreno, kao i činjenica da je upalilo.) Ovakvo infrastrukturno manevrisanje tada je bilo nemoguće za manje kompanije.
Hajdemo u sadašnjost. Danas postoje startupi u kojima je omjer mikroservisa i programera 5:1 (ili čak ), a osim toga, uspješno se nose s njima! Ako je startup od 5 ljudi sposoban da upravlja 50 mikroservisa bez naprezanja, onda je nešto jasno smanjilo troškove njihove implementacije.
1500 mikroservisa u Monzu; svaka linija je propisano mrežno pravilo koje dozvoljava promet
Dramatično smanjenje troškova operativnih mikrousluga rezultat je jednog procesa: rastuća popularnost kontejnera и orkestratori. Upravo je to dubok odgovor na pitanje šta je doprinijelo nastanku servisne mreže. Ista tehnologija učinila je i servisnu mrežu i mikroservise privlačnima: Kubernetes i Docker.
Zašto? Pa, Docker rješava jedan veliki problem - problem pakovanja. Pakovanjem aplikacije i njenih (nemrežnih) ovisnosti o vremenu izvođenja u kontejner, Docker pretvara aplikaciju u zamjenjivu jedinicu koja se može hostirati i pokretati bilo gdje. Istovremeno, uvelike pojednostavljuje rad. višejezičan stek: Pošto je kontejner atomska jedinica izvršenja, nije važno šta je unutra, da li je to JVM, Node, Go, Python ili Ruby aplikacija, za primenu i operativne svrhe. Samo ga pokreneš i to je to.
Kubernetes sve podiže na viši nivo. Sada kada postoji gomila "izvršnih stvari" i mnogo mašina na kojima se mogu pokrenuti, postoji potreba za alatom koji ih može uporediti. U širem smislu, dajete Kubernetesu mnogo kontejnera i mnogo mašina, i on ih međusobno usklađuje (naravno, ovo je dinamičan proces koji se stalno menja: novi kontejneri se kreću po sistemu, mašine se pokreću i zaustavljaju, itd. Međutim, Kubernetes sve ovo uzima u obzir).
Jednom kada je Kubernetes postavljen, vrijeme potrebno za implementaciju i rad jedne usluge ne razlikuje se mnogo od cijene implementacije i rada deset usluga (u stvari, skoro je isto za 100 usluga). Dodajte ovim kontejnerima kao mehanizam za pakovanje koji podstiče višejezičnu implementaciju, i imaćete gomilu novih aplikacija implementiranih kao mikroservise napisane na više jezika, upravo takvo okruženje za koje je servisna mreža tako dobro prilagođena.
Dakle, dolazimo do odgovora na pitanje zašto je ideja o servisnoj mreži postala popularna upravo sada: uniformnost koju Kubernetes pruža za usluge direktno je primjenjiva na operativne zadatke s kojima se servisna mreža suočava. Pakujete proksije u kontejnere, dajete Kubernetesu zadatak da ih zalijepi gdje god je to moguće, i voila! Kao rezultat, dobijate servisnu mrežu, dok Kubernetes kontroliše svu mehaniku njenog postavljanja. (Barem iz ptičje perspektive. Naravno, postoji mnogo nijansi u ovom procesu.)
Da sumiramo: razlog zašto je servisna mreža postala popularna sada, a ne prije deset godina je taj što su Kubernetes i Docker ne samo značajno porasli potreba u njemu, pojednostavljujući implementaciju aplikacija kao skupova višejezičnih mikroservisa, ali i značajno smanjene troškovi za svoj rad obezbeđivanjem mehanizama za postavljanje i održavanje proxy parkova bočnih prikolica.
Zašto se toliko priča o servisnoj mreži?
Prevencija: U ovom dijelu pribjegavam raznim pretpostavkama, nagađanjima, izmišljotinama i povlaštenim informacijama.
Potraga za "servisnom mrežom" će otkriti gomilu recikliranih, niskokaloričnih sadržaja, čudnih projekata i kaleidoskopa izobličenja dostojnog eho komore. Svaka moderna nova tehnologija to ima, ali u slučaju servisne mreže, problem je posebno akutan. Zašto?
Pa, dijelom sam ja kriv. Dao sam sve od sebe da promoviram Linkerd i servisnu mrežu u svakoj prilici, kroz bezbroj postova na blogu i članaka poput ovog. Ali nisam toliko moćan. Da bismo zaista odgovorili na ovo pitanje, moramo malo porazgovarati o općoj situaciji. A o tome je nemoguće govoriti a da se ne spomene jedan projekat: je open source servisna mreža koju su zajednički razvili Google, IBM i Lyft.
(Te tri kompanije imaju veoma različite uloge: čini se da je učešće Lyfta ograničeno samo na ime; autori su Envoy-a, ali ne koriste ili su uključeni u razvoj Istio-a. IBM je uključen u razvoj Istio-a i koristi ga. Google je u velikoj mjeri uključen u razvoj Istio-a, ali koliko ja mogu reći, zapravo ga ne koristi.)
Projekat Istio je prepoznatljiv po dvije stvari. Prvo, to je ogroman marketinški napor koji Google, posebno, ulaže u svoju promociju. Procjenjujem da je većina ljudi koji su trenutno svjesni koncepta servisne mreže prvi put saznali za njega zahvaljujući Istio-u. Druga karakteristika je koliko je Istio loše primljen. Po ovom pitanju, ja sam, očigledno, zainteresovana strana, ali pokušavajući da ostanem što objektivniji, ipak ne mogu a da ne , nije baš specifično (iako nije jedinstveno: sistemd mi pada na pamet, ...) za projekat otvorenog koda.
(U praksi se čini da Istio ima problema ne samo sa složenošću i UX-om, već i sa performansama. Na primjer, tokom koje je provela treća strana, stručnjaci su pronašli situacije u kojima je Istio rep latencija bio 100 puta veći od Linkerdovog, kao i situacije s nedostatkom resursa, kada je Linkerd nastavio uspješno funkcionirati, a Istio je potpuno prestao raditi.)
Ostavljajući po strani moje teorije o tome zašto se to dogodilo, vjerujem da je pompa oko mreže usluga uzrokovana umiješanošću Googlea. Naime, kombinacija sljedeća tri faktora:
- opsesivna promocija Istio od strane Googlea;
- odgovarajući neodobravajući, kritički odnos prema projektu;
- nedavna naglo rastuća popularnost Kubernetesa, čije je sjećanje još uvijek svježe.
Zajedno, ovi faktori se spajaju u neku vrstu opojnog, anoksičnog okruženja u kojem je sposobnost racionalnog prosuđivanja oslabljena i ostaje samo divna raznolikost. .
Sa Linkerdove tačke gledišta, ovo je... Ja bih to opisao kao mješoviti blagoslov. Mislim, sjajno je što je servisna mreža ušla u mainstream – što nije bio slučaj 2016. godine kada se Linkerd prvi put pojavio i bilo je zaista teško privući pažnju ljudi na projekat. Sada nema takvog problema! Ali loša vijest je da je situacija s servisnom mrežom danas toliko zbunjujuća da je gotovo nemoguće otkriti koji projekti zaista pripadaju kategoriji servisne mreže (a kamoli otkriti koji je najbolji za određeni slučaj upotrebe). Ovo svakako svima smeta (a definitivno je u nekim slučajevima Istio ili neki drugi projekt bolji od Linkerda, budući da potonji nije rješenje za sve).
Sa Linkerdove strane, naša strategija je bila da ignorišemo buku, nastavimo da se fokusiramo na rešavanje stvarnih problema u zajednici, i u suštini čekamo da se hype ugasi. Na kraju će pompa splasnuti i možemo nastaviti raditi u miru.
Do tada, svi ćemo morati biti strpljivi.
Hoće li servisna mreža biti korisna meni, skromnom softverskom inženjeru?
Sljedeći upitnik će vam pomoći da odgovorite na ovo pitanje:
Bavite li se isključivo implementacijom poslovne logike? U ovom slučaju, servisna mreža vam neće biti od koristi. To bi vas, naravno, moglo zanimati, ali u idealnom slučaju servisna mreža ne bi trebala direktno utjecati na ništa u vašem okruženju. Nastavite da radite na onome za šta ste plaćeni.
Da li održavate platformu u kompaniji koja koristi Kubernetes? Da, u ovom slučaju vam je potrebna servisna mreža (naravno, ako ne koristite K8s samo za pokretanje monolitne ili batch obrade - ali onda bih želio da pitam zašto vam treba K8s). Najvjerovatnije ćete se naći u situaciji s mnogo mikroservisa koje su napisali različiti ljudi. Svi oni stupaju u interakciju jedni s drugima i vezani su u splet ovisnosti o vremenu izvršavanja, a vi morate pronaći način da se nosite sa svim tim. Upotreba Kubernetesa omogućava vam da odaberete servisnu mrežu "za sebe". Da biste to učinili, upoznajte se s njihovim mogućnostima i karakteristikama i odgovorite na pitanje da li vam neki od dostupnih projekata uopće odgovara (preporučujem da svoje istraživanje započnete s Linkerdom).
Da li koristite platformu za kompaniju 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 da možete imitirati service mesh hostovanjem gomile proksija, ali važna prednost Kubernetesa je upravo model implementacije: ručno održavanje ovih proksija zahteva mnogo više vremena, truda i troškova.
Da li ste zaduženi za platformu u kompaniji koja radi sa monolitima? U ovom slučaju, vjerovatno vam ne treba servisna mreža. Ako radite s monolitima (ili čak skupovima monolita) koji imaju dobro definirane i rijetko promjenjive obrasce interakcije, tada vam servisna mreža nema mnogo toga za ponuditi. Tako da ga možete jednostavno ignorisati i nadati se da će nestati kao ružan san...
zaključak
Vjerovatno, servisnu mrežu još uvijek ne treba nazivati „najnaglašenijom tehnologijom na svijetu“ - ova sumnjiva čast vjerojatno pripada bitcoinu ili AI. Možda je u prvih pet. Ali ako se probijete kroz slojeve buke i buke, postaje jasno da servisna mreža donosi stvarne prednosti onima koji kreiraju aplikacije u Kubernetesu.
Želio bih da isprobate Linkerd - instalirate ga u Kubernetes klaster (ili čak Minikube na laptopu) i sami vidite o čemu pričam.
FAQ
- Ako zanemarim servisnu mrežu, hoće li nestati?
- Moram vas razočarati: servisna mreža je kod nas dugo vremena.
— Ali NE ŽELIM koristiti servisnu mrežu!
- Pa nije potrebno! Samo pročitajte moj upitnik iznad da vidite da li biste se trebali barem upoznati s njegovim osnovama.
— Nije li to dobri stari ESB/middleware sa novim sosom?
- Servisna mreža se bavi operativnom logikom, a ne semantičkom. poslovni autobus za usluge (). Održavanje ovog razdvajanja pomaže servisnoj mreži da izbjegne istu sudbinu.
- Kako se servisna mreža razlikuje od API gatewaya?
Postoji milion članaka na ovu temu. Samo google.
Da li je Envoy servisna mreža?
- Ne, Envoy nije servisna mreža, to je proxy server. Može se koristiti za organiziranje servisne mreže (i još mnogo toga - to je proxy opće namjene). Ali samo po sebi, to nije servisna mreža.
- Network Service Mesh - da li je to servisna mreža?
- Ne. Unatoč imenu, ovo nije servisna mreža (kako vam se sviđaju čuda marketinga?).
- Hoće li servisna mreža pomoći mom reaktivnom asinhronom sistemu zasnovanom na redu poruka?
- Ne, servisna mreža ti neće pomoći.
- Koju servisnu mrežu da koristim?
- , nema pameti.
- Članak je sranje! / Autor - na sapunu!
— Molimo podijelite link do njega sa svim svojim prijateljima kako bi se mogli uvjeriti u ovo!
Zahvalnice
Kao što možete pretpostaviti iz naslova, ovaj članak je inspiriran fantastičnom raspravom Jaya Krepsa "". Upoznala sam Jaya prije deset godina dok sam radila intervju na Linked Inu i on mi je od tada inspiracija.
Iako volim sebe da nazivam "Linkard programerom", stvarnost je da sam više održavalac datoteke README.md u projektu. Danas radim na Linkerdu , , ljudi, a ovaj projekat ne bi bio moguć bez nevjerovatne zajednice saradnika i korisnika.
I na kraju, posebno hvala kreatoru Linkerda, (primus inter pares), koji je zajedno sa mnom prije mnogo godina bezglavo uronio u svu ovu gužvu sa servisnom mrežom.
PS od prevodioca
Pročitajte i na našem blogu:
- «»;
- «»;
- «»;
- «»;
- «".
izvor: www.habr.com