Komunikační infrastruktura Service Mesh
Tip
Tento obsah je výňatek z eBooku, Architekting Cloud Native .NET Applications for Azure, který je k dispozici na webu Docs pro .NET nebo jako soubor PDF zdarma ke stažení, který si můžete přečíst offline.
V této kapitole jsme prozkoumali výzvy komunikace mikroslužeb. Řekli jsme, že vývojové týmy musí být citlivé na to, jak spolu back-endové služby komunikují. V ideálním případě je lepší komunikace mezi službami. Vyloučení ale není vždy možné, protože back-endové služby často vzájemně spoléhají na dokončení operací.
Prozkoumali jsme různé přístupy k implementaci synchronní komunikace HTTP a asynchronního zasílání zpráv. V každém z těchto případů je vývojář zatížen implementací komunikačního kódu. Komunikační kód je složitý a časově náročný. Nesprávná rozhodnutí můžou vést k významným problémům s výkonem.
Modernější přístup k komunikačním centrem mikroslužeb kolem nové a rychle se vyvíjející technologie s názvem Service Mesh. Síť služeb je konfigurovatelná vrstva infrastruktury s integrovanými funkcemi pro zpracování komunikace mezi službami, odolnosti a mnoha průřezových problémů. Přesouvá odpovědnost za tyto obavy z mikroslužeb a do vrstvy sítě služeb. Komunikace se od mikroslužeb abstrahuje.
Klíčovou součástí sítě služeb je proxy server. V aplikaci nativní pro cloud je instance proxy serveru obvykle společně s každou mikroslužbou společně. Při provádění v samostatných procesech jsou tyto dva úzce propojené a sdílejí stejný životní cyklus. Tento model se označuje jako model sajdkáře a je zobrazený na obrázku 4–24.
Obrázek 4–24 Servisní síť s bočním autem
Všimněte si na předchozím obrázku, jak jsou zprávy zachyceny proxy serverem, který běží společně s jednotlivými mikroslužbami. Každý proxy server je možné nakonfigurovat s pravidly provozu specifickými pro mikroslužbu. Rozumí zprávám a může je směrovat napříč vašimi službami a vnějším světem.
Spolu se správou komunikace mezi službami poskytuje služba Mesh podporu pro zjišťování služeb a vyrovnávání zatížení.
Po nakonfigurování je síť služeb vysoce funkční. Síť načte odpovídající fond instancí z koncového bodu zjišťování služby. Odešle požadavek na konkrétní instanci služby, zaznamenává latenci a typ odpovědi výsledku. Zvolí instanci, která bude pravděpodobně vracet rychlou odpověď na základě různých faktorů, včetně pozorované latence nedávných požadavků.
Síť služeb spravuje přenosy, komunikaci a sítě na úrovni aplikace. Rozumí zprávám a žádostem. Síť služeb se obvykle integruje s orchestrátorem kontejnerů. Kubernetes podporuje rozšiřitelnou architekturu, do které je možné přidat síť služeb.
V kapitole 6 se podrobně podíváme na technologie Service Mesh, včetně diskuze o její architektuře a dostupných opensourcových implementacích.
Shrnutí
V této kapitole jsme probrali způsoby komunikace nativní pro cloud. Začali jsme zkoumáním toho, jak front-endoví klienti komunikují s back-endovými mikroslužbami. Po celou dobu jsme mluvili o platformách služby API Gateway a komunikaci v reálném čase. Pak jsme se podívali na to, jak mikroslužby komunikují s dalšími back-endovými službami. Podívali jsme se na synchronní komunikaci HTTP i asynchronní zasílání zpráv napříč službami. Probrali jsme gRPC, chystanou technologii v nativním cloudu. Nakonec jsme představili novou a rychle se vyvíjející technologii s názvem Service Mesh, která může zjednodušit komunikaci mikroslužeb.
Zvláštní důraz byl kladen na spravované služby Azure, které můžou pomoct implementovat komunikaci v systémech nativních pro cloud:
- Azure Application Gateway
- Azure API Management
- Služba Azure SignalR
- Fronty Azure Storage
- Azure Service Bus
- Azure Event Grid
- Azure Event Hub
Dále přejdeme k distribuovaným datům v systémech nativních pro cloud a výhody a výzvy, které představují.
