Zuordnung von eShopOnContainers zu Azure-Diensten

Obwohl nicht erforderlich, eignet sich Azure gut für die Unterstützung von eShopOnContainers, da das Projekt als cloudeigene Anwendung erstellt wurde. Die Anwendung wird mit .NET erstellt, sodass sie abhängig vom Docker-Host auf Linux- oder Windows-Containern ausgeführt werden kann. Die Anwendung besteht aus mehreren autonomen Microservices, die jeweils eigene Daten enthalten. Die verschiedenen Microservices zeigen unterschiedliche Ansätze, von einfachen CRUD-Vorgängen bis hin zu komplexeren DDD- und CQRS-Mustern. Microservices kommunizieren mit Clients über HTTP und miteinander über nachrichtenbasierte Kommunikation. Die Anwendung unterstützt auch mehrere Plattformen für Clients, da sie HTTP als Standardkommunikationsprotokoll verwendet und ASP.NET Core- und Xamarin-Mobile-Apps umfasst, die auf Android-, iOS- und Windows-Plattformen ausgeführt werden. (Xamarin wird ab Mai 2024 nicht unterstützt.)

Die Architektur der Anwendung ist in Abbildung 2-5 dargestellt. Auf der linken Seite befinden sich die Client-Apps, die in mobile, herkömmliche Web- und Web Single Page Application (SPA)-Varianten unterteilt sind. Auf der rechten Seite befinden sich die serverseitigen Komponenten, aus denen das System besteht, von denen jeder in Docker-Containern und Kubernetes-Clustern gehostet werden kann. Die herkömmliche Web-App wird von der in Gelb angezeigten ASP.NET Core MVC-Anwendung unterstützt. Diese App und die mobilen und Web SPA-Anwendungen kommunizieren mit den einzelnen Microservices über ein oder mehrere API-Gateways. Die API-Gateways folgen dem Muster "Back-Ends für Front-Ends" (BFF), was bedeutet, dass jedes Gateway für die Unterstützung eines bestimmten Front-End-Clients konzipiert ist. Die einzelnen Microservices sind rechts neben den API-Gateways aufgeführt und enthalten sowohl Geschäftslogik als auch eine Art Persistenzspeicher. Die verschiedenen Dienste nutzen SQL Server-Datenbanken, Redis-Cacheinstanzen und MongoDB/CosmosDB-Speicher. Ganz rechts ist der Event Bus des Systems, der für die Kommunikation zwischen den Microservices verwendet wird.

Abbildung 2–5. Die eShopOnContainers-Architektur.

Die serverseitigen Komponenten dieser Architektur sind allen Azure-Diensten einfach zugeordnet.

Containerorchestrierung und Clustering

Die containergehosteten Dienste der Anwendung, von ASP.NET Core MVC-Apps bis hin zu einzelnen Katalog- und Sortierungs-Microservices, können in Azure Kubernetes Service (AKS) gehostet und verwaltet werden. Die Anwendung kann lokal auf Docker und Kubernetes ausgeführt werden, und die gleichen Container können dann in Staging- und Produktionsumgebungen bereitgestellt werden, die in AKS gehostet werden. Dieser Prozess kann automatisiert werden, wie wir im nächsten Abschnitt sehen.

AKS bietet Verwaltungsdienste für einzelne Cluster von Containern. Die Anwendung stellt separate Container für jeden Microservice im AKS-Cluster bereit, wie im obigen Architekturdiagramm dargestellt. Mit diesem Ansatz kann jeder einzelne Dienst unabhängig nach seinen Ressourcenanforderungen skaliert werden. Jeder Microservice kann auch unabhängig bereitgestellt werden, und idealerweise sollten solche Bereitstellungen keine Systemausfallzeiten verursachen.

API-Gateway

Die eShopOnContainers-Anwendung verfügt über mehrere Front-End-Clients und mehrere verschiedene Back-End-Dienste. Es gibt keine 1:1-Korrespondenz zwischen den Clientanwendungen und den Microservices, die sie unterstützen. In einem solchen Szenario kann es eine große Komplexität geben, wenn Clientsoftware so geschrieben wird, dass sie auf sichere Weise mit den verschiedenen Back-End-Diensten zusammenarbeiten kann. Jeder Client müsste diese Komplexität eigenständig beheben, was zu Duplizierungen und vielen Stellen führt, an denen Aktualisierungen vorgenommen werden, wenn Dienste geändert oder neue Richtlinien implementiert werden.

Azure API Management (APIM) hilft Organisationen beim Veröffentlichen von APIs in konsistenter, verwaltbarer Weise. APIM besteht aus drei Komponenten: dem API-Gateway und dem Verwaltungsportal (dem Azure-Portal) und einem Entwicklerportal.

Das API-Gateway akzeptiert API-Aufrufe und leitet sie an die entsprechende Back-End-API weiter. Sie kann auch zusätzliche Dienste bereitstellen, wie die Überprüfung von API-Schlüsseln oder JWT-Tokens und die API-Transformation in Echtzeit ohne Codeänderungen (zum Beispiel, um Clients mit einer älteren Schnittstelle zu unterstützen).

Im Azure-Portal definieren Sie das API-Schema und verpacken verschiedene APIs in Produkte. Außerdem konfigurieren Sie den Benutzerzugriff, zeigen Berichte an und konfigurieren Richtlinien für Kontingente oder Transformationen.

Das Entwicklerportal dient als Hauptressource für Entwickler. Es stellt Entwicklern API-Dokumentation, eine interaktive Testkonsole und Berichte über ihre eigene Verwendung zur Verfügung. Entwickler verwenden auch das Portal zum Erstellen und Verwalten eigener Konten, einschließlich Abonnement- und API-Schlüsselunterstützung.

Mithilfe von APIM können Anwendungen verschiedene Gruppen von Diensten verfügbar machen, wobei jeweils ein Back-End für einen bestimmten Front-End-Client bereitgestellt wird. APIM wird für komplexe Szenarien empfohlen. Für einfachere Anforderungen kann das einfache API-Gateway Ocelot verwendet werden. Die eShopOnContainers-App verwendet Ocelot aufgrund ihrer Einfachheit und weil sie in derselben Anwendungsumgebung wie die Anwendung selbst bereitgestellt werden kann. Erfahren Sie mehr über eShopOnContainers, APIM und Ocelot.

Eine weitere Option, wenn Ihre Anwendung AKS verwendet, besteht darin, den Azure Gateway Ingress Controller als Pod in Ihrem AKS-Cluster bereitzustellen. Mit diesem Ansatz kann Ihr Cluster in ein Azure-Anwendungsgateway integriert werden, sodass das Gateway für den Datenverkehr mit den AKS-Pods einen Lastenausgleich durchführen kann. Erfahren Sie mehr über den Azure Gateway-Eingangsdatencontroller für AKS.

Daten

Die verschiedenen back-End-Dienste, die von eShopOnContainers verwendet werden, weisen unterschiedliche Speicheranforderungen auf. Mehrere Microservices verwenden SQL Server-Datenbanken. Der Basket Microservice nutzt einen Redis-Cache für seine Persistenz. Der Locations microservice erwartet eine MongoDB-API für seine Daten. Azure unterstützt jedes dieser Datenformate.

Für die SQL Server-Datenbankunterstützung bietet Azure Produkte an, die alles abdecken, von einzelnen Datenbanken bis hin zu hoch skalierbaren SQL-Datenbank-Elastic-Pools. Einzelne Microservices können so konfiguriert werden, dass sie schnell und einfach mit ihren eigenen SQL Server-Datenbanken kommunizieren. Diese Datenbanken können nach Bedarf skaliert werden, um jeden separaten Microservice entsprechend seinen Anforderungen zu unterstützen.

Die eShopOnContainers-Anwendung speichert den aktuellen Einkaufskorb des Benutzers zwischen Anfragen. Dieser Aspekt wird vom Basket microservice verwaltet, der die Daten in einem Redis-Cache speichert. In der Entwicklung kann dieser Cache in einem Container bereitgestellt werden, während er in der Produktion Azure Cache für Redis nutzen kann. Azure Cache for Redis ist ein vollständig verwalteter Dienst, der hohe Leistung und Zuverlässigkeit bietet, ohne Redis-Instanzen oder -Container eigenständig bereitstellen und verwalten zu müssen.

Der Locations microservice verwendet eine MongoDB NoSQL-Datenbank für die Persistenz. Während der Entwicklung kann die Datenbank in einem eigenen Container bereitgestellt werden, während der Dienst in der Produktionsumgebung die API von Azure Cosmos DB für MongoDB nutzen kann. Einer der Vorteile von Azure Cosmos DB ist die Möglichkeit, mehrere verschiedene Kommunikationsprotokolle zu nutzen, einschließlich einer SQL-API und gängigen NoSQL-APIs wie MongoDB, Cassandra, Gremlin und Azure Table Storage. Azure Cosmos DB bietet eine vollständig verwaltete und global verteilte Datenbank als Dienst, die skaliert werden kann, um die Anforderungen der Dienste zu erfüllen, die sie verwenden.

Verteilte Daten in cloudeigenen Anwendungen werden in Kapitel 5ausführlicher behandelt.

Ereignisbus

Die Anwendung verwendet Ereignisse, um Änderungen zwischen verschiedenen Diensten zu kommunizieren. Diese Funktionalität kann mit verschiedenen Implementierungen implementiert werden, und die eShopOnContainers-Anwendung verwendet RabbitMQ. Wenn die Anwendung in Azure gehostet würde, würde sie den Azure Service Bus für ihre Nachrichten nutzen. Azure Service Bus ist ein vollständig verwalteter Nachrichtenbroker für die Integration, mit dem Anwendungen und Dienste auf entkoppelte, zuverlässige und asynchrone Weise miteinander kommunizieren können. Azure Service Bus unterstützt einzelne Warteschlangen sowie separate Themen, um Herausgeber-Abonnenten-Szenarien zu unterstützen. Die eShopOnContainers-Anwendung nutzt Themen mit Azure Service Bus, um die Verteilung von Nachrichten von einem Microservice an jeden anderen Microservice zu unterstützen, der für die Reaktion auf eine bestimmte Nachricht erforderlich ist.

Elastizität

Nach der Bereitstellung in der Produktion kann die eShopOnContainers-Anwendung mehrere Azure-Dienste nutzen, die zur Verbesserung der Resilienz verfügbar sind. Die Anwendung veröffentlicht Gesundheitsprüfungen, die in das Application Insights integriert werden können, um Berichte und Warnungen bereitzustellen, die auf der Verfügbarkeit der App basieren. Azure-Ressourcen stellen auch Diagnoseprotokolle bereit, die zum Identifizieren und Beheben von Fehlern und Leistungsproblemen verwendet werden können. Ressourcenprotokolle enthalten detaillierte Informationen dazu, wann und wie verschiedene Azure-Ressourcen von der Anwendung verwendet werden. Weitere Informationen zu Cloud-nativen Resilienzfeatures finden Sie in Kapitel 6.