Mapowanie aplikacji eShopOnContainers na usługi platformy Azure
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.
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.
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 są zgodne ze wzorcem "zaplecza frontonów" (BFF), co oznacza, że każda brama jest przeznaczona do obsługi danego klienta frontonu. Poszczególne mikrousługi są wyświetlane po prawej stronie bram interfejsu API i obejmują zarówno logikę biznesową, jak i jakiś magazyn trwałości. 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.
Rysunek 2–5. Architektura eShopOnContainers.
Składniki po stronie serwera tej architektury można łatwo mapować na usługi platformy Azure.
Orkiestracja kontenerów i klastrowanie
Usługi hostowane w kontenerach aplikacji z aplikacji ASP.NET Core MVC do poszczególnych usług katalogu i zamawiania mikrousług 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.
Usługa AKS udostępnia usługi zarządzania dla poszczególnych klastrów 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.
Brama interfejsu API
Aplikacja eShopOnContainers ma wielu klientów frontonu 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.
Brama interfejsu API akceptuje wywołania interfejsu API i kieruje je do odpowiedniego interfejsu API zaplecza. 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 zaplecze dla określonego klienta frontonu. Usługa APIM jest zalecana w przypadku złożonych scenariuszy. W przypadku prostszych potrzeb można użyć uproszczonego rozwiązania Ocelot bramy interfejsu API. 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 usługi AKS, jest wdrożenie kontrolera ruchu przychodzącego usługi Azure Gateway jako zasobnika w klastrze usługi AKS. Takie podejście umożliwia klastrowi integrację z bramą aplikacja systemu Azure, umożliwiając bramie równoważenie obciążenia ruchu do zasobników usługi AKS. Dowiedz się więcej o kontrolerze ruchu przychodzącego usługi Azure Gateway dla usługi AKS.
Data
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 w celu utrzymania. Mikrousługa Locations oczekuje interfejsu API bazy danych MongoDB dla swoich danych. pomoc techniczna platformy Azure 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.
Magistrala zdarzeń
Aplikacja używa zdarzeń do komunikowania zmian między różnymi usługami. Tę funkcję można zaimplementować za pomocą 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 na potrzeby obsługi komunikatów. Azure Service Bus to w pełni zarządzany broker komunikatów integracji, 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.
Odporność
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 aplikacją Szczegółowe informacje 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.
