Service Mesh je známý architektonický vzor pro integraci mikroslužeb a migraci do cloudové infrastruktury. Dnes, v cloud-kontejnerovém světě, se bez něj obejdete docela těžko. Na trhu je již k dispozici několik implementací open-source service mesh, ale jejich funkčnost, spolehlivost a bezpečnost zdaleka vždy nestačí, zejména pokud jde o požadavky velkých finančních společností po celé republice. Proto jsme se ve Sbertechu rozhodli přizpůsobit Service Mesh a chceme mluvit o tom, co je na Service Mesh skvělé, co není příliš dobré a co s tím uděláme.
Obliba vzoru Service Mesh roste s oblibou cloudových technologií. Je to vyhrazená vrstva infrastruktury, která zjednodušuje interakci mezi různými síťovými službami. Moderní cloudové aplikace se skládají ze stovek a dokonce tisíců takových služeb, z nichž každá může mít tisíce kopií.
Interakce mezi těmito službami a jejich správa je klíčovým úkolem Service Mesh. Ve skutečnosti se jedná o síťový model mnoha proxy, spravovaných centrálně a vykonávajících sadu velmi užitečných funkcí.
Na úrovni proxy (datová rovina):
- Přidělování a šíření zásad směrování a vyvažování provozu
- Distribuce klíčů, certifikátů, tokenů
- Sběr telemetrie, tvorba monitorovacích metrik
- Integrace s bezpečnostní a monitorovací infrastrukturou
Na úrovni řídicí roviny:
- Použití zásad směrování a vyvažování provozu
- Správa opakování a timeoutů, detekce „mrtvých“ uzlů (přerušení obvodu), řízení poruchových situací (injektování poruch) a zajištění stability (odolnosti) služeb prostřednictvím dalších mechanismů
- Ověření/autorizace volání
- Vypouštění metrik (pozorovatelnost)
Okruh uživatelů se zájmem o vývoj této technologie je velmi široký – od malých startupů až po velké internetové korporace, jako je PayPal.
Proč potřebujete Service Mesh ve firemním sektoru
Použití Service Mesh přináší mnoho zjevných výhod. Za prvé, je to pohodlné pro vývojáře: pro psaní kódu vznikající technologická platforma, což výrazně zjednodušuje integraci do cloudové infrastruktury díky tomu, že transportní vrstva je zcela izolovaná od aplikační logiky.
Kromě toho, Service Mesh zjednodušuje vztah mezi dodavateli a spotřebiteli. Dnes je pro poskytovatele a spotřebitele API mnohem snazší dohodnout se na rozhraních a smlouvách sami, aniž by k tomu potřebovali speciálního integračního prostředníka a rozhodce – podnikovou servisní sběrnici. Tento přístup výrazně ovlivňuje dva ukazatele. Zvyšuje se rychlost uvádění nové funkcionality na trh (time-to-market), ale zároveň se zvyšují náklady na řešení, protože integrace musí být provedena nezávisle. Používání Service Mesh týmy obchodních funkcí pomáhá udržet rovnováhu. V důsledku toho se poskytovatelé API mohou soustředit výhradně na aplikační složku své služby a jednoduše ji publikovat v Service Mesh - API bude okamžitě dostupné všem klientům a kvalita integrace bude připravena na produkci a nebude vyžadovat jedinou linku doplňkového kódu.
Další výhodou je, že vývojář využívající Service Mesh se zaměřuje výhradně na obchodní funkce - na produktu, nikoli na technologické složce jejich služby. Už si například nemusíte myslet, že v situaci, kdy bude služba volána po síti, může někde dojít k přerušení spojení. Služba Service Mesh navíc pomáhá vyvážit provoz mezi kopiemi stejné služby: pokud jedna z kopií „umřela“, systém přepne veškerý provoz na zbývající živé kopie.
Servisní síť - je to dobrý základ pro vytváření distribuovaných aplikací, která před klientem skrývá detaily poskytování volání na své služby zevnitř i zvenčí. Všechny aplikace využívající Service Mesh jsou izolované od sítě a od sebe navzájem na úrovni přenosu: neexistuje mezi nimi žádné spojení. To dává vývojářům plnou kontrolu nad jejich službami.
Je třeba poznamenat, že aktualizace distribuovaných aplikací v prostředí, kde se používá Service Mesh, se stává jednodušší. Například modrozelené nasazení, kde jsou k dispozici dvě aplikační prostředí pro instalaci, z nichž jedno není aktualizováno a je nečinné. Návrat k předchozí verzi v případě neúspěšného vydání provádí speciální router, jehož roli perfektně zvládá Service Mesh. Chcete-li otestovat novou verzi, můžete také použít vypuštění kanárků - přejít na novou verzi pouze 10 % provozu nebo požadavků od pilotní skupiny klientů. Hlavní provoz jde na starou verzi, nic se nerozbije.
Také Service Mesh nám poskytuje kontrolu SLA v reálném čase. Systém distribuovaných proxy nedovolí zahltit službu, když některý z klientů překročí kvótu, která mu byla přidělena. Pokud je šířka pásma na API omezená, nikdo ji nebude moci tlačit velkým počtem transakcí: Service Mesh stojí před službou a neumožňuje extra provoz. Jednoduše se bude bránit v integrační vrstvě a samotné služby budou dál fungovat, aniž by si toho všimli.
Pokud chce společnost snížit náklady na vývoj integračních řešení, Service Mesh také pomáhá: můžete přejít na jeho open-source verze z komerčních produktů. Naše Enterprise Service Mesh je založena na open-source verzi Service Mesh.
Další výhodou je dostupnost jediné plnohodnotné sady integračních služeb. Vzhledem k tomu, že veškerá integrace je postavena prostřednictvím této střední vrstvy, můžeme řídit veškerý integrační provoz a komunikaci mezi aplikacemi, které tvoří obchodní jádro společnosti. Je to velmi pohodlné.
A konečně Service Mesh podněcuje společnost k přechodu na dynamickou infrastrukturu. Nyní se mnozí pohlížejí na kontejnerizaci. Rozřezání monolitu na mikroslužby, to vše je krásné implementovat – téma je na vzestupu. Ale když se pokusíte postavit nový systém, který se vyrábí mnoho let, okamžitě narazíte na řadu problémů: není snadné to všechno natlačit do kontejnerů a nasadit na platformu. A implementace, synchronizace a interakce těchto distribuovaných komponent je dalším komplexním tématem. Jak spolu budou komunikovat? Dojde ke kaskádovým poruchám? Service Mesh vám umožňuje vyřešit některé z těchto problémů a usnadnit migraci ze staré architektury na novou, protože můžete zapomenout na logiku síťové výměny.
Proč je přizpůsobení služby Service Mesh nutné
V naší společnosti spolu koexistují stovky systémů a modulů a běh je velmi vytížený. Takže jednoduchý vzorec, kdy jeden systém volá druhý a dostává odpověď, nestačí, protože ve výrobě chceme víc. Co dalšího potřebujete od podnikové sítě služeb?
Služba vyřizování akcí
Představme si, že potřebujeme udělat zpracování událostí v reálném čase – systém, který v reálném čase analyzuje jednání klienta a dokáže mu okamžitě udělat relevantní nabídku. K implementaci této funkce použijte architektonický vzor nazývaný událostmi řízená architektura (EDA). Žádný ze současných Service Mesh nativně nepodporuje takové vzory, a to je velmi důležité, zejména pro banku!
Je poněkud zvláštní, že „vzdálené volání“ Remote Procedure Call (RPC) podporují všechny verze Service Mesh, ale s EDA nejsou přátelé. Protože Service Mesh je druh moderní distribuované integrace a EDA je velmi relevantní architektonický vzor, který vám umožňuje dělat jedinečné věci z hlediska zákaznické zkušenosti.
Náš Enterprise Service Mesh by měl tento problém vyřešit. Navíc v něm chceme vidět implementaci garantovaného doručení, streamování a komplexního zpracování událostí pomocí nejrůznějších filtrů a šablon.
Služba přenosu souborů
Kromě EDA by bylo hezké umět přenášet soubory: v Enterprise scales je velmi často možná pouze integrace souborů. Zejména se používá architektonický vzor ETL (Extract, Transform, Load). V něm si zpravidla všichni vyměňují výhradně soubory: používají se velká data, která není vhodné strkat samostatnými požadavky. Schopnost nativně podporovat přenos souborů v Enterprise Service Mesh vám dává flexibilitu, kterou vaše podnikání potřebuje.
Orchestrální služba
Velké organizace mají téměř vždy různé týmy, které vyrábějí různé produkty. Například v bance některé týmy pracují s vklady, jiné zase s úvěrovými produkty a takových případů je hodně. Jsou to různí lidé, různé týmy, které vyrábějí své produkty, vyvíjejí vlastní API a poskytují je ostatním. A velmi často je potřeba složení těchto služeb a také implementace komplexní logiky pro sekvenční volání sady API. K vyřešení tohoto problému je potřeba řešení v integrační vrstvě, které celou tuto složenou logiku zjednoduší (volání několika API, popis cesty požadavku atd.). Toto je služba orchestrace v Enterprise Service Mesh.
AI a ML
Když mikroslužby komunikují prostřednictvím jediné integrační vrstvy, Service Mesh přirozeně ví vše o volání každé služby. Shromažďujeme telemetrii: kdo komu volal, kdy, na jak dlouho, kolikrát atd. Když existují statisíce těchto služeb a miliardy hovorů, pak se to všechno hromadí a tvoří velká data. Tato data lze analyzovat pomocí AI, strojového učení atd. a na základě výsledků analýzy pak lze provést některé užitečné věci. Bylo by vhodné alespoň částečně přenést řízení veškerého tohoto síťového provozu a volání aplikací integrovaných do Service Mesh na umělou inteligenci.
Služba API Gateway (API Gateway)
Síť služeb má obvykle proxy a služby, které spolu komunikují v rámci důvěryhodného obvodu. Existují ale i externí partneři. Požadavky na API vystavená této skupině spotřebitelů jsou mnohem přísnější. Tento úkol rozdělíme na dvě hlavní části.
- zabezpečení. Problémy související s ddos, zranitelnostmi protokolů, aplikacemi, operačními systémy a tak dále.
- Měřítko. Když počet rozhraní API, která mají být poskytnuta zákazníkům, dosáhne tisíců nebo dokonce stovek tisíc, existuje potřeba nějakého nástroje pro správu této sady rozhraní API. Musíte neustále sledovat API: zda fungují nebo ne, v jakém stavu, jaký provoz přichází, jaké statistiky atd. API Gateway by měla být schopna zvládnout tento úkol, díky čemuž bude celý proces spravovatelný a bezpečný. Díky této komponentě se Enterprise Service Mesh naučí, jak snadno publikovat interní API i externí API.
Služba podpory pro konkrétní protokoly a datové formáty (brána AS)
V současné době může většina řešení Service Mesh nativně pracovat pouze s provozem HTTP a HTTP2 nebo ve zkráceném režimu na úrovni TCP / IP. Enterprise Service Mesh má mnoho dalších velmi specifických protokolů přenosu dat. Některé systémy mohou využívat zprostředkovatele zpráv, jiné jsou integrovány na úrovni databáze. Pokud má firma SAP, pak může využít i vlastní integrační systém. A to vše funguje a je důležitou součástí podnikání.
Nemůžete jen říct: "Opusťme dědictví a vytvořme nové systémy, které mohou využívat Service Mesh." Aby se spřátelily všechny staré systémy s novými (na mikroservisní architektuře), systémy, které mohou používat Service Mesh, budou potřebovat nějaký adaptér, prostředníka, bránu. Souhlasím, bylo by hezké, kdyby to přišlo v krabici se službou. AC brána může podporovat jakoukoli možnost integrace. Jen si to představte, stačí nainstalovat Enterprise Service Mesh a je již připraven k interakci se všemi protokoly, které potřebujete. Pro nás je tento přístup velmi důležitý.
Takto představujeme podnikovou verzi Service Mesh (Enterprise Service Mesh). Popsaná customizace řeší většinu problémů, které vznikají při pokusu o použití hotových open-source verzí integrační platformy. Architektura Service Mesh, která se objevila teprve před několika lety, se nadále vyvíjí a jsme rádi, že můžeme přispět k jejímu rozvoji. Doufáme, že naše zkušenosti budou pro vás užitečné.
Zdroj: www.habr.com