Poznámka. preklad.: Servisná sieť je fenomén, ktorý ešte nemá stabilný preklad do ruštiny (pred viac ako 2 rokmi sme navrhli možnosť „sieťka pre služby“ a o niečo neskôr niektorí kolegovia začali aktívne propagovať kombináciu „servisné sito“). Neustále reči o tejto technológii viedli k situácii, v ktorej sú marketingové a technické zložky príliš úzko prepojené. Tento úžasný materiál od jedného z autorov pôvodného termínu má poskytnúť prehľadnosť pre inžinierov a iných.
Komiks od
Úvod
Ak ste softvérový inžinier pracujúci niekde v oblasti backendových systémov, výraz „servisná sieť“ sa vám za posledných pár rokov pravdepodobne už pevne zakorenil. Vďaka zvláštnej zhode okolností sa toto slovné spojenie čoraz viac zmocňuje tohto odvetvia a hype a súvisiace propagačné ponuky rastú ako snehová guľa, lietajú z kopca a nevykazujú žiadne známky spomalenia.
Obslužná sieť sa zrodila v kalných, tendenčných vodách cloudového pôvodného ekosystému. Nanešťastie to znamená, že veľká časť kontroverzie, ktorá ho obklopuje, siaha od „nízkokalorického klábosenia“ až po – povedané odborným výrazom – nehorázne kecy. Ale ak odfiltrujete všetok hluk, zistíte, že servisná sieť má veľmi reálnu, jednoznačnú a dôležitú funkciu.
V tomto príspevku sa pokúsim urobiť práve to: poskytnúť čestný, hĺbkový, inžiniersky orientovaný sprievodca servisnou sieťou. Odpoviem nielen na otázku: "Čo to je?", - ale tiež "Prečo?"a "Prečo teraz?". Na záver sa pokúsim načrtnúť, prečo (podľa mňa) práve táto technológia vyvolala taký šialený hype, čo je samo o sebe zaujímavý príbeh.
Kto som?
Ahojte všetci! Moje meno je . Som jedným z tvorcov — úplne prvý sieťový projekt služieb a projekt, ktorý má na svedomí vzhľad tohto výrazu servisné pletivo ako také (prepáčte chlapci!). (Poznámka prel.: Mimochodom, na úsvite objavenia sa tohto termínu, pred viac ako 2,5 rokmi, sme už preložili raný materiál toho istého autora s názvom „".) Tiež vediem je startup, ktorý vytvára skvelé služby typu „sieťoviek“ ako Linkerd a .
Asi tušíte, že mám na túto problematiku veľmi zaujatý a subjektívny názor. Pokúsim sa však obmedziť zaujatosť na minimum (s výnimkou jednej časti: "Prečo sa toľko hovorí o servisnej sieti?", - v ktorej sa napriek tomu podelím o svoje predsudky). Urobím tiež všetko pre to, aby bola táto príručka čo najobjektívnejšia. V konkrétnych príkladoch sa budem spoliehať najmä na skúsenosti Linkerdu, pričom poukážem na rozdiely (ak nejaké sú), o ktorých viem pri implementácii iných typov service mesh.
Dobre, je čas prejsť na maškrty.
Čo je to servisná sieť?
Napriek všetkému humbuku je štruktúra servisnej siete pomerne jednoduchá. Toto je len skupina proxy používateľského priestoru umiestnených „vedľa“ služieb (o tom, čo je „ďalšie“, si niečo povieme neskôr), plus súbor riadiacich procesov. Proxy sa nazývajú spoločne dátová rovinaa riadiace procesy sa nazývajú riadiaca rovina. Dátová rovina zachytáva hovory medzi službami a robí s nimi „čokoľvek iné“; kontrolná rovina, respektíve koordinuje správanie proxy a poskytuje prístup pre vás, t.j. operátora, do API, čo umožňuje manipuláciu a meranie siete ako celku.
Čo je to proxy? Toto je TCP proxy kategórie "Layer 7-aware". (t. j. "berúc do úvahy" 7. vrstvu modelu OSI) ako HAProxy a NGINX. Môžete si vybrať proxy podľa svojich predstáv; Linkerd používa proxy server Rust, nekomplikovane pomenovaný . Zostavili sme ho špeciálne pre servisnú sieť. Iné siete uprednostňujú iné proxy (Envoy je bežnou voľbou). Výber proxy je však len otázkou implementácie.
Čo robia tieto proxy servery? Je zrejmé, že zastupujú hovory do a zo služieb (presne povedané, fungujú ako proxy a reverzné proxy, ktoré spracovávajú prichádzajúce aj odchádzajúce hovory). A implementujú sadu funkcií, ktorá sa zameriava na hovory medzi služby. Toto zameranie na prevádzku medzi službami je to, čo odlišuje server proxy siete od, povedzme, brán API alebo vstupných proxy serverov (posledné sa zameriavajú na volania prichádzajúce do klastra z vonkajšieho sveta). (Poznámka. preklad.: Porovnanie existujúcich ovládačov Kubernetes Ingress, z ktorých mnohé využívajú už spomínaný Envoy, nájdete na .)
Takže sme prišli na dátovú rovinu. Riadiaca rovina je jednoduchšia: je to súbor komponentov, ktoré poskytujú všetku mechaniku, ktorú dátová rovina potrebuje, aby fungovala koordinovaným spôsobom, vrátane zisťovania služieb, vydávania certifikátov TLS, agregácie metrík atď. Dátová rovina informuje riadiacu rovinu o jeho správanie; riadiaca rovina zase poskytuje API, ktoré vám umožňuje meniť a sledovať správanie dátovej roviny ako celku.
Nižšie je uvedený diagram riadiacej roviny a dátovej roviny v Linkerd. Ako vidíte, riadiaca rovina obsahuje niekoľko rôznych komponentov vrátane inštancie Prometheus, ktorá zhromažďuje metriky z proxy serverov, ako aj ďalšie komponenty, ako napr. destination (objavenie služby), identity (certifikačná autorita, CA) a public-api (koncové body pre web a CLI). Naproti tomu dátová rovina je jednoduchý linkerd-proxy vedľa inštancie aplikácie. Toto je len logický diagram; v nasadení v reálnom svete môžete mať tri repliky každého komponentu riadiacej roviny a stovky alebo tisíce proxy v dátovej rovine.
(Modré obdĺžniky v tomto diagrame symbolizujú hranice Kubernetes podov. Môžete vidieť, že kontajnery s linkerd-proxy sú v rovnakej pod ako aplikačné kontajnery. Táto schéma je známa ako kontajner postranného vozíka.)
Architektúra siete služieb má niekoľko dôležitých dôsledkov. Po prvé, keďže úlohou servera proxy je zachytávať hovory medzi službami, sieť služieb má zmysel iba vtedy, ak bola vaša aplikácia vytvorená pre súbor služieb. pletivo jeden môže použitie s monolitmi, ale to je zjavne nadbytočné kvôli jedinému proxy a jeho funkčnosť pravdepodobne nebude žiadaná.
Ďalším dôležitým dôsledkom je, že servisná sieť vyžaduje obrovský počet proxy. V skutočnosti Linkerd pripája linkerd-proxy ku každej inštancii každej služby (iné implementácie pridávajú proxy ku každému uzlu/hostiteľovi/virtuálnemu stroju. Aj tak je to veľa). Takéto aktívne používanie serverov proxy so sebou nesie množstvo ďalších komplikácií:
- Proxy v dátovej rovine by mali byť rýchlo, pretože pre každý hovor existuje niekoľko hovorov na server proxy: jeden na strane klienta, jeden na strane servera.
- Tiež musia byť proxy malý и ľahký. Každý bude spotrebovávať pamäť a zdroje CPU a táto spotreba bude rásť lineárne s aplikáciou.
- Na nasadenie a aktualizáciu veľkého počtu serverov proxy budete potrebovať mechanizmus. Robiť to ručne nie je možné.
Vo všeobecnosti vyzerá sieť služieb takto (aspoň z vtáčej perspektívy): nasadíte množstvo proxy používateľského priestoru, ktoré „niečo urobia“ s internou medziservisnou prevádzkou a na ich monitorovanie a správu používate riadiacu rovinu.
Je čas na otázku "Prečo?"
Na čo slúži servisná sieť?
Pre tých, ktorí sa prvýkrát stretli s myšlienkou servisnej siete, je odpustené byť trochu v úžase. Dizajn sieťky služieb znamená, že nielen zvýši latenciu aplikácie, ale aj zvýši konzumovať zdrojov a pridá veľa nových mechanizmov v infraštruktúre. Najprv nastavíte sieť služieb a potom zrazu zistíte, že potrebujete obsluhovať stovky (ak nie tisíce) serverov proxy. Otázkou je, kto sa k tomu dobrovoľne prihlási?
Odpoveď na túto otázku má dve časti. Po prvé, transakčné náklady spojené s nasadením týchto proxy môžu byť výrazne znížené v dôsledku niektorých zmien, ktoré prebiehajú v ekosystéme (viac o tom neskôr).
Po druhé, takéto zariadenie je v skutočnosti skvelým spôsobom, ako do systému zaviesť dodatočnú logiku. Nielen preto, že sieť služieb môže pridať veľa nových funkcií, ale aj preto, že to možno urobiť bez zásahu do ekosystému. V skutočnosti je celý model servisnej siete založený na tomto predpoklade: v multiservisnom systéme, bez ohľadu na to, čo robiť jednotlivé služby, návštevnosť medzi nimi je ideálnym bodom na pridanie funkčnosti.
Napríklad v Linkerd (ako vo väčšine sietí) je funkčnosť zameraná predovšetkým na volania HTTP, vrátane HTTP/2 a gRPC*. Funkčnosť je pomerne bohatá - možno ju rozdeliť do troch tried:
- Funkcie súvisiace s spoľahlivosť. Požiadavky na zopakovanie, časové limity, kanársky prístup (rozdelenie/presmerovanie návštevnosti) atď.
- Funkcie súvisiace s monitorovanie. Agregácia mier úspešnosti, oneskorení a objemov žiadostí pre každú službu alebo jednotlivé destinácie; budovanie topologických máp služieb a pod.
- Funkcie súvisiace s bezpečnosť. Vzájomné TLS, kontrola prístupu atď.
* Z pohľadu Linkerdu sa gRPC prakticky nelíši od HTTP/2: používa len protobuf v užitočnej časti. Z pohľadu vývojára sú tieto dve veci, samozrejme, odlišné.
Mnohé z týchto mechanizmov fungujú na úrovni požiadaviek (preto „proxy L7“). Napríklad, ak služba Foo uskutoční HTTP volanie do servisného panela, linkerd-proxy na strane Foo môže inteligentne vyvažovať záťaž a smerovať hovory z inštancií Foo do Bar na základe pozorovanej latencie; v prípade potreby môže žiadosť zopakovať (a ak je idempotentná); môže zaznamenať kód odpovede a časový limit atď. Podobne môže linkerd-proxy na strane Bar odmietnuť požiadavku, ak to nie je povolené alebo ak je prekročený limit žiadosti; môže opraviť oneskorenie zo svojej strany atď.
Proxy môžu „niečo robiť“ aj na úrovni pripojenia. Napríklad linkerd-proxy na strane Foo môže iniciovať TLS pripojenie a linkerd-proxy na strane Bar ho môže ukončiť a obe strany si môžu navzájom overiť svoje TLS certifikáty*. To poskytuje nielen šifrovanie medzi službami, ale aj kryptograficky bezpečný spôsob identifikácie služieb: Foo a Bar môžu „dokázať“, že sú tým, za koho sa vydávajú.
* "Vzájomný priateľ" znamená, že je overený aj klientsky certifikát (vzájomné TLS). V „klasickom“ TLS, napríklad medzi prehliadačom a serverom, sa zvyčajne overuje certifikát iba jednej strany (servera).
Či už fungujú na úrovni požiadavky alebo pripojenia, je dôležité zdôrazniť, že všetky funkcie siete služieb sú operatívne charakter. Linkerd nedokáže transformovať sémantiku užitočného zaťaženia, ako je pridávanie polí do fragmentu JSON alebo vykonávanie zmien v protobuf. O tejto dôležitej funkcii si povieme neskôr, keď budeme hovoriť o ESB a middleware.
Toto je súbor funkcií, ktoré ponúka sieť služieb. Vynára sa otázka: prečo ich neimplementovať priamo do aplikácie? A načo sa vôbec baviť s proxy?
Prečo je servisná sieť dobrý nápad
Aj keď sú možnosti servisnej siete očarujúce, jej hlavná hodnota skutočne nespočíva vo funkciách. Nakoniec my Môcť implementovať ich priamo v aplikácii (neskôr uvidíme, že to bol pôvod servisnej siete). Aby som to vyjadril jednou vetou, hodnota servisnej siete je: poskytuje funkcionalitu kritickú pre spustenie moderného serverového softvéru konzistentným spôsobom bez ohľadu na aplikačný kód.
Poďme analyzovať tento návrh.
«Funkcie kritické pre spustenie moderného serverového softvéru". Ak budujete transakčnú serverovú aplikáciu pripojenú na verejný internet, ktorá prijíma požiadavky z vonkajšieho sveta a odpovedá na ne v krátkom čase – napríklad webová aplikácia, API server a veľká väčšina iných moderných aplikácií – a ak ho implementujete ako súbor služieb, ktoré navzájom synchrónne interagujú, a ak tento softvér neustále aktualizujete, pridávate nové funkcie a ak ste nútení udržiavať tento systém vo funkčnom stave počas procesu modifikácie – v tomto prípade, gratulujeme, vytvárate moderný serverový softvér. A všetky tieto skvelé funkcie uvedené vyššie sa v skutočnosti ukážu ako rozhodujúce pre vás. Aplikácia musí byť spoľahlivá, bezpečná a musíte byť schopní vidieť, čo robí. Práve tieto otázky pomáha vyriešiť servisná sieť.
(OK, predchádzajúci odsek stále obsahuje moje presvedčenie, že tento prístup je moderný spôsob vytvárania serverového softvéru. Iní uprednostňujú vývoj monolitov, „reaktívnych mikroslužieb“ a iných vecí, ktoré nespadajú pod definíciu uvedenú vyššie. Títo ľudia majú pravdepodobne svoje Na druhej strane si myslím, že sa "mýlia" - aj keď v každom prípade nie je pre nich servisná sieť veľmi užitočná).
«Uniforma pre celý stoh". Funkcie, ktoré poskytuje servisná sieť, nie sú len kritické. Vzťahujú sa na všetky služby v aplikácii, bez ohľadu na to, v akom jazyku sú napísané, aký framework používajú, kto ich napísal, ako boli nasadené a akékoľvek ďalšie jemnosti ich vývoja a používania.
«Nezávislosť na kóde aplikácie". Nakoniec, sieť služieb nielenže poskytuje konzistentnú funkčnosť v rámci celého zásobníka, ale robí to spôsobom, ktorý nevyžaduje úpravu aplikácie. Základný základ funkčnosti siete služieb, vrátane úloh konfigurácie, aktualizácie, prevádzky, údržby atď., je čisto na úrovni platformy a je nezávislý od aplikácie. Aplikácia sa môže zmeniť bez ovplyvnenia siete služieb. Na druhej strane, sieť služieb sa môže zmeniť bez akéhokoľvek zásahu aplikácie.
Stručne povedané, sieť služieb poskytuje nielen životne dôležité funkcie, ale robí to globálnym, jednotným a na aplikácii nezávislým spôsobom. A tak, zatiaľ čo funkčnosť siete služieb môže byť implementovaná v kóde služby (napríklad ako knižnica zahrnutá v každej službe), tento prístup nezabezpečí jednotnosť a nezávislosť, ktorá je taká cenná v prípade služby. servisné pletivo.
A všetko, čo musíte urobiť, je pridať veľa proxy serverov! Sľubujem, že už čoskoro sa pozrieme na prevádzkové náklady spojené s pridaním týchto proxy. Najprv sa však zastavme a pozrime sa na túto myšlienku nezávislosti z perspektívy rôznych ľudia.
Komu servisná sieť pomáha?
Akokoľvek je to nepohodlné, aby sa technológia stala dôležitou súčasťou ekosystému, ľudia ju musia akceptovať. Kto má teda záujem o servisné pletivo? Kto profituje z jej používania?
Ak vyvíjate moderný serverový softvér, môžete si zhruba predstaviť svoj tím ako skupinu vlastníkov služiebktorí spoločne vyvíjajú a implementujú obchodnú logiku a vlastníkov platformypodieľajú sa na vývoji internej platformy, na ktorej tieto služby bežia. V malých organizáciách to môžu byť tí istí ľudia, ale ako spoločnosť rastie, tieto roly majú tendenciu sa zvýrazniť a dokonca sa rozdelia na podrole... (Tu sa dá veľa povedať o meniacej sa povahe devops, organizačný vplyv mikroslužieb atď.).
Z tohto hľadiska sú jasnými príjemcami siete služieb majitelia platforiem. Koniec koncov, cieľom tímu platformy je vytvoriť internú platformu, na ktorej môžu vlastníci služieb implementovať obchodnú logiku a robiť to spôsobom, ktorý zaisťuje, že budú čo najviac nezávislí od nejasných detailov jej fungovania. Sieť služieb nielenže ponúka schopnosti, ktoré sú dôležité na dosiahnutie tohto cieľa, ale robí to spôsobom, ktorý na druhej strane nevytvára závislosť od vlastníkov služieb.
Z toho profitujú aj vlastníci služieb, aj keď nepriamo. Cieľom vlastníka služby je byť čo najproduktívnejší pri implementácii logiky obchodného procesu a čím menej sa bude musieť starať o prevádzkové záležitosti, tým lepšie. Namiesto presadzovania, povedzme, opakovaných zásad alebo TLS, sa môžu sústrediť výlučne na podnikanie a dúfať, že platforma sa postará o zvyšok. Pre nich je to veľká výhoda.
Organizačnú hodnotu takéhoto rozdelenia medzi vlastníkov platforiem a služieb nemožno preceňovať. Myslím, že prispieva hlavné príspevok k hodnote servisnej siete.
Túto lekciu sme sa naučili, keď nám prvý fanúšik Linkerdu povedal, prečo si vybrali sieť služieb: pretože im to umožnilo „hovoriť na minime“. Tu sú niektoré podrobnosti: chlapci z jednej veľkej spoločnosti migrovali svoju platformu na Kubernetes. Keďže aplikácia pracovala s citlivými informáciami, chceli celú komunikáciu v klastroch šifrovať. Situáciu však komplikovala prítomnosť stoviek služieb a stoviek vývojových tímov. Vidina, že všetkých osloví a presvedčí ich, aby do svojich plánov zahrnuli podporu TLS, ich vôbec nepotešila. Inštaláciou Linkerdu migrovali zodpovednosť od vývojárov (z pohľadu ktorých to boli zbytočné problémy) až po platformistov, pre ktorých to bola priorita najvyššej úrovne. Inými slovami, Linkerd pre nich neriešil ani tak technický problém, ako skôr organizačný.
Stručne povedané, servisná sieť nie je skôr technickým riešením, ale sociálno-technické Problémy. (Ďakujem na uvedenie tohto pojmu.)
Vyrieši servisná sieť všetky moje problémy?
Áno. Teda nie!
Pri pohľade na tri triedy funkcií načrtnutých vyššie – spoľahlivosť, bezpečnosť a pozorovateľnosť – je jasné, že sieť služieb nie je úplným riešením žiadneho z týchto problémov. Aj keď Linkerd môže posielať opakované požiadavky (ak vie, že sú idempotentné), nemôže rozhodovať o tom, čo má vrátiť používateľovi, ak služba konečne nefunguje – takéto rozhodnutia musí urobiť aplikácia. Linkerd môže viesť štatistiky o úspešných požiadavkách, ale nie je schopný nahliadnuť do služby a poskytnúť jej interné metriky - aplikácia by mala mať takúto sadu nástrojov. A zatiaľ čo Linkerd je schopný hostiť mTLS, plnohodnotné bezpečnostné riešenia vyžadujú oveľa viac.
Súvisí to s podmnožinou funkcií v týchto oblastiach, ktoré ponúka sieť služieb funkcie platformy. Mám tým na mysli funkcie, ktoré:
- Nezávislé od obchodnej logiky. Spôsob, akým sa vytvárajú histogramy hovorov medzi Foo a Bar, je úplne nezávislý od toho, či prečo Foo volá Bar.
- Je ťažké správne implementovať. V Linkerd sú opakované pokusy parametrizované so všetkými druhmi efektných vecí, ako sú rozpočty na opakované pokusy (skúste znova rozpočty), keďže jednoducho zmýšľajúci prístup k realizácii takýchto vecí určite povedie k vzniku takzvanej „lavíny žiadostí“ (opakovať búrku) a ďalšie problémy špecifické pre distribuované systémy.
- Najúčinnejšie pri dôslednej aplikácii. Mechanizmus TLS má zmysel len vtedy, ak sa aplikuje všade.
Pretože tieto funkcie sú implementované na vrstve proxy (a nie na aplikačnej vrstve), servisná sieť ich odhaľuje na plošina, nie aplikácie. Nezáleží teda na tom, v akom jazyku sú služby napísané, aký framework používajú, kto ich napísal a prečo. Proxy fungujú nad rámec všetkých týchto detailov a základný základ tejto funkčnosti, vrátane úloh konfigurácie, aktualizácie, prevádzky, údržby atď., leží výlučne na úrovni platformy.
Príklady možností servisnej siete
Stručne povedané, servisná sieť nie je úplným riešením spoľahlivosti, pozorovateľnosti alebo bezpečnosti. Rozsah týchto oblastí zahŕňa povinnú účasť vlastníkov služieb, tímov Ops / SRE a ďalších zainteresovaných strán spoločnosti. Sieť služieb poskytuje iba „výrez“ na úrovni platformy pre každú z týchto oblastí.
Prečo sa servisná sieť stala populárnou práve teraz?
Pravdepodobne sa teraz pýtate: OK, ak je sieť služieb taká dobrá, prečo sme nezačali nasadzovať milióny proxy serverov na zásobník pred desiatimi rokmi?
Na túto otázku existuje banálna odpoveď: pred desiatimi rokmi každý staval monolity a nikto nepotreboval servisnú sieť. To je pravda, ale podľa mňa sa táto odpoveď míňa pointou. Ešte pred desiatimi rokmi bol koncept mikroslužieb ako sľubný spôsob budovania rozsiahlych systémov široko diskutovaný a aplikovaný v spoločnostiach ako Twitter, Facebook, Google a Netflix. Všeobecný názor – aspoň v častiach odvetvia, s ktorými som prišiel do kontaktu – bol taký, že mikroslužby sú „správnou cestou“ na budovanie veľkých systémov, aj keď to bolo sakramentsky ťažké.
Samozrejme, aj keď pred desiatimi rokmi existovali spoločnosti využívajúce mikroslužby, nenalepili proxy všade, kde sa dalo, aby vytvorili sieť služieb. Ak sa však pozriete pozorne, urobili niečo podobné: mnohé z týchto spoločností nariadili používanie špeciálnej internej knižnice na vytváranie sietí (niekedy nazývanej knižnica tučných klientov, knižnica tučných klientov).
Netflix mal Hysterix, Google mal Stubby, Twitter mal knižnicu Finagle. Finagle bol napríklad povinný pre každú novú službu na Twitteri. Zaoberal sa klientskou aj serverovou stranou pripojení, umožňoval opakované požiadavky, podporoval smerovanie požiadaviek, vyrovnávanie záťaže a meranie. Poskytoval konzistentnú úroveň spoľahlivosti a pozorovateľnosti v rámci celého zásobníka Twitteru bez ohľadu na to, čo služba robila. Samozrejme, fungoval iba pre jazyky JVM a bol založený na programovacom modeli, ktorý bolo potrebné použiť pre celú aplikáciu. Jeho funkčnosť však bola takmer rovnaká ako u servisnej siete. (V skutočnosti prvá verzia Linkerd bola jednoducho Finagle zabalená v proxy forme.)
Pred desiatimi rokmi teda existovali nielen mikroslužby, ale aj špeciálne proto-service-mesh knižnice, ktoré riešili rovnaké problémy, aké dnes rieši servisná sieť. Samotné služobné pletivo však vtedy neexistovalo. Než sa objavila, musela nastať ďalšia zmena.
A práve tu sa skrýva hlbšia odpoveď ukrytá v ďalšej zmene, ktorá sa udiala za posledných 10 rokov: došlo k prudkému poklesu nákladov na nasadenie mikroslužieb. Vyššie uvedené spoločnosti, ktoré pred desiatimi rokmi využívali mikroslužby – Twitter, Netflix, Facebook, Google – boli spoločnosti obrovského rozsahu a obrovských zdrojov. Mali nielen potrebu, ale aj schopnosť vytvárať, nasadzovať a prevádzkovať veľké aplikácie založené na mikroslužbách. Energia a úsilie, ktoré inžinieri Twitteru vložili do prechodu od monolitického prístupu k mikroslužbám, sú úžasné. (Úprimne povedané, rovnako ako skutočnosť, že to fungovalo.) Tento druh manévrovania s infraštruktúrou bol vtedy pre menšie spoločnosti nemožný.
Presuňme sa do súčasnosti. Dnes existujú startupy, kde je pomer mikroslužieb k vývojárom 5:1 (alebo dokonca ), a navyše sa s nimi úspešne vyrovnávajú! Ak 5-členný startup dokáže bez problémov prevádzkovať 50 mikroslužieb, tak niečo jednoznačne znížilo náklady na ich implementáciu.
1500 mikroslužieb v Monze; každá linka je predpísaným sieťovým pravidlom, ktoré povoľuje prevádzku
Dramatické zníženie nákladov na prevádzku mikroslužieb je výsledkom jedného procesu: rastúca popularita kontajnerov и orchestrátorov. Presne toto je hlboká odpoveď na otázku, čo prispelo k vzniku obslužného pletiva. Rovnaká technológia zatraktívnila servisné siete aj mikroslužby: Kubernetes a Docker.
prečo? No, Docker rieši jeden veľký problém – problém balenia. Zabalením aplikácie a jej (nie sieťových) runtime závislostí do kontajnera Docker premení aplikáciu na vymeniteľnú jednotku, ktorú je možné hostiť a spustiť kdekoľvek. Zároveň výrazne zjednodušuje obsluhu. viacjazyčný zásobník: Keďže kontajner je atómová jednotka vykonávania, nezáleží na tom, čo je vo vnútri, či je to aplikácia JVM, Node, Go, Python alebo Ruby, na účely nasadenia a prevádzky. Jednoducho to spustíte a je to.
Kubernetes posúva všetko na ďalšiu úroveň. Teraz, keď existuje veľa „spustiteľných vecí“ a veľa strojov, na ktorých ich možno spustiť, je potrebný nástroj, ktorý ich dokáže navzájom porovnávať. V širšom zmysle dáte Kubernetesu veľa kontajnerov a veľa strojov a on ich navzájom spája (samozrejme, ide o dynamický a neustále sa meniaci proces: nové kontajnery sa pohybujú po systéme, stroje sa spúšťajú a zastavujú atď.). Kubernetes toto všetko zohľadňuje).
Po nastavení Kubernetes sa čas potrebný na nasadenie a prevádzku jednej služby príliš nelíši od nákladov na nasadenie a prevádzku desiatich služieb (v skutočnosti je to takmer rovnaké pre 100 služieb). Pridajte k týmto kontajnerom mechanizmus balenia, ktorý podporuje viacjazyčnú implementáciu, a máte veľa nových aplikácií implementovaných ako mikroslužby napísané vo viacerých jazykoch, presne do takého prostredia, na ktoré sa sieť služieb tak dobre hodí.
Dostávame sa teda k odpovedi na otázku, prečo sa myšlienka siete služieb stala teraz populárnou: homogenita, ktorú Kubernetes poskytuje službám, sa priamo vzťahuje na prevádzkové výzvy, ktorým čelí sieť služieb. Proxy zabalíte do kontajnerov, dáte Kubernetes za úlohu ich nalepiť všade, kde sa dá, a voila! V dôsledku toho získate sieť služieb, pričom všetky mechaniky jej nasadenia spravuje Kubernetes. (Aspoň z vtáčej perspektívy. Samozrejme, tento proces má veľa odtieňov.)
Aby som to zhrnul: dôvodom, prečo sa sieťové siete stali populárnymi teraz, a nie pred desiatimi rokmi, je to, že Kubernetes a Docker sa nielen výrazne zvýšili potrebu v ňom zjednodušuje implementáciu aplikácií ako súborov viacjazyčných mikroslužieb, ale aj výrazne obmedzuje náklady zabezpečenie mechanizmov na nasadenie a podporu náhradných flotíl postranných vozíkov.
Prečo sa toľko hovorí o servisnej sieti?
výstraha: V tejto časti sa uchyľujem k najrôznejším domnienkam, dohadom, výmyslom a interným informáciám.
Hľadajte „service mesh“ a narazíte na tonu recyklovaného nízkokalorického obsahu, podivné projekty a kaleidoskop skreslenia hodný echo komory. Robí to akákoľvek nová technológia, ale v prípade servisnej siete je problém obzvlášť akútny. prečo?
No čiastočne je to moja chyba. Tvrdo som pracoval na propagácii Linkerdu a servisnej siete pri každej príležitosti, ktorú dostanem prostredníctvom nespočetných blogových príspevkov a článkov, ako je tento. Ale nie som taký silný. Aby sme skutočne odpovedali na túto otázku, musíme sa trochu porozprávať o celkovej situácii. A nemožno o tom hovoriť bez toho, aby sme spomenuli jeden projekt: je sieť služieb s otvoreným zdrojovým kódom vyvinutá spoločne spoločnosťami Google, IBM a Lyft.
(Tieto tri spoločnosti majú veľmi odlišné úlohy: Zdá sa, že účasť spoločnosti Lyft je obmedzená na samotné meno; sú autorom Envoy, ale nepoužívajú alebo sa podieľajú na vývoji Istio. IBM je zapojená do vývoja Istio a používa ho. Google výrazne zapojený do vývoja Istio, ale pokiaľ viem, v skutočnosti ho nepoužíva.)
Projekt Istio je pozoruhodný dvoma vecami. Po prvé je to obrovské marketingové úsilie, ktoré do svojej propagácie vkladá najmä Google. Odhadujem, že väčšina ľudí, ktorí si v súčasnosti uvedomujú koncept service mesh, sa o ňom prvýkrát dozvedela vďaka Istio. Druhou vlastnosťou je, ako zle bolo Istio prijaté. V tejto veci som, samozrejme, zainteresovaná strana, ale snažím sa zostať čo najobjektívnejšia, stále si nemôžem pomôcť , nie veľmi konkrétne (aj keď nie jedinečné: napadá ma systemd, ...) pre projekt s otvoreným zdrojom.
(V praxi sa zdá, že Istio má problémy nielen so zložitosťou a UX, ale aj s výkonom. Napr. V štúdii tretej strany výskumníci našli situácie, v ktorých bola latencia chvosta Istio 100-krát vyššia ako latencia Linkerdu, ako aj situácie s nedostatkom zdrojov, keď Linkerd naďalej úspešne fungoval, zatiaľ čo Istio úplne prestal fungovať.)
Odhliadnuc od mojich teórií o tom, prečo sa to stalo, verím, že obrovské vzrušenie okolo servisnej siete je vysvetlené účasťou spoločnosti Google. Konkrétne ide o kombináciu nasledujúcich troch faktorov:
- obsedantná propagácia Istio spoločnosťou Google;
- primeraný nesúhlasný, kritický postoj k projektu;
- nedávna raketovo rastúca popularita Kubernetes, na ktorú si ešte stále pamätáme.
Spoločne sa tieto faktory kombinujú a vytvárajú ohromujúce prostredie bez kyslíka, v ktorom je oslabená schopnosť racionálneho úsudku a zostáva len podivná rozmanitosť. .
Z Linkerdovho pohľadu je to... Opísal by som to ako zmiešané požehnanie. Chcem povedať, že je skvelé, že sieť služieb vstúpila do hlavného prúdu – čo nebol prípad v roku 2016, keď sa Linkerd prvýkrát objavil, a bolo naozaj ťažké upútať pozornosť ľudí na tento projekt. Teraz už takýto problém neexistuje! Ale zlou správou je, že situácia sieťových služieb je dnes taká mätúca, že je takmer nemožné zistiť, ktoré projekty skutočne patria do kategórie sieťových služieb (nehovoriac o tom, ktorý z nich je najlepší pre konkrétny prípad použitia). Toto určite prekáža každému (a rozhodne je v niektorých prípadoch Istio alebo iný projekt lepší ako Linkerd, keďže ten druhý nie je univerzálne riešenie).
Zo strany Linkerdu bolo našou stratégiou ignorovať hluk, naďalej sa zameriavať na riešenie skutočných problémov v komunite a v podstate čakať, kým humbuk utíchne. Nakoniec humbuk opadne a môžeme pokojne pracovať ďalej.
Dovtedy budeme musieť byť všetci trpezliví.
Bude servisná sieť užitočná pre mňa, skromného softvérového inžiniera?
Na túto otázku vám pomôže odpovedať nasledujúci dotazník:
Zaoberáte sa výlučne implementáciou obchodnej logiky? V tomto prípade vám servisná sieť nebude užitočná. To je, samozrejme, môže vás to zaujímať, ale v ideálnom prípade by sieť služieb nemala priamo ovplyvňovať nič vo vašom prostredí. Pokračujte v práci na tom, za čo ste platení.
Spravujete platformu v spoločnosti, ktorá používa Kubernetes? Áno, v tomto prípade potrebujete servisnú sieť (pokiaľ, samozrejme, nepoužívate K8 len na spustenie monolitu alebo dávkového spracovania - ale potom by som sa chcel opýtať, prečo potrebujete K8). Pravdepodobne skončíte s množstvom mikroslužieb napísaných rôznymi ľuďmi. Všetky sa navzájom ovplyvňujú a sú zviazané do spleti runtime závislostí a musíte nájsť spôsob, ako sa s tým všetkým vysporiadať. Používanie Kubernetes vám umožňuje vybrať si sieť služieb „pre seba“. Aby ste to urobili, oboznámte sa s ich schopnosťami a funkciami a odpovedzte si na otázku, či je niektorý z dostupných projektov pre vás vhodný (odporúčam začať svoj výskum s Linkerdom).
Prevádzkujete platformu pre spoločnosť, ktorá NEPOUŽÍVA Kubernetes, ale využíva mikroslužby? V tomto prípade vám bude užitočná sieťka, ale jej použitie bude netriviálne. Samozrejme môžete imitovať service mesh hostením množstva proxy, ale dôležitou výhodou Kubernetes je práve model nasadenia: manuálna údržba týchto proxy serverov si bude vyžadovať oveľa viac času, úsilia a nákladov.
Máte na starosti platformu vo firme, ktorá pracuje s monolitmi? V tomto prípade pravdepodobne nebudete potrebovať servisnú sieť. Ak pracujete s monolitmi (alebo dokonca skupinami monolitov), ktoré majú dobre definované a zriedka sa meniace vzorce interakcie, potom vám sieť služieb nemá čo ponúknuť. Takže to môžete jednoducho ignorovať a dúfať, že to zmizne ako zlý sen...
Záver
Pravdepodobne by sa sieť služieb stále nemala nazývať „najvychvaľovanejšou technológiou na svete“ - táto pochybná pocta pravdepodobne patrí bitcoinom alebo AI. Pravdepodobne je v prvej päťke. Ak však preseknete vrstvy hluku, je jasné, že sieť služieb prináša skutočné výhody tým, ktorí vytvárajú aplikácie na Kubernetes.
Chcel by som, aby ste vyskúšali Linkerd - jeho inštaláciu do klastra Kubernetes (alebo dokonca Minikube na prenosnom počítači) a sám vidíš, o čom hovorím.
FAQ
- Ak budem servisnú sieť ignorovať, zmizne?
- Musím vás sklamať: servisná sieť je tu s nami už dlho.
— Ale NECHCEM používať servisnú sieť!
- No, to nie je potrebné! Stačí si prečítať môj dotazník vyššie, či by ste sa nemali oboznámiť aspoň s jeho základmi.
— Nie je to starý dobrý ESB/middleware s novou omáčkou?
— Sieť služieb sa zaoberá operačnou logikou, nie sémantickou. podnikový autobus (). Zachovanie tohto oddelenia pomáha servisnej sieti vyhnúť sa rovnakému osudu.
- Ako sa sieť služieb líši od brán API?
Na túto tému je milión článkov. Stačí si to vygoogliť.
— Vyslanec je služobná sieť?
- Nie, Envoy nie je servisná sieť, je to proxy server. Môže sa použiť na organizáciu siete služieb (a oveľa viac - je to server proxy na všeobecné použitie). Ale samo o sebe to nie je servisná sieť.
- Network Service Mesh - je to sieť služieb?
- Nie. Napriek názvu to nie je sieť služieb (ako sa vám páčia zázraky marketingu?).
— Pomôže mi sieť služieb s mojím reaktívnym asynchrónnym systémom založeným na fronte správ?
- Nie, servisná sieť vám nepomôže.
- Akú sieťku by som mal použiť?
- , bez rozmýšľania.
- Ten článok je na hovno! / Autor je vítaný!
— Zdieľajte odkaz naň so všetkými svojimi priateľmi, aby sa o tom mohli presvedčiť!
Poďakovanie
Ako ste už z názvu mohli uhádnuť, tento článok bol inšpirovaný fantastickým pojednaním Jaya Krepsa “". S Jayom som sa stretol pred desiatimi rokmi, keď som robil rozhovor na Linked In a odvtedy je pre mňa inšpiráciou.
Aj keď sa rád nazývam „vývojár Linkerd“, realita je taká, že som skôr správcom súboru README.md v projekte. Dnes sa pracuje na Linkerde , , ľudí a tento projekt by nebol možný bez úžasnej komunity prispievateľov a používateľov.
A nakoniec, špeciálne poďakovanie patrí tvorcovi Linkerd, (primus inter pares), ktorý sa spolu so mnou pred mnohými rokmi bezhlavo pustil do všetkého toho ošiaľu so služobným pletivom.
PS od prekladateľa
Prečítajte si aj na našom blogu:
- «»;
- «»;
- «»;
- «»;
- «".
Zdroj: hab.com