🥇Případy použití servisní sítě

Poznámka. přel.: Autor tohoto článku (Luc Perkins) je zastáncem vývojářů v organizaci CNCF, která je domovem takových projektů s otevřeným zdrojovým kódem jako Linkerd, SMI (Service Mesh Interface) a Kuma (mimochodem, také vás zajímalo, proč je Istio není na tomto seznamu?). Znovu se snaží přinést komunitě DevOps lepší pochopení trendového humbuku zvaného „service mesh“, uvádí 16 charakteristických schopností, které taková řešení poskytují.

Dnes servisní síť ― jedno z nejžhavějších témat v oblasti softwarového inženýrství (a právem!). Myslím si, že tato technologie je neuvěřitelně slibná a rád bych viděl, aby byla široce rozšířena (když to bude mít smysl, samozřejmě). Pro většinu lidí je však stále obklopen aurou tajemna. Přitom i ti, kteří dobře známý s ním je často obtížné vyjádřit jeho výhody a co přesně to je (včetně vašich skutečných). V tomto článku se pokusím napravit situaci uvedením různých případy užití "servisní sítě"*.

* Poznámka překlad: zde a dále v článku bude přesně tento překlad („servisní síť“) použit pro stále nový termín servisní síť.

Nejprve bych ale chtěl uvést několik poznámek:

Nikdy jsem se servisními sítěmi nepracoval ani jsem je nepoužíval mimo projekty zahájené pro vlastní vzdělávání. Na druhou stranu jsem to byl já, kdo v roce 2015 napsal hromadu dokumentace pro interní servisní síť Twitteru (tehdy se tomu ještě neříkalo „service mesh“) a podílel se na vývoji webu a dokumentace pro Linkerd, takže to něco znamená.
Můj seznam je přibližný a neúplný. Mohou existovat případy použití, které neznám, a nové možnosti se pravděpodobně objeví v průběhu času, jak se technologie vyvíjí a její popularita roste.
Zároveň ne každá existující implementace sítě služeb podporuje všechny uvedené případy použití. Moje výroky jako „síť služeb může...“ by proto měla být chápána jako „individuální a snad všechny populární implementace sítě služeb mohou...“.
Pořadí příkladů nehraje žádný rozdíl.

Krátký seznam:

vyhledávání služeb;
šifrování;
ověřování a autorizace;
vyvažování zátěže;
přerušení obvodu;
automatické škálování;
kanárské nasazení;
modrozelené nasazení;
zdravotní prohlídka;
odlehčení zátěže;
zrcadlení dopravy;
izolace;
omezení rychlosti požadavků, opakování a časové limity;
telemetrie;
audit;
vizualizace.

1. Zjištění služby

TL;DR: Připojte se k dalším službám v síti pomocí jednoduchých názvů.

Služby by měly být schopny se navzájem automaticky „najít“ pomocí vhodných jmen – např. service.api.production, pets/staging nebo cassandra. Cloudová prostředí jsou elastická a jeden název může skrývat mnoho instancí služby. Je jasné, že v takové situaci je fyzicky nemožné napevno zakódovat všechny IP adresy.

Navíc, když jedna služba najde jinou, měla by být schopna odesílat požadavky této službě bez obav, že skončí na vstupu její nefunkční instance. Jinými slovy, síť služeb musí monitorovat stav všech instancí služeb a udržovat seznam hostitelů co nejaktuálnější.

Každá síť služeb implementuje mechanismus zjišťování služeb odlišně. V tuto chvíli je nejběžnějším způsobem delegování na externí procesy, jako je Kubernetes DNS. V minulosti jsme na Twitteru používali k tomuto účelu systém pojmenování Podvádět. Technologie service mesh navíc umožňuje vznik vlastních pojmenovacích mechanismů (ačkoli jsem ještě neviděl žádnou implementaci SM s takovou funkčností).

2. Šifrování

TL;DR: Zbavte se nešifrovaného provozu mezi službami a udělejte tento proces automatizovaným a škálovatelným.

Je příjemné vědět, že útočníci nemohou proniknout do vaší vnitřní sítě. Firewally v tom dělají skvělou práci. Co se ale stane, když se dovnitř dostane hacker? Bude si moci s vnitroslužbovým provozem dělat, co chce? Doufejme, že se tak nakonec nestane. Abyste tomuto scénáři zabránili, měli byste implementovat síť s nulovou důvěryhodností, ve které je veškerý provoz mezi službami šifrován. Většina moderních servisních sítí toho dosahuje vzájemným TLS (vzájemné TLS, mTLS). V některých případech funguje mTLS v celých oblacích a shlucích (myslím, že meziplanetární komunikace bude jednou uspořádána podobně).

Samozřejmě pro síť služeb mTLS volitelný. Každá služba se může postarat o své vlastní TLS, ale to znamená, že budete muset najít způsob, jak generovat certifikáty, distribuovat je mezi hostitele služeb a zahrnout kód do aplikace, která bude tyto certifikáty načítat ze souborů. Ano, nezapomeňte si tyto certifikáty v pravidelných intervalech obnovovat. Servisní sítě automatizují mTLS se systémy jako SPIFFE, které zase automatizují proces vydávání a rotace certifikátů.

3. Autentizace a autorizace

TL;DR: Určete, kdo je žadatel, a definujte, co smí dělat, než požadavek vůbec dorazí ke službě.

Služby často chtějí vědět kdo provede požadavek (autentizaci) a na základě těchto informací rozhodne že daná entita smí dělat (oprávnění). V tomto případě se zájmeno „kdo“ může skrývat:

Ostatní služby. Tomu se říká "ověření" peer" Například servis web chce získat přístup ke službě db. Servisní sítě obvykle řeší tyto problémy pomocí mTLS: certifikáty v tomto případě fungují jako nezbytný identifikátor.
Někteří lidští uživatelé. Tomu se říká "ověření" žádost" Například uživatel haxor69 chce koupit novou lampu. Servisní sítě poskytují různé mechanismy, např. Webové tokeny JSON.
Mnoho z nás to udělalo v kódu aplikace. Přichází žádost, prohlížíme stůl users, najděte uživatele a porovnejte heslo, poté zkontrolujte sloupec permissions atd. V případě sítě služeb k tomu dojde dříve, než požadavek vůbec dorazí ke službě.

Jakmile zjistíme, od koho žádost přišla, musíme určit, co tento subjekt smí dělat. Některé sítě služeb vám umožňují nastavit základní zásady (o tom, kdo co může dělat) jako soubory YAML nebo na příkazovém řádku, zatímco jiné nabízejí integraci s frameworky, jako je Otevřete Policy Agent. Konečným cílem je, aby vaše služby přijaly jakýkoli požadavek, bezpečně za předpokladu, že pochází z důvěryhodného zdroje и tato akce je povolena.

4. Vyvažování zátěže

TL;DR: Rozloží zátěž mezi instance služby podle specifického vzoru.

„Služba“ v rámci servisní sekce se velmi často skládá z mnoha identických instancí. Například dnes služba cache sestává z 5 kopií a zítra se jejich počet může zvýšit na 11. Žádosti zasílány na cache, musí být distribuovány v souladu s konkrétním účelem. Například minimalizovat latenci nebo maximalizovat pravděpodobnost, že se dostanete k fungující instanci. Nejčastěji používaným algoritmem je Round-robin, ale existuje mnoho dalších – například vážená metoda (váženo) dotazy (můžete vybrat preferované cíle), prsten (prsten) hashování (použití konzistentního hashování napříč upstreamovými hostiteli) nebo metoda nejmenšího požadavku (přednost je dána instanci s nejmenším počtem požadavků).

Klasické balancery mají další funkce, jako je HTTP caching a DDoS ochrana, ale pro provoz z východu na západ (tedy pro provoz proudící v rámci datového centra - cca transl.) nejsou příliš relevantní (typický rozsah service mesh). Samozřejmě není nutné používat síť služeb pro vyrovnávání zátěže, ale umožňuje vám nastavit a řídit zásady vyrovnávání pro každou službu z centralizované řídicí vrstvy, čímž eliminuje potřebu spouštět a konfigurovat samostatné nástroje pro vyrovnávání zátěže v zásobníku sítě. .

5. Přerušení obvodu

TL;DR: Zastavte provoz na problematické službě a kontrolujte poškození v nejhorších scénářích.

Pokud se služba z nějakého důvodu nemůže vypořádat s provozem, poskytuje síť služeb několik možností řešení tohoto problému (další budou popsány v příslušných částech). Přerušení obvodu je nejzávažnější možností pro odpojení služby od provozu. Samo o sobě to však nedává smysl – je potřeba záložní plán. Může být zajištěn protitlak (protitlak) na služby, které podávají požadavky (jen si na to nezapomeňte nakonfigurovat síť služeb!), nebo například obarvit stavovou stránku červeně a přesměrovat uživatele na jinou verzi stránky s „padající velrybou“ („Twitter je dolů").

Servisní sítě umožňují nejen definovat kdy bude následovat vypnutí a že toto bude následovat. V tomto případě může „kdy“ zahrnovat libovolnou kombinaci zadaných parametrů: celkový počet požadavků za určité období, počet paralelních připojení, nevyřízené požadavky, aktivní opakování atd.

Pravděpodobně nechcete zneužít přerušení obvodu, ale je příjemné vědět, že máte záložní plán pro případ nouze.

6. Automatické škálování

TL;DR: Zvyšte nebo snižte počet instancí služby v závislosti na zadaných kritériích.

Servisní sítě nejsou plánovače, takže ne vykonat škálování sebe sama. Mohou však poskytnout informace o tom, kteří plánovači budou zakládat svá rozhodnutí. Vzhledem k tomu, že sítě služeb mají přístup k veškerému provozu mezi službami, mají rozsáhlé informace o tom, co se děje: které služby mají problémy, které služby jsou velmi málo zatíženy (kapacita jim přidělená je plýtvána) atd.

Například Kubernetes škáluje služby na základě využití CPU a paměti podů (viz naše zpráva "Automatické škálování a správa zdrojů v Kubernetes"- Cca. překlad.), ale pokud se rozhodnete škálovat na základě jakékoli jiné metriky (v našem případě související s návštěvností), budete potřebovat speciální metriku. Řízení takhle ukazuje, jak to udělat s Vyslanec, Stejný и Prometheus, ale samotný proces je poměrně komplikovaný. Chtěli bychom, aby to síť služeb zjednodušila tím, že nám umožní jednoduše nastavit podmínky jako „zvýšit počet instancí služeb auth, pokud počet nevyřízených požadavků během minuty překročí prahovou hodnotu."

7. Kanárské nasazení

TL;DR: Testujte nové funkce nebo verze služeb na podskupině uživatelů.

Řekněme, že vyvíjíte produkt SaaS a máte v úmyslu uvést na trh jeho skvělou novou verzi. Vyzkoušeli jste to v inscenaci a fungovalo to skvěle. Jisté obavy z jejího chování v reálných podmínkách ale stále panují. Jinými slovy, musíte otestovat novou verzi na skutečných problémech, aniž byste riskovali důvěru uživatelů. K tomu se skvěle hodí nasazení Canary. Umožňují vám předvést novou funkci podskupině uživatelů. Tato podmnožina se může skládat z nejvěrnějších uživatelů nebo těch, kteří pracují s bezplatnou verzí produktu, nebo uživatelů, kteří vyjádřili touhu být „pokusnými králíky“.

Sítě služeb to implementují tím, že vám umožňují zadat kritéria, která určují, kdo uvidí kterou verzi aplikace, a podle toho směrovat provoz. Na samotných službách se však nic nemění. Verze 1.0 služby věří, že všechny požadavky pocházejí od uživatelů, kteří by ji měli vidět, a verze 1.1 věří totéž svým uživatelům. Mezitím můžete změnit procento provozu mezi starou a novou verzí a přesměrovat rostoucí počet uživatelů na novou, pokud bude fungovat stabilně a vaši „pokusní králíci“ dají souhlas.

8. Modro-zelené nasazení

TL;DR: Zaveďte skvělou novou funkci, ale buďte připraveni okamžitě vzít vše zpět.

Význam modro-zelené nasazení je zavést novou „modrou“ službu a spustit ji souběžně se starou, „zelenou“. Pokud vše půjde hladce a nová služba bude fungovat dobře, lze starou postupně deaktivovat. (Běda, jednou tato nová „modrá“ služba zopakuje osud té „zelené“ a zmizí...) Modrozelené nasazení se od kanárských liší tím, že nová funkce pokrývá všichni najednou uživatelé (není součástí); Jde o to mít připravený „bezpečný přístav“ pro případ, že by se něco pokazilo.

Servisní sítě nabízejí velmi pohodlný způsob, jak otestovat „modrou“ službu a v případě problémů okamžitě přejít na fungující „zelenou“. Nemluvě o tom, že po cestě poskytují spoustu informací (viz „Telemetrie“ níže) o práci „modrého“, což pomáhá pochopit, zda je připraven na plný provoz.

Poznámka. přel.: Více o různých strategiích nasazení v Kubernetes (včetně zmiňovaného canary, blue/green a dalších) si můžete přečíst v tento článek.

9. Kontrola zdravotního stavu

TL;DR: Sledujte, které instance služby jsou funkční, a reagujte na ty, které již nejsou funkční.

Zdravotní prohlídka (zdravotní prohlídka) pomáhá rozhodnout, zda jsou instance služeb připraveny přijímat a zpracovávat provoz. Například v případě služeb HTTP může kontrola stavu vypadat jako požadavek GET na koncový bod /health. Odpovědět 200 OK bude znamenat, že instance je zdravá, jakákoli jiná - že není připravena přijímat provoz. Servisní sítě umožňují specifikovat jak způsob kontroly funkčnosti, tak frekvenci, s jakou bude tato kontrola prováděna. Tyto informace pak mohou být použity pro jiné účely - například pro vyrovnávání zátěže a přerušení obvodu.

Kontrola stavu tedy není samostatný případ použití, ale obvykle se používá k dosažení jiných cílů. V závislosti na výsledcích kontrol stavu mohou být také vyžadovány akce mimo jiné cíle sítě služeb: například aktualizace stavové stránky, vytvoření problému na GitHubu nebo vyplnění lístku JIRA. A servisní síť nabízí pohodlný mechanismus pro automatizaci toho všeho.

10. Odlehčení zátěže

TL;DR: Přesměrování provozu v reakci na dočasný nárůst využití.

Pokud je určitá služba přetížena provozem, můžete část tohoto provozu dočasně přesměrovat na jiné místo (tj. (kůlna) je tam). Například do zálohovací služby nebo datového centra nebo do trvalého lis téma. V důsledku toho bude služba nadále zpracovávat některé požadavky, místo aby se zhroutila a přestala zpracovávat úplně všechno. Odlehčení zátěže je vhodnější než přerušení obvodu, ale přesto není vhodné jej zneužívat. Pomáhá předcházet kaskádovým selháním, která způsobují pád služeb.

11. Paralelizace/zrcadlení provozu

TL;DR: Pošlete jeden požadavek na několik míst najednou.

Někdy je potřeba poslat požadavek (nebo určitý výběr požadavků) na více služeb najednou. Typickým příkladem je odesílání části produkčního provozu do stagingové služby. Hlavní produkční webový server odešle požadavek navazující službě products.production a jen jemu. A servisní síť inteligentně zkopíruje tento požadavek a odešle jej products.staging, o čemž webový server ani neví.

Další související případ použití sítě služeb, který lze implementovat vedle paralelizace provozu, je regresní testování. Zahrnuje odesílání stejných požadavků na různé verze služby a kontrolu, zda se všechny verze chovají stejně. Ještě jsem nenarazil na implementaci servisní sítě s integrovaným systémem regresního testování jako Diffy, ale samotná myšlenka se zdá být slibná.

12. Izolace

TL;DR: Rozdělte svou síť služeb na mini-sítě.

Také známý jako segmentaceIzolace je umění rozdělit síť služeb na logicky odlišné segmenty, které o sobě navzájem nic nevědí. Izolace je trochu jako vytváření virtuálních privátních sítí. Zásadní rozdíl je v tom, že stále můžete využívat všechny výhody sítě služeb (jako je zjišťování služeb), ale s přidanou bezpečností. Pokud se například útočníkovi podaří proniknout do služby v jedné z podsítí, nebude schopen vidět, jaké služby běží v jiných podsítích, ani zachytit jejich provoz.

Kromě toho mohou být výhody také organizační. Možná budete chtít vytvořit podsíť svých služeb na základě struktury vaší společnosti a ulehčit vývojářům od kognitivní zátěže spojené s nutností mít na paměti celou síť služeb.

13. Omezení rychlosti požadavku, opakování a časové limity

TL;DR: Již nemusíte do své kódové základny začleňovat složité úlohy správy požadavků.

Všechny tyto věci by se daly považovat za samostatné případy použití, ale rozhodl jsem se je zkombinovat kvůli jedné společné vlastnosti: přebírají úkoly správy životního cyklu požadavků, které obvykle zpracovávají knihovny aplikací. Pokud vyvíjíte webový server v Ruby on Rails (neintegrovaný se sítí služeb), který odesílá požadavky na backendové služby prostřednictvím gRPC, aplikace se bude muset rozhodnout, co dělat, pokud N požadavků selže. Budete také muset zjistit, jaký objem provozu budou tyto služby schopny zpracovat a pevně zakódovat tyto parametry pomocí speciální knihovny. Navíc se aplikace bude muset rozhodnout, kdy je čas to vzdát a nechat požadavek vyprchat (na základě časového limitu). A aby bylo možné změnit některý z výše uvedených parametrů, bude nutné webový server zastavit, překonfigurovat a znovu spustit.

Přesunutí těchto úkolů do sítě služeb nejenže znamená, že o nich vývojáři služeb nebudou muset přemýšlet, ale také to, že na ně lze nahlížet globálnějším způsobem. Pokud je použit složitý řetězec služeb, řekněme A -> B -> C -> D -> E, je třeba vzít v úvahu celý životní cyklus požadavku. Pokud je úkolem prodloužit časové limity ve službě C, je logické to udělat najednou a ne po částech: aktualizací servisního kódu a čekáním, dokud není přijat požadavek na stažení a systém CI nasadí aktualizovanou službu.

14. Telemetrie

TL;DR: Sbírejte všechny potřebné (a ne tak docela) informace ze služeb.

Telemetrie je obecný pojem, který zahrnuje metriky, distribuované trasování a protokoly. Servisní sítě nabízejí mechanismy pro sběr a zpracování všech tří typů dat. Zde jsou věci trochu rozmazané, protože počet možných možností je příliš velký. Pro sběr metrik existuje Prometheus a další nástroje, které lze použít ke sběru protokolů plynulý, Loki, vektor et al. (například ClickHouse s naším srub pro K8 - cca. překlad.), pro distribuované sledování existuje Mořský pták a tak dále. Každá síť služeb může podporovat některé nástroje a jiné ne. Bude zajímavé sledovat, zda projekt dokáže Otevřete telemetrii poskytnout určitou konvergenci.

V tomto případě je výhodou technologie service mesh to, že kontejnery postranních vozíků mohou v zásadě sbírat všechna výše uvedená data ze svých služeb. Jinými slovy, máte k dispozici jediný telemetrický sběrný systém a servisní síť může všechny tyto informace zpracovávat různými způsoby. Například:

tail logs z určité služby v CLI;
sledovat objem požadavků z řídicího panelu služby;
shromažďovat distribuované stopy a předávat je systému jako Jaeger.

Pozor, subjektivní soud: Obecně řečeno, telemetrie je oblast, ve které je nežádoucí silné rušení ze sítě služeb. Shromažďování základních informací a průběžné sledování některých zlatých metrik, jako je úspěšnost požadavků a latence, je v pořádku, ale doufejme, že se neobjeví Frankensteinovy zásobníky, které by se pokusily nahradit specializované systémy, z nichž některé se již osvědčily a dobře prostudovaly. .

15. Audit

TL;DR: Ti, kteří zapomínají na lekce historie, jsou odsouzeni je opakovat.

Auditování je umění pozorovat důležité události v systému. V případě sítě služeb by to mohlo znamenat sledování toho, kdo odeslal požadavky na konkrétní koncové body pro konkrétní služby, nebo kolikrát došlo za poslední měsíc k nějaké události související se zabezpečením.

Je jasné, že auditování velmi úzce souvisí s telemetrií. Rozdíl je v tom, že telemetrie je obvykle spojena s věcmi, jako je produktivita a technická integrita, zatímco audit se může týkat právních a jiných záležitostí, které přesahují čistě technickou sféru (například soulad s GDPR - Obecné nařízení EU o ochraně dat).

16. Vizualizace

TL;DR: Ať žije React.js – nevyčerpatelný zdroj efektních rozhraní.

Možná existuje lepší termín, ale já ho neznám. Jednoduše mám na mysli grafické znázornění sítě služeb nebo některé její součásti. Tyto vizualizace mohou zahrnovat indikátory, jako jsou průměrné latence, informace o konfiguraci postranního vozíku, výsledky kontroly stavu a výstrahy.

Práce v prostředí orientovaném na služby zahrnuje mnohem vyšší kognitivní zátěž ve srovnání s Jeho Veličenstvom Monolitem. Kognitivní tlak by proto měl být za každou cenu snížen. Jednoduché grafické rozhraní pro servisní síť s možností kliknout na tlačítko a získat požadovaný výsledek by mohlo být rozhodující pro růst popularity této technologie.

Nebyly zařazeny do seznamu

Původně jsem měl v úmyslu zahrnout do seznamu několik dalších případů použití, ale pak jsem se rozhodl ne. Zde jsou spolu s důvody mého rozhodnutí:

Multi-datové centrum. Podle mého názoru nejde ani tak o případ použití, jako o úzkou a specifickou oblast použití servisních sítí nebo nějakou sadu funkcí, jako je zjišťování služeb.
Vstup a výstup. Jedná se o související oblast, ale omezil jsem se (možná uměle) na případ použití „dopravy z východu na západ“. Ingress a egress si zaslouží samostatný článek.

Závěr

To je prozatím vše! Tento seznam je opět velmi svévolný a s největší pravděpodobností neúplný. Pokud si myslíte, že jsem něco přehlédl nebo mám něco špatně, kontaktujte mě prosím na Twitteru (@luckerkins). Prosím respektujte pravidla slušného chování.

PS od překladatele

Titulní ilustrace k článku je založena na obrázku z článku “Co je Service Mesh (a kdy ji použít)?“ (Gregory MacKinnon). Ukazuje, jak se některé funkce z aplikací (zeleně) přesunuly do servisní sítě, která mezi nimi zajišťuje propojení (modře).

Přečtěte si také na našem blogu:

Zdroj: www.habr.com