Mapowanie aplikacji eShopOnContainers na usługi platformy Azure
Napiwek
Ta zawartość jest fragmentem e-książki, Architektura Cloud Native .NET Applications for Azure, dostępnej w .NET Docs lub jako bezpłatny plik PDF do pobrania, który można czytać offline.
Mimo że nie jest to wymagane, platforma Azure jest odpowiednia do obsługi aplikacji eShopOnContainers, ponieważ projekt został utworzony jako aplikacja natywna dla chmury. Aplikacja jest kompilowana przy użyciu platformy .NET, więc może działać w kontenerach systemu Linux lub Windows w zależności od hosta platformy Docker. Aplikacja składa się z wielu autonomicznych mikrousług, z których każda ma własne dane. Różne mikrousługi przedstawiają różne podejścia, od prostych operacji CRUD po bardziej złożone wzorce DDD i CQRS. Mikrousługi komunikują się z klientami za pośrednictwem protokołu HTTP i ze sobą za pośrednictwem komunikacji opartej na komunikatach. Aplikacja obsługuje również wiele platform dla klientów, ponieważ przyjmuje protokół HTTP jako standardowy protokół komunikacyjny i zawiera aplikacje mobilne ASP.NET Core i Xamarin, które działają na platformach Android, iOS i Windows. (Platforma Xamarin nie jest obsługiwana od maja 2024 r.)
Architektura aplikacji jest wyświetlana na rysunku 2–5. Po lewej stronie są aplikacje klienckie, podzielone na mobilne, tradycyjne internetowe i internetowe aplikacje jednostronicowe (SPA). Po prawej stronie znajdują się składniki po stronie serwera, które tworzą system, z których każdy może być hostowany w kontenerach platformy Docker i klastrach Kubernetes. Tradycyjna aplikacja internetowa jest obsługiwana przez aplikację ASP.NET Core MVC wyświetlaną na żółto. Ta aplikacja i aplikacje mobilne i internetowe SPA komunikują się z poszczególnymi mikrousługami za pośrednictwem co najmniej jednej bramy interfejsu API. Bramy interfejsu API stosują wzorzec "zaplecza dla interfejsów frontowych" (BFF), co oznacza, że każda brama jest zaprojektowana do obsługi danego klienta frontowego. Poszczególne mikrousługi są wyświetlane po prawej stronie bram API i obejmują zarówno logikę biznesową, jak i pewien rodzaj magazynu danych. Różne usługi korzystają z baz danych programu SQL Server, wystąpień pamięci podręcznej Redis i magazynów Bazy danych MongoDB/CosmosDB. Po prawej stronie znajduje się system Event Bus, który jest używany do komunikacji między mikrousługami.
architektura 
Rysunek 2–5. Architektura eShopOnContainers.
Składniki po stronie serwera tej architektury można łatwo przyporządkować do usług oferowanych przez platformę Azure.
Orkiestracja kontenerów i klastrowanie
Usługi hostowane w kontenerach, od aplikacji ASP.NET Core MVC po poszczególne mikrousługi katalogu i zamawiania, mogą być hostowane i zarządzane w usłudze Azure Kubernetes Service (AKS). Aplikacja może działać lokalnie na platformach Docker i Kubernetes, a te same kontenery można następnie wdrożyć w środowiskach przejściowych i produkcyjnych hostowanych w usłudze AKS. Ten proces można zautomatyzować, jak zobaczymy w następnej sekcji.
AKS świadczy zarządzanie poszczególnymi klastrami kontenerów. Aplikacja wdroży oddzielne kontenery dla każdej mikrousługi w klastrze usługi AKS, jak pokazano na powyższym diagramie architektury. Takie podejście umożliwia każdej usłudze niezależne skalowanie zgodnie z wymaganiami dotyczącymi zasobów. Każda mikrousługa może być również wdrażana niezależnie, a w idealnym przypadku takie wdrożenia powinny spowodować zerowy przestój systemu.
Bramka API
Aplikacja eShopOnContainers ma wielu klientów front-endu i wiele różnych usług zaplecza. Między aplikacjami klienckimi a mikrousługami, które je obsługują, nie istnieje żadna korespondencja typu jeden do jednego. W takim scenariuszu może wystąpić duża złożoność podczas pisania oprogramowania klienckiego do interfejsu z różnymi usługami zaplecza w bezpieczny sposób. Każdy klient musi samodzielnie rozwiązać tę złożoność, co powoduje duplikowanie i wiele miejsc, w których należy wprowadzać aktualizacje w miarę wprowadzania zmian usług lub wdrażania nowych zasad.
Usługa Azure API Management (APIM) ułatwia organizacjom publikowanie interfejsów API w spójny, możliwy do zarządzania sposób. Usługa APIM składa się z trzech składników: bramy interfejsu API i portalu administracyjnego (witryny Azure Portal) oraz portalu dla deweloperów.
Bramka API akceptuje zgłoszenia i kieruje je do odpowiedniego zaplecza API. Może również udostępniać dodatkowe usługi, takie jak weryfikacja kluczy interfejsu API lub tokeny JWT i przekształcanie interfejsu API na bieżąco bez modyfikacji kodu (na przykład w celu uwzględnienia klientów spodziewających się starszego interfejsu).
Witryna Azure Portal służy do definiowania schematu interfejsu API i tworzenia pakietów różnych interfejsów API w produktach. Można również skonfigurować dostęp użytkowników, wyświetlać raporty i konfigurować zasady dotyczące przydziałów lub przekształceń.
Portal deweloperów służy jako główny zasób dla deweloperów. Udostępnia ona deweloperom dokumentację interfejsu API, interaktywną konsolę testową i raporty dotyczące własnego użycia. Deweloperzy używają również portalu do tworzenia własnych kont i zarządzania nimi, w tym obsługi subskrypcji i klucza interfejsu API.
Za pomocą usługi APIM aplikacje mogą uwidaczniać kilka różnych grup usług, z których każda udostępnia back-end dla określonego klienta front-end. Usługa APIM jest zalecana w przypadku złożonych scenariuszy. W przypadku prostszych potrzeb można użyć lekkiej bramy interfejsu API Ocelot. Aplikacja eShopOnContainers używa rozwiązania Ocelot ze względu na prostotę i dlatego, że można ją wdrożyć w tym samym środowisku aplikacji co sama aplikacja. Dowiedz się więcej o eShopOnContainers, APIM i Ocelot.
Inną opcją, jeśli aplikacja używa AKS, jest wdrożenie kontrolera ruchu przychodzącego Azure Gateway jako pod w klastrze AKS. Takie podejście umożliwia integrację klastra z usługą Azure Application Gateway, co pozwala na równoważenie obciążenia ruchu przez bramę do zasobników w AKS. Dowiedz się więcej o kontrolerze Ingress dla Azure Gateway w AKS.
Dane
Różne usługi zaplecza używane przez firmę eShopOnContainers mają różne wymagania dotyczące magazynu. Kilka mikrousług używa baz danych programu SQL Server. Mikrousługa Koszyk korzysta z pamięci podręcznej Redis do przechowywania danych. Mikrousługa Locations oczekuje interfejsu API bazy danych MongoDB dla swoich danych. Platforma Azure obsługuje każdy z tych formatów danych.
W przypadku obsługi bazy danych programu SQL Server platforma Azure udostępnia produkty dla wszystkich elementów— od pojedynczych baz danych do wysoce skalowalnych elastycznych pul usługi SQL Database. Poszczególne mikrousługi można skonfigurować do szybkiego i łatwego komunikowania się z własnymi indywidualnymi bazami danych programu SQL Server. Te bazy danych można skalować zgodnie z potrzebami w celu obsługi każdej oddzielnej mikrousługi.
Aplikacja eShopOnContainers przechowuje bieżący koszyk zakupów użytkownika między żądaniami. Ten aspekt jest zarządzany przez mikrousługę Koszyk, która przechowuje dane w pamięci podręcznej Redis. W trakcie programowania tę pamięć podręczną można wdrożyć w kontenerze, podczas gdy w środowisku produkcyjnym może korzystać z usługi Azure Cache for Redis. Azure Cache for Redis to w pełni zarządzana usługa oferująca wysoką wydajność i niezawodność bez konieczności samodzielnego wdrażania wystąpień lub kontenerów usługi Redis oraz zarządzania nimi.
Mikrousługa Locations używa bazy danych MongoDB NoSQL do jej trwałości. Podczas programowania bazę danych można wdrożyć we własnym kontenerze, podczas gdy w środowisku produkcyjnym usługa może korzystać z interfejsu API usługi Azure Cosmos DB dla bazy danych MongoDB. Jedną z zalet usługi Azure Cosmos DB jest możliwość korzystania z wielu różnych protokołów komunikacyjnych, w tym interfejsu API SQL i typowych interfejsów API NoSQL, takich jak MongoDB, Cassandra, Gremlin i Azure Table Storage. Usługa Azure Cosmos DB oferuje w pełni zarządzaną i globalnie rozproszoną bazę danych jako usługę, która może być skalowana zgodnie z potrzebami usług, które z niej korzystają.
Dane rozproszone w aplikacjach natywnych dla chmury zostały szczegółowo omówione w rozdziale 5.
Bus zdarzeń
Aplikacja używa zdarzeń do komunikowania zmian między różnymi usługami. Tę funkcję można zaimplementować przy użyciu różnych implementacji, a lokalnie aplikacja eShopOnContainers używa RabbitMQ. W przypadku hostowania na platformie Azure aplikacja będzie korzystać z usługi Azure Service Bus do obsługi komunikatów. Azure Service Bus to w pełni zarządzany broker komunikatów integracyjnych, który umożliwia aplikacjom i usługom komunikowanie się ze sobą w sposób oddzielony, niezawodny i asynchroniczny. Usługa Azure Service Bus obsługuje poszczególne kolejki, a także oddzielne tematy do obsługi scenariuszy wydawcy-subskrybentów. Aplikacja eShopOnContainers korzystałaby z tematów w usłudze Azure Service Bus, aby obsługiwać dystrybucję komunikatów z jednej mikrousługi do dowolnej innej mikrousługi, która musiała reagować na dany komunikat.
Elastyczność
Po wdrożeniu w środowisku produkcyjnym aplikacja eShopOnContainers będzie mogła korzystać z kilku dostępnych usług platformy Azure w celu zwiększenia odporności. Aplikacja publikuje kontrole kondycji, które można zintegrować z usługą Application Insights w celu zapewnienia raportowania i alertów na podstawie dostępności aplikacji. Zasoby platformy Azure udostępniają również dzienniki diagnostyczne, których można użyć do identyfikowania i poprawiania usterek oraz problemów z wydajnością. Dzienniki zasobów zawierają szczegółowe informacje na temat tego, kiedy i jak różne zasoby platformy Azure są używane przez aplikację. Więcej informacji na temat funkcji odporności natywnych dla chmury znajdziesz w rozdziale 6.
