Zuordnen von eShopOnContainers zu Azure-Diensten
Tipp
Diese Inhalte sind ein Auszug aus dem E-Book „Architecting Cloud Native .NET Applications for Azure“, verfügbar in der .NET-Dokumentation oder als kostenlos herunterladbare PDF-Datei, die offline gelesen werden kann.
Obwohl nicht erforderlich, eignet sich Azure gut für die Unterstützung von eShopOnContainers, da das Projekt als cloudnative 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 verwenden untereinander eine 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 enthält, die auf Android-, iOS- und Windows-Plattformen ausgeführt werden.
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 jede 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 sowie die 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 Cache-Instanzen und MongoDB/CosmosDB-Speicher. Ganz rechts befindet sich 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 lassen sich alle problemlos den Azure-Diensten zuordnen.
Containerorchestrierung und Clustering
Die in Containern gehosteten Dienste der Anwendung, von ASP.NET Core MVC-Apps bis hin zu einzelnen Microservices für Katalog und Bestellung, können in Azure Kubernetes Service (AKS) gehostet und verwaltet werden. Die Anwendung kann lokal unter 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 Downtime des Systems 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 sich als sehr komplex erweisen, 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 behandeln, 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) sowie 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, z. B. die Überprüfung von API-Schlüsseln oder JWT-Token und die dynamische API-Transformation ohne Codeänderungen (z. B. 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 die eigene Nutzung 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-Eingangsdatencontroller 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 verfügt Azure über Produkte für alles, von einzelnen Datenbanken bis hin zu hochgradig skalierbaren Pools für elastische SQL-Datenbanken. 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 Warenkorb des Benutzers zwischen Anforderungen. 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 Produktionsumgebung Azure Cache for 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 cloudnativen Anwendungen werden in Kapitel 5 ausfü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 sie in Azure gehostet wird, nutzt die Anwendung Azure Service Bus für das Messaging. 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.
Resilienz
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 Integritätsprüfungen, die in Application Insights integriert werden können, um Berichte und Warnungen basierend auf der Verfügbarkeit der App bereitzustellen. 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 cloudnativen Resilienzfeatures finden Sie in Kapitel 6.
