Wzorce komunikacji rozwiązań natywnych dla chmury
Napiwek
Ta zawartość jest fragmentem książki eBook, Architekting Cloud Native .NET Applications for Azure, dostępnej na platformie .NET Docs lub jako bezpłatny plik PDF do pobrania, który można odczytać w trybie offline.
Podczas konstruowania systemu natywnego dla chmury komunikacja staje się znaczącą decyzją projektową. Jak aplikacja kliencka frontonu komunikuje się z mikrousługą zaplecza? Jak mikrousługi zaplecza komunikują się ze sobą? Jakie są zasady, wzorce i najlepsze rozwiązania, które należy wziąć pod uwagę podczas implementowania komunikacji w aplikacjach natywnych dla chmury?
Zagadnienia dotyczące komunikacji
W aplikacji monolitycznej komunikacja jest prosta. Moduły kodu są wykonywane razem w tej samej przestrzeni wykonywalnej (procesu) na serwerze. Takie podejście może mieć zalety wydajności, ponieważ wszystkie elementy są uruchamiane razem w pamięci udostępnionej, ale skutkuje ściśle powiązanym kodem, który staje się trudny do utrzymania, rozwoju i skalowania.
Systemy natywne dla chmury implementują architekturę opartą na mikrousługach z wieloma małymi, niezależnymi mikrousługami. Każda mikrousługa jest wykonywana w osobnym procesie i zwykle działa wewnątrz kontenera wdrożonego w klastrze.
Klaster grupuje pulę maszyn wirtualnych w celu utworzenia środowiska o wysokiej dostępności. Są one zarządzane za pomocą narzędzia orkiestracji, które jest odpowiedzialne za wdrażanie konteneryzowanych mikrousług i zarządzanie nimi. Rysunek 4–1 przedstawia klaster Kubernetes wdrożony w chmurze platformy Azure z w pełni zarządzanymi usługami Azure Kubernetes Services.
Rysunek 4–1. Klaster Kubernetes na platformie Azure
W całym klastrze mikrousługi komunikują się ze sobą za pośrednictwem interfejsów API i technologii obsługi komunikatów.
Chociaż zapewniają one wiele korzyści, mikrousługi nie są bezpłatnym obiadem. Lokalne wywołania metody w procesie między składnikami są teraz zastępowane wywołaniami sieciowymi. Każda mikrousługa musi komunikować się za pośrednictwem protokołu sieciowego, co zwiększa złożoność systemu:
- Przeciążenie sieci, opóźnienie i błędy przejściowe są stałym problemem.
- Odporność (czyli ponawianie żądań, które zakończyły się niepowodzeniem) jest niezbędne.
- Niektóre wywołania muszą być idempotentne, aby zachować spójny stan.
- Każda mikrousługa musi uwierzytelniać i autoryzować wywołania.
- Każdy komunikat musi być serializowany, a następnie deserializowany — co może być kosztowne.
- Szyfrowanie/odszyfrowywanie komunikatów staje się ważne.
Książka .NET Microservices: Architecture for Containerized .NET Applications(Architektura konteneryzowanych aplikacji .NET) dostępna bezpłatnie od firmy Microsoft zapewnia szczegółowy zakres wzorców komunikacji dla aplikacji mikrousług. W tym rozdziale przedstawiono ogólne omówienie tych wzorców wraz z opcjami implementacji dostępnymi w chmurze platformy Azure.
W tym rozdziale najpierw zajmiemy się komunikacją między aplikacjami frontonu i mikrousługami zaplecza. Następnie przyjrzymy się mikrousługom zaplecza, które komunikują się ze sobą. Zapoznamy się z technologią komunikacji gRPC. Na koniec przyjrzymy się nowym innowacyjnym wzorom komunikacji przy użyciu technologii siatki usług. Zobaczymy również, jak chmura platformy Azure udostępnia różne rodzaje usług pomocniczych do obsługi komunikacji natywnej dla chmury.
