Service Mesh — známý architektonický vzor pro integraci mikroservisů a přechod na cloudovou infrastrukturu. Dnes je ve světě cloudových kontejnerů obtížné se bez něj obejít. Na trhu je již k dispozici několik open-source realizací service mesh, ale jejich funkčnost, spolehlivost a bezpečnost často nestačí, zejména pokud jde o požadavky velkých finančních společností na národní úrovni. Proto jsme v Sbertechu se rozhodli přizpůsobit Service Mesh a chceme říct, co je na Service Mesh skvělé, co ne a co s tím hodláme udělat.
Popularita vzoru Service Mesh roste s oblibou cloudových technologií. Představuje dedikovanou infrastrukturní vrstvu, 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. V podstatě se jedná o síťový model z mnoha proxy, které jsou řízeny centrálně a vykonávají soubor velmi užitečných funkcí.
Na úrovni proxy (data plane):
- Přiřazení a šíření politik směrování a vyvažování provozu
- Distribuce klíčů, certifikátů, tokenů
- Sběr telemetrie, formování metrik monitorování
- Integrace s infrastrukturou bezpečnosti a monitorování
Na úrovni řídicí smyčky (control plane):
- Aplikace politik směrování a vyvažování provozu
- Správa opakování a časových limitů, určení "mrtvých" uzlů (circuit breaking), správa havarijních situací (injecting faults) a zajištění odolnosti (resilience) služeb prostřednictvím dalších mechanismů
- Autentizace/ autorizace volání
- Odbavení metrik (observability)
Okruh uživatelů, kteří mají zájem o rozvoj této technologie, je velmi široký — od malých startupů po velké internetové korporace, jako je například PayPal.
K čemu je Service Mesh v podnikatelském sektoru
Používání Service Mesh přináší řadu zřejmých výhod. Především je to jednodušší pro vývojáře: pro psaní kódu se objevuje technologická platforma, která výrazně usnadňuje integraci do cloudové infrastruktury tím, že je transportní vrstva plně izolována od aplikační logiky.
Kromě toho, Service Mesh usnadňuje vztahy mezi poskytovateli a uživateli. Dnes je pro poskytovatele a uživatele API mnohem snazší vyjednat rozhraní a smlouvy samostatně, aniž by byl zapotřebí specializovaný integrační zprostředkovatel či rozhodčí – podniková servisní šina. Tento přístup má zásadní vliv na dvě metriky. Zvýšuje se rychlost uvádění nové funkčnosti na trh (time-to-market), avšak zároveň se zvyšují náklady na řešení, neboť integraci je nutno provádět samostatně. Použití Service Mesh týmy vyvíjejícími podnikové funkce umožňuje udržet rovnováhu. Výsledkem je, že poskytovatelé API se mohou soustředit pouze 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 ani řádek dalšího kódu.
Další výhodou je, že vývojář, používající Service Mesh, se soustředí výhradně na podnikové funkce – na produktovou, nikoli na technologickou složku své služby. Například již není třeba přemýšlet o tom, že v situaci, kdy bude služba vyvolána přes síť, může někde dojít k přerušení spojení. Kromě toho Service Mesh pomáhá vyvážit provoz mezi kopiemi jedné a té samé služby: pokud jedna z kopií "zhynula", systém přepne veškerý provoz na zbývající živé kopie.
Service Mesh — to je dobrý základ pro vytváření distribuovaných aplikací, která skrývá před uživateli detaily zajištění volání jejich služeb jak z vnitřní, tak z vnější strany. Všechny aplikace, které používají Service Mesh, jsou na transportní úrovni izolovány jak od sítě, tak i mezi sebou navzájem: neexistuje mezi nimi žádné spojení. Nicméně vývojář získává plnou kontrolu nad svými službami.
Nelze opomenout, že aktualizace distribuovaných aplikací v prostředí, kde se používá Service Mesh, se stává snazší. Například blue/green nasazení, kde jsou k dispozici dvě prostředí aplikace, z nichž jedno není aktualizováno a čeká. V případě neúspěšného vydání je zpětný přechod na předchozí verzi proveden speciálním routerem, s jehož rolí si skvěle poradí Service Mesh.. Pro testování nové verze lze použít i kanárkovou verzi – přepnout na novou verzi pouze 10 % provozu nebo požadavky od pilotní skupiny zákazníků. Hlavní provoz jde na starou verzi, nic se nezhroutí.
Také Service Mesh nám poskytuje kontrolu SLA v reálném čase.Systém distribuovaných proxy neumožní zkolabovat službě, když někdo ze zákazníků překročí jemu přidělenou kvótu. Pokud je šířka pásma API omezena, nikdo jej nebude moci obtěžovat velkým množstvím transakcí: Service Mesh stojí před službou a nepropustí nadbytečný provoz. Ten jednoduše odrazí v integračním layeru, zatímco samotné služby budou pokračovat v provozu, jako by si ničeho nevšimly.
Pokud chce společnost snížit náklady na vývoj integračních řešení, Service Mesh rovněž pomáhá: na jeho open-source verzi lze přejít z komerčních produktů.Náš Enterprise Service Mesh je založen na open-source verzi Service Mesh.
Další výhodou je existence jednotné komplexní sady integračních služeb.Vzhledem k tomu, že celá integrace probíhá prostřednictvím této prostřední vrstvy, můžeme řídit celý integrační provoz a vztahy mezi aplikacemi, které tvoří obchodní jádro společnosti. To je velmi pohodlné.
A nakonec Service Mesh povzbuzuje společnost k přechodu na dynamickou infrastrukturu. V současnosti se mnoho lidí dívá na kontejnery. Rozdělení monolitu na mikroslužby a jejich elegantní zavádění - toto téma je v kurzu. Když se ale pokoušíte převést systém, který běží v produkci již řadu let, na nový model, narazíte na řadu problémů: VMístit to vše do kontejnerů a nasadit to na platformě není snadné. Implementace, synchronizace a interakce těchto distribuovaných komponentů je další velmi složité téma. Jak spolu budou komunikovat? Nebudou zde kaskádové selhání? Service Mesh umožňuje částečně vyřešit tyto problémy a usnadnit migraci ze staré architektury na novou díky tomu, že se můžete přestat zabývat logikou síťové výměny.
Proč je potřeba přizpůsobení Service Mesh
Naše společnost si poradí se stovkami systémů a modulů, přičemž runtime je velmi zatížený. Proto jednoduchý vzor, kdy jeden systém volá druhý a dostává odpověď, nestačí, protože v produkci chceme více. Co dalšího potřebujeme od podnikového Service Mesh?
Služba zpracování událostí
Představme si, že potřebujeme vytvořit systém pro zpracování událostí v reálném čase, který analyzuje akce klienta a může mu okamžitě nabídnout relevantní nabídku. Pro implementaci takové funkčnosti se používá architektonický vzor nazvaný event-driven architecture (EDA). Žádný z aktuálních Service Mesh tento vzor nativně nepodporuje, což je velmi důležité, zejména pro banku!
Je poměrně podivné, že „vzdálené volání“ Remote Procedure Call (RPC) podporují všechny verze Service Mesh, zatímco s EDA nemají dobré vztahy. Protože Service Mesh je podobné moderní distribuované integraci, zatímco EDA je velmi aktuální architektonický vzor, který umožňuje vytvářet jedinečné možnosti, pokud jde o zákaznickou zkušenost.
Naše Enterprise Service Mesh by mělo tento problém řešit. Kromě toho chceme, aby obsahovalo implementaci zaručené dodávky, streamového a komplexního zpracování událostí s využitím různých filtrů a šablon.
Služba přenosu souborů
Kromě EDA by bylo dobré mít možnost přenášet soubory: v rámci podniků je velmi často možná pouze souborová integrace. Konkrétně se používá architektonický vzor ETL (Extract, Transform, Load — „extrakce, transformace, načítání“). V něm obvykle všechny strany vyměňují výhradně soubory: používají se velká data, která není efektivní posílat jednotlivými dotazy. Možnost nativní podpory přenosu souborů v Enterprise Service Mesh poskytuje potřebnou flexibilitu pro podnikání.
Služba orchestrace
Ve velkých organizacích téměř vždy existují různé týmy, které vyvíjejí různé produkty. Například v bance některé týmy pracují s vklady, zatímco jiné se zabývají úvěrovými produkty, a takových případů je dost. Jsou to různí lidé, různé týmy, které vytvářejí své produkty, vyvíjejí své API a poskytují je ostatním. A velmi často vzniká potřeba složitosti těchto služeb, stejně jako implementace složité logiky sekvenčního volání sady API. Pro řešení tohoto problému je zapotřebí řešení na integračním vrstvě, které usnadní celou tuto kompoziční logiku (volání několika API, popis trasy dotazů atd.). To je služba orchestrace v Enterprise Service Mesh.
AI a ML
Když mikroservisy komunikují přes jednotnou integrační vrstvu, Service Mesh samozřejmě ví vše o voláních každé služby. Shromažďujeme telemetrii: kdo koho volal, kdy, jak dlouho, kolikrát a tak dále. Když je těchto služeb stovky tisíc a volání miliardy, všechno se to shromažďuje a tvoří Big Data. Tyto údaje lze analyzovat pomocí AI, strojového učení atd., a poté na základě výsledků analýzy vytvořit nějaké užitečné věci. Bylo by vhodné alespoň částečně přenést umělé inteligenci řízení celého tohoto síťového provozu a volání aplikací integrovaných do Service Mesh.
Služba API Gateway (API brána)
Obecně v Service Mesh existují proxy a služby, které si vzájemně volají uvnitř důvěrného prostoru. Existují však i externí partneři. Požadavky na API poskytované této skupině zákazníků jsou mnohem přísnější. Tuto úlohu dělíme na dvě hlavní části.
- Bezpečnost. Otázky související s ddos, zranitelností protokolů, aplikací, operačních systémů atd.
- Měřítka. Když počet API, které je třeba poskytnout klientům, dosahuje tisíců nebo dokonce stovek tisíc, vzniká potřeba nástroje pro správu této sady API. Je třeba neustále sledovat API: zda fungují, jaký mají stav, jaký je na nich provoz, jaké jsou statistiky atd. API brána musí tuto úlohu splnit, aby byl celý proces řízený a bezpečný. Díky této komponentě se Enterprise Service Mesh učí bez zbytečných složitostí publikovat jak interní API, tak externí.
Služba podpory specifických protokolů a datových formátů (brána AS)
V současnosti většina řešení Service Mesh nativně pracuje pouze s provozem HTTP a HTTP2 nebo v omezeném režimu na úrovni TCP/IP. Enterprise Service Mesh má k dispozici řadu dalších velmi specifických protokolů pro přenos dat. Některé systémy mohou používat zprostředkovatele zpráv, jiné jsou integrovány na úrovni databází. Pokud má společnost SAP, může také použít vlastní integrační systém. A to vše funguje a je důležitou součástí podnikání.
Nelze jednoduše říct: „Pojďme se vzdát legacy a vytvořit nové systémy, které budou schopny používat Service Mesh“. Aby se všechny staré systémy spřátelily s novými (na mikroservisní architektuře), systémy, které mohou používat Service Mesh, potřebují nějaký adaptér, prostředníka, bránu. Přiznejte, bylo by skvělé, kdyby byl dodáván společně se službou. Brána AS právě může podpořit jakoukoli možnost integrace. Jen si představte, že prostě nainstalujete Enterprise Service Mesh a je již připravena komunikovat se všemi protokoly, které potřebujete. Tento přístup je pro nás velmi důležitý.
Takto si představujeme podnikové řešení Service Mesh (Enterprise Service Mesh). Popsaná customizace řeší většinu problémů, které se objevují při pokusech o použití hotových open-source verzí integrační platformy. Architektura Service Mesh, která se objevila před pouhými dvěma lety, pokračuje ve vývoji 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: habr.com
