Odolná komunikace
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 knize jsme přijali přístup založený na architektuře založený na mikroslužbách. I když taková architektura přináší důležité výhody, představuje mnoho výzev:
Síťová komunikace mimo proces. Každá mikroslužba komunikuje přes síťový protokol, který zavádí zahlcení sítě, latenci a přechodné chyby.
Zjišťování služeb. Jak mikroslužby při spouštění v clusteru počítačů s vlastními IP adresami a porty vzájemně komunikují?
Odolnost. Jak spravujete krátkodobé selhání a udržujete systém stabilní?
Vyrovnávání zatížení. Jak se příchozí provoz distribuuje napříč několika instancemi mikroslužby?
Zabezpečení. Jak se vynucují obavy zabezpečení, jako je šifrování na úrovni přenosu a správa certifikátů?
Distribuované monitorování – Jak korelujete a zaznamenáváte sledovatelnost a monitorování jednoho požadavku napříč několika spotřebovými mikroslužbami?
Tyto obavy můžete řešit v různých knihovnách a architekturách, ale implementace může být náročná, složitá a časově náročná. Nakonec také máte obavy o infrastrukturu spojenou s obchodní logikou.
Síť služeb
Lepším přístupem je vyvíjející se technologie s názvem Service Mesh. Síť služeb je konfigurovatelná vrstva infrastruktury s integrovanými možnostmi pro zpracování komunikace se službami a dalšími výše uvedenými výzvami. Tyto obavy odděluje jejich přesunutím do proxy služby. Proxy server se nasadí do samostatného procesu (označovaného jako sajdkárna), který poskytuje izolaci od obchodního kódu. Sajdkárna je ale propojená se službou – vytvoří se s ní a sdílí její životní cyklus. Obrázek 6–7 ukazuje tento scénář.
Obrázek 6–7 Servisní síť s bočním autem
Na předchozím obrázku si všimněte, jak proxy server zachytí a spravuje komunikaci mezi mikroslužbami a clusterem.
Síť služeb je logicky rozdělená do dvou různorodých komponent: rovina dat a řídicí rovina. Obrázek 6–8 znázorňuje tyto komponenty a jejich odpovědnosti.
Obrázek 6–8 Řízení sítě služeb a rovina dat
Po nakonfigurování je síť služeb vysoce funkční. Může načíst odpovídající fond instancí z koncového bodu zjišťování služby. Síť pak může odeslat požadavek na konkrétní instanci, zaznamenat latenci a typ odpovědi výsledku. Síť může zvolit instanci s největší pravděpodobností, že vrátí rychlou odpověď na základě mnoha faktorů, včetně zjištěné latence pro poslední požadavky.
Pokud instance nereaguje nebo selže, bude síť opakovat požadavek na jinou instanci. Pokud vrátí chyby, síť vyřadí instanci z fondu vyrovnávání zatížení a po jeho opravách ji znovu přestaví. Pokud vyprší časový limit požadavku, může síť selhat a potom požadavek zopakovat. Síť zachycuje a generuje metriky a distribuované trasování do centralizovaného systému metrik.
Istio a envoy
I když v současné době existuje několik možností sítě služeb, istio je v době psaní tohoto článku nejoblíbenější. Istio je společný podnik od IBM, Googlu a Lyftu. Jedná se o opensourcovou nabídku, kterou je možné integrovat do nové nebo existující distribuované aplikace. Technologie poskytuje konzistentní a kompletní řešení pro zabezpečení, připojení a monitorování mikroslužeb. Mezi její funkce patří:
- Zabezpečená komunikace mezi službami v clusteru se silným ověřováním a autorizací na základě identit
- Automatické vyrovnávání zatížení pro provoz HTTP, gRPC, WebSocket a TCP.
- Jemně odstupňované řízení chování provozu pomocí bohatých pravidel směrování, opakování, převzetí služeb při selhání a injektáže chyb.
- Připojitelná vrstva zásad a konfigurační rozhraní API podporující řízení přístupu, omezení rychlosti a kvóty
- Automatické metriky, protokoly a trasování pro veškerý provoz v clusteru, včetně příchozího a výchozího přenosu clusteru.
Klíčovou komponentou implementace Istio je proxy služba s názvem proxy proxy server. Běží společně s každou službou a poskytuje základ nezávislý na platformě pro následující funkce:
- Dynamické zjišťování služeb.
- Vyrovnávání zatížení.
- Ukončení protokolu TLS.
- Proxy servery HTTP a gRPC.
- Odolnost jističe.
- Kontroly stavu.
- Kumulativní aktualizace s využitím kanárských nasazení
Jak jsme už dříve probírali, envoy se nasadí jako sajdkárna do každé mikroslužby v clusteru.
Integrace se službou Azure Kubernetes Services
Cloud Azure využívá Istio a poskytuje pro něj přímou podporu v rámci azure Kubernetes Services. Následující odkazy vám můžou pomoct začít:
