Odolná komunikace

Návod

Tento obsah je výňatek z elektronické knihy Architektura cloud-native .NET aplikací pro Azure, která je k dispozici na .NET Docs nebo jako bezplatné PDF ke stažení, které si můžete přečíst offline.

Stáhnout PDF

miniatura obálky e-knihy Cloud-nativní aplikace .NET pro Azure.

V této knize jsme přijali architektonický přístup 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 si mikroslužby vyměňují informace a komunikují mezi sebou při běhu na soustavě počítačů s vlastními IP adresami a porty?

  • 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?

  • Bezpečnost. 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. Odděluje tyto záležitosti tak, že je přesouvá do proxy služby. Proxy server se nasadí do samostatného procesu (označovaného jako sidecar), který poskytuje izolaci od obchodního kódu. Sidecar kontejner je ale propojen se službou – je vytvořen spolu s ní a sdílí její životní cyklus. Obrázek 6–7 ukazuje tento scénář.

Servisní síť s bočním autem

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.

Řízení sítě služeb a rovina dat

Obrázek 6–8 Řízení síťového provozu a datová rovina

Po nakonfigurování je síť služeb vysoce funkční. Může načíst odpovídající skupinu instancí z bodu pro objevování služeb. 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íťový modul vyřadí instanci z fondu vyrovnávání zatížení a poté, co se zotaví, ji znovu zařadí. Pokud vyprší časový limit požadavku, může síť selhat a potom požadavek zopakovat. Síť zachycuje a emituje 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, logy a trasování pro veškerý provoz v rámci clusteru, včetně příchozího a odchozího provozu.

Klíčovou komponentou implementace Istio je proxy služba s názvem Envoy proxy. 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.
  • HTTP a gRPC proxy.
  • Odolnost elektrického jističe.
  • Kontroly stavu.
  • Postupné aktualizace s kanárským nasazením

Jak jsme už dříve probírali, Envoy se nasadí jako sidecar ke každé mikroslužbě 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:

Odkazy

předchozíDalší

  • Last updated on