In diesem Artikel werden der Prozess und die Komponenten des Microsoft CSE-Teams (Commercial Software Engineering) zusammengefasst, die zum Erstellen einer Lösung für einen Kunden aus dem Finanzwesen verwendet wurden. Um die Anonymität des Kunden zu wahren, wird die Bank im Artikel als Contoso Bank bezeichnet. Dabei handelt es sich um eine bedeutende internationale Organisation aus dem Finanzdienstleistungsbereich (Financial Services Industry, FSI), die eines ihrer Finanztransaktionssysteme modernisieren wollte.
Aufbau
Laden Sie eine Visio-Datei dieser Architektur herunter.
Die Lösung besteht aus drei Hauptblöcken: Back-End-Dienste, Auslastungstests und Überwachung mit der Autoskalierung für Ereignisse.
Die tatsächlichen Container mit dem Microservices von Contoso wurden manuell über Docker in den Kubernetes-Cluster gepusht. Dieser Cluster umfasst Folgendes:
Azure Red Hat OpenShift (ARO) im Kubernetes/OpenShift Horizontal Pod Autoscaler (HPA) für:
Channel Holder (Kanalhost)
Skalierbarkeit und Leistung für Transaktionssimulationsergebnisse
Azure Kubernetes Services (AKS) für die Autoskalierung des Knotens für den Channel Holder
Das CSE-Team erstellte die anderen Microservices als Stubs, um die eigentlichen Contoso-Microservices von anderen externen Mainframediensten zu isolieren, die von der Lösung über die Azure-Pipelines gepusht wurden.
Workflow
Im Kern stellen die Back-End-Dienste die erforderliche Logik für die EFT-Durchführung bereit:
Ein neuer EFT-Vorgang beginnt mit einer HTTP-Anforderung, die vom Channel Holder-Dienst empfangen wird.
Der Dienst bietet synchrone Antworten auf Anforderungen mithilfe eines Veröffentlichen-Abonnieren-Musters über Azure Cache for Redis und wartet auf eine Antwort vom Back-End.
Die Lösung überprüft diese anfängliche Anforderung mithilfe des EFT-Pilotkennwortdiensts.
Neben Validierungen führt der Dienst auch Datenanreicherung aus. Mithilfe der Datenanreicherung kann das Back-End entscheiden, ob für die Lösung ein Legacy-Microservicesystem oder ein neues System zur Verarbeitung der EFT-Anforderung verwendet werden soll.
Der Channel Holder-Dienst startet dann den asynchronen Flow.
Der Dienst ruft den EFT-Controller auf, einen reaktiven Orchestrator, der einen Transaktionsflow koordiniert. Dies geschieht durch das Erstellen von Befehlen und das Verarbeiten von Ereignissen von anderen Microservices über Azure Event Hubs/Kafka.
Bei einem dieser Dienste handelt es sich um den EFT-Prozessor, der die eigentliche Transaktion aktiviert und die Aus- und Einzahlungsvorgänge ausführt.
Das CSE-Team nutzte KEDA (Kubernetes Event-driven Autoscaling, automatische ereignisgestützte Kubernetes-Skalierung). Dabei handelt es sich um ein Framework, das Anwendungen basierend auf der Auslastung der von der Lösung verarbeiteten Nachrichten automatisch skaliert. In der Lösung wurde es zum Skalieren des EFT-Prozessors verwendet, wenn die Lösung neue EFT-Anforderungen verarbeiten musste.
KEDA wird auf AKS und Azure Container Apps unterstützt
Im nächsten Schritt folgt der Auslastungstest. Azure Load Testing ist ein vollständig verwalteter Auslastungstestdienst, mit dem Sie eine hohe Auslastung generieren können. Der Dienst simuliert den Datenverkehr für Ihre Anwendungen, ohne dass zusätzliche Ressourcen bereitgestellt werden müssen. Azure Load Testing bietet auch die Möglichkeit, ein vorhandenes Apache JMeter-Skript zu verwenden, um einen Lasttest durchzuführen.
Zum Abschluss mussten die Ergebnisse des Auslastungstests, die Infrastruktur und die Anwendungsmetriken über die Überwachung integriert werden.
Das Team korrelierte einen Auslastungstestlauf mit den Nebeneffekten der Verwendung von Microservices auf Speicher- und Containerorchestrierungsebene. Dies ermöglichte einen schnellen Feedbackzyklus für die Anwendungsoptimierung. Prometheus, Grafana und Application Insights in Azure Monitor waren die wichtigsten Komponenten für diese Überwachungs- und Analysefunktionen. Die Autoskalierung der Ereignisse unterstützte die Überprüfung eines Szenarios, in dem Anwendungen basierend auf dem empfangenen Nachrichtenvolumen skaliert werden. Um dieses Verhalten zu implementieren, passte das CSE-Team KEDA so an, dass die Skalierung von Java-Anwendungen unterstützt wird.
Funktionen der Lösung
Die Lösung bietet drei Hauptfunktionen:
Horizontal Pod Autoscaler für den Channel Holder
Automatische Skalierung der Knoten für den Channel Holder
Skalierbarkeit und Leistung für Transaktionssimulationsergebnisse
Horizontal Pod Autoscaler für den Channel Holder
In dieser Lösung verwendete das Team einen Mechanismus mit Kubernetes/OpenShift HPA. HPA skaliert die Anzahl der Pods automatisch basierend auf einer ausgewählten Metrik. Auf diese Weise erhalten Sie einen effizienten Mechanismus zum Auf- und Abskalieren von Containern. Aufgrund der CPU-Bindung der REST-API für den Channel Holder entschied sich das Team für die Verwendung von HPA mit CPU, damit die Dienstreplikate bei neuen EFT-Anforderungen zunehmen können.
Diese Komponente führt einen Dienst namens Channel Holder in Azure Red Hat OpenShift aus. Sie führt Tests der automatischen Skalierung der Pods für diesen Dienst aus. Die Komponente sollte die folgenden Funktionen erfüllen:
Bereitstellen einer lokalen DevOps-Pipeline in Azure für den Channel Holder-Dienst
Bereitstellen der OpenShift-Clusterüberwachung über ein Grafana-Dashboard
Ausführen von Tests zur Auf- und Abskalierung der Pods für den Channel Holder-Dienst
Bereitstellen von Einblicken in den Channel Holder durch Aktivierung der Metrikerfassung (z. B. Verbrauch) mit Prometheus und Grafana
Bereitstellen eines ausführlichen Berichts über die ausgeführten Tests, das Verhalten der Anwendungen und ggf. die angewandten Kafka-Partitionierungsstrategien
Automatische Skalierung der Knoten für den Channel Holder
Zunächst skaliert HPA die Replikate bis zu einem Punkt auf, an dem die Clusterinfrastruktur ausgelastet ist. Anschließend sorgt der Mechanismus zum Ab- und Aufskalieren der Knoten dafür, dass die Anwendungen neue Anforderungen empfangen und verarbeiten. Für diesen Mechanismus verwendete das Team die automatische Skalierung von Kubernetes-Knoten, die das Wachstum des Clusters unterstützt, auch wenn alle Knoten nahe an ihrer vollen Kapazität arbeiteten.
Diese Komponente gilt hauptsächlich für die Ausführung des Channel Holder-Diensts in AKS, um Tests der automatischen Skalierung zu ermöglichen. Sie sollte die folgenden Funktionen erfüllen:
Bereitstellen der AKS-Clusterüberwachung über ein Grafana-Dashboard
Ausführen von Tests der automatischen Skalierung der Knoten für den Channel Holder-Dienst
Bereitstellen von Einblicken in den Channel Holder durch Aktivierung der Metrikerfassung mit Prometheus und Grafana
Bereitstellen eines ausführlichen Berichts über die ausgeführten Tests, das Verhalten der Anwendungen und ggf. die angewandten Kafka-Partitionierungsstrategien
Skalierbarkeit und Leistung für Transaktionssimulationsergebnisse
Mithilfe des Frameworks für die Auslastungstests generierte das CSE-Team eine ausreichende Auslastung, um sowohl HPA als auch die Mechanismen für die automatische Skalierung der Knoten auszulösen. Wenn die Lösung die Komponenten auslöste, wurden Infrastruktur- und Anwendungsmetriken generiert, mit denen das Team die Antwortzeiten für die Skalierung des Channel Holder-Diensts und das Anwendungsverhalten bei hoher Auslastung überprüfen konnte.
Diese Komponente bezieht sich hauptsächlich auf die Ausführung der Dienste für Channel Holder, EFT-Controller und EFT-Prozessor in ARO und AKS. Außerdem führt sie die Tests der automatischen Skalierung von Pods und Knoten sowie Leistungstests für alle Dienste aus. Sie sollte die folgenden Funktionen erfüllen:
Ausführen von Leistungstests für die Microservices, bis diese 2.000 Transaktionen pro Sekunde erreichen oder überschreiten
Ausführen von Tests zur Auf- und Abskalierung von Pods/Knoten über Microservices
Bereitstellen von Einblicken in den Channel Holder durch Aktivierung der Metrikerfassung mit Prometheus und Grafana
Bereitstellen eines ausführlichen Berichts über die ausgeführten Tests, das Verhalten der Anwendungen und die angewandten Kafka-Partitionierungsstrategien
Komponenten
In der folgenden Liste sind die Technologien zusammengefasst, die das CSE-Team zum Erstellen dieser Lösung verwendete:
Azure
Drittanbieter
Back-End-Dienste der Contoso Bank
VS Code ist eine Open-Source-Software.
Szenariodetails
Contoso Bank ist eine bedeutende internationale Organisation aus dem Finanzdienstleistungsbereich (Financial Services Industry, FSI), die eines ihrer Finanztransaktionssysteme modernisieren wollte.
Es sollten nach dem Wunsch der Contoso Bank simulierte und tatsächliche Anwendungen sowie vorhandene Workloads verwendet werden, um die Reaktion der Lösungsinfrastruktur auf Skalierbarkeit und Leistung zu überwachen. Die Lösung musste den Anforderungen des vorhandenen Zahlungssystems entsprechen.
Mögliche Anwendungsfälle
Die Contoso Bank wollte eine Reihe von Simulationen für Folgendes verwenden:
Ermitteln der Auswirkungen der Infrastrukturskalierbarkeit
Ermitteln der Reaktion auf Fehler im vorhandenen Architekturentwurf bestimmter Mainframesoftware.
Bei der vorgeschlagenen Lösung würden funktionale Szenarien in einer virtuellen Anwendung simuliert. Ihr Zweck bestünde darin, die Leistung und Skalierbarkeit der Infrastruktur zu überwachen. Das Ziel dieser Simulationen bestand darin, die Auswirkungen von Fehlern in Workloads des EFT-Systems (Electronic Funds Transfer) auf dem Mainframe zu ermitteln.
Außerdem war es erforderlich, einen reibungslosen DevOps-Übergang vom lokalen Standort zur Cloud vorzuschlagen. Der Übergang musste die Prozesse und Methoden der Bank umfassen und die vorhandenen Tools der Contoso Bank verwenden. Die Verwendung vorhandener Technologien würde den Aufwand der Entwickler für das Erlernen neuer Fähigkeiten verringern. Während des Übergangs sollte die Contoso Bank bei der Überprüfung aktueller und zukünftiger Entwurfsentscheidungen unterstützt werden. Darüber hinaus sollte der Übergang Gewissheit schaffen, dass Azure als Umgebung robust genug ist, um die neuen verteilten Systeme zu hosten.
Überlegungen
Erfolgskriterien
Das Contoso-Team und das CSE-Team definierten die folgenden Erfolgskriterien für dieses Engagement:
Allgemeine Kriterien
Die folgenden allgemeinen Punkte wurden von der Contoso Bank als Erfolgskriterien für alle Komponenten betrachtet:
Schaffen der Möglichkeit für das technische Team von Contoso, die digitale Transformation und die Cloudeinführung umzusetzen Das CSE-Team hatte folgende Aufgaben:
Bereitstellen der erforderlichen Tools und Prozesse in Azure
Zeigen, wie das technische Team von Contoso die vorhandenen Tools weiterhin nutzen kann
Zu jeder Komponente gibt es ein Dokument, das Folgendes abdeckt:
Ergebnisse von Skalierbarkeits- und Leistungstests
Die bei jedem Test berücksichtigten Parameter und Metriken
Sämtliche Code- oder Infrastrukturänderungen, die bei den einzelnen Tests erforderlich waren
Erkenntnisse aus Leistungsanpassungen und Leistungsoptimierung sowie Parameter, die bei den einzelnen Tests berücksichtigt wurden
Erkenntnisse und Leitfäden zu Kafka-Partitionierungsstrategien
Allgemeine Empfehlungen und Leitfäden zur Architektur auf der Grundlage der Erkenntnisse aus den Ergebnissen
Kriterien für Ergebnisse
| Metrik | Wert (Bereich) |
|---|---|
| Möglichkeit zum Ausführen von Tests der automatischen Skalierung von Pods für den Channel Holder | Ziel: Das System erstellt automatisch ein neues Podreplikat für den Channel Holder, wenn 50 % CPU-Auslastung erreicht wurden. |
| Möglichkeit zum Ausführen von Tests der automatischen Skalierung von Knoten basierend auf dem Channel Holder | Ziel: Das System erstellt neue Kubernetes-Knoten aufgrund von Ressourceneinschränkungen bei Pods (z. B. CPU-Auslastung). Kubernetes beschränkt die Anzahl der Knoten, die vom System erstellt werden können. Das Knotenlimit beträgt drei Knoten. |
| Möglichkeit der Ausführung von Tests der automatischen Skalierung von Pods/Knoten sowie Leistungstests in einer EFT-Simulation | Ziel: Das System erstellt automatisch neue Podreplikate für alle Dienste. Die Replikation erfolgt nach Erreichen einer CPU-Auslastung von 50 % und der Erstellung eines neuen Kubernetes-Knotens basierend auf den CPU-Ressourceneinschränkungen. Die Lösung muss 2.000 Transaktionen pro Sekunde unterstützen. |
Technische Lösung
Die vom Team bereitgestellte Lösung enthielt übergreifende Bedenken sowie spezielle Implementierungen, um die gewünschten Ergebnisse zu erzielen. Es mussten auch einige Entwurfseinschränkungen eingehalten werden, die den Richtlinien der Contoso Bank geschuldet waren.
Es muss darauf hingewiesen werden, dass Contoso die Verwendung von Azure Kubernetes Service zum Testen von Szenarien für die automatische Skalierung von Knoten aufgrund einer Featureeinschränkung in Azure Red Hat OpenShift 3.11 anforderte.
Es gab eine Reihe von Entwurfseinschränkungen, die das CSE-Team berücksichtigen musste:
Aufgrund interner Anforderungen forderte die Contoso Bank die Verwendung der folgenden Technologien:
OpenShift 3.11 als Plattform für die Containerorchestrierung
Java und Spring Boot für die Entwicklung von Microservices
Kafka als Ereignisstreamingplattform mit dem Feature „Confluent Schema Registry“
Die Lösung sollte cloudunabhängig sein.
Die DevOps- und Überwachungstools mussten denen entsprechen, die von Contoso bereits in der lokalen Entwicklungsumgebung verwendet wurden.
Die Lösung durfte den Quellcode, den Contoso in der lokalen Umgebung hostet, nicht für externe Umgebungen freigeben. Die Richtlinien von Contoso erlauben nur das Verschieben von Containerimages aus der lokalen Umgebung nach Azure.
Außerdem schränken die Richtlinien von Contoso die Möglichkeit ein, eine CI-Pipeline (Constant Integration) zwischen der lokalen Umgebungen und einer Cloud einzusetzen. Contoso stellte den gesamten in der lokalen Umgebung gehosteten Quellcode manuell als Containerimages in Azure Container Registry bereit. Die Bereitstellung auf lokaler Seite lag in der Verantwortung von Contoso.
Das simulierte Szenario für Tests musste eine Teilmenge der Mainframe-EFT-Workloads als Flowverweis verwenden.
Die Contoso Bank musste alle HPA- und Leistungstests in ARO ausführen.
Übergreifende Bedenken bei der Lösung
Nachrichtenstreaming
Das CSE-Team entschied sich für die Verwendung von Apache Kafka als verteilte Nachrichtenstreamingplattform für seine Microservices. Um eine bessere Skalierbarkeit zu erzielen, zog das Team eine Consumergruppe pro Microservice in Erwägung. In dieser Konfiguration ist jede Instanz eines Microservice eine Skalierungseinheit zum Aufteilen und Parallelisieren der Ereignisverarbeitung.
Mithilfe einer Formel wurde die geschätzte optimale Anzahl von Partitionen pro Thema berechnet, um den geschätzten Durchsatz zu unterstützen. Weitere Informationen zu dieser Formel finden Sie unter Auswählen der Anzahl von Themen oder Partitionen in einem Kafka-Cluster.
CI/CD-Geschwindigkeit
Für DevOps nutzte die Contoso Bank bereits eine lokale Instanz von GitLab für ihr Coderepository. Sie entwickelte CI/CD-Pipelines (Continuous Integration/Continuos Delivery) für Entwicklungsumgebungen mit einer benutzerdefinierten Jenkins-basierten Lösung, die intern entwickelt wurde. Dies bot jedoch kein optimales DevOps-Verfahren.
Das CSE-Team stellte zur Verbesserung der DevOps-Abläufe für Contoso Azure Pipelines in Azure DevOps bereit, um den Anwendungslebenszyklus zu verwalten. Die CI-Pipeline wird bei jedem Pull Request ausgeführt, während die CD-Pipeline bei jedem erfolgreichen Merge im Mainbranch ausgeführt wird. Jedes Mitglied des Entwicklungsteams war für die Verwaltung der Repositorys und Pipelines für jeden Dienst zuständig. Außerdem musste das Team Code Reviews, Komponententests und Linting (statische Quellcodeanalyse) erzwingen.
Das CSE-Team stellte Dienste parallel ohne Abhängigkeiten untereinander bereit und setzte wie von der Contoso Bank gefordert Jenkins-Agents ein.
Es integrierte Prometheus als Teil der Lösung, um die Dienste und den Cluster zu überwachen. Neben dem Generieren aussagekräftiger Daten für die Lösung kann die Contoso Bank in Zukunft Prometheus verwenden, um die Produkte basierend auf der täglichen Nutzung zu verbessern. Diese Metriken werden auf einem Grafana-Dashboard dargestellt.
Rolloutstrategie
Das Team führte die Lösung über Azure Pipelines in der Entwicklungsumgebung ein. Jeder Dienst verfügte über eine eigene Build- und Bereitstellungspipeline. Dabei wurde eine Bereitstellungspipeline verwendet, die manuell ausgelöst werden konnte. Sie sollte eine vollständige Bereitstellung der Umgebung und der Container in einer bestimmten Branchversion erzwingen.
Das CSE-Team erstellte Releasebranches, mit denen stabile Versionen für die Bereitstellung generiert wurden. Das Zusammenführen von Branches im Mainbranch erfolgt nur, wenn das Team sicher ist, dass die Lösung für die Bereitstellung fertig ist. Eine Rollbackstrategie, die über die Bereitstellung der letzten stabilen Version hinausgeht, war bei diesem Engagement nicht vorgesehen. Für jede Phase waren Genehmigungsstufen vorgesehen. Auf jeder Stufe war eine Genehmigung der Bereitstellung erforderlich.
Notfallwiederherstellung
Die Lösung verwendet Terraform-Skripts und Azure Pipelines für alle Dienste. Bei einem Notfall kann die Contoso Bank die gesamte Umgebung mithilfe von Terraform-Skripts oder durch erneutes Ausführen der Releasepipeline erneut erstellen. Terraform erkennt, dass sich die Umgebung geändert hat, und erstellt sie neu. Die Lösung stellt die Infrastruktur bedarfsgesteuert dynamisch in Azure bereit und löscht sie. Die Speicherkonten nutzen zonenredundanten Speicher (ZRS). Eine Sicherungsstrategie war bei diesem Engagement nicht vorgesehen.
Sicherheit und Datenschutz
Sämtliche Containerimages werden in einer privaten Registrierung (Azure Container Registry) gespeichert.
Die Lösung verwendet ARO- und AKS-Geheimnisse, um vertrauliche Daten wie Verbindungszeichenfolgen und Schlüssel in Pods einzufügen.
Der Zugriff auf Kubernetes-API-Server erfordert eine Authentifizierung über Microsoft Entra ID für ARO und AKS.
Für den Zugriff auf Jenkins ist eine Authentifizierung über Microsoft Entra ID erforderlich.
Zusammenfassung
Am Ende des Projekts konnte das CSE-Team die folgenden Erkenntnisse weitergeben:
Ergebnisse der Lösung und des Engagements
Das Team stellte ein hohes Maß an Kompatibilität zwischen AKS und ARO für die Bereitstellung von Diensten fest.
Application Insights ohne Code vereinfacht das Gewinnen von Einblicken und die Zusammenarbeit bei der Cloudeinführung über Lift & Shift-Migrationsvorgänge.
Auslastungstests sind ein wichtiger Bestandteil von umfangreichen Lösungen. Sie erfordern eine vorherige Analyse und Planung, bei der die Besonderheiten von Microservices berücksichtigt werden müssen.
Das Potenzial von Auslastungstests für das Erkennen von Nebeneffekten von Microservices wird von Kunden häufig unterschätzt.
Das Erstellen einer Testumgebung erfordert möglicherweise eine Strategie zur Infrastrukturbereinigung, um unnötige Infrastrukturkosten zu vermeiden.
Wichtige Erkenntnisse
Es ist möglich, Anwendungen reibungslos von ARO zu AKS zu migrieren.
Das Feature zur automatischen Skalierung von Knoten steht in Red Hat OpenShift 3.11 nicht zur Verfügung. Diese Version wurde jedoch bei diesem Engagement verwendet. Daher führte das CSE-Team Testszenarien für die automatische Skalierung von Knoten über AKS aus.
Beim Ablauf des Lebenszyklus eines Produkts sind möglicherweise kreative Anpassungen erforderlich. Die Vorbereitungsphase spielt eine wichtige Rolle für eine erfolgreiche Bereitstellung der Lösung durch das Team.
Zum Zeitpunkt der Erstellung dieses Artikels hat das CSE-Team eine Lösung für Lasttests entwickelt, die ACI und JMeter in eine Azure DevOps Pipeline integriert. Azure Load Testing ist seitdem als vollständig verwalteter Lasttest-Service verfügbar, ohne dass zusätzliche Rechenressourcen bereitgestellt werden müssen.
Das Team empfiehlt die Verwendung von Azure Event Hubs für Kafka, aber für die Contoso Bank war die Schemaregistrierung ein wichtiges Feature. Um im angeforderten Zeitrahmen der Contoso Bank zu bleiben, musste das Team die Verwendung einer Schemaregistrierung in einer anderen Instanz von AKS in Erwägung ziehen.
Das Kafka-Protokoll mit Schemaregistrierung wurde vom Event Hubs-Scaler in KEDA nicht unterstützt.
Nächste Schritte
Automatisches Skalieren von Java-Anwendungen mit KEDA und Azure Event Hubs: Beispiel für KEDA für Java
Muster: Saga: Informationen zum Saga-Muster auf Microservices.io
Zugehörige Ressourcen
Weitere Details zu den Prozessen und Technologien, die zum Erstellen dieser Lösung verwendet wurden, finden Sie in den folgenden Artikeln: