Poznámka. přel.: Service mesh je fenomén, který zatím nemá stabilní překlad do ruštiny (před více než 2 lety jsme nabízeli možnost „mesh for services“ a o něco později začali někteří kolegové aktivně propagovat kombinaci „service site“). . Neustálé řeči o této technologii vedly k situaci, kdy jsou marketingové a technické složky příliš úzce propojeny. Tento úžasný materiál od jednoho z autorů původního termínu má přinést srozumitelnost nejen inženýrům.
Komiks od
úvod
Pokud jste softwarovým inženýrem pracujícím někde v oblasti backendových systémů, termín „service mesh“ se ve vaší mysli pravděpodobně za posledních pár let již pevně usadil. Díky podivné shodě okolností toto sousloví stále více přebírá toto odvětví a humbuk a související akční nabídky rostou jako sněhová koule, letí z kopce a nevykazují žádné známky zpomalení.
Servisní síť se zrodila v kalných, tendenčních vodách cloudového přirozeného ekosystému. Bohužel to znamená, že většina kontroverzí kolem toho sahá od „nízkokalorického žvanění“ až po – abychom použili odborný termín – nehorázné kecy. Ale pokud odfiltrujete všechen hluk, zjistíte, že servisní síť má velmi reálnou, určitou a důležitou funkci.
V tomto příspěvku se pokusím udělat právě to: poskytnout upřímný, hloubkový, inženýrsky orientovaný průvodce servisní sítí. Odpovím víc než jen na otázku: "Co to je?", - ale také "Proč?"a "Proč teď?". Na závěr se pokusím nastínit, proč (podle mě) právě tato technologie vyvolala tak šílený hype, což je samo o sobě zajímavý příběh.
Кто я?
Ahoj všichni! Jmenuji se . Jsem jedním z tvůrců - úplně první síťový projekt služeb a projekt, který má na svědomí vzhled termínu servisní síť jako takové (promiňte, kluci!). (Poznámka přel.: Mimochodem, na úsvitu výskytu tohoto termínu, před více než 2,5 lety, jsme již přeložili raný materiál stejného autora s názvem „. “) Taky vedu je startup, který staví skvělé věci typu service mesh jako Linkerd a .
Asi tušíte, že mám na tuto problematiku velmi zaujatý a subjektivní názor. Pokusím se však zkreslení omezit na minimum (s výjimkou jedné části: "Proč se tolik mluví o servisní síti?", - ve kterém se přesto podělím o své předsudky). Také udělám vše pro to, aby byl tento průvodce co nejobjektivnější. V konkrétních příkladech se budu opírat především o zkušenosti Linkerdu, přičemž poukážu na rozdíly (pokud existují), o kterých vím při implementaci jiných typů service mesh.
Dobře, je čas přejít k pamlskům.
Co je to servisní síť?
Přes všechen humbuk je servisní síť konstrukčně docela jednoduchá. Je to jen hromada proxy uživatelského prostoru umístěných „vedle“ služeb (o „blízko“ si něco povíme později), plus sada kontrolních procesů. Proxy se nazývají souhrnně datová rovinaa řídicí procesy se nazývají kontrolní letadlo. Datová rovina zachycuje hovory mezi službami a dělá s nimi „cokoli jiného“; řídicí rovina, respektive koordinuje chování proxy a poskytuje přístup pro vás, tzn. operátora, k API, což umožňuje manipulaci a měření sítě jako celku.
Co je to proxy? Toto je TCP proxy kategorie "Layer 7-aware". (tj. "s přihlédnutím k" 7. vrstvě modelu OSI) jako HAProxy a NGINX. Můžete si vybrat proxy podle svých představ; Linkerd používá proxy server Rust, nekomplikovaně pojmenovaný . Sestavili jsme jej speciálně pro servisní síť. Ostatní sítě preferují jiné proxy (Envoy je běžná volba). Výběr proxy je však pouze otázkou implementace.
Co tyto proxy servery dělají? Je zřejmé, že zastupují volání do a ze služeb (přesně řečeno fungují jako proxy a reverzní proxy, zpracovávají příchozí i odchozí hovory). A implementují sadu funkcí, která se zaměřuje na hovory между služby. Toto zaměření na provoz mezi službami je to, co odlišuje proxy server typu service mesh od, řekněme, API bran nebo vstupních proxy serverů (druhé se zaměřují na volání přicházející do clusteru z vnějšího světa). (Poznámka. přel.: Porovnání stávajících ovladačů Kubernetes Ingress, z nichž mnohé využívají již zmíněný Envoy, viz. .)
Takže jsme přišli na datovou rovinu. Řídicí rovina je jednodušší: je to sada komponent, které poskytují veškerou mechaniku, kterou datová rovina potřebuje ke koordinovanému fungování, včetně zjišťování služeb, vydávání certifikátů TLS, agregace metrik atd. Datová rovina informuje řídicí rovinu o jeho chování; řídicí rovina zase poskytuje API, které vám umožňuje měnit a sledovat chování datové roviny jako celku.
Níže je schéma řídicí roviny a datové roviny v Linkerdu. Jak můžete vidět, řídicí rovina zahrnuje několik různých komponent, včetně instance Prometheus, která shromažďuje metriky z proxy serverů, a také další komponenty, jako je destination (objevení služby), identity (certifikační autorita, CA) a public-api (koncové body pro web a CLI). Naproti tomu datová rovina je jednoduchý linkerd-proxy vedle instance aplikace. Toto je pouze logické schéma; v reálném nasazení můžete mít tři repliky každé komponenty řídicí roviny a stovky nebo tisíce proxy v datové rovině.
(Modré rámečky v tomto diagramu představují hranice Kubernetes podů. Můžete vidět, že kontejnery s linkerd-proxy jsou ve stejném podu jako aplikační kontejnery. Toto schéma je známé jako kontejner postranního vozíku.)
Architektura sítě služeb má několik důležitých důsledků. Za prvé, protože úkolem proxy je zachytit hovory mezi službami, má síť služeb smysl pouze v případě, že vaše aplikace byla vytvořena pro sadu služeb. pletivo jeden může použití s monolity, ale to je zjevně nadbytečné kvůli jedinému proxy a jeho funkčnost pravděpodobně nebude požadována.
Dalším důležitým důsledkem je, že servisní síť vyžaduje obrovský počet proxy. Ve skutečnosti Linkerd zřetězuje linkerd-proxy ke každé instanci každé služby (jiné implementace přidávají proxy do každého uzlu/hostitele/VM. To je každopádně hodně). Takové aktivní používání proxy samo o sobě přináší řadu dalších komplikací:
- Proxy v datové rovině by měly být rychle, protože pro každé volání existuje několik volání na proxy: jedno na straně klienta, jedno na straně serveru.
- Také musí být proxy malý и lehká váha. Každý bude spotřebovávat paměť a zdroje CPU a tato spotřeba poroste lineárně s aplikací.
- Budete potřebovat mechanismus pro nasazení a aktualizaci velkého počtu proxy. Dělat to ručně není možné.
Obecně platí, že síť služeb vypadá takto (alespoň z ptačí perspektivy): nasadíte hromadu proxy uživatelského prostoru, které „něco dělají“ s interním, meziobslužným provozem, a používáte řídicí rovinu k jejich monitorování a správě.
Je čas na otázku "Proč?"
K čemu slouží servisní síť?
Pro ty, kteří se poprvé setkali s myšlenkou servisní sítě, je omluvitelné být trochu v úžasu. Design service mesh znamená, že nejen zvýší aplikační latenci, ale také zvýší konzumovat zdroje a přidá spoustu nových mechanismů v infrastruktuře. Nejprve nastavíte síť služeb a pak najednou zjistíte, že potřebujete obsluhovat stovky (ne-li tisíce) proxy. Otázkou je, kdo se k tomu dobrovolně přihlásí.
Odpověď na tuto otázku má dvě části. Za prvé, transakční náklady spojené s nasazením těchto proxy mohou být výrazně sníženy díky některým změnám probíhajícím v ekosystému (více o tom později).
Za druhé, takové zařízení je vlastně skvělý způsob, jak do systému zavést další logiku. A to nejen proto, že pomocí servisní sítě lze přidat spoustu nových funkcí, ale také proto, že to lze provést bez zásahu do ekosystému. Ve skutečnosti je celý model servisní sítě založen na tomto postulátu: v multiservisním systému, bez ohledu na to, co dělat jednotlivé služby, provoz mezi nimi je ideálním místem pro přidání funkčnosti.
Například v Linkerdu (jako ve většině sítí) je funkčnost zaměřena primárně na HTTP volání, včetně HTTP/2 a gRPC*. Funkčnost je poměrně bohatá - lze ji rozdělit do tří tříd:
- Související funkce spolehlivost. Požadavky na opakování, časové limity, kanárský přístup (rozdělení/přesměrování provozu) atd.
- Související funkce sledování. Agregace úspěšnosti, zpoždění a objemů požadavků pro každou službu nebo jednotlivé destinace; vytváření topologických map služeb atd.
- Související funkce bezpečnostní. Vzájemné TLS, řízení přístupu atd.
* Z pohledu Linkerdu se gRPC prakticky neliší od HTTP/2: pouze používá protobuf v užitečné zátěži. Z pohledu vývojáře jsou tyto dvě věci samozřejmě odlišné.
Mnoho z těchto mechanismů funguje na úrovni požadavku (odtud „L7 proxy“). Pokud například služba Foo zavolá HTTP do služby Bar, může linkerd-proxy na straně Foo inteligentně vyvažovat zátěž a směrovat volání z instancí Foo do Bar na základě pozorované latence; v případě potřeby může žádost opakovat (a pokud je idempotentní); může zaznamenat kód odpovědi a časový limit a tak dále. Podobně může linkerd-proxy na straně baru odmítnout požadavek, pokud to není povoleno nebo pokud je překročen limit požadavku; může opravit zpoždění ze své strany atd.
Proxy mohou „něco udělat“ i na úrovni připojení. Například linkerd-proxy na straně Foo může iniciovat TLS připojení a linkerd-proxy na straně Bar je může ukončit a obě strany si mohou vzájemně ověřit TLS certifikáty*. To poskytuje nejen šifrování mezi službami, ale také kryptograficky bezpečný způsob identifikace služeb: Foo a Bar mohou „prokázat“, že jsou tím, kým se vydávají.
* "Přítel přítele" znamená, že je ověřen i certifikát klienta (vzájemné TLS). V "klasickém" TLS se například mezi prohlížečem a serverem ověřuje certifikát pouze jedné strany (serveru).
Ať už fungují na úrovni požadavku nebo připojení, je důležité zdůraznit, že všechny funkce sítě služeb jsou provozní charakter. Linkerd není schopen transformovat sémantiku datové části, jako je přidávání polí do fragmentu JSON nebo provádění změn v protobufu. O této důležité funkci si povíme později, až budeme mluvit o ESB a middlewaru.
Toto je sada funkcí, které síť služeb nabízí. Nabízí se otázka: proč je neimplementovat přímo do aplikace? A proč se vůbec bavit s proxy?
Proč je servisní síť dobrý nápad
I když jsou schopnosti servisní sítě uchvacující, její hlavní hodnota ve skutečnosti nespočívá ve funkcích. Nakonec my Umět implementovat je přímo v aplikaci (později uvidíme, že to byl původ servisní sítě). Abych to vyjádřil jednou větou, hodnota servisní sítě je: poskytuje funkce kritické pro provoz moderního serverového softwaru konzistentním způsobem bez ohledu na aplikační kód.
Pojďme analyzovat tento návrh.
«Funkce kritické pro provoz moderního serverového softwaru". Pokud budujete transakční serverovou aplikaci připojenou k veřejnému internetu, která přijímá požadavky z vnějšího světa a v krátkém čase na ně odpovídá – například webová aplikace, API server a velká většina dalších moderních aplikací – a pokud jej implementujete jako sadu služeb, které se vzájemně synchronně ovlivňují, a pokud tento software neustále aktualizujete, přidáváte nové funkce a pokud jste nuceni udržovat tento systém v provozuschopném stavu během procesu modifikace – v tomto případě, gratulujeme, vytváříte moderní serverový software. A všechny ty skvělé funkce uvedené výše se pro vás skutečně ukážou jako kritické. Aplikace musí být spolehlivá, bezpečná a musíte být schopni vidět, co dělá. Právě tyto otázky pomáhá řešit servisní síť.
(Dobře, mé přesvědčení, že tento přístup je moderním způsobem budování serverového softwaru, se vkradlo do předchozího odstavce. Jiní dávají přednost vývoji monolitů, „reaktivních mikroslužeb“ a dalších věcí, které nespadají pod výše uvedenou definici. Tito lidé mají pravděpodobně názor že se liší od mých, a já zase věřím, že jsou "špatné" - i když v každém případě pro ně není servisní síť příliš užitečná).
«Uniforma pro celý stoh". Funkce poskytované servisní sítí nejsou jen kritické. Vztahují se na všechny služby v aplikaci, bez ohledu na to, v jakém jazyce jsou napsány, jaký framework používají, kdo je napsal, jak byly nasazeny a všechny další jemnosti jejich vývoje a použití.
«Nezávislost na kódu aplikace". A konečně, síť služeb nejenže poskytuje konzistentní funkce v celém zásobníku, ale dělá to způsobem, který nevyžaduje úpravy aplikace. Základní základ funkčnosti servisní sítě, včetně úkolů konfigurace, aktualizace, provozu, údržby atd., je čistě na úrovni platformy a je nezávislý na aplikaci. Aplikace se může změnit, aniž by to ovlivnilo síť služeb. Na druhé straně se síť služeb může změnit bez jakéhokoli zásahu aplikace.
Stručně řečeno, síť služeb nejen poskytuje životně důležité funkce, ale činí tak globálním, jednotným a na aplikaci nezávislým způsobem. A tak, zatímco funkcionalitu sítě služeb lze implementovat do kódu služeb (například jako knihovnu součástí každé služby), tento přístup nezajistí jednotnost a nezávislost, která je tak cenná v případě sítě služeb. .
A vše, co musíte udělat, je přidat spoustu proxy! Slibuji, že se velmi brzy podíváme na provozní náklady spojené s přidáním těchto proxy. Nejprve se však zastavme a podívejme se na tuto myšlenku nezávislosti z pohledu různých lidé.
Komu servisní síť pomáhá?
Jakkoli to může být nepohodlné, aby se technologie stala důležitou součástí ekosystému, musí ji lidé přijmout. Kdo má tedy zájem o servisní síť? Kdo má z jejího používání prospěch?
Pokud vyvíjíte moderní serverový software, můžete si zhruba představit svůj tým jako skupinu majitelé služebkteří společně vyvíjejí a implementují obchodní logiku a majitelé platformypodílí se na vývoji interní platformy, na které tyto služby běží. V malých organizacích to mohou být stejní lidé, ale jak společnost roste, tyto role mají tendenci se zvýraznit a dokonce se dělit na dílčí role... (Tady je třeba hodně říci o měnící se povaze devops, organizační dopad mikroslužeb atd.).
Z tohoto pohledu jsou jasnými příjemci sítě služeb vlastníci platformy. Koneckonců, konečným cílem týmu platformy je vytvořit interní platformu, na které mohou majitelé služeb implementovat obchodní logiku a dělat to způsobem, který jim zaručí maximální nezávislost na ponurých detailech jejího fungování. Síť služeb nejenže nabízí schopnosti kritické pro dosažení tohoto cíle, ale dělá to způsobem, který naopak nevytváří žádnou závislost na vlastníkech služeb.
Z toho mají prospěch i majitelé služeb, i když nepřímo. Cílem vlastníka služby je být co nejproduktivnější při implementaci logiky obchodního procesu a čím méně se bude muset starat o provozní záležitosti, tím lépe. Namísto vynucování, řekněme, opakování zásad nebo TLS, se mohou soustředit pouze na podnikání a doufat, že se platforma postará o zbytek. Pro ně je to velká výhoda.
Organizační hodnotu takového rozdělení mezi vlastníky platforem a služeb nelze přeceňovat. Myslím, že přispívá hlavní příspěvek k hodnotě sítě služeb.
Tuto lekci jsme se naučili, když nám první fanoušek Linkerd řekl, proč si vybral servisní síť: protože jim to umožnilo „mluvit na minimum“. Zde jsou některé podrobnosti: kluci z jedné velké společnosti migrovali svou platformu na Kubernetes. Protože aplikace pracovala s citlivými informacemi, chtěli veškerou komunikaci v clusterech šifrovat. Situaci však komplikovala přítomnost stovek služeb a stovek vývojových týmů. Vyhlídka, že všechny osloví a přesvědčí je, aby podporu TLS zahrnuli do svých plánů, je vůbec nepotěšila. Instalací Linkerdu migrovali odpovědnost od vývojářů (z jejich pohledu to byly zbytečné potíže) až po plošinovky, pro které to byla priorita nejvyšší úrovně. Jinými slovy, Linkerd pro ně neřešil ani tak technický problém, jako spíše organizační.
Stručně řečeno, servisní síť není spíše technické řešení, ale sociálně-technické Problémy. (Děkuji pro zavedení tohoto termínu.
Vyřeší servisní síť všechny mé problémy?
Ano. Myslím tím ne!
Při pohledu na tři třídy funkcí nastíněných výše – spolehlivost, bezpečnost a pozorovatelnost – je jasné, že síť služeb není úplným řešením žádného z těchto problémů. I když Linkerd může posílat opakované požadavky (pokud ví, že jsou idempotentní), není v pozici, kdy může rozhodovat o tom, co vrátit uživateli, pokud služba konečně nefunguje – taková rozhodnutí musí učinit aplikace. Linkerd může vést statistiky o úspěšných požadavcích, ale není schopen nahlížet do služby a poskytovat její interní metriky - aplikace by takovou sadu nástrojů měla mít. A zatímco Linkerd je schopen hostovat mTLS, plnohodnotná bezpečnostní řešení vyžadují mnohem více.
Souvisí podmnožina funkcí v těchto oblastech, které nabízí síť služeb funkce platformy. Tím mám na mysli funkce, které:
- Nezávislé na obchodní logice. Způsob, jakým jsou konstruovány histogramy volání mezi Foo a Bar, je zcela nezávislý na tom, zda proč Foo volá Bar.
- Je obtížné správně implementovat. V Linkerdu jsou opakování parametrizovány pomocí nejrůznějších efektních věcí, jako jsou rozpočty na opakování. (zkuste znovu rozpočty), protože prostoduchý přístup k realizaci takových věcí jistě povede ke vzniku tzv. „laviny žádostí“ (opakovat bouři) a další problémy specifické pro distribuované systémy.
- Nejúčinnější při důsledné aplikaci. Mechanismus TLS má smysl pouze tehdy, je-li aplikován všude.
Protože jsou tyto funkce implementovány na vrstvě proxy (a ne na aplikační vrstvě), síť služeb je odhaluje na platforma, nikoli aplikace. Nezáleží tedy na tom, v jakém jazyce jsou služby napsány, jaký rámec používají, kdo je napsal a proč. Proxy fungují mimo všechny tyto detaily a základní základ této funkčnosti, včetně úkolů konfigurace, aktualizace, provozu, údržby atd., leží výhradně na úrovni platformy.
Příklady funkcí sítě služeb
Abych to shrnul, chci říci, že servisní síť není kompletním řešením pro zajištění spolehlivosti, pozorovatelnosti nebo bezpečnosti. Rozsah těchto oblastí implikuje povinnou účast vlastníků služeb, týmů Ops/SRE a dalších zainteresovaných stran společnosti. Síť služeb poskytuje pouze „výřez“ na úrovni platformy pro každou z těchto oblastí.
Proč se servisní síť stala populární právě teď?
Pravděpodobně se teď ptáte: OK, když je síť služeb tak dobrá, proč jsme nezačali nasazovat miliony proxy serverů na zásobník před deseti lety?
Na tuto otázku existuje banální odpověď: před deseti lety každý stavěl monolity a nikdo nepotřeboval servisní síť. To je pravda, ale podle mého názoru se tato odpověď míjí účinkem. Již před deseti lety byl koncept mikroslužeb jako slibný způsob vytváření rozsáhlých systémů široce diskutován a aplikován ve společnostech jako Twitter, Facebook, Google a Netflix. Obecná představa – alespoň v částech odvětví, se kterými jsem byl v kontaktu – byla taková, že mikroslužby jsou „správnou cestou“ k budování velkých systémů, i když to bylo zatraceně těžké.
Samozřejmě, i když před deseti lety existovaly společnosti využívající mikroslužby, nenalepovaly proxy všude, kde by mohly vytvořit síť služeb. Pokud se však podíváte pozorně, udělali něco podobného: mnoho z těchto společností nařídilo použití speciální interní knihovny pro vytváření sítí (někdy nazývané knihovna tlustých klientů, tlustá klientská knihovna).
Netflix měl Hysterix, Google měl Stubby, Twitter měl knihovnu Finagle. Například Finagle bylo povinné pro každou novou službu na Twitteru. Zpracovával připojení na straně klienta i serveru, umožňoval opakované požadavky, podporoval směrování požadavků, vyvažování zátěže a měření. Poskytoval konzistentní vrstvu spolehlivosti a sledovatelnosti v celém zásobníku Twitteru, bez ohledu na to, co služba dělala. Samozřejmě fungoval pouze pro jazyky JVM a byl založen na programovacím modelu, který bylo nutné použít pro celou aplikaci. Jeho funkčnost však byla téměř stejná jako u servisní sítě. (Ve skutečnosti byla první verze Linkerdu jen Finagle zabalená v proxy formě.)
Před deseti lety tedy existovaly nejen mikroslužby, ale také speciální proto-service-mesh knihovny, které řešily stejné problémy, jaké dnes řeší service mesh. Samotné obslužné pletivo však tehdy neexistovalo. Než se objevila, musela nastat další směna.
A zde se skrývá hlubší odpověď, skrytá v další změně, ke které došlo za posledních 10 let: došlo k prudkému poklesu nákladů na nasazení mikroslužeb. Výše zmíněné společnosti, které před deseti lety využívaly mikroslužby – Twitter, Netflix, Facebook, Google – byly společnosti obrovského rozsahu a obrovských zdrojů. Měli nejen potřebu, ale také schopnost vytvářet, nasazovat a provozovat velké aplikace založené na mikroslužbách. Energie a úsilí, které inženýři Twitteru vložili do přechodu od monolitického přístupu k mikroslužbám, jsou úžasné. (Upřímně řečeno, stejně jako skutečnost, že to fungovalo.) Tento druh manévrování s infrastrukturou byl tehdy pro menší společnosti nemožný.
Přesuňme se do současnosti. Dnes existují startupy, kde je poměr mikroslužeb k vývojářům 5:1 (nebo dokonce ), a navíc se s nimi úspěšně vyrovnávají! Pokud je startup o 5 lidech schopen provozovat 50 mikroslužeb bez namáhání, pak něco jednoznačně snížilo náklady na jejich implementaci.
1500 mikroslužeb v Monzu; každá linka je předepsané síťové pravidlo, které povoluje provoz
Dramatické snížení nákladů na provoz mikroslužeb je výsledkem jediného procesu: rostoucí obliba kontejnerů и orchestrátory. To je právě hluboká odpověď na otázku, co přispělo ke vzniku obslužného pletiva. Stejná technologie učinila jak síť služeb, tak mikroslužby atraktivní: Kubernetes a Docker.
Proč? No, Docker řeší jeden velký problém – problém balení. Zabalením aplikace a jejích (nesíťových) runtime závislostí do kontejneru přemění Docker aplikaci na zastupitelnou jednotku, kterou lze hostovat a provozovat kdekoli. Zároveň výrazně zjednodušuje obsluhu. vícejazyčný zásobník: Vzhledem k tomu, že kontejner je atomická jednotka provádění, nezáleží na tom, co je uvnitř, zda je to aplikace JVM, Node, Go, Python nebo Ruby, pro účely nasazení a provozu. Prostě to spustíte a je to.
Kubernetes posouvá vše na další úroveň. Nyní, když existuje spousta "spustitelných věcí" a mnoho strojů, na kterých je lze spustit, je potřeba nástroj, který je dokáže porovnat. V širokém slova smyslu dáte Kubernetes mnoho kontejnerů a mnoho strojů a ono je vzájemně spojuje (samozřejmě je to dynamický a neustále se měnící proces: nové kontejnery se pohybují po systému, stroje se spouštějí a zastavují atd.). Kubernetes to vše bere v úvahu).
Jakmile je Kubernetes nastaven, čas potřebný k nasazení a provozování jedné služby se příliš neliší od nákladů na nasazení a provoz deseti služeb (ve skutečnosti je to téměř stejné pro 100 služeb). Přidejte k tomu kontejnery jako balicí mechanismus, který podporuje vícejazyčnou implementaci, a máte spoustu nových aplikací implementovaných jako mikroslužby napsané ve více jazycích, přesně takové prostředí, pro které se síť služeb tak dobře hodí.
Dostáváme se tedy k odpovědi na otázku, proč se myšlenka servisní sítě stala populární právě teď: uniformita, kterou Kubernetes poskytuje službám, je přímo použitelná na provozní úkoly, kterým čelí servisní síť. Zabalíte proxy do kontejnerů, dáte Kubernetes za úkol je nalepit, kdekoli je to možné, a voila! Na výstupu získáte servisní síť, zatímco Kubernetes ovládá všechny mechaniky jejího nasazení. (Alespoň z ptačí perspektivy. Tento proces má samozřejmě mnoho nuancí.)
Abych to shrnul: důvodem, proč se síť služeb stala populární nyní a ne před deseti lety, je to, že Kubernetes a Docker nejen výrazně vzrostly potřeba v něm zjednodušuje implementaci aplikací jako sady vícejazyčných mikroslužeb, ale také výrazně omezuje náklady pro jeho provoz poskytnutím mechanismů pro zavádění a údržbu náhradních parkovišť postranních vozíků.
Proč se tolik mluví o servisní síti?
výstraha: V této sekci se uchyluji k nejrůznějším domněnkám, dohadům, výmyslům a interním informacím.
Hledání "servisní sítě" objeví spoustu recyklovaných, nízkokalorických, zvláštních projektů a kaleidoskop zkreslení hodný echo komory. Každá moderní nová technologie to má, ale v případě servisní sítě je problém obzvláště akutní. Proč?
No, je to částečně moje chyba. Snažil jsem se propagovat Linkerd a servisní síť při každé příležitosti prostřednictvím bezpočtu blogových příspěvků a článků, jako je tento. Ale nejsem tak mocný. Abychom na tuto otázku skutečně odpověděli, musíme si trochu promluvit o obecné situaci. A nelze o tom mluvit, aniž bych zmínil jeden projekt: je síť open source služeb vyvinutá společně společnostmi Google, IBM a Lyft.
(Tyto tři společnosti mají velmi odlišné role: zapojení společnosti Lyft se zdá být omezeno pouze na jméno; jsou autory Envoy, ale nepoužívají nebo se podílejí na vývoji Istio. IBM se podílí na vývoji Istio a využívá jej. Google je silně podílí se na vývoji Istio , ale pokud mohu říci, ve skutečnosti jej nepoužívá.)
Projekt Istio je pozoruhodný dvěma věcmi. Za prvé je to obrovské marketingové úsilí, které do propagace vkládá zejména Google. Odhaduji, že většina lidí, kteří v současné době znají koncept service mesh, se o něm poprvé dozvěděla díky Istio. Druhým rysem je, jak špatně bylo Istio přijato. V této věci jsem samozřejmě zainteresovaná strana, ale snažím se zůstat co nejobjektivnější, stále nemohu jinak než , nepříliš konkrétní (i když ne jedinečné: napadá mě systemd, ...) pro projekt Open Source.
(V praxi se zdá, že Istio má problémy nejen se složitostí a UX, ale také s výkonem. Například během provedené třetí stranou experti našli situace, ve kterých byla latence ocasu Istio 100krát vyšší než u Linkerdu, a také situace s nedostatkem zdrojů, kdy Linkerd nadále úspěšně fungoval a Istio úplně přestal fungovat.)
Pomineme-li mé teorie o tom, proč se to stalo, domnívám se, že neobyčejný humbuk kolem sítě služeb je způsoben zapojením společnosti Google. Konkrétně jde o kombinaci následujících tří faktorů:
- posedlá propagace Istio společností Google;
- přiměřený nesouhlasný, kritický postoj k projektu;
- nedávná raketově stoupající popularita Kubernetes, na kterou si stále čerstvá vzpomínka.
Dohromady se tyto faktory spojují v jakési opojné, anoxické prostředí, ve kterém slábne schopnost racionálního úsudku a zůstává jen bizarní rozmanitost .
Z Linkerdova pohledu je to... Popsal bych to jako smíšené požehnání. Chci říct, že je skvělé, že se síť služeb stala mainstreamem – což nebyl případ v roce 2016, kdy Linkerd poprvé vyšel, a bylo opravdu těžké upoutat pozornost lidí na projekt. Teď už takový problém není! Špatnou zprávou ale je, že situace se síťovou sítí služeb je dnes tak nepřehledná, že je téměř nemožné zjistit, které projekty skutečně patří do kategorie síťových služeb (natož zjistit, který z nich je pro konkrétní případ použití nejlepší). To určitě každému překáží (a rozhodně v některých případech je Istio nebo jiný projekt lepší než Linkerd, protože ten není univerzální řešení).
Ze strany Linkerdu bylo naší strategií ignorovat hluk, nadále se soustředit na řešení skutečných problémů v komunitě a v podstatě čekat, až humbuk opadne. Nakonec humbuk opadne a my můžeme v klidu pracovat dál.
Do té doby budeme muset být všichni trpěliví.
Bude servisní síť užitečná pro mě, skromného softwarového inženýra?
Na tuto otázku vám pomůže odpovědět následující dotazník:
Zabýváte se výhradně implementací obchodní logiky? V tomto případě vám servisní síť nebude užitečná. To je samozřejmě, že vás to může zajímat, ale v ideálním případě by síť služeb neměla přímo ovlivňovat nic ve vašem prostředí. Pokračujte v práci na tom, za co jste placeni.
Udržujete platformu ve společnosti, která používá Kubernetes? Ano, v tomto případě potřebujete servisní síť (samozřejmě, pokud nepoužíváte K8 jen ke spuštění monolitu nebo dávkového zpracování - ale pak bych se chtěl zeptat, proč potřebujete K8). S největší pravděpodobností se ocitnete v situaci s mnoha mikroslužbami napsanými různými lidmi. Všechny se vzájemně ovlivňují a jsou svázány do spleti závislostí běhového prostředí a vy musíte najít způsob, jak se s tím vším vypořádat. Použití Kubernetes vám umožňuje vybrat si síť služeb „pro sebe“. Chcete-li to provést, seznamte se s jejich možnostmi a funkcemi a odpovězte si na otázku, zda vám některý z dostupných projektů vůbec vyhovuje (doporučuji začít svůj výzkum s Linkerdem).
Provozujete platformu pro společnost, která NEPOUŽÍVÁ Kubernetes, ale používá mikroslužby? V tomto případě se vám bude servisní síť hodit, ale její použití bude netriviální. Samozřejmě můžete napodobit service mesh hostováním hromady proxy, ale důležitou výhodou Kubernetes je právě model nasazení: ruční údržba těchto proxy serverů bude vyžadovat mnohem více času, úsilí a nákladů.
Máte na starosti platformu ve firmě, která pracuje s monolity? V tomto případě pravděpodobně nepotřebujete servisní síť. Pokud pracujete s monolity (nebo dokonce sadami monolitů), které mají dobře definované a zřídka se měnící vzorce interakce, pak vám síť služeb nemá co nabídnout. Takže to můžete prostě ignorovat a doufat, že zmizí jako zlý sen...
Závěr
Pravděpodobně by síť služeb stále neměla být nazývána „nejvíce medializovanou technologií na světě“ - tato pochybná čest pravděpodobně patří bitcoinu nebo AI. Možná je v první pětce. Ale pokud prolomíte vrstvy hluku a hluku, je jasné, že síť služeb přináší skutečné výhody těm, kteří vytvářejí aplikace v Kubernetes.
Chtěl bych, abyste vyzkoušeli Linkerd - instalaci do clusteru Kubernetes (nebo dokonce Minikube na notebooku) a sami vidíte, o čem mluvím.
FAQ
- Když budu servisní síť ignorovat, zmizí?
- Musím vás zklamat: servisní síť je tu s námi již dlouho.
— Ale NECHCI používat servisní síť!
- No, to není nutné! Stačí si přečíst můj dotazník výše, zda byste se neměli seznámit alespoň s jeho základy.
— Není to staré dobré ESB/middleware s novou omáčkou?
- Service mesh se zabývá operační logikou, nikoli sémantickou. podnikový servisní autobus (). Zachování tohoto oddělení pomáhá servisní síti vyhnout se stejnému osudu.
- Jak se síť služeb liší od bran API?
Na toto téma existuje milion článků. Stačí googlit.
Je Envoy servisní síť?
- Ne, Envoy není servisní síť, je to proxy server. Lze jej použít k uspořádání sítě služeb (a mnohem více - je to proxy pro všeobecné použití). Ale samo o sobě to není servisní síť.
- Network Service Mesh - je to síť služeb?
- Ne. Navzdory názvu se nejedná o síť služeb (jak se vám líbí zázraky marketingu?).
- Pomůže síť služeb s mým reaktivním asynchronním systémem založeným na frontě zpráv?
- Ne, servisní síť vám nepomůže.
- Jakou servisní síť mám použít?
- , žádný přemýšlení.
- Ten článek je na hovno! / Autor - na mýdlo!
— Sdílejte odkaz na něj se všemi svými přáteli, aby se o tom mohli přesvědčit!
Poděkování
Jak už z názvu asi tušíte, tento článek byl inspirován fantastickým pojednáním Jaye Krepse “". S Jayem jsem se setkal před deseti lety, když jsem dělal rozhovor na Linked In a od té doby je pro mě inspirací.
I když si rád říkám „vývojář Linkerd“, realita je taková, že jsem spíše správcem souboru README.md v projektu. Dnes pracujeme na Linkerdu , , lidí a tento projekt by nebyl možný bez úžasné komunity přispěvatelů a uživatelů.
A nakonec zvláštní poděkování tvůrci Linkerd, (primus inter pares), který se spolu se mnou před mnoha lety vrhl po hlavě do všeho toho povyku s obslužným pletivem.
PS od překladatele
Přečtěte si také na našem blogu:
- «";
- «";
- «";
- «";
- «".
Zdroj: www.habr.com