Komunikace front-endového klienta

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.

Stáhnout PDF

V nativním cloudovém systému vyžadují front-endoví klienti (mobilní, webové a desktopové aplikace) komunikační kanál pro interakci s nezávislými back-endovými mikroslužbami.

Jaké jsou možnosti?

Aby bylo všechno jednoduché, mohl by front-endový klient přímo komunikovat s back-endovými mikroslužbami, jak je znázorněno na obrázku 4-2.

Obrázek 4–2 Směrování komunikace klienta na službu

S tímto přístupem má každá mikroslužba veřejný koncový bod, který je přístupný front-endovými klienty. V produkčním prostředí byste umístili nástroj pro vyrovnávání zatížení před mikroslužby a směrujte provoz úměrně.

I když je implementace jednoduchá, přímá komunikace klientů by byla přijatelná pouze pro jednoduché aplikace mikroslužeb. Tento model úzce páruje front-endové klienty se základními back-endovými službami a otevírá dveře pro mnoho problémů, mezi které patří:

• Citlivost klienta na refaktoring back-endové služby
• Širší prostor pro útoky, protože základní back-endové služby jsou přímo vystaveny.
• Duplikace průřezových obav napříč jednotlivými mikroslužbami
• Příliš složitý kód klienta – klienti musí sledovat více koncových bodů a zpracovávat chyby odolným způsobem.

Místo toho je široce uznávaným vzorem návrhu cloudu implementovat službu brány rozhraní API mezi front-endovými aplikacemi a back-endovými službami. Vzor je znázorněn na obrázku 4–3.

Obrázek 4–3 Model brány rozhraní API

Na předchozím obrázku si všimněte, jak služba API Gateway abstrahuje back-endové základní mikroslužby. Implementované jako webové rozhraní API funguje jako reverzní proxy server a směruje příchozí provoz do interních mikroslužeb.

Brána izoluje klienta od interního dělení služeb a refaktoringu. Pokud změníte back-endovou službu, přizpůsobíte ji v bráně bez narušení klienta. Je to také vaše první obranná linie pro průřezové aspekty, jako je identita, ukládání do mezipaměti, odolnost, měření a omezování. Mnohé z těchto průřezových obav je možné načíst z back-endových základních služeb do brány, což zjednodušuje back-endové služby.

Je potřeba dbát na to, aby služba API Gateway byla jednoduchá a rychlá. Obchodní logika se obvykle uchovává mimo bránu. Složitá brána se stává kritickým bodem a nakonec se stane monolitem. Větší systémy často zpřístupňují více bran rozhraní API segmentovaných podle typu klienta (mobilní, webové, desktopové) nebo back-endové funkce. Model Back-endu pro front-endy poskytuje směr pro implementaci více bran. Vzor je znázorněn na obrázku 4–4.

Obrázek 4–4 Back-end pro vzor front-endu

Všimněte si na předchozím obrázku, jak se příchozí provoz odesílá do konkrétní brány rozhraní API – na základě typu klienta: webová, mobilní nebo desktopová aplikace. Tento přístup dává smysl, protože možnosti jednotlivých zařízení se výrazně liší v rámci faktoru, výkonu a omezení zobrazení. Mobilní aplikace obvykle zpřístupňují méně funkcí než prohlížeč nebo desktopové aplikace. Každou bránu je možné optimalizovat tak, aby odpovídala možnostem a funkcím odpovídajícího zařízení.

Jednoduché brány

Začněte tím, že vytvoříte vlastní službu brány rozhraní API. Rychlé hledání GitHubu bude poskytovat mnoho příkladů.

V případě jednoduchých aplikací nativních pro cloud .NET můžete zvážit bránu Ocelot Gateway. Open source a vytvořený pro mikroslužby .NET je jednoduchý, rychlý a škálovatelný. Stejně jako každá brána rozhraní API má primární funkce předávat příchozí požadavky HTTP podřízeným službám. Kromě toho podporuje širokou škálu funkcí, které lze konfigurovat v kanálu middlewaru .NET.

YARP (ještě další reverzní proxy server) je dalším open source reverzním proxy serverem, který vede skupina produktových týmů Microsoftu. Ke stažení jako balíček NuGet se YARP připojí k rozhraní ASP.NET jako middleware a je vysoce přizpůsobitelný. YarP je dobře zdokumentovaný s různými příklady použití.

V případě podnikových aplikací nativních pro cloud existuje několik spravovaných služeb Azure, které vám můžou pomoct začít s vaším úsilím.

Azure Application Gateway

U jednoduchých požadavků na bránu můžete zvážit Aplikace Azure Gateway. K dispozici jako služba Azure PaaS zahrnuje základní funkce brány, jako je směrování adres URL, ukončení protokolu SSL a firewall webových aplikací. Služba podporuje možnosti vyrovnávání zatížení vrstvy 7. S vrstvou 7 můžete směrovat požadavky na základě skutečného obsahu zprávy HTTP, nejen síťových paketů TCP nízké úrovně.

V této knize budeme hostovat systémy nativní pro cloud v Kubernetes. Orchestrátor kontejnerů Kubernetes automatizuje nasazení, škálování a provozní aspekty kontejnerizovaných úloh. Aplikace Azure Bránu je možné nakonfigurovat jako bránu rozhraní API pro Cluster Azure Kubernetes Service

Kontroler příchozího přenosu dat služby Application Gateway umožňuje Aplikace Azure Gateway pracovat přímo se službou Azure Kubernetes Service. Obrázek 4.5 znázorňuje architekturu.

Obrázek 4–5 Kontroler příchozího přenosu dat služby Application Gateway

Kubernetes obsahuje integrovanou funkci, která podporuje vyrovnávání zatížení HTTP (úroveň 7), označovanou jako příchozí přenos dat. Příchozí přenos dat definuje sadu pravidel pro to, jak mohou být instance mikroslužeb uvnitř AKS vystaveny vnějšímu světu. Na předchozí imagi kontroler příchozího přenosu dat interpretuje pravidla příchozího přenosu dat nakonfigurovaná pro cluster a automaticky nakonfiguruje bránu Aplikace Azure. Na základě těchto pravidel služba Application Gateway směruje provoz do mikroslužeb spuštěných v AKS. Kontroler příchozího přenosu dat naslouchá změnám pravidel příchozího přenosu dat a provede příslušné změny v bráně Aplikace Azure.

Azure API Management

Pro středně rozsáhlé cloudové nativní systémy můžete zvážit Azure API Management. Jedná se o cloudovou službu, která nejen řeší potřeby služby API Gateway, ale poskytuje plnohodnotné prostředí pro vývojáře a správu. Služba API Management se zobrazuje na obrázku 4–6.

Obrázek 4–6 Azure API Management

Služba API Management zpřístupňuje server brány, který umožňuje řízený přístup k back-endovým službám na základě konfigurovatelných pravidel a zásad. Tyto služby můžou být v cloudu Azure, v místním datacentru nebo v jiných veřejných cloudech. Klíče rozhraní API a tokeny JWT určují, kdo může co dělat. Veškerý provoz se protokoluje pro analytické účely.

Pro vývojáře nabízí API Management portál pro vývojáře, který poskytuje přístup ke službám, dokumentaci a vzorovém kódu pro jejich vyvolání. Vývojáři můžou použít rozhraní Swagger/Open API ke kontrole koncových bodů služby a analýze jejich využití. Služba funguje na hlavních vývojových platformách: .NET, Java, Golang a další.

Portál vydavatele zveřejňuje řídicí panel pro správu, kde správci zveřejňují rozhraní API a spravují jejich chování. Přístup ke službě je možné udělit, monitorovat stav služby a shromažďovat telemetrická data služeb. Správa istrátory aplikují zásady na každý koncový bod, aby ovlivnily chování. Zásady jsou předem připravené příkazy, které se pro každé volání služby spouštějí postupně. Zásady se konfigurují pro příchozí volání, odchozí volání nebo vyvolání při chybě. Zásady se dají použít v různých oborech služby, pokud chcete povolit deterministické řazení při kombinování zásad. Produkt se dodává s velkým počtem předem připravených zásad.

Tady jsou příklady toho, jak můžou zásady ovlivnit chování vašich služeb nativních pro cloud:

• Omezte přístup ke službě.
• Vynucujte ověřování.
• V případě potřeby omezte volání z jednoho zdroje.
• Povolte ukládání do mezipaměti.
• Zablokujte volání z konkrétních IP adres.
• Řízení toku služby
• Převeďte požadavky z PROTOKOLU SOAP na REST nebo mezi různými datovými formáty, například z XML na JSON.

Azure API Management může vystavit back-endové služby hostované kdekoli – v cloudu nebo v datovém centru. U starších služeb, které můžete zveřejnit ve svých nativních cloudových systémech, podporuje rozhraní REST i SOAP API. Prostřednictvím služby API Management je možné zpřístupnit i jiné služby Azure. Spravované rozhraní API můžete umístit na backingovou službu Azure, jako je Azure Service Bus nebo Azure Logic Apps. Azure API Management nezahrnuje integrovanou podporu vyrovnávání zatížení a měla by se používat ve spojení se službou vyrovnávání zatížení.

Azure API Management je k dispozici ve čtyřech různých úrovních:

• Vývojář
• Basic
• Standard
• Premium

Úroveň Developer je určená pro neprodukční úlohy a vyhodnocení. Ostatní úrovně nabízejí postupně větší výkon, funkce a vyšší smlouvy o úrovni služeb (SLA). Úroveň Premium poskytuje podporu služby Azure Virtual Network a více oblastí. Všechny úrovně mají pevnou cenu za hodinu.

Cloud Azure také nabízí bezserverovou úroveň pro Azure API Management. Tato služba se označuje jako cenová úroveň spotřeby a je variantou služby API Management navrženou pro model bezserverové architektury. Na rozdíl od dříve zobrazených cenových úrovní předem přidělených poskytuje úroveň Consumption okamžité zřizování a ceny plateb za akci.

Umožňuje funkce služby API Gateway pro následující případy použití:

• Mikroslužby implementované pomocí bezserverových technologií, jako jsou Azure Functions a Azure Logic Apps.
• Backingové prostředky služeb Azure, jako jsou fronty a témata služby Service Bus, úložiště Azure a další.
• Mikroslužby, ve kterých dochází k občas velkým špičkám provozu, ale ve většině případů zůstává nízká.

Úroveň Consumption používá stejné základní komponenty služby API Management, ale využívá zcela odlišnou architekturu založenou na dynamicky přidělených prostředcích. Dokonale odpovídá modelu bezserverové architektury:

• Není potřeba spravovat žádnou infrastrukturu.
• Žádná nečinná kapacita.
• Vysoká dostupnost.
• Automatické škálování
• Náklady vycházejí ze skutečného využití.

Nová úroveň Consumption je skvělou volbou pro systémy nativní pro cloud, které zpřístupňují bezserverové prostředky jako rozhraní API.

Komunikace v reálném čase

Komunikace v reálném čase nebo nabízená oznámení je další možností pro front-endové aplikace, které komunikují s back-endovými systémy nativními pro cloud přes PROTOKOL HTTP. Aplikace, jako jsou finanční tickery, online vzdělávání, hry a aktualizace průběhu práce, vyžadují okamžité odpovědi v reálném čase z back-endu. Při normální komunikaci HTTP není možné, aby klient věděl, kdy jsou k dispozici nová data. Klient se musí průběžně dotazovat nebo posílat požadavky na server. Díky komunikaci v reálném čase může server kdykoli do klienta odesílat nová data.

Systémy v reálném čase jsou často charakterizovány vysokofrekvenčními toky dat a velkým počtem souběžných klientských připojení. Ruční implementace připojení v reálném čase se může rychle stát složitým, což vyžaduje nevýkonnou infrastrukturu, aby se zajistila škálovatelnost a spolehlivé zasílání zpráv připojeným klientům. Můžete zjistit, že spravujete instanci Azure Redis Cache a sadu nástrojů pro vyrovnávání zatížení nakonfigurovaných pomocí rychlých relací pro spřažení klientů.

Azure SignalR Service je plně spravovaná služba Azure, která zjednodušuje komunikaci v reálném čase pro vaše aplikace nativní pro cloud. Technické podrobnosti implementace, jako je zřizování kapacity, škálování a trvalá připojení, se abstrahují. Řeší se za vás s 99,9% smlouvou o úrovni služeb. Zaměřujete se na funkce aplikací, ne na instalatérské infrastruktury.

Po povolení může cloudová služba HTTP odesílat aktualizace obsahu přímo připojeným klientům, včetně prohlížeče, mobilních a desktopových aplikací. Klienti se aktualizují bez nutnosti dotazovat server. Azure SignalR abstrahuje přenosové technologie, které vytvářejí připojení v reálném čase, včetně webSocketů, událostí na straně serveru a dlouhých dotazování. Vývojáři se zaměřují na odesílání zpráv všem nebo konkrétním podmnožině připojených klientů.

Obrázek 4–7 ukazuje sadu klientů HTTP připojujících se k aplikaci nativní pro cloud s povolenou službou Azure SignalR.

Obrázek 4–7 Azure SignalR

Další výhodou služby Azure SignalR je implementace bezserverových cloudových nativních služeb. Možná se váš kód spouští na vyžádání pomocí triggerů Azure Functions. Tento scénář může být složitý, protože váš kód neudržuje dlouhá připojení k klientům. Služba Azure SignalR dokáže tuto situaci řešit díky tomu, že už za vás spravuje připojení.

Služba Azure SignalR se úzce integruje s dalšími službami Azure, jako jsou Azure SQL Database, Service Bus nebo Redis Cache, a otevírá mnoho možností pro vaše aplikace nativní pro cloud.

PředchozíDalší