Pozn. přek.: Služební síť — je fenomén, který dosud nemá ustálený překlad do češtiny (před více než 2 lety jsme navrhli variantu „síť pro služby“, a o něco později někteří kolegové začali aktivně prosazovat spojení „služební sítko“). Neustálé diskuse o této technologii vedly k situaci, kdy se příliš těsně propletly marketingové a technické aspekty. Tento vynikající materiál od jednoho z autorů původního termínu má za cíl přinést jasnost pro inženýry a nejen pro ně.
Komiks od
Úvod
Pokud jste softwarový inženýr pracující někde v oblasti backendových systémů, termín „service mesh“ se pravděpodobně již pevně usadil ve vaší mysli během posledních pár let. Díky podivnému shodě okolností toto spojení stále více ovládá odvětví, a hype a s ním spojené reklamní nabídky narůstají jako sněhová koule, která se kutálí dolů po svahu a nejeví žádné známky zpomalení.
Služební síť vznikla v temných, tendenčních vodách ekosystému cloud native. Bohužel to znamená, že značná část související debaty se pohybuje od „nízkokalorických tlachů“ po — pokud použijeme technický termín — jasné nesmysly. Ale pokud odfiltrujeme veškerý šum, můžeme zjistit, že služební síť má zcela reálnou, konkrétní a důležitou funkci.
V této publikaci se pokusím udělat právě to: představit čestného, hlubokého, na inženýry orientovaného průvodce po služební síti. Budu se snažit odpovědět nejen na otázku: „Co to je?“, — ale i „Proč?“, a také „Proč právě teď?“. Nakonec se pokusím načrtnout, proč (podle mého názoru) právě tato technologie vyvolala tak šílený zájem, což je samo o sobě zajímavý příběh.
Kdo jsem já?
Ahoj všem! Jmenuji se . Jsem jedním z tvůrců — prvního projektu služební sítě a projektu, který je zodpovědný za vznik tohoto termínu service mesh jako takového (omlouvám se, kluci!). (P.S.: Mimochodem, na samotném začátku tohoto termínu, před více než 2,5 lety, jsme již překládali raný materiál téhož autora s názvem „».) Také vedu — startup, který se zabývá vytvářením skvělých věcí v oblasti služebních sítí, jako je Linkerd a .
Možná tušíte, že mám v tomto ohledu dosti zaujatý a subjektivní názor. Každopádně se pokusím minimalizovat svou zaujatost (s výjimkou jedné části: „Proč je tolik řečí o service mesh?“, - ve které se přece jen podělím o své předpojaté myšlenky). Také se maximálně vynasnažím, abych tuto příručku učinil co nejobjektivnější. U konkrétních příkladů se převážně budu řídit zkušenostmi Linkerd, přičemž naznačím známé rozdíly (pokud nějaké existují) v implementaci jiných typů service mesh.
Dobře, je čas přejít k lahůdkám.
Co je to service mesh?
I přes veškerý hype je struktura service mesh relativně jednoduchá. Je to jen hromada userspace proxy umístěných "vedle" služeb (o tom, co to znamená „vedle“, si povíme později), plus soubor řídicích procesů. Proxy dohromady nazýváme data plane, a řídící procesy se nazývají control plane. Data plane zachycuje volání mezi službami a provádí s nimi "všechno možné"; control plane tedy koordinuje chování proxy a zajišťuje přístup pro vás, tedy operátora, k API, což vám umožňuje manipulovat se sítí a měřit ji jako celek.
Co jsou tyto proxy? Jsou to TCP proxy kategorie „Layer 7-aware“ (tj. „zohledňující“ 7. úroveň modelu OSI) , jako například HAProxy a NGINX. Můžete si vybrat proxy podle své chuti; Linkerd používá proxy napsanou v Rustu, která se skromně nazývá . Shromáždili jsme ji speciálně pro service mesh. Ostatní mesh obvykle preferují jiné proxy (Envoy je častou volbou). Nicméně, volba proxy je pouze otázkou implementace.
Co tyto proxy servery dělají? Je jasné, že procházejí voláními k službám a od nich (striktně vzato, plní funkci proxy a reverzní proxy, zpracovávají jak příchozí, tak odchozí volání). A realizují soubor funkcí, který se zaměřuje na volání mezi službami. Tento důraz na provoz mezi službami odlišuje service mesh proxy od, řekněme, API gateway nebo ingress proxy (ty se soustředí na volání přicházející do clusteru z vnějšího světa). (Pozn. přek.: srovnání stávajících Ingress controllerů pro Kubernetes, z nichž mnohé využívají již zmíněný Envoy, viz .)
Takže jsme si objasnili data plane. Control plane je jednoduší: je to soubor komponent, které zajišťují veškerou mechaniku potřebnou pro to, aby data plane fungovala koordinovaně, včetně objevování služeb, vydávání certifikátů TLS, agregace metrik atd. Data plane informuje control plane o svém chování; control plane na oplátku poskytuje API, které umožňuje měnit a sledovat chování data plane jako celku.
Níže je uveden diagram control plane a data plane v Linkerd. Jak je vidět, control plane zahrnuje několik různých komponent, včetně instance Prometheus, která shromažďuje metriky z proxy serverů, a také další komponenty, jako jsou cílová destinace (objevování služeb), identity (certifikační centrum, CA) a public-api (endpoints pro web a CLI). Na rozdíl od toho, data plane představuje jednoduchý linkerd-proxy vedle instance aplikace. Toto je pouze logický diagram; v reálných podmínkách nasazení můžete mít tři repliky každé komponenty control plane a stovky nebo tisíce proxy v data plane.
(Modré obdélníky v tomto diagramu symbolizují hranice podů Kubernetes. Je vidět, že kontejnery s linkerd-proxy se nacházejí ve stejném podu jako kontejnery aplikace. Tento typ diagramu je známý jako sidecar kontejner..)
Architektura service mesh má několik důležitých důsledků. Za prvé, protože úkolem proxy je zachycovat volání mezi službami, service mesh dává smysl pouze tehdy, pokud byla vaše aplikace vytvořena na základě určitě sady služeb. Mesh lze používat s monolity, ale to je jasně nadbytečné pro jeden jediný proxy, navíc její funkce pravděpodobně nebudou vyžadovány.
Další důležitý důsledek je, že service mesh vyžaduje obrovské množství proxy. Ve skutečnosti Linkerd připojuje linkerd-proxy k každé instanci každé služby (jiné implementace přidávají proxy k každému uzlu/hospodu/virtuálnímu stroji. V každém případě je to hodně). Tak aktivní použití proxy samo o sobě přináší řadu dodatečných komplikací:
- Proxy v data plane musí být rychlé, protože na každý požadavek připadá pár volání na proxy: jedno na straně klienta, jedno — na straně serveru.
- Také proxy musí být malé a lehké.Každá z nich spotřebovává prostředky paměti a CPU, a tato spotřeba lineárně poroste s aplikací.
- Budete potřebovat mechanismus pro nasazení a aktualizaci velkého množství proxy. Dělat to ručně není variantou.
Obecně vzato, service mesh vypadá takto (alespoň z ptačí perspektivy): nasadíte spoustu userspace proxy, které "něco dělají" s interním, mezi službami probíhajícím provozem, a používáte kontrolní vrstvu k jejich sledování a správě.
Nastal čas na otázku "Proč?"
K čemu je service mesh?
Jedině ti, kteří se poprvé setkali s myšlenkou service mesh, mohou zažít mírné chvění. Konstrukce service mesh navrhuje, že nejenže zvýší latenci aplikace, ale také bude spotřebovávat zdroje a přidá spoustu nových mechanismů do infrastruktury. Nejdříve nainstalujete service mesh a pak náhle zjistíte, že je třeba spravovat stovky (pokud ne tisíce) proxy. Kdo by se na to dobrovolně přihlásil?
Odpověď na tuto otázku má dvě části. Za prvé, provozní náklady spojené s nasazováním těchto proxy mohou být výrazně sníženy díky některým změnám, které se odehrávají v ekosystému (více o tom později).
Za druhé, takové zařízení je ve skutečnosti skvělý způsob, jak zavést dodatečnou logiku do systému. A nejen proto, že pomocí service mesh můžete přidat mnoho nových funkcí, ale také proto, že to můžete udělat, aniž byste zasahovali do ekosystému. Ve skutečnosti je celý model service mesh založen na tomto postulátu: v multiservisním systému, ať už dělají jednotlivé služby, provoz mezi nimi je ideálním místem pro přidání funkčnosti.
Například, v Linkerd (jako v většině meshů) se funkčnost soustředí převážně na HTTP volání, včetně HTTP/2 a gRPC*. Funkčnost je poměrně bohatá – lze ji rozdělit do tří tříd:
- Funkce spojené s spolehlivostí.Opakované požadavky, časové limity, kanárkový přístup (dělení/přesměrování provozu) atd.
- Funkce spojené s monitoringem.Agregace ukazatelů úspěšnosti, latencí a objemem požadavků pro každou službu nebo jednotlivé směry; vytváření topologických map služeb atd.
- Funkce spojené s bezpečností.Mutual TLS, řízení přístupu atd.
* Z pohledu Linkerd se gRPC od HTTP/2 prakticky neliší: v užitečném zatížení se používá pouze protobuf. Z pohledu vývojáře se tyto dvě věci samozřejmě liší.
Mnoho z těchto mechanismů funguje na úrovni požadavků (odtud také „L7-proxy“). Například pokud služba Foo posílá HTTP volání službě Bar, linkerd-proxy na straně Foo může provádět inteligentní vyvažování zátěže a směrovat volání z Foo na instance Bar v závislosti na pozorované latenci; může opakovat požadavek, pokud je to nutné (a pokud je idempotentní); může zaznamenat kód odpovědi a dobu čekání atd. Podobně linkerd-proxy na straně Bar může odmítnout požadavek, pokud není povolen nebo překročen limit požadavků; může zaznamenat latenci z jeho strany, atd.
Proxy mohou „dělat něco“ i na úrovni připojení. Například linkerd-proxy na straně Foo může iniciovat TLS-připojení, zatímco linkerd-proxy na straně Bar je může ukončit, a obě strany mohou kontrolovat TLS certifikáty navzájem. To zajišťuje nejen šifrování mezi službami, ale i kryptograficky bezpečný způsob identifikace služeb: Foo a Bar mohou „dokázat“, že jsou tím, za koho se vydávají.
* „Navzájem“ znamená, že certifikát klienta je také ověřován (vzájemné TLS). V „klasickém“ TLS, například mezi prohlížečem a serverem, se obvykle ověřuje certifikát pouze jedné strany (serveru).
Bez ohledu na to, zda fungují na úrovni požadavků nebo připojení, je důležité zdůraznit, že všechny funkce service mesh mají provozní charakter. Linkerd není schopen transformovat sémantiku užitečného zatížení — například přidávat pole do JSON fragmentu nebo provádět změny v protobuf. O této důležité vlastnosti budeme hovořit později, když se budeme zabývat ESB a middleware.
Toto je soubor funkcí, které nabízí service mesh. Vzniká otázka: proč je neimplementovat přímo v aplikaci? A proč se vůbec zabývat proxy?
Proč je service mesh dobrý nápad
I když možnosti service mesh fascinují, její skutečná hodnota ve skutečnosti neleží v funkcích. Nakonec můžeme můžeme implementovat je přímo v aplikaci (poté uvidíme, že to byla podstata service mesh). Pokud bychom to měli vyjádřit jednou větou, hodnota service mesh spočívá v následujícím: poskytuje funkce, které jsou kriticky důležité pro fungování moderního serverového softwaru, jednotně pro celý stack a nezávisle na kódu aplikace.
Pojďme tuto větu analyzovat.
«Funkce, které jsou kriticky důležité pro fungování moderního serverového softwaruPokud vytváříte transakční serverovou aplikaci, která je spojena s veřejným internetem, přijímá požadavky z vnějšího světa a odpovídá na ně během krátkého časového úseku - například webová aplikace, API server, a vlastně většina jiných moderních aplikací - a pokud ji implementujete jako sadu služeb, které vzájemně synchronně spolupracují, a pokud neustále modernizujete tento software, přidáváte nové funkcionality, a pokud musíte udržovat tuto systém ve funkčním stavu během jeho modifikace - v tomto případě vás gratuluji, zabýváte se vytvářením moderního serverového softwaru. A všechny tyto úžasné funkce, které byly zmíněny výše, se ukazují jako nezbytné pro vás. Aplikace musí být spolehlivá a bezpečná, a musíte mít možnost sledovat, co dělá. Právě tyto otázky pomáhá vyřešit service mesh.
(Dobře, do předchozího odstavce se přesto dostala má víra v to, že tento přístup je moderním způsobem, jak vytvářet serverový software. Jiní preferují vyvíjet monolity, "reaktivní mikroservisy" a jiné věci, které nespadají pod definici, kterou jsem uvedl výše. Tito lidé mají jistě svůj názor, který se liší od mého. Na oplátku si myslím, že "nejsou správní" - i když pro ně service mesh není příliš užitečná).
«Jednotně pro celý stackFunkce poskytované service mesh nejsou jen kriticky důležité. Jsou aplikovány na všechny služby v aplikaci nezávisle na tom, v jakém jazyce byly napsány, jaký framework používají, kdo je napsal, jak byly nasazeny a na všechny ostatní nuance jejich vývoje a využití.
«Nezávisle na kódu aplikaceKonečně, service mesh nejen poskytuje jednotné funkce pro celý stack — dělá to způsobem, který nevyžaduje úpravy aplikace. Základní funkcionalita service mesh, včetně úkolů souvisejících s konfigurací, aktualizacemi, provozem, údržbou atd., je umístěna výhradně na úrovni platformy a je nezávislá na aplikaci. Aplikace se může měnit, aniž by zasahovala do service mesh. Na oplátku se service mesh může měnit bez jakékoli účasti aplikace.
Stručně řečeno, service mesh nejenže poskytuje životně důležité funkce, ale činí to globálním, jednotným a nezávislým na aplikaci způsobem. A proto, ačkoliv funkčnost service mesh může být implementována v kódu služby (například jako knihovna zahrnutá v každé službě), tento přístup nezajistí jednotnost a nezávislost, které jsou tolik cenné v případě service mesh.
A vše, co pro to potřebujete, je přidat hromadu proxy! Slibuji, velmi brzy prozkoumáme provozní náklady spojené s přidáním těchto proxy. Ale nejprve se zastavme a podívejme se na tuto myšlenku nezávislosti z pohledu různých lidí.
Komu pomáhá service mesh?
Ať už se to zdá jakkoli nepříjemné, aby nějaká technologie se stala důležitou součástí ekosystému, musí být přijata lidmi. Tak kdo je tedy zainteresován v service mesh? Kdo těží z jejího používání?
Pokud vyvíjíte moderní serverový software, můžete si svou tým přiblížit jako skupinu majitelů služeb, kteří společně vyvíjejí a implementují obchodní logiku, a majitelů platformy, kteří se zabývají vývojem vnitřní platformy, na které tyto služby běží. V malých organizacích to mohou být jedni a ti samí lidé, ale jak firma roste, tyto role se obvykle stávají výraznějšími a dokonce se dělí na podrole… (O měnící se povaze devopsu, organizačním vlivu mikroslužeb a tak dále toho lze říci mnohé. Ale prozatím přijměme tyto popisy jako dané).
Z tohoto pohledu jsou zřejmými beneficienty service mesh vlastníci platforem. Cílem platformního týmu je totiž vytvořit interní platformu, na které mohou vlastníci služeb realizovat obchodní logiku a dělat to způsobem, který zaručuje jejich maximální nezávislost na choulostivých detailech jejího provozu. Service mesh nejenže nabízí možnosti, které jsou pro dosažení tohoto cíle kriticky důležité: dělá to způsobem, který na vlastníky služeb zároveň nenahazuje žádné závislosti.
Vlastníci služeb také těží, ačkoliv více nepřímo. Cílem vlastníka služby je být co nejproduktivnější v realizaci logiky obchodního procesu a čím méně se musí starat o otázky provozu, tím lépe. Místo toho, aby se zabývali implementací například politiky opakovaných požadavků nebo TLS, mohou se soustředit výhradně na obchodní úkoly a doufat, že platforma se postará o všechno ostatní. Pro ně je to velká výhoda.
Organizační hodnotu tohoto rozdělení mezi vlastníky platforem a služeb je těžké přeceňovat. Myslím, že to přispívá hlavní k hodnotě service mesh.
Tuto lekci jsme se naučili, když nám jeden z prvních fanoušků Linkerd řekl, proč si vybrali service mesh: protože jim to umožnilo „minimalizovat zbytečné diskuse“. Tady je trochu podrobností: kluci z jedné velké společnosti migrali svou platformu do Kubernetes. Protože aplikace pracovala s citlivými informacemi, chtěli zašifrovat všechny komunikace v klastrech. Situaci však ztěžovalo množství služeb a stovky vývojářských týmů. Perspektiva spojit se se všemi a přesvědčit je, aby podpořili TLS ve svých plánech, je vůbec netěšila. Po instalaci Linkerd přesunuli odpovědnost od vývojářů (z jejichž pohledu to bylo zbytečné obtěžování) na platformáře, pro které to bylo prioritou nejvyšší úrovně. Jinými slovy, Linkerd pro ně řešil spíše organizační než technickou problematiku.
Stručně řečeno, service mesh je spíše řešení ne technického, ale socio-technického problému. (Děkuji za seznámení s tímto termínem.)
Vyřeší service mesh všechny mé problémy?
Ano. Myslím tím, že ne!
Pokud se podíváme na tři třídy funkcí uvedených výše: spolehlivost, bezpečnost a observabilita, je jasné, že service mesh 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í schopen se rozhodnout, co vrátit uživateli, pokud služba úplně selhala – tato rozhodnutí by měla učinit aplikace. Linkerd může sledovat statistiku úspěšných požadavků, avšak není schopen nahlédnout do služby a poskytnout její interní metriky – takové nástroje by měly být součástí aplikace. A i když Linkerd dokáže organizovat mTLS, kompletní řešení v oblasti zabezpečení vyžaduje mnohem více.
Podmnožina funkcí v těchto oblastech, které nabízí service mesh, se týká funkcí platformy. Tím mám na mysli funkce, které:
- Jsou nezávislé na obchodní logice. Způsob, jakým se vytváří histogramy volání mezi Foo a Bar, vůbec nezávisí na tom, proč Foo volá Bar.
- Je těžké to správně implementovat. V Linkerd jsou opakované pokusy parametrize různými složitými prvky, jako jsou rozpočty pokusů (retry budgets), protože primitivní přístup-čelní do implementace takových věcí jistě povede k vzniku tzv. "laviny požadavků" (retry storm) a dalším problémům typickým pro distribuované systémy.
- Jsou nejúčinnější, když jsou aplikovány jednotně. Mechanismus TLS dává smysl pouze v případě, že je používaný všude.
Protože tyto funkce jsou implementovány na úrovni proxy (nikoli na úrovni aplikace), service mesh je poskytuje na úrovni platformy, nikoli na úrovni aplikace. Takže nezáleží na tom, v jakém jazyce jsou služby napsány, jaký framework používají, kdo je napsal a proč. Proxy pracují mimo všechny tyto podrobnosti, a základní logika této funkčnosti, včetně úkolů pro konfiguraci, aktualizaci, údržbu a tak dále, leží výhradně na úrovni platformy.
Příklady schopností service mesh
Na závěr chci říci, že service mesh není úplné řešení pro zajištění spolehlivosti, pozorovatelnosti nebo bezpečnosti. Rozsah těchto oblastí vyžaduje nezbytnou účast majitelů služeb, týmů Ops/SRE a dalších subjektů ve společnosti. Service mesh poskytuje pouze „průřez“ na úrovni platformy pro každou z těchto oblastí.
Proč se service mesh stala populární právě teď?
Pravděpodobně se nyní ptáte: dobře, pokud je service mesh tak skvělá, proč jsme nezačali nasazovat miliony proxy do stacku před deseti lety?
Na tuto otázku existuje velmi jednoduchá odpověď: před deseti lety všichni stavěli monolity a service mesh nikdo nepotřeboval. To je pravda, ale podle mého názoru v tom je podstata. I před deseti lety byla koncepce mikroslužeb jako perspektivní způsob tvorby rozsáhlých systémů široce diskutována a uplatňována v takových společnostech, jako jsou Twitter, Facebook, Google a Netflix. Obecné vnímání — alespoň v těch částech odvětví, se kterými jsem měl čest pracovat — bylo, že mikroslužby jsou „správný způsob“ jak vytvářet rozsáhlé systémy, i když to bylo neuvěřitelně obtížné.
Samozřejmě, že před deseti lety existovaly společnosti, které pracovaly s mikroslužbami, ale rozhodně nevkládaly proxy kamkoliv to šlo, aby vytvořily service mesh. Nicméně, když se na to podíváte zblízka, dělaly něco podobného: v mnoha z těchto firem bylo předepsáno používat speciální interní knihovnu pro síťovou komunikaci (někdy nazývanou knihovna fat client, fat client library).
Netflix měl Hysterix, Google měl Stubby, Twitter měl knihovnu Finagle. Finagle byla například povinná pro každou novou službu na Twitteru. Zpracovávala jak klientskou, tak serverovou část spojení, umožňovala opakování požadavků, podporovala směrování požadavků, vyvažování zátěže a měření. Zajišťovala konzistentní vrstvu spolehlivosti a pozorovatelnosti pro celý stack Twitteru, bez ohledu na to, čemu se služba věnovala. Samozřejmě fungovala pouze pro jazyky JVM a byla založena na programovacím modelu, který bylo třeba použít pro celou aplikaci. Její funkce byly téměř shodné s funkcemi service mesh. (Ve skutečnosti první verze Linkerd byla vlastně Finagle, obalený v podobě proxy.)
Takže před deseti lety existovaly nejen mikroslužby, ale také speciální knihovny proto-service-mesh, které řešily stejné problémy, které service mesh řeší dnes. Nicméně samotná service mesh tehdy neexistovala. Musela nastat ještě jedna změna, než se objevila.
A právě zde leží hlubší odpověď, skrytá v dalším posunu, který se udál za posledních 10 let: došlo k drtivému poklesu nákladů na nasazení mikroslužeb. Zmíněné společnosti, které používaly mikroslužby před deseti lety: Twitter, Netflix, Facebook, Google — byly velkými společnostmi s obrovskými zdroji. Měly nejen potřebu, ale i možnost vytvářet, nasazovat a provozovat rozsáhlé aplikace na základě mikroslužeb. Energie a úsilí, které inženýři Twitteru vložili do přechodu z monolitického na mikroslužbový přístup, jsou naprosto ohromující. (Upřímně řečeno, stejně jako fakt, že se to podařilo.) Takového druhu infrastrukturální manévry byly tehdy pro menší společnosti nemožné.
Přenášejme se do současnosti. Dnes existují startupy, kde je poměr mikroslužeb k vývojářům 5:1 (nebo i méně) ), a navíc je úspěšně zvládají! Pokud startup o 5 lidech dokáže bez námahy provozovat 50 mikroslužeb, znamená to, že něco výrazně snížilo náklady na jejich zavedení.
1500 mikroslužeb v Monzo; každý řádek je předepsané síťové pravidlo, které povoluje provoz.
Drastické snížení nákladů na provoz mikroslužeb je výsledkem jednoho procesu: růstu popularity kontejnerů. a orchestrátorů.. Právě v tom spočívá hluboká odpověď na otázku, co přispělo k vzniku service mesh. Stejná technologie učinila jak service mesh, tak mikroslužby atraktivní: Kubernetes a Docker.
Proč? Nu, Docker řeší jeden velký problém — problém balení. Balením aplikace a jejích (ne-síťových) runtime závislostí do kontejneru přetváří Docker aplikaci na zaměnitelnou jednotku, kterou lze umístit a spustit kdekoli. Zároveň výrazně zjednodušuje provoz. vícejazyčných. stack: protože kontejner je atomární jednotkou provádění, pro účely nasazení a provozu nezáleží na tom, co je uvnitř, ať už je to aplikace na JVM, Node, Go, Python nebo Ruby. Jen ji spustíte a je to.
Kubernetes posouvá vše na novou úroveň. Nyní, když je k dispozici spousta "prováděcích věcí" a mnoho strojů, na kterých je můžete spouštět, vzniká potřeba nástroje, který je dokáže mezi sebou mapovat. Ve širokém smyslu, dáváte Kubernetes spoustu kontejnerů a spoustu strojů, a on je mapuje mezi sebou (samozřejmě, že je to dynamický a neustále se měnící proces: nové kontejnery se pohybují systémem, stroje se spouštějí a zastavují atd. Nicméně Kubernetes to všechno zohledňuje).
Po nastavení Kubernetes se časové náklady na nasazení a provoz jednoho servisu příliš neliší od nákladů na nasazení a provoz deseti servisů (ve skutečnosti jsou prakticky shodné i pro 100 servisů). Přidejte k tomu kontejnery jako mechanismus balení, který podporuje vícejazyčnou implementaci, a získáte množství nových aplikací realizovaných ve formě mikroslužeb napsaných v různých jazycích — přesně to prostředí, pro které je service mesh velmi vhodná.
Takže jsme se dostali k odpovědi na otázku, proč se myšlenka service mesh stala populární právě teď: ta jednotnost, kterou Kubernetes zajišťuje pro služby, je přímo aplikovatelná na provozní úkoly, které stojí před service mesh. Balením proxy do kontejnerů dáváte Kubernetes úkol je připevnit kamkoli, a voila! Výsledkem je service mesh, přičemž celou mechaniku jejího nasazení obsluhuje Kubernetes. (Asi pohledem z ptačí perspektivy. Samozřejmě, že v tomto procesu existuje mnoho nuancí.)
Shrnutí: důvod, proč se service mesh stala populární právě nyní a ne před deseti lety, spočívá v tom, že Kubernetes a Docker nejen výrazně zvýšily potřebu tím, že zjednodušily realizaci aplikací jako souboru vícejazykových mikroslužeb, ale také výrazně snížily náklady na jejich provoz, umožňující mechanismy nasazení a podpory parků sidecar-proxy.
Proč je tolik diskuzí o service mesh?
Upozornění: v této části se uchyluji k různým předpokladům, domněnkám, výmyslům a interním informacím.
Po vyhledávání výrazu „service mesh“ narazíte na spoustu přepracovaného nízkokalorického obsahu, podivných projektů a kaleidoskopu zkreslení, hodných echo komory. Každé módní nové technologii to má, ale v případě service mesh je problém obzvlášť vážný. Proč?
No, částečně je to moje vina. Dal jsem veškeré úsilí do propagace Linkerd a service mesh při každé příležitosti, prostřednictvím nesčetných příspěvků na blogu a článků jako je tento. Ale nejsem tak mocný. Aby bylo možné na tuto otázku skutečně odpovědět, je třeba se trochu zabývat celkovou situací. O ní nelze hovořit, aniž bychom zmínili jeden projekt: — open-source service mesh vyvíjený společně Googlem, IBM a Lyft.
(Tyto tři společnosti mají zcela odlišné role: účast Lyftu se zdá být pouze jménem; jsou autory Envoy, ale nevyužívají Istio ani se na jeho vývoji nepodílejí. IBM se podílí na vývoji Istio a využívá ho. Google se aktivně podílí na vývoji Istio, ale podle toho, co mohu soudě, ho ve skutečnosti nepoužívá.)
Projekt Istio je pozoruhodný dvěma rysy. Za prvé, jsou to obrovské marketingové úsilí, které Google, konkrétně, vynakládá na jeho propagaci. Odhaduji, že většina lidí, kteří jsou v současnosti obeznámeni s konceptem service mesh, o něm poprvé slyšela díky Istio. Druhou zvláštností je, jak špatně bylo Istio přijato. V této záležitosti jsem, očividně, zainteresovaná strana, ale snažíc se zachovat co nejobjektivnější postoj, si nemohu pomoci , což není příliš charakteristické (i když ne unikátní: na mysli mi vytanula systemd, …) pro open-source projekt.
(V praxi se zdá, že Istio má problémy nejen se složitostí a UX, ale i s výkonem. Například během , provedeného třetí stranou, odborníci zjistili situace, v nichž byly latence na konci (tail latency) Istio stokrát vyšší než obdobný údaj pro Linkerd, a také situace s nedostatkem prostředků, kdy Linkerd nadále úspěšně fungoval, zatímco Istio zcela selhal.)
Když opustím stranou své teorie o tom, proč k tomu došlo, domnívám se, že obrovská popularita service mesh je vlastně způsobena účastí Google. A to konkrétně kombinací následujících tří faktorů:
- agresivní propagace Istio ze strany Google;
- odpovídající negativní, kritický postoj k projektu;
- nedávný rychlý vzestup popularity Kubernetes, jehož vzpomínky jsou stále čerstvé.
Tyto faktory se společně spojují v jakési omamné, bezzásobové prostředí, ve kterém se schopnost racionálního úsudku oslabuje a zbývá pouze podivná varianta .
Z pohledu Linkerd bych to popsal jako nejednoznačné dobro. Mám na mysli, že je skvělé, že se service mesh dostalo do mainstreamu — což v roce 2016 nebylo, když Linkerd teprve vznikal a bylo opravdu těžké přitáhnout pozornost k projektu. Nyní tento problém neexistuje! Ale špatná zpráva je, že situace se service mesh je dnes tak zamotaná, že prakticky není možné pochopit, které projekty skutečně spadají do kategorie service mesh (nemluvě o tom, abychom pochopili, který z nich je nejvhodnější pro konkrétní případ použití). To zcela jistě brání všem (a určitě v některých případech může být Istio nebo jiný projekt lépe přizpůsobený, protože Linkerd také není univerzální řešení).
Z pohledu Linkerd byla naše strategie ignorovat šum, pokračovat v soustředění na řešení skutečných problémů komunity a v podstatě čekat, až nadšení vychladne. Nakonec hype ustoupí a my budeme moci pokračovat v klidné práci.
Zatím nám všem zbývá vydržet trochu déle.
Bude pro mě, skromného software inženýra, service mesh užitečná?
Na tuto otázku pomůže odpovědět následující dotazník:
Zaměřujete se výhradně na implementaci obchodní logiky? V takovém případě pro vás service mesh nebude užitečná. Samozřejmě, můžete se o ni zajímat, ale ideálně by service mesh neměla mít přímý dopad na nic ve vašem prostředí. Pokračujte v práci na tom, za co vám platí.
Podporujete platformu ve společnosti, která používá Kubernetes? Ano, v tomto případě potřebujete service mesh (pokud jej samozřejmě nepoužíváte K8s jen pro spuštění monolitu nebo dávkového zpracování – v tom případě bych se chtěl zeptat, proč potřebujete K8s). Pravděpodobně se ocitnete v situaci se spoustou mikroslužeb napsaných různými lidmi. Všechny si navzájem interagují a jsou spojeny v klubko runtime závislostí, a vy musíte najít způsob, jak se s tím vyrovnat. Použití Kubernetes vám umožňuje vybrat si service mesh „na míru“. Za tímto účelem se seznamte s jejich možnostmi a vlastnostmi a odpovězte na otázku, zda vám nějaký projekt vyhovuje (doporučuji začít zkoumání s Linkerd).
Zabýváte se platformou ve společnosti, která NEPOUŽÍVÁ Kubernetes, ale používá mikroslužby? V takovém případě vám service mesh může být užitečná, avšak její použití bude netriviální. Samozřejmě, můžete imitovat funkci service mesh tím, že rozmístíte spoustu proxy, ale důležitou výhodou Kubernetes je právě model nasazení: ruční správa těchto proxy si vyžádá mnohem více času, úsilí a nákladů.
Odpovídáte za platformu ve společnosti, která pracuje s monolity? V takovém případě vám service mesh pravděpodobně není potřeba. Pokud pracujete s monolity (nebo dokonce s sadami monolitů), které mají jasně definované a zřídka se měnící vzory interakce, pak vám service mesh mnoho nenabídne. Takže ji můžete prostě ignorovat a doufat, že zmizí jako zlý sen...
Závěr
Pravděpodobně bychom service mesh neměli nazývat "nejvíce hype technologií na světě" – tato pochybná pocta pravděpodobně patří bitcoinu nebo AI. Možná se nachází v první pětce. Ale pokud se prokoušete přes vrstvy šumu a hluku, stane se jasným, že service mesh přináší skutečné výhody těm, kdo vytvářejí aplikace v Kubernetes.
Chtěl bych, abyste vyzkoušeli Linkerd – jeho nainstalování do cloudu Kubernetes (nebo dokonce do Minikube na notebooku) , a sami uvidíte, o čem mluvím.
Často kladené dotazy
— Pokud budu ignorovat service mesh, zmizí?
— Musím vás zklamat: service mesh je s námi na dlouho.
— Ale NECHCI používat service mesh!
— Tak to nemusíte! Jen si přečtěte můj dotazník výše, abyste pochopili, zda se alespoň na její základy podívat.
— Není to jen staré dobré ESB/middleware pod novou omáčkou?
— Služební síť se zabývá provozní logikou, nikoli smyslem. podnikové sběrnice (). Uchování tohoto rozdělení pomáhá služební síti vyhnout se stejnému osudu.
— Čím se služební síť liší od API brán?
— Existuje milion článků na toto téma. Stačí googlit.
— Je Envoy služební síť?
— Ne, Envoy není služební síť, je to proxy server. Lze jej použít k zajištění služební sítě (a mnoha dalším účelům – je to proxy pro obecné použití). Ale sám o sobě není služební síť.
— Je Network Service Mesh služební síť?
— Ne. I když se podle názvu zdá, že je to služební síť (jaké marketingové zázraky?).
— Pomůže mi služební síť s mým reaktivním asynchronním systémem založeným na frontách zpráv?
— Ne, služební síť vám nepomůže.
— Jakou služební síť bych měl použít?
— , to je jasné.
— Článek je špatný! / Autor na smetí!
— Prosím, podělte se o odkaz na něj se všemi svými přáteli, aby se v tom mohli přesvědčit!
Poděkování
Jak jste mohli uhodnout z názvu, tento článek byl inspirován fantastickým traktátem Jay Krepsa „“. Potkal jsem Jay’e před deseti lety, když jsem dělal rozhovor pro LinkedIn, a od té doby je pro mě inspirací.
Ačkoliv se rád nazývám „vývojářem Linkerd“, realita je taková, že spíše udržuji soubor README.md v projektu. Na Linkerd dnes pracuje , , lidí a tento projekt by se neuskutečnil bez úžasného společenství přispěvatelů a uživatelů.
A na závěr zvláštní poděkování zakladateli Linkerd, (primus inter pares), který se spolu se mnou před mnoha lety vrhl do této rušné problematiky služební sítě.
P.S. od překladatele
Přečtěte si také náš blog:
- «»;
- «»;
- «»;
- «»;
- «».
Zdroj: habr.com
