Komunikacja z klientem frontonu
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.
W systemie natywnym dla chmury klienci frontonu (aplikacje mobilne, internetowe i klasyczne) wymagają kanału komunikacyjnego do interakcji z niezależnymi mikrousługami zaplecza.
Jakie są opcje?
Aby zachować prostotę, klient frontonu może bezpośrednio komunikować się z mikrousługami zaplecza, pokazanymi na rysunku 4-2.
Rysunek 4–2. Bezpośredni klient do komunikacji między usługami
W przypadku tego podejścia każda mikrousługa ma publiczny punkt końcowy dostępny dla klientów frontonu. W środowisku produkcyjnym przed mikrousługami należy umieścić moduł równoważenia obciążenia proporcjonalnie do ruchu.
Chociaż prosta implementacja, bezpośrednia komunikacja klienta byłaby akceptowalna tylko w przypadku prostych aplikacji mikrousług. Ten wzorzec ściśle łączy klientów frontonu z podstawowymi usługami zaplecza, otwierając drzwi dla wielu problemów, w tym:
- Podatność klienta na refaktoryzację usługi zaplecza.
- Szersza powierzchnia ataków jako podstawowe usługi zaplecza są bezpośrednio widoczne.
- Duplikowanie zagadnień krzyżowych w każdej mikrousłudze.
- Zbyt złożony kod klienta — klienci muszą śledzić wiele punktów końcowych i obsługiwać błędy w odporny sposób.
Zamiast tego powszechnie akceptowany wzorzec projektowania chmury polega na zaimplementowaniu usługi bramy interfejsu API między aplikacjami frontonu i usługami zaplecza. Wzorzec pokazano na rysunku 4–3.
Rysunek 4–3. Wzorzec bramy interfejsu API
Na poprzedniej ilustracji zwróć uwagę, jak usługa API Gateway abstrakcji mikrousług podstawowych zaplecza. Zaimplementowany jako internetowy interfejs API działa jako zwrotny serwer proxy, który kieruje ruch przychodzący do wewnętrznych mikrousług.
Brama izoluje klienta od partycjonowania i refaktoryzacji usługi wewnętrznej. Jeśli zmienisz usługę zaplecza, uwzględnisz ją w bramie bez przerywania działania klienta. Jest to również pierwsza linia obrony dla kwestii krzyżowych, takich jak tożsamość, buforowanie, odporność, pomiary i ograniczanie przepustowości. Wiele z tych zagadnień krzyżowych można odciążyć z usług podstawowych zaplecza do bramy, upraszczając usługi zaplecza.
Należy zachować prostotę i szybkość działania usługi API Gateway. Zazwyczaj logika biznesowa jest przechowywana poza bramą. Złożona brama może stać się wąskim gardłem i ostatecznie samym monolitem. Większe systemy często uwidaczniają wiele bram interfejsów API segmentowanych według typu klienta (mobilnych, internetowych, klasycznych) lub zaplecza. Wzorzec zaplecza dla frontonów zapewnia kierunek implementowania wielu bram. Wzorzec pokazano na rysunku 4–4.
Rysunek 4–4. Zaplecze dla wzorca frontonu
Zwróć uwagę na sposób wysyłania ruchu przychodzącego do określonej bramy interfejsu API na podstawie typu klienta: internetowego, mobilnego lub klasycznego. Takie podejście ma sens, ponieważ możliwości poszczególnych urządzeń różnią się znacząco w zależności od współczynnika formularzy, wydajności i ograniczeń wyświetlania. Zazwyczaj aplikacje mobilne udostępniają mniej funkcji niż przeglądarka lub aplikacje klasyczne. Każda brama może być zoptymalizowana pod kątem zgodności z możliwościami i funkcjami odpowiedniego urządzenia.
Proste bramy
Aby rozpocząć, możesz utworzyć własną usługę api Gateway. Szybkie wyszukiwanie w usłudze GitHub zawiera wiele przykładów.
W przypadku prostych aplikacji natywnych dla chmury platformy .NET można rozważyć bramę Ocelot Gateway. Oprogramowanie open source i utworzone dla mikrousług platformy .NET jest lekkie, szybkie i skalowalne. Podobnie jak każda usługa API Gateway, jej podstawową funkcją jest przekazywanie przychodzących żądań HTTP do usług podrzędnych. Ponadto obsługuje szeroką gamę możliwości konfigurowalnych w potoku oprogramowania pośredniczącego platformy .NET.
YARP (jeszcze inny zwrotny serwer proxy) to kolejny zwrotny serwer proxy typu open source kierowany przez grupę zespołów produktów firmy Microsoft. Można pobrać jako pakiet NuGet, yaRP podłącza się do platformy ASP.NET jako oprogramowania pośredniczącego i jest wysoce dostosowywalny. Opisano dobrze dokumentację yaRP z różnymi przykładami użycia.
W przypadku aplikacji natywnych dla chmury dla przedsiębiorstw istnieje kilka zarządzanych usług platformy Azure, które mogą ułatwić szybkie rozpoczęcie pracy.
Usługa Azure Application Gateway
W przypadku prostych wymagań dotyczących bramy można rozważyć aplikacja systemu Azure Gateway. Dostępna jako usługa PaaS platformy Azure zawiera podstawowe funkcje bramy, takie jak routing adresów URL, kończenie żądań SSL i zapora aplikacji internetowej. Usługa obsługuje funkcje równoważenia obciążenia warstwy 7. W warstwie 7 można kierować żądania na podstawie rzeczywistej zawartości komunikatu HTTP, a nie tylko pakietów sieciOWYCH TCP niskiego poziomu.
W tej książce ewangelizujemy hosting systemów natywnych dla chmury na platformie Kubernetes. Orkiestrator kontenerów, Platforma Kubernetes automatyzuje wdrażanie, skalowanie i problemy operacyjne związane z konteneryzowanymi obciążeniami. aplikacja systemu Azure Gateway można skonfigurować jako bramę interfejsu API dla Klaster usługi Azure Kubernetes Service.
Kontroler ruchu przychodzącego usługi Application Gateway umożliwia aplikacja systemu Azure Gateway bezpośrednią pracę z usługą Azure Kubernetes Service. Rysunek 4.5 przedstawia architekturę.
Rysunek 4–5. Kontroler ruchu przychodzącego usługi Application Gateway
Platforma Kubernetes zawiera wbudowaną funkcję, która obsługuje równoważenie obciążenia HTTP (poziom 7) o nazwie Ruch przychodzący. Ruch przychodzący definiuje zestaw reguł dotyczących sposobu uwidaczniania wystąpień mikrousług w usłudze AKS na zewnątrz. Na poprzedniej ilustracji kontroler ruchu przychodzącego interpretuje reguły ruchu przychodzącego skonfigurowane dla klastra i automatycznie konfiguruje bramę aplikacja systemu Azure Gateway. Na podstawie tych reguł usługa Application Gateway kieruje ruch do mikrousług działających w usłudze AKS. Kontroler ruchu przychodzącego nasłuchuje zmian reguł ruchu przychodzącego i wprowadza odpowiednie zmiany w usłudze aplikacja systemu Azure Gateway.
Usługa Azure API Management
W przypadku umiarkowanych i dużych systemów natywnych dla chmury można rozważyć usługę Azure API Management. Jest to usługa oparta na chmurze, która nie tylko rozwiązuje potrzeby bramy API Gateway, ale zapewnia w pełni funkcjonalne środowisko deweloperskie i administracyjne. Usługa API Management jest wyświetlana na rysunku 4–6.
Rysunek 4–6. Usługa Azure API Management
Aby rozpocząć, usługa API Management uwidacznia serwer bramy, który umożliwia kontrolowany dostęp do usług zaplecza na podstawie konfigurowalnych reguł i zasad. Te usługi mogą znajdować się w chmurze platformy Azure, w centrum danych lokalnych lub w innych chmurach publicznych. Klucze interfejsu API i tokeny JWT określają, kto może to zrobić. Cały ruch jest rejestrowany do celów analitycznych.
Dla deweloperów usługa API Management oferuje portal dla deweloperów, który zapewnia dostęp do usług, dokumentacji i przykładowego kodu służącego do wywoływania ich. Deweloperzy mogą używać programu Swagger/Open API do sprawdzania punktów końcowych usługi i analizowania ich użycia. Usługa działa na głównych platformach programistycznych: .NET, Java, Golang i nie tylko.
Portal wydawcy udostępnia pulpit nawigacyjny zarządzania, na którym administratorzy uwidaczniają interfejsy API i zarządzają swoim zachowaniem. Można udzielić dostępu do usługi, monitorować kondycję usługi i zbierać dane telemetryczne usługi. Administracja istratory stosują zasady do każdego punktu końcowego, aby wpływać na zachowanie. Zasady to wstępnie utworzone instrukcje, które są wykonywane sekwencyjnie dla każdego wywołania usługi. Zasady są konfigurowane pod kątem wywołania przychodzącego, wywołania wychodzącego lub wywołania po błędzie. Zasady można stosować w różnych zakresach usług, aby umożliwić określanie kolejności podczas łączenia zasad. Produkt jest dostarczany z dużą liczbą wstępnie utworzonych zasad.
Oto przykłady wpływu zasad na zachowanie usług natywnych dla chmury:
- Ograniczanie dostępu do usługi.
- Wymuszanie uwierzytelniania.
- W razie potrzeby ogranicz wywołania z jednego źródła.
- Włącz buforowanie.
- Blokuj wywołania z określonych adresów IP.
- Sterowanie przepływem usługi.
- Konwertowanie żądań z protokołu SOAP na interfejs REST lub między różnymi formatami danych, takimi jak xml do JSON.
Usługa Azure API Management może uwidaczniać usługi zaplecza hostowane w dowolnym miejscu — w chmurze lub centrum danych. W przypadku starszych usług, które można uwidocznić w systemach natywnych dla chmury, obsługuje zarówno interfejsy API REST, jak i SOAP. Nawet inne usługi platformy Azure można uwidocznić za pośrednictwem usługi API Management. Możesz umieścić zarządzany interfejs API na podstawie usługi tworzenia kopii zapasowych platformy Azure, takiej jak Azure Service Bus lub Azure Logic Apps. Usługa Azure API Management nie obejmuje wbudowanej obsługi równoważenia obciążenia i powinna być używana w połączeniu z usługą równoważenia obciążenia.
Usługa Azure API Management jest dostępna w czterech różnych warstwach:
- Deweloper
- Podstawowa
- Standardowa (Standard)
- Premium
Warstwa Deweloper jest przeznaczona dla obciążeń nieprodukcyjnych i oceny. Inne warstwy oferują stopniowo większą moc, funkcje i wyższe umowy dotyczące poziomu usług (SLA). Warstwa Premium zapewnia obsługę usługi Azure Virtual Network i wielu regionów. Wszystkie warstwy mają stałą cenę za godzinę.
Chmura platformy Azure oferuje również warstwę bezserwerową dla usługi Azure API Management. Nazywana warstwą cenową zużycie, usługa jest wariantem usługi API Management zaprojektowanym wokół modelu przetwarzania bezserwerowego. W przeciwieństwie do wcześniej przedstawionych warstw cenowych "wstępnie przydzielonych", warstwa zużycie zapewnia natychmiastową aprowizację i cennik płatności za akcję.
Umożliwia ona korzystanie z funkcji usługi API Gateway dla następujących przypadków użycia:
- Mikrousługi zaimplementowane przy użyciu technologii bezserwerowych, takich jak Azure Functions i Azure Logic Apps.
- Zasoby usługi tworzenia kopii zapasowej platformy Azure, takie jak kolejki i tematy usługi Service Bus, usługa Azure Storage i inne.
- Mikrousługi, w których ruch ma okazjonalne duże skoki, ale pozostaje najwięcej czasu.
Warstwa zużycia korzysta z tych samych podstawowych składników usługi API Management, ale korzysta z zupełnie innej architektury opartej na dynamicznie przydzielonych zasobach. Idealnie pasuje do modelu przetwarzania bezserwerowego:
- Brak infrastruktury do zarządzania.
- Brak bezczynności pojemności.
- Wysoka dostępność.
- Automatyczne skalowanie.
- Koszt jest oparty na rzeczywistym użyciu.
Nowa warstwa zużycia to doskonały wybór dla systemów natywnych dla chmury, które uwidaczniają zasoby bezserwerowe jako interfejsy API.
Komunikacja w czasie rzeczywistym
Komunikacja w czasie rzeczywistym lub wypychanie jest kolejną opcją dla aplikacji frontonu komunikujących się z systemami natywnymi dla chmury zaplecza za pośrednictwem protokołu HTTP. Aplikacje, takie jak znaczniki finansowe, edukacja online, gry i aktualizacje postępu pracy, wymagają natychmiastowej odpowiedzi w czasie rzeczywistym z zaplecza. W przypadku normalnej komunikacji HTTP nie ma możliwości, aby klient wiedział, kiedy są dostępne nowe dane. Klient musi stale sondować lub wysyłać żądania do serwera. Dzięki komunikacji w czasie rzeczywistym serwer może wypychać nowe dane do klienta w dowolnym momencie.
Systemy czasu rzeczywistego często charakteryzują się przepływami danych o wysokiej częstotliwości i dużą liczbą współbieżnych połączeń klientów. Ręczne implementowanie łączności w czasie rzeczywistym może szybko stać się złożone, co wymaga nietrygalnego infrastruktury w celu zapewnienia skalowalności i niezawodnej obsługi komunikatów dla połączonych klientów. Możesz samodzielnie zarządzać wystąpieniem usługi Azure Redis Cache i zestawem modułów równoważenia obciążenia skonfigurowanych z lepkimi sesjami koligacji klienta.
Azure SignalR Service to w pełni zarządzana usługa platformy Azure, która upraszcza komunikację w czasie rzeczywistym dla aplikacji natywnych dla chmury. Szczegóły implementacji technicznej, takie jak aprowizowanie pojemności, skalowanie i połączenia trwałe, są abstrakcje. Są one obsługiwane w przypadku umowy dotyczącej poziomu usług na poziomie 99,9%. Koncentrujesz się na funkcjach aplikacji, a nie na instalacji kanalizacyjnej infrastruktury.
Po włączeniu usługa HTTP oparta na chmurze może wypychać aktualizacje zawartości bezpośrednio do połączonych klientów, w tym aplikacji przeglądarkowych, mobilnych i klasycznych. Klienci są aktualizowani bez konieczności sondowania serwera. Usługa Azure SignalR tworzy abstrakcje technologii transportu, które tworzą łączność w czasie rzeczywistym, w tym protokoły WebSocket, zdarzenia po stronie serwera i długie sondowanie. Deweloperzy koncentrują się na wysyłaniu komunikatów do wszystkich lub określonych podzestawów połączonych klientów.
Rysunek 4–7 przedstawia zestaw klientów HTTP łączących się z aplikacją natywną dla chmury z włączoną usługą Azure SignalR.
Rysunek 4–7. Azure SignalR
Kolejną zaletą usługi Azure SignalR Service jest zaimplementowanie bezserwerowych usług natywnych dla chmury. Być może kod jest wykonywany na żądanie za pomocą wyzwalaczy usługi Azure Functions. Ten scenariusz może być trudny, ponieważ kod nie utrzymuje długich połączeń z klientami. Usługa Azure SignalR Service może obsłużyć taką sytuację, ponieważ już zarządza połączeniami za Ciebie.
Usługa Azure SignalR Service ściśle integruje się z innymi usługami platformy Azure, takimi jak Azure SQL Database, Service Bus lub Redis Cache, co otwiera wiele możliwości dla aplikacji natywnych dla chmury.
