Auswählen einer Azure-Computeoption für Microservices

Dieser Artikel hilft Ihnen bei der Auswahl einer Azure-Computeplattform für eine Workload, die auf einer Microservices-Architektur basiert. Eine Microservices-Architektur besteht aus kleinen, unabhängig bereitgestellten Diensten, die über das Netzwerk kommunizieren. Ihre Computeplattform muss unabhängige Skalierung, unabhängige Bereitstellung und zuverlässige Interservicekommunikation über viele Dienste hinweg unterstützen.

Für Entscheidungsfaktoren, die für jede Workload gelten, wie Teamkenntnisse, Netzwerk und Portabilität, finden Sie Informationen unter Auswählen eines Azure-Computediensts. Dieser Artikel konzentriert sich auf die Faktoren, die speziell für Microservices wichtig sind.

Azure-Computeplattformen für Microservices

Die folgenden Azure-Plattformen unterstützen Microservices-Workloads. Sie unterscheiden sich darin, wie viel Orchestrierung, Interservicekommunikation und Skalierungsverhalten sie bieten.

Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) ist ein verwalteter Kubernetes-Dienst , der direkten Zugriff auf Kubernetes-APIs und die Steuerungsebene bietet. AKS bietet Knotenverwaltung, Patching und optionale automatische Upgrades. Sie konfigurieren die Cluster-, Netzwerk- und Skalierungsrichtlinien.

Für Microservices unterstützt AKS Service Meshes wie Istio für die Verkehrssteuerung und die gegenseitige Transport Layer Security (mTLS), die Skalierung pro Bereitstellung über Horizontaler Pod Autoscaler (HPA) und Kubernetes Event-driven Autoscaling (KEDA) und Kubernetes-native Bereitstellungsstrategien wie Rolling Updates und Canary Releases.

AKS Automatic ist ein Modus von AKS, der die Knotenverwaltung, Skalierung, Sicherheit und Beobachtbarkeit basierend auf den empfohlenen Architekturprinzipien von AKS vorkonfiguriert, sodass Teams einen produktionsbereiten Cluster ohne spezifische Konfiguration der einzelnen Fähigkeiten erhalten.

Azure Container Apps – ein Dienst für containerbasierte Anwendungen

Azure Container Apps ist ein verwalteter Dienst, der auf Kubernetes basiert und die Clusterverwaltung abstrahiert.

Container-Apps bieten integrierte Features für Microservices, einschließlich Dienstermittlung, Dapr-Integration für Dienst-zu-Dienst-Aufrufe mit mTLS, Publisher-Subscriber-Messaging und Statusverwaltung. KEDA-basierte Automatische Skalierung ermöglicht die ereignisgesteuerte Skalierung, einschließlich Skalierung auf Null. Container-Apps unterstützen auch das Traffic-Splitting zwischen Überarbeitungen für Canary-Bereitstellungen und Jobs für On-Demand-, geplante oder ereignisgesteuerte Aufgaben.

Container-Apps machen Kubernetes-APIs nicht verfügbar. Wenn Die Konfiguration der Bereitstellungstools oder des Dienstgitters von Kubernetes-Grundtypen abhängt, verwenden Sie stattdessen AKS.

Azure-Funktionen

Azure Functions ist ein serverloser, ereignisgesteuerter Computedienst, der für Microservices geeignet ist, die auf Trigger wie HTTP-Anforderungen, Warteschlangennachrichten oder Timer reagieren. Funktionen skalieren jede Funktions-App unabhängig voneinander und können auf Null skaliert werden. Stellen Sie für Microservices jeden Dienst als eigene Funktions-App bereit.

Funktionen bieten keine Dienstentdeckung auf Plattformebene oder Interservicekommunikation. Implementieren Sie diese Funktionen im Anwendungscode oder über externe Dienste wie Azure API Management.

Funktionen unterstützen mehrere Programmiersprachen. Sie können auch das Funktionenprogrammiermodell für Container-Apps ausführen, das Funktionentrigger und Bindungen mit Container-Apps-Netzwerk- und Skalierungsfeatures kombiniert.

Azure App Service

Azure App Service passt zu HTTP-basierten Microservices wie Web-APIs. Der App-Dienst unterstützt die Bereitstellung als Code oder als einzelner Container. Es bietet eine integrierte automatische Skalierung, Bereitstellungs-Slots für Blue-Green-Deployments und prozentsatzbasiertes Traffic-Routing sowie die Integration in Continuous Integration und Continuous Delivery (CI/CD)-Pipelines. Der App Service bietet keine Dienstermittlung, daher eignet er sich für Microservices, die über externe Nachrichtensysteme oder ein API-Gateway kommunizieren, anstatt auf Interservice-Kommunikation auf Plattformebene zu vertrauen.

Azure Red Hat OpenShift

Azure Red Hat OpenShift bietet vollständig verwaltete OpenShift-Cluster und erweitert Kubernetes mit einer vorkonfigurierten Entwicklererfahrung. Red Hat und Microsoft entwickeln, betreiben und unterstützen den Dienst gemeinsam. Verwenden Sie Azure Red Hat OpenShift, wenn Ihre Organisation auf OpenShift standardisiert.

Vergleichen von Plattformen für Microservices

In der folgenden Tabelle wird verglichen, wie jede Plattform die Funktionen unterstützt, die für eine Microservices-Architektur wichtig sind. Einen detaillierteren Vergleich der Azure-Containerhostingplattformen und deren Funktionen finden Sie unter Auswählen eines Azure-Containerdiensts.

Fähigkeit AKS Container Apps Funktionen App Service
Dienstermittlung Kubernetes Domain Name System (DNS), Dienstgitter Integriert, Dapr Keine (App-Ebene) Keine (App-Ebene)
Kommunikation zwischen Diensten Dienstgitter (Istio) Dapr, Umgebungsebene Keine (App-Ebene) Keine (App-Ebene)
Publisher-Subscriber-Nachrichtenübermittlung App-Ebene (wie Azure Service Bus, Azure Event Hubs) Dapr pub/sub Bindungen App-Ebene
Unabhängige Skalierung Pro Bereitstellung (HPA, KEDA) Pro App (KEDA) App je Funktion (auf Flex-Plattform je Funktion) Pro-Anwendung-Serviceplan
Skalierung auf null Teilweise (nur Benutzerknotenpools) Yes Ja (Verbrauchs- oder Flex-Verbrauchspläne) No
Ausgleich beim Kaltstart Minimale Knotenanzahl, minimale Podreplikate Minimale Replikatanzahl Vorwarm oder immer einsatzbereite Instanzen (Premium- oder Flex-Verbrauch) Nicht zutreffend (Always On)
Verkehrsaufteilung und Canary-Bereitstellungen Kubernetes-natives Dienstgitter Revisionsbasiert Bereitstellungsplätze (Premium/Dediziert) Bereitstellungsslots mit Datenverkehrssteuerung
Verteiltes Tracing OpenTelemetry, Open-Source-Tool Integrierte Dapr-Ablaufverfolgung Anwendungsanalysen Anwendungsanalysen
Zustandsbehaftete Dienste Persistente Volumes, StatefulSets Volume-Mounts, Dapr-Status Dauerhafte Funktionen Einbindung von Azure Files
Dienstspezifische Identität Workload-Identität Verwaltete Identität Verwaltete Identität Verwaltete Identität
Kubernetes-API-Zugriff Yes No No No
Unabhängige Bereitstellungsfähigkeit Ja (pro Pod oder pro Deployment) Ja (pro Container-App) Ja (pro Funktions-App) Ja (pro App oder Bereitstellungsplatz)
Führt Container aus Yes Yes Yes Yes
Führt Code ohne Container aus. No No Yes Yes

Die App-Ebene in dieser Tabelle bedeutet, dass die Plattform die Funktion nicht als integriertes Feature bereitstellt. Sie implementieren sie in Anwendungscode über ein SDK oder einen externen Dienst, der eine Abhängigkeit von diesem Dienst einführt.

Note

Diese Tabelle enthält keine Azure Red Hat OpenShift. Es stellt die vollständige Kubernetes-API bereit, sodass seine kernigen Microservices-Funktionen wie Skalierung pro Bereitstellung, Dienstermittlung und rollierende Updates mit AKS vergleichbar sind.

Die Plattformen unterscheiden sich in ihren operativen Tools, nicht in ihren Kern-Microservices-Funktionen. Beispielsweise stellt AKS Dapr und KEDA als verwaltete Add-Ons bereit, aber bei OpenShift installieren und verwalten Sie sie selbst. Weitere Informationen finden Sie in der Dokumentation zu Azure Red Hat OpenShift.

Auswählen Ihrer Plattform

  • Beginnen Sie mit Container-Apps, wenn Sie integrierte Microservices-Funktionen wie Dienstermittlung, Dapr und Pro-App-Skalierung benötigen, die das Skalieren bis auf Null und die Verwaltung ohne Cluster ermöglichen.

  • Wählen Sie AKS aus, wenn Sie direkten Kubernetes-API-Zugriff, eine benutzerdefinierte Dienstgitterkonfiguration oder eine differenzierte Kontrolle über die Clusterinfrastruktur benötigen, z. B. Knotenpools, Netzwerkrichtlinien oder Planungseinschränkungen.

  • Verwenden Sie Funktionen für ereignisgesteuerte Microservices, die sporadische oder plötzliche Datenverkehrsmuster aufweisen und von der Abrechnung mit Skalierung auf Null und ausgelöster Ausführung profitieren.

  • Verwenden Sie App Service für einfache HTTP-basierte Dienste, die keine Funktionen für die Dienstermittlung auf Plattformebene oder Interservice-Kommunikation benötigen.

Ihre Microservices-Workload muss nicht auf einer einzigen Plattform ausgeführt werden. Sie können beispielsweise Kerndienste auf AKS oder Container-Apps ausführen, während Funktionen ereignisgesteuerte Workloads verarbeiten. Bewerten Sie jeden Dienst in Ihrer Komposition anhand seines eigenen Datenverkehrsmusters, Skalierungsanforderungen und Kommunikationsanforderungen. Wählen Sie die Plattform aus, die zu diesem Dienst passt, anstatt den Dienst an die Plattform anzupassen.

Wichtige Entscheidungsfaktoren

Die Vergleichstabelle zeigt, was jede Plattform unterstützt. In den folgenden Abschnitten können Sie diese Funktionen abwägen, je nachdem, welche Microservices für Ihre Workload am wichtigsten sind.

Kommunikation zwischen Diensten

Microservices hängen von der zuverlässigen Dienst-zu-Dienst-Kommunikation mit Funktionen wie Dienstentdeckung, erneute Versuche und mTLS ab.

Wenn Ihre Architektur von synchronen Dienst-zu-Dienst-Aufrufen über viele Dienste abhängt, priorisieren Sie eine Plattform mit integrierten Kommunikationsgrundtypen. Container Apps stellen diese Primitive über Dapr ohne zusätzliche Infrastruktur bereit. AKS bietet sie über Service Meshes wie Istio an, die Ihnen die Kontrolle über Traffic-Richtlinien, Wiederholungsversuche und Schaltkreis-Unterbrechungen im Mesh ermöglichen. Sie verwalten den Gitterlebenszyklus, die Konfiguration und Upgrades.

Wenn Ihre Dienste in erster Linie über asynchrones Messaging wie Warteschlangen oder Ereignisstreams kommunizieren, sind die integrierten Kommunikationsfeatures der Plattform weniger wichtig, da Sie mit diesen Diensten über ein SDK oder eine Abstraktion interagieren müssen. Verwenden Sie das Muster "Asynchrone Request-Reply " für lange ausgeführte Vorgänge, da Plattformtimeouts zu einem Problem werden können. Beispielsweise erzwingen Funktionen und App-Dienst aufgrund von Azure Load Balancer-Grenzwerten ein Timeout für http-Antworten von 230 Sekunden .

Unabhängige Skalierung

Jeder Microservice in einer Komposition weist unterschiedliche Ladeeigenschaften auf.

Wenn Ihre Dienste stark schwankenden oder plötzlichen Spitzen im Datenverkehr aufweisen, skalieren Container-Apps und -Funktionen pro Dienst und können nicht genutzte Dienste auf Null herunterskalieren. Bei diesem Ansatz werden nicht verwendete Kapazitätsgebühren vermieden. Bei Funktionen ist jede Funktions-App die Skalierungseinheit. Stellen Sie daher jeden Microservice als eigene Funktions-App bereit. AKS ermöglicht die Skalierung pro Bereitstellungsvorgang. Sie verwalten freigegebene Knotenpools, die weiterhin bereitgestellt werden, und Benutzerknotenpools können auf Null skaliert werden.

Plattformen zur Skalierung auf Null führen zu Kaltstartlatenz, wenn ein inaktiver Dienst seine erste Anforderung empfängt. In einer Microservices-Architektur kann eine einzelne Benutzeranforderung mehrere Dienste durchlaufen. Wenn mehrere Dienste in der Aufrufkette kalt sind, steigt die Latenz. Um synchrone Interservice-Aufrufe mit niedriger Latenz zu ermöglichen, verwenden Sie die Kaltstartminderungsfunktionen der Plattform, oder tragen Sie die Kosten, indem Sie minimale Instanzen aktiv halten, um Kaltstarts zu vermeiden.

Wenn Ihre Dienste eine stetige, vorhersagbare Last haben, können AKS oder App Service Kosten reduzieren, da Sie reservierte Kapazität anstelle der verbrauchsbasierten Abrechnung bezahlen.

Unabhängige Bereitstellungsfähigkeit

Sie müssen einzelne Microservices bereitstellen, aktualisieren und zurücksetzen, ohne dass sich dies auf den Rest des Systems auswirkt. Alle vier Plattformen unterstützen die unabhängige Bereitstellungsfähigkeit, unterscheiden sich jedoch darin, wie Sie Änderungen überprüfen. Container Apps und AKS bieten native Traffic-Aufteilung für schrittweise Rollouts. Der App-Service unterstützt prozentbasiertes Verkehrsrouting über Bereitstellungsplätze hinweg. Die Funktion unterstützt Bereitstellungsplätze in Premium- und dedizierten Plänen.

Verteilte Beobachtbarkeit

Eine einzelne Benutzeranforderung kann viele Dienste durchlaufen. Wenn Sie korrelierte Ablaufverfolgungen in der gesamten Anrufkette benötigen, überprüfen Sie, ob das Observability-Tool Ihrer Plattform in Ihre Ablaufverfolgungsstrategie integriert ist. Container-Apps bieten eingebaute Beobachtbarkeit mit Dapr-Ablaufverfolgung. AKS integriert sich in OpenTelemetry- und Open-Source-Ablaufverfolgungstools, mit denen Sie Ihr Ablaufverfolgungs-Back-End (z. B. Jaeger, Zipkin oder Azure Monitor) auswählen können, aber Sie müssen die Erfassungspipeline bereitstellen und konfigurieren. Funktionen und App Service sind mit Application Insights für die End-to-End-Transaktionsablaufverfolgung mit minimaler Konfiguration integriert.

Stellen Sie sicher, dass jeder Dienst in der Komposition Metriken pro Dienst verfügbar macht, z. B. Anforderungsrate, Fehlerrate und Latenz. Anhand dieser Metriken können Sie ermitteln, welcher Dienst beeinträchtigt wird, ohne Protokolle in der gesamten Anrufkette zu korrelieren.

Zustandsverwaltung

In einer Microservices-Architektur besitzt jeder Service typischerweise seine eigenen Daten und externalisiert seinen Zustand zu einer dedizierten Datenbank oder einem dedizierten Cache. Dieses Muster sorgt dafür, dass Dienste unabhängig bereitgestellt werden können, und alle vier Plattformen unterstützen sie gleichermaßen, da der Datenspeicher eine separate Azure-Ressource ist.

Die Plattformen unterscheiden sich, wenn ein Dienst plattformverwaltete Zustandsabstraktionen benötigt, z. B. akteurbasierte Muster, Workflow-Orchestrierung oder dedizierten Speicher pro Instanz:

  • AKS bietet die größte Flexibilität durch persistente Volumes und StatefulSets, die In-Cluster-Datenspeicher und stabile Identitäten pro Instanz unterstützen.

  • Container-Apps unterstützen Volume-Mounts und Dapr-Zustandsverwaltung, einschließlich Dapr-Actors.

  • Funktionen unterstützen zustandsbehaftete Orchestrierungen und Entitäten über dauerhafte Funktionen.

  • Der App Service unterstützt freigegebenen Speicher durch Azure Files-Einbindungen, bietet jedoch keinen Instanzspeicher oder plattformweite Zustandsabstraktionen.

Überlegungen

Diese Überlegungen bilden die Säulen des Azure Well-Architected Framework, einer Reihe von Leitprinzipien, die Sie zur Verbesserung der Qualität eines Workloads verwenden können. Weitere Informationen finden Sie unter Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit trägt dazu bei, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie für Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Zuverlässigkeit.

Bei einer Microservices-Architektur ist das primäre Zuverlässigkeitsrisiko kaskadierender Fehler. Ein fehlerhafter Dienst bewirkt, dass Anrufer Timeouts sammeln und das Problem über die Anrufkette nach außen verteilt wird. Ihre Plattformauswahl wirkt sich darauf aus, wie Sie dieses Risiko mindern.

  • AKS und Container-Apps bieten Integritätsüberprüfungen auf Plattformebene, mit denen fehlerhafte Instanzen erkannt und automatisch aus dem Verkehr gezogen werden.

  • Funktionen versuchen fehlgeschlagene Ausführungen je nach Triggertyp erneut.

Unabhängig von der Plattform sollten Sie Schutzschalter, Richtlinien für Wiederholungen mit Rückoff und Timeouts in Ihrer Dienste-Kommunikation implementieren, um zu verhindern, dass ein einzelner Dienstausfall zu einem systemweiten Ausfall wird.

Stellen Sie jeden Dienst über Verfügbarkeitszonen bereit, um vor Fehlern auf Rechenzentrumsebene zu schützen. Überprüfen Sie in einem gemischten Plattform-Setup, ob alle verwendeten Plattformen die Zonenredundanz für Ihre Bereitstellungsregion unterstützen.

Plattformspezifische Zuverlässigkeitsleitfaden finden Sie in den Abschnitten zur Zuverlässigkeit des Well-Architected Framework-Dienstleitfadens für AKS, Container-Apps und -Funktionen.

Sicherheit

Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Sicherheit.

Microservices erhöhen die Angriffsfläche, da jeder Dienst-zu-Dienst-Aufruf eine Netzwerkgrenze überschreitet. Behandeln Sie den gesamten Interservice-Datenverkehr als nicht vertrauenswürdig, und verschlüsseln Sie ihn über mTLS. AKS unterstützt mTLS über Dienstgitter wie Istio. Container-Apps stellen mTLS über dapr oder umgebungsbasierte Konfiguration bereit. Funktionen und App Service bieten keine mTLS auf Plattformebene. Wenn diese Plattformen Dienste in Ihrer Komposition hosten, erzwingen Sie die Transportsicherheit über HTTPS auf Anwendungsebene, API-Gatewayrichtlinien oder virtuelle Netzwerkisolation.

In einer Zusammensetzung vieler Dienste sollte jeder Dienst sich nur für die benötigten Ressourcen authentifizieren. Vergeben Sie dienstspezifische Identitäten, anstatt eine einzige Identität über die Arbeitslast hinweg zu teilen. Plattformspezifische Mechanismen finden Sie in der Vergleichstabelle in der Zeile "Identität pro Dienst".

Plattformspezifische Sicherheitsleitfaden finden Sie in den Sicherheitsabschnitten der Well-Architected Framework-Diensthandbücher für AKS, Container-Apps und -Funktionen.

Kostenoptimierung

Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Kostenoptimierung.

Eine Microservices-Architektur kann Dutzende von Diensten umfassen, und jeder Dienst verarbeitet unterschiedliche Datenverkehrsvolumen. Ordnen Sie jeden Dienst dem Abrechnungsmodell zu, das seinem Datenverkehrsmuster entspricht. Verbrauchsbasierte Plattformen wie Container-Apps und Azure Functions reduzieren Leerlaufdienste auf Null, jedoch können dedizierte Rechenressourcen wie AKS kostengünstiger sein für Dienste mit anhaltender Last. Bei einer gemischten Plattformkomposition ist die Flexibilität bei der Abrechnung pro Service einer der wichtigsten Kostenvorteile. Berücksichtigen Sie jedoch den Aufwand für die Aufrechterhaltung von separaten Bereitstellungspipelines, Überwachungskonfigurationen und Teamkompetenzen auf allen Plattformen.

Plattformspezifische Kostenleitfaden finden Sie in den Abschnitten zur Kostenoptimierung der Well-Architected Framework-Dienstleitfäden für AKS, Container-Apps und -Funktionen.

Referenzarchitekturen

Schränken Sie Ihre Optionen auf eine oder zwei Plattformen ein, indem Sie die Vergleichskriterien in diesem Artikel anwenden. Führen Sie einen Machbarkeitsnachweis aus, indem Sie eine repräsentative Teilmenge Ihrer Dienste bereitstellen und Interservicekommunikation, Skalierungsverhalten und Bereitstellungsworkflows anhand Ihrer Anforderungen testen. Vergewissern Sie sich, dass die Plattform die betrieblichen Erwartungen Ihres Teams erfüllt, bevor Sie sich für die Produktion verpflichten. Die folgenden Architekturen bieten produktionsbereite Ausgangspunkte:

Nächster Schritt

Entwurf der dienstübergreifenden Kommunikation für Microservices

  • Last updated on