Dieser Artikel enthält Anleitungen zur Implementierung des zuverlässigen Web-App-Musters. Dieses Muster beschreibt, wie Web-Apps für die Cloudmigration geändert werden (Umzug auf eine neue Plattform). Es bietet präskriptive Anleitungen zur Architektur, Konfiguration und zum Code, die den Prinzipien des Well-Architected Framework entsprechen.
Gründe für das Muster für zuverlässige Web-Apps für Java
Das zuverlässige Web-App-Muster besteht aus einer Reihe von Grundsätzen und Implementierungstechniken, die festlegen, wie Sie Web-Apps bei der Migration in die Cloud auf eine neue Plattform umziehen. Es führt nur die Codeupdates durch, die für eine erfolgreiche Ausführung in der Cloud benötigt werden. In den folgenden Anleitungen wird durchgehend die Referenzimplementierung als Beispiel verwendet und der Umstieg auf eine neue Plattform des fiktiven Unternehmens Contoso Fiber verfolgt, um den geschäftlichen Kontext für Ihren geschäftlichen Weg zu schaffen. Vor der Implementierung des zuverlässigen Web-App-Musters für Java verfügte Contoso Fiber über ein monolithisches, lokales Kundenkontoverwaltungssystem (CAMS), das das Spring Boot Framework verwendet hat.
Tipp
Es gibt eine Referenzimplementierung (Beispiel-App) des zuverlässigen Web-App-Musters. Sie stellt den Endzustand der Implementierung der zuverlässigen Web-App dar. Es handelt sich um eine Web-App mit Produktionsniveau, die alle in diesem Artikel beschriebenen Code-, Architektur- und Konfigurationsupdates enthält. Stellen Sie die Referenzimplementierung bereit, um die Implementierung des zuverlässigen Web-App-Musters anzuleiten.
Implementieren des zuverlässigen Web-App-Musters
Dieser Artikel enthält Architektur-, Code- und Konfigurationsanleitungen zum Implementieren des zuverlässigen Web-App-Musters. Verwenden Sie die folgenden Links, um zu den benötigten Anleitungen zu navigieren:
- Geschäftskontext: Passen Sie diese Anleitung an Ihren geschäftlichen Kontext an und erfahren Sie, wie Sie unmittelbare und langfristige Ziele definieren, die die Entscheidungen für eine Neuausrichtung der Plattform beeinflussen.
- Architekturanleitung: Erfahren Sie, wie Sie die richtigen Clouddienste auswählen und eine Architektur entwerfen, die Ihren Geschäftsanforderungen entspricht.
- Codeanleitung: Implementieren Sie drei Entwurfsmuster, um die Zuverlässigkeit und Leistungsfähigkeit Ihrer Web-App in der Cloud zu verbessern: Retry, Circuit-Breaker, and Cache-Aside.
- Konfigurationsanleitung: Konfigurieren Sie die Authentifizierung und Autorisierung, verwaltete Identitäten, rechteisierte Umgebungen, Infrastruktur als Code und die Überwachung.
Geschäftskontext
Der erste Schritt beim Umzug einer Web-App auf eine andere Plattform besteht darin, Ihre Geschäftsziele zu definieren. Sie sollten sofortige Ziele festlegen, z. B. Ziele auf Serviceebene und Kostenoptimierungsziele sowie zukünftige Ziele für Ihre Webanwendung. Diese Ziele sind für Ihre Wahl von Clouddiensten und die Architektur Ihrer Webanwendung in der Cloud relevant. Definieren Sie ein Ziel-SLO für Ihre Web-App, z. B. 99,9 % Betriebszeit. Berechnen Sie die zusammengesetzte SLA für alle Dienste, die sich auf die Verfügbarkeit Ihrer Web-App auswirken.
Beispiel: Contoso Fiber wollte seine lokale Customer Account Management System (CAMS)-Web-App erweitern, um weitere Regionen zu erreichen. Um die erhöhte Auslastung der Web-App zu bewältigen, hat das Unternehmen die folgenden Ziele festgelegt:
- Anwendung kostengünstiger, aber hochwertiger Codeänderungen
- Erreichen eines Servicelevel-Ziels (Service Level Objective, SLO) von 99,9 %
- Einführung von DevOps-Verfahren
- Entwicklung kostenoptimierter Umgebungen
- Verbesserung von Zuverlässigkeit und Sicherheit
Contoso Fiber hat festgestellt, dass seine lokale Infrastruktur keine kostengünstige Lösung für die Skalierung der Anwendung darstellte. Das Unternehmen kam zu dem Schluss, dass die Migration ihrer CAMS-Webanwendung zu Azure die kostengünstigste Möglichkeit war, die unmittelbaren und zukünftigen Ziele zu erreichen.
Anleitung zur Architektur
Das zuverlässige Web-App-Muster verfügt über einige wesentliche Architekturelemente. Sie benötigen DNS zum Verwalten der Endpunktauflösung, einer Webanwendungsfirewall zum Blockieren des bösartigen HTTP-Datenverkehrs und einen Load Balancer zum Schutz und Weiterleiten eingehender Benutzeranforderungen. Die Anwendungsplattform hostet Ihren Web-App-Code und führt Aufrufe an alle Back-End-Dienste über private Endpunkte in einem virtuellen Netzwerk aus. Ein Tool zur Anwendungsleistungsüberwachung erfasst Metriken und Protokolle, um Ihre Web-App zu verstehen.
Abbildung 1. Wesentliche Architekturelemente des zuverlässigen Web-App-Musters
Entwerfen der Architektur
Entwerfen Sie Ihre Infrastruktur, um Ihre Wiederherstellungsmetriken zu unterstützen, z. B. Wiederherstellungszeitvorgabe (Recovery Time Objective, RTO) und Wiederherstellungspunktvorgabe (Recovery Point Objective, RPO). Das RTO wirkt sich auf die Verfügbarkeit aus und muss Ihre SLO unterstützen. Ermitteln Sie eine Wiederherstellungspunktvorgabe (RPO), und konfigurieren Sie die Datenredundanz, um das RPO zu erfüllen.
Entscheiden Sie sich für die Zuverlässigkeit der Infrastruktur. Ermitteln Sie, wie viele Verfügbarkeitszonen und Regionen Sie benötigen, um Ihre Verfügbarkeitsanforderungen zu erfüllen. Fügen Sie Verfügbarkeitszonen und Regionen hinzu, bis die zusammengesetzte SLA Ihre SLO erfüllt. Das zuverlässige Web-App-Muster unterstützt mehrere Regionen für eine aktive oder passive Konfiguration. Die Referenzimplementierung verwendet beispielsweise eine aktiv-passive Konfiguration, um eine SLO von 99,9 % zu erfüllen.
Konfigurieren Sie für eine Web-App mit mehreren Regionen Ihren Lastenausgleich so, dass der Datenverkehr an die zweite Region weitergeleitet wird, um je nach Geschäftsbedarf eine aktive oder passive Konfiguration zu unterstützen. Die beiden Regionen benötigen dieselben Dienste, mit der Ausnahme, dass eine Region über ein virtuelles Hub-Netzwerk verfügt, das die Regionen verbindet. Verwenden Sie eine Hub-and-Spoke-Netzwerktopologie, um freigegebene Ressourcen wie eine Netzwerkfirewall zu zentralisieren und gemeinsam zu nutzen. Wenn Sie über virtuelle Computer verfügen, fügen Sie dem virtuellen Hubnetzwerk einen Bastionhost hinzu, um sie sicher zu verwalten (siehe Abbildung 2).
Abbildung 2. Das zuverlässige Web-App-Muster mit einer zweiten Region und einer Hub-and-Spoke-Topologie
Wählen Sie eine Netzwerktopologie aus. Wählen Sie die richtige Netzwerktopologie für Ihre Web- und Netzwerkanforderungen aus. Wenn Sie mehrere virtuelle Netzwerke haben möchten, verwenden Sie eine Hub- und Spoke-Netzwerktopologie. Sie bietet Kosten-, Verwaltungs- und Sicherheitsvorteile mit Hybridkonnektivitätsoptionen zu lokalen und virtuellen Netzwerken.
Wählen Sie die richtigen Azure-Dienste aus.
Wenn Sie eine Web-App zur Cloud migrieren, sollten Sie Azure-Dienste auswählen, die Ihren geschäftlichen Anforderungen entsprechen und an den aktuellen Funktionen der lokalen Web-App ausgerichtet sind. Die Ausrichtung trägt zur Minimierung des Aufwands für die Verlagerung zu einer neuen Plattform bei. Sie könnten beispielsweise Dienste verwenden, mit denen Sie das Datenbankmodul beibehalten und vorhandene Middleware und Frameworks unterstützen können. In den folgenden Abschnitten finden Sie Anleitungen für die Auswahl der richtigen Azure-Dienste für Ihre Web-App.
Beispiel: Vor der Migration zur Cloud handelt es sich bei der CAMS-Web-App von Contoso Fiber um eine lokale, monolithische Java-Web-App. Es war eine Spring Boot-App mit einer PostgreSQL-Datenbank. Die Web-App erfüllte die Aufgabe einer branchenspezifischen Support-App. Sie ist für Mitarbeiter zugänglich. Die Mitarbeitenden von Contoso Fiber verwalten über die Anwendung Supportfälle ihrer Kunden. Die Web-App litt unter häufigen Problemen hinsichtlich Skalierbarkeit und Funktionsbereitstellung. Dieser Ausgangspunkt, die geschäftlichen Ziele und das SLO lagen der Auswahl der Dienste zugrunde.
Anwendungsplattform: Verwenden Sie Azure App Service als Ihre Anwendungsplattform. Contoso Fiber hat sich aus den folgenden Gründen für Azure App Service als Anwendungsplattform entschieden:
- Natürlicher Verlauf: Contoso Fiber hatte die Spring Boot-Datei
jar
auf dem lokalen Server bereitgestellt und wollte den Umfang der Architekturänderungen für dieses Bereitstellungsmodell minimieren. App Service stellt eine robuste Unterstützung für die Ausführung von Spring Boot-Apps bereit. Daher war die Verwendung von App Service ein natürlicher Schritt für Contoso Fiber. Azure Container Apps ist auch eine attraktive Alternative für diese App. Weitere Informationen finden Sie unter Was ist Azure Spring Apps? und Java auf Azure Container Apps – Übersicht. - Hoher SLA-Wert: Es bietet einen hohen SLA-Wert, der die Anforderungen für die Produktionsumgebung erfüllt.
- Reduzierung des Verwaltungsaufwands: Es handelt sich um eine vollständig verwaltete Hostinglösung.
- Fähigkeit zur Containerisierung: App Service funktioniert mit privaten Containerimageregistrierungen wie Azure Container Registry. Contoso Fiber kann diese Registrierungen verwenden, um die Web-App in der Zukunft zu containerisieren.
- Automatische Skalierung:Die Web-App kann basierend auf Benutzerdatenverkehr schnell hoch- und herunterskaliert sowie auf- und abskaliert werden.
- Natürlicher Verlauf: Contoso Fiber hatte die Spring Boot-Datei
Identitätsverwaltung: Verwenden Sie Microsoft Entra ID als Ihre Identitäts- und Zugriffsverwaltungslösung. Contoso Fiber hat sich aus den folgenden Gründen für Microsoft Entra ID entschieden:
- Authentifizierung und Autorisierung: Die Anwendung muss Mitarbeitende eines Callcenters authentifizieren und autorisieren.
- Skalierbarkeit: Die Lösung kann skaliert werden, um größere Szenarien zu unterstützen.
- Steuerung der Identitäten der Benutzer*innen: Mitarbeitende des Callcenters können ihre vorhandenen Unternehmensidentitäten verwenden.
- Unterstützung des Autorisierungsprotokolls: Die Lösung unterstützt OAuth 2.0 für verwaltete Identitäten.
Datenbank: Verwenden Sie einen Dienst, mit dem Sie dasselbe Datenbankmodul beibehalten können. Verwenden Sie die Entscheidungsstruktur für Datenspeicher Contoso Fiber hat sich aus den folgenden Gründen für Azure Database for PostgreSQL und die Option mit flexiblem Server entschieden:
- Zuverlässigkeit: Das Bereitstellungsmodell für flexible Server unterstützt zonenredundante Hochverfügbarkeit über mehrere Verfügbarkeitszonen hinweg. Diese Konfiguration verwaltet einen betriebsbereiten Standbyserver in einer anderen Verfügbarkeitszone innerhalb derselben Azure-Region. Die Konfiguration repliziert Daten synchron auf den Standbyserver.
- Regionenübergreifende Replikation: Es ist ein Lesereplikatfeature vorhanden, mit dem Sie Daten asynchron in eine schreibgeschützte Replikatdatenbank in einer anderen Region replizieren können.
- Leistung: Es werden vorhersagbare Leistung und intelligente Optimierung geboten, um die Leistung Ihrer Datenbank mithilfe von realen Nutzungsdaten zu verbessern.
- Geringerer Verwaltungsaufwand: Es handelt sich um einen vollständig verwalteten Azure-Dienst, der die Verwaltungsverpflichtungen reduziert.
- Migrationsunterstützung: Die Datenbankmigration aus lokalen Einzelserver-PostgreSQL-Datenbanken wird unterstützt. Das Unternehmen kann das Migrationstool verwenden, um die Migration zu vereinfachen.
- Konsistenz mit lokalen Konfigurationen: Es werden verschiedene Communityversionen von PostgreSQL unterstützt, einschließlich der Version, die Contoso Fiber derzeit verwendet.
- Resilienz. Die Flexible Server-Bereitstellung erstellt automatisch Serversicherungen und speichert diese in zonenredundantem Speicher innerhalb der gleichen Region. Das Unternehmen kann die Datenbank zu jedem Zeitpunkt innerhalb des Aufbewahrungszeitraums der Sicherung wiederherstellen. Die Funktionalität für Sicherung und Wiederherstellung bietet ein besseres RPO (d. h. akzeptablen Umfang des Datenverlusts), als Contoso Fiber lokal erzielen könnte.
Anwendungsleistungsüberwachung: Verwenden Sie Application Insights, um die Telemetrie in Ihrer Anwendung zu analysieren. Contoso Fiber hat sich aus den folgenden Gründen für Application Insights entschieden:
- Integration in Azure Monitor: Die Lösung bietet die beste Integration in Azure Monitor.
- Anomalieerkennung: Die Lösung erkennt automatisch Leistungsanomalien.
- Fehlerbehebung: Die Lösung unterstützt Sie bei der Diagnose von Problemen in der ausgeführten App.
- Überwachung: Die Lösung sammelt Informationen zur App-Nutzung der Benutzer*innen und ermöglicht die mühelose Nachverfolgung benutzerdefinierter Ereignisse.
- Transparenzlücke: Die lokale Lösung verfügte über keine Lösung für die Überwachung der Anwendungsleistung. Application Insights bietet eine einfache Integration in die Anwendungsplattform und in den Code.
Cache: Legen Sie fest, ob der Web-App-Architektur ein Zwischenspeicher hinzugefügt werden soll. Azure Cache for Redis ist die primäre Zwischenspeicherlösung von Azure. Es handelt sich um einen verwalteten In-Memory-Datenspeicher auf der Basis der Redis-Software. Contoso Fiber hat sich aus den folgenden Gründen für Azure Cache for Redis entschieden:
- Geschwindigkeit und Volumen: Azure Cache for Redis bietet einen hohen Datendurchsatz und Lesevorgänge mit geringer Latenz für häufig abgerufene Daten, die sich nur langsam ändern.
- Vielfältige Unterstützung: Es ist ein konsolidierter Zwischenspeicher, der von allen Instanzen der Web-App verwendet werden kann.
- Externer Datenspeicher. Von den lokalen Anwendungsservern wurde eine VM-lokale Zwischenspeicherung durchgeführt. Bei diesem Setup wurden häufig verwendete Daten nicht ausgelagert, und Daten konnten nicht ungültig gemacht werden.
- Nicht fixierte Sitzungen: Der Zwischenspeicher ermöglicht der Web-App die Externalisierung des Sitzungsstatus und die Verwendung nicht fixierter Sitzungen. Die meisten lokalen Java-Web-Apps verwenden die clientseitige Zwischenspeicherung im Arbeitsspeicher. Das clientseitige Zwischenspeichern im Arbeitsspeicher skaliert nicht gut und erhöht den Arbeitsspeicherbedarf auf dem Host. Mit der Verwendung von Azure Cache for Redis verfügt Contoso Fiber jetzt über einen vollständig verwalteten, skalierbaren Zwischenspeicherdienst, um die Skalierbarkeit und Leistung seiner Anwendungen zu verbessern. Contoso Fiber verwendete ein Framework für die Zwischenspeicherabstraktion (Spring Cache). Daher waren nur minimale Konfigurationsänderungen erforderlich, um den Zwischenspeicheranbieter zu wechseln. Dadurch konnten sie von einem Ehcache-Anbieter zum Redis-Anbieter wechseln.
Load Balancer: Webanwendungen, die PaaS-Lösungen verwenden, sollten Azure Front Door, Azure Application Gateway oder beide basierend auf Web-App-Architektur und -Anforderungen verwenden. Verwenden Sie die Entscheidungsstruktur des Load Balancer , um das richtige Lastenausgleichsmodul auszuwählen. Contoso Fiber benötigte einen Layer-7-Load Balancer, der den Datenverkehr durch mehrere Regionen leiten kann. Contoso Fiber benötigte eine multiregionale Web-App, um das SLO von 99,9 % zu erreichen. Contoso Fiber hat sich aus den folgenden Gründen für Azure Front Door entschieden:
- Globaler Lastenausgleich: Es handelt sich um einen Layer-7-Load Balancer, der den Datenverkehr durch mehrere Regionen leiten kann.
- Web Application Firewall: Der Load Balancer kann nativ in Azure Web Application Firewall integriert werden.
- Flexibilität beim Routing: Der Load Balancer ermöglicht dem Anwendungsteam die Konfiguration der Anforderungen an den eingehenden Datenverkehr, um zukünftige Änderungen in der Anwendung zu unterstützen.
- Beschleunigung des Datenverkehrs: Der Load Balancer verwendet Anycast, um den nächstgelegenen Azure Point of Presence (PoP) zu erreichen und die schnellste Route zur Web-App zu finden.
- Angepasste Domänen: Der Load Balancer unterstützt angepasste Domänennamen mit flexibler Domänenvalidierung.
- Integritätstests: Die Anwendung benötigt eine intelligente Überwachung mittels Integritätstests. Azure Front Door ermittelt anhand der Ergebnisse des Tests den besten Ursprung für die Weiterleitung Ihrer Clientanforderungen.
- Unterstützung der Überwachung: Der Load Balancer unterstützt integrierte Berichte mit einem zentralen Dashboard für Front Door und Sicherheitsmuster. Sie können Warnungen konfigurieren, die in Azure Monitor integriert werden. Die Anwendung kann jede Anforderung sowie fehlerhafte Integritätstests protokollieren.
- DDoS-Schutz: Der Load Balancer verfügt über integrierten DDoS-Schutz für Layer 3 und 4.
- Netzwerk zur Bereitstellung von Inhalten: Der Load Balancer ermöglicht Contoso Fiber die Verwendung eines Netzwerk zur Bereitstellung von Inhalten. Das Netzwerk zur Bereitstellung von Inhalten ermöglicht die Beschleunigung der Website.
Web Application Firewall: Verwenden Sie Azure Web Application Firewall, um zentralisierten Schutz vor gängigen Exploits und Sicherheitsrisiken für Ihre Webanwendungen bereitzustellen. Contoso Fiber hat sich aus den folgenden Gründen für Azure Web Application Firewall entschieden:
- Globaler Schutz: Web Application Firewall bietet einen verbesserten globalen Schutz für die Web-App, ohne dass die Leistung beeinträchtigt wird.
- Botnet-Schutz: Dem Team stehen Überwachungs- und Konfigurationseinstellungen zur Behandlung von Sicherheitsbedenken im Zusammenhang mit Botnets zur Verfügung.
- Parität mit der lokalen Umgebung: Die lokale Lösung wurde hinter einer Webanwendungsfirewall ausgeführt, die von der IT verwaltet wurde.
- Benutzerfreundlichkeit: Web Application Firewall kann in Azure Front Door integriert werden.
Geheimnisverwaltung: Verwenden Sie Azure Key Vault, wenn Sie geheime Schlüssel in Azure verwalten müssen. Contoso Fiber hat sich aus den folgenden Gründen für Key Vault entschieden:
- Verschlüsselung: Key Vault unterstützt die Verschlüsselung im Ruhezustand und während der Übertragung.
- Unterstützung verwalteter Identitäten: Die Anwendungsdienste können verwaltete Identitäten verwenden, um auf den Geheimnisspeicher zuzugreifen.
- Überwachung und Protokollierung: Key Vault unterstützt den Überwachungszugriff und generiert Warnungen, wenn gespeicherte Geheimnisse geändert werden.
- Integration: Key Vault bietet eine native Integration mit dem Azure-Konfigurationsspeicher (App Configuration) und der Webhostingplattform (App Service).
Endpunktsicherheit: Verwenden Sie Azure Private Link, um den Zugriff auf Platform-as-a-Service-Lösungen über einen privaten Endpunkt in Ihrem virtuellen Netzwerk bereitzustellen. Datenverkehr zwischen Ihrem virtuellen Netzwerk und dem Dienst wird über das Microsoft-Backbone-Netzwerk übertragen. Contoso Fiber hat sich aus den folgenden Gründen für Private Link entschieden:
- Verbesserte Sicherheit für die Kommunikation: Private Link ermöglicht den privaten Zugriff der Anwendung auf Dienste auf der Azure-Plattform und reduziert die Netzwerkausdehnung von Datenspeichern zum Schutz vor Datenlecks.
- Minimaler Aufwand: Die privaten Endpunkte unterstützen die von der Web-App verwendete Web-App- und Datenbankplattform. Beide Plattformen spiegeln vorhandene lokale Konfigurationen, sodass nur minimale Änderungen erforderlich sind.
Netzwerksicherheit: Verwenden Sie Azure Firewall, um ein- und ausgehenden Datenverkehr auf Netzwerkebene zu steuern. Verwenden Sie Azure Bastion für die sichere Verbindung zu virtuellen Computern, ohne dass RDP/SSH-Ports verfügbar werden. Contoso Fiber führte eine Hub-Spoke-Netzwerktopologie ein und wollte gemeinsam genutzte Netzwerksicherheitsdienste im Hub platzieren. Azure Firewall verbessert die Sicherheit durch die Überprüfung des gesamten ausgehenden Datenverkehrs aus den Speichen, um die Netzwerksicherheit zu erhöhen. Contoso Fiber benötigte Azure Bastion für sichere Bereitstellungen über einen Bastion Host im DevOps-Subnetz.
Anleitung zum Code
Um eine Web-App erfolgreich in die Cloud zu verschieben, müssen Sie Ihren Web-App-Code mit den Wiederholungs-, Circuit-Breaker- und Cache-Aside-Mustern aktualisieren.
Abbildung 3. Rolle der Entwurfsmuster.
Jedes Entwurfsmuster bietet Workloadentwurfsvorteile, die sich an einer von mehreren Säulen des Well-Architected Framework orientieren. Hier ist eine Übersicht über die Muster, die Sie implementieren sollten:
Wiederholungsmuster: Das Wiederholungsmuster behandelt vorübergehende Fehler durch Wiederholungsvorgänge, die zeitweise fehlschlagen können. Implementieren Sie dieses Muster für alle ausgehenden Aufrufe an andere Azure-Dienste.
Circuit Breaker-Muster: Das Circuit Breaker-Muster verhindert, verhindert, dass eine Anwendung Vorgänge erneut versucht, die nicht vorübergehend sind. Implementieren Sie dieses Muster in allen ausgehenden Aufrufen an andere Azure-Dienste.
Cache-Aside-Muster: Das Cache-Aside-Muster fügt Daten häufiger zu einem Cache hinzu und ruft sie häufiger aus einem Cache ab als ein Datenspeicher. Implementieren Sie dieses Muster für Anforderungen an die Datenbank.
Entwurfsmuster | Zuverlässigkeit (Reliability, RE) | Sicherheit (Security, SE) | Kostenoptimierung (Cost Optimization, CO) | Erstklassige Betriebsprozesse (Operational Excellence, OE) | Leistungseffizienz (Performance Efficiency, PE) | Unterstützung von WAF-Prinzipien |
---|---|---|---|---|---|---|
Wiederholungsmuster | ✔ | RE:07 | ||||
Circuit-Breaker-Muster | ✔ | ✔ | RE:03 RE:07 PE:07 PE:11 |
|||
Cache-Aside-Muster | ✔ | ✔ | RE:05 PE:08 PE:12 |
Implementieren des Wiederholungsmusters
Fügen Sie ihrem Anwendungscode das Wiederholungsmuster hinzu, um temporäre Dienstunterbrechungen zu beheben. Diese Störungen werden als vorübergehende Fehler bezeichnet. Vorübergehende Fehler werden in der Regel innerhalb von Sekunden behoben. Mit dem Wiederholungsmuster können Sie fehlgeschlagene Anforderungen erneut senden. Außerdem können Sie die Anforderungsverzögerungen und die Anzahl der Versuche konfigurieren, bevor ein Fehler akzeptiert wird.
Verwenden Sie Resilience4j, eine einfache Fehlertoleranzbibliothek, um das Wiederholungsmuster in Java zu implementieren. Beispiel: Die Referenzimplementierung fügt das Wiederholungsmuster hinzu, indem die Methode listServicePlans des Dienstplan-Controllers mit Wiederholungsanmerkungen versehen wird. Der Code ruft den Aufruf einer Liste von Dienstplänen aus der Datenbank erneut auf, wenn der anfängliche Aufruf fehlschlägt. Die Referenzimplementierung konfiguriert die Wiederholungsrichtlinie, einschließlich der maximalen Anzahl der Versuche, der Wartezeiten und bei welchen Ausnahmen Wiederholungsversuche ausgeführt werden sollten. Die Wiederholungsrichtlinie ist in application.properties
konfiguriert.
@GetMapping("/list")
@PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
@CircuitBreaker(name = SERVICE_PLAN)
@Retry(name = SERVICE_PLAN)
public String listServicePlans(Model model) {
List<serviceplandto> servicePlans = planService.getServicePlans();
model.addAttribute("servicePlans", servicePlans);
return "pages/plans/list";
}
Implementieren des Trennschaltermusters
Verwenden Sie das Circuit Breaker-Muster, um Dienstunterbrechungen zu behandeln, bei denen es sich nicht um vorübergehende Fehler handelt. Das Wiederholungsmuster verhindert, dass eine Anwendung kontinuierlich versucht, auf einen nicht reagierenden Dienst zuzugreifen. Es gibt die Anwendung frei und vermeidet die Veröffentlichung von CPU-Zyklen, damit die Leistungsintegrität der Anwendung für Endbenutzer erhalten bleibt.
Verwenden Sie Spring Circuit Breaker und die Resilience4j-Dokumentation, um das Circuit-Breaker-Muster zu implementieren. Beispiel: Die Referenzimplementierung implementiert das Trennschaltermuster, indem Methoden mit dem Circuit Breaker-Attribut versehen werden.
Impelementieren des Cache-Aside-Musters
Fügen Sie Ihrer Web-App das Cache-Aside-Muster hinzu, um die Speicherdatenverwaltung zu verbessern. Das Muster weist der Anwendung die Verantwortung für die Verarbeitung von Datenanforderungen zu und stellt Konsistenz zwischen dem Zwischenspeicher und einem persistenten Speicher her, z. B. einer Datenbank. Dies verkürzt die Reaktionszeiten, verbessert den Durchsatz und reduziert die Notwendigkeit für eine weitere Skalierung. Außerdem wird die Auslastung des primären Datenspeichers reduziert, die Zuverlässigkeit und Kostenoptimierung verbessert. Befolgen Sie die folgenden Empfehlungen, um das Cache-Aside-Muster zu implementieren:
Konfigurieren Sie eine Anwendung für die Verwendung von Cache. Um die Zwischenspeicherung zu aktivieren, fügen Sie das Paket
spring-boot-starter-cache
in Ihrerpom.xml
-Datei als Abhängigkeit hinzu. Dieses Paket stellt Standardkonfigurationen für den Redis-Cache bereit.Zwischenspeichern von Daten mit hohem Bedarf. Wenden Sie das Cache-Aside-Muster auf Daten mit hohem Bedarf an, um ihre Effektivität zu verstärken. Verwenden Sie Azure Monitor, um die CPU, den Arbeitsspeicher und den Speicher der Datenbank nachzuverfolgen. Anhand dieser Metriken können Sie bestimmen, ob Sie nach dem Anwenden des Cache-Aside-Musters eine kleinere Datenbank-SKU verwenden können. Um bestimmte Daten in Ihrem Code zwischenzuspeichern, fügen Sie die
@Cacheable
-Anmerkung hinzu. Diese Anmerkung teilt Spring mit, welche Methoden ihre Ergebnisse zwischengespeichert haben sollen.Cachedaten auf dem neuesten Stand halten. Planen Sie regelmäßige Aktualisierungen des Zwischenspeichers, um die Daten mit den neuesten Änderungen in der Datenbank zu synchronisieren. Ermitteln Sie die optimale Aktualisierungsrate basierend auf Datenvolatilität und Anforderungen der Benutzer*innen. Dieses Verfahren stellt sicher, dass die Anwendung das cachefremde Muster verwendet, um sowohl einen schnellen Zugriff als auch aktuelle Informationen bereitzustellen. Die Standardcacheeinstellungen passen möglicherweise nicht zu Ihrer Webanwendung. Sie können diese Einstellungen in der
application.properties
-Datei oder den Umgebungsvariablen anpassen. Beispielsweise können Sie denspring.cache.redis.time-to-live
-Wert (ausgedrückt in Millisekunden) ändern, um zu steuern, wie lange Daten im Cache verbleiben sollen, bevor sie gelöscht wird.Sicherstellen der Datenkonsistenz. Implementieren Sie Mechanismen zum Aktualisieren des Zwischenspeichers direkt nach jedem Schreibvorgang in der Datenbank. Verwenden Sie ereignisgesteuerte Updates oder dedizierte Datenverwaltungsklassen, um die Kohärenz des Zwischenspeichers sicherzustellen. Die konsistente Synchronisierung des Zwischenspeichers mit Datenbankänderungen ist für das cachefremde Muster von zentraler Bedeutung.
Anleitung zur Konfiguration
In den folgenden Abschnitten finden Sie Anleitungen zum Implementieren der Konfigurationsupdates. Jeder Abschnitt richtet sich an einer oder mehreren Säulen des Well-Architected Frameworks aus.
Konfiguration | Zuverlässigkeit (Reliability, RE) | Sicherheit (Security, SE) | Kostenoptimierung (Cost Optimization, CO) | Erstklassige Betriebsprozesse (Operational Excellence, OE) | Leistungseffizienz (Performance Efficiency, PE) | Unterstützung von WAF-Prinzipien |
---|---|---|---|---|---|---|
Konfigurieren der Benutzerauthentifizierung & -autorisierung | ✔ | ✔ | SE:05 OE:10 |
|||
Implementieren verwalteter Identitäten | ✔ | ✔ | SE:05 OE:10 |
|||
Umgebungen in der richtigen Größe | ✔ | CO:05 CO:06 |
||||
Implementieren automatischer Skalierung | ✔ | ✔ | ✔ | RE:06 CO:12 PE:05 |
||
Automatische Ressourcenbereitstellung | ✔ | OE:05 | ||||
Implementieren von Überwachung | ✔ | ✔ | ✔ | OE:07 PE:04 |
Konfigurieren der Benutzerauthentifizierung und -autorisierung
Wenn Sie Webanwendungen zu Azure migrieren, konfigurieren Sie die Benutzerauthentifizierungs- und Autorisierungsmechanismen. Befolgen Sie die nachstehenden Empfehlungen:
Verwenden Sie eine Identitätsplattform. Verwenden Sie die Microsoft Identity-Plattform, um die Web-App-Authentifizierung einzurichten. Diese Plattform unterstützt Anwendungen, die ein einzelnes Microsoft Entra-Verzeichnis, mehrere Microsoft Entra-Verzeichnisse aus verschiedenen Organisationen und Microsoft-Identitäten oder soziale Konten verwenden.
Der Spring Boot Starter für Microsoft Entra ID optimiert diesen Prozess und nutzt Spring Security und Spring Boot für die einfache Einrichtung. Die Lösung stellt verschiedene Authentifizierungsflows, eine automatische Tokenverwaltung, anpassbare Autorisierungsrichtlinien und Funktionen für die Integration mit Spring Cloud-Komponenten bereit. Dies ermöglicht die einfache Integration von Microsoft Entra ID und OAuth 2.0 in Spring Boot-Anwendungen, ohne dass eine manuelle Bibliotheks- oder Einstellungskonfiguration erforderlich ist.
Beispiel: Die Referenzimplementierung verwendet die Microsoft-Identitätsplattform (Microsoft Entra ID) als Identitätsanbieter für die Web-App. Sie verwendet die OAuth 2.0-Autorisierungscode-Genehmigung für die Anmeldung eines Benutzers bzw. einer Benutzerin mit einem Microsoft Entra-Konto. Der folgende XML-Codeausschnitt definiert die zwei erforderlichen Abhängigkeiten des OAuth 2.0-Autorisierungscode-Genehmigungsflows. Die Abhängigkeit
com.azure.spring: spring-cloud-azure-starter-active-directory
ermöglicht die Microsoft Entra-Authentifizierung und -Autorisierung in einer Spring Boot-Anwendung. Die Abhängigkeitorg.springframework.boot: spring-boot-starter-oauth2-client
unterstützt die OAuth 2.0-Authentifizierung und -Autorisierung in einer Spring Boot-Anwendung.<dependency> <groupid>com.azure.spring</groupid> <artifactid>spring-cloud-azure-starter-active-directory</artifactid> </dependency> <dependency> <groupid>org.springframework.boot</groupid> <artifactid>spring-boot-starter-oauth2-client</artifactid> </dependency>
Erstellen Sie eine -App-Registrierung. Microsoft Entra ID erfordert eine Anwendungsregistrierung im primären Mandanten. Die Anwendungsregistrierung stellt sicher, dass die Benutzer, die Zugriff auf die Web-App erhalten, über Identitäten im primären Mandanten verfügen. Die Referenzimplementierung verwendet beispielsweise Terraform, um eine Microsoft Entra ID-App-Registrierung zusammen mit einer App-spezifischen Account Manager-Rolle zu erstellen.
resource "azuread_application" "app_registration" { display_name = "${azurecaf_name.app_service.result}-app" owners = [data.azuread_client_config.current.object_id] sign_in_audience = "AzureADMyOrg" # single tenant app_role { allowed_member_types = ["User"] description = "Account Managers" display_name = "Account Manager" enabled = true id = random_uuid.account_manager_role_id.result value = "AccountManager" } }
Erzwingen Sie die Autorisierung in der Anwendung. Verwenden Sie die rollenbasierte Zugriffssteuerung (RBAC), um Anwendungsrollen die geringsten Berechtigungen zuzuweisen. Definieren Sie bestimmte Rollen für verschiedene Benutzeraktionen, um Überlappungen zu vermeiden und Klarheit zu gewährleisten. Ordnen Sie Benutzer den entsprechenden Rollen zu, und stellen Sie sicher, dass sie nur Zugriff auf erforderliche Ressourcen und Aktionen haben. Konfigurieren Sie Spring Security für die Verwendung von Spring Boot Starter für Microsoft Entra ID. Diese Bibliothek ermöglicht die Integration mit Microsoft Entra ID und hilft Ihnen sicherzustellen, dass Benutzer*innen sicher authentifiziert werden. Das Konfigurieren und Aktivieren der Microsoft Authentication Library (MSAL) bietet Zugriff auf weitere Sicherheitsfeatures. Zu diesen Features gehören Tokenzwischenspeicherung und automatische Tokenaktualisierung.
Beispiel: Die Referenzimplementierung erstellt App-Rollen, die die Arten von Benutzerrollen im Kontoverwaltungssystem von Contoso Fiber widerspiegeln. Rollen werden während der Autorisierung in Berechtigungen übersetzt. Beispiele für App-spezifische Rollen in CAMS sind Konto-Manager*in, Supportmitarbeiter*in auf Stufe 1 und Mitarbeiter*in im Außendienst. Die Rolle „Konto-Manager*in“ besitzt Berechtigungen zum Hinzufügen neuer App-Benutzer*innen und Kund*innen. Außendienstmitarbeiter*innen können Supporttickets erstellen. Das Attribut
PreAuthorize
schränkt den Zugriff auf bestimmte Rollen ein.@GetMapping("/new") @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')") public String newAccount(Model model) { if (model.getAttribute("account") == null) { List<ServicePlan> servicePlans = accountService.findAllServicePlans(); ServicePlan defaultServicePlan = servicePlans.stream().filter(sp -> sp.getIsDefault() == true).findFirst().orElse(null); NewAccountRequest accountFormData = new NewAccountRequest(); accountFormData.setSelectedServicePlanId(defaultServicePlan.getId()); model.addAttribute("account", accountFormData); model.addAttribute("servicePlans", servicePlans); } model.addAttribute("servicePlans", accountService.findAllServicePlans()); return "pages/account/new"; } ...
Für die Integration mit Microsoft Entra-ID verwendet die Referenzimplementierung den Codegenehmigungsflow für die OAuth 2.0-Autorisierung. Dieser Flow ermöglicht Benutzer*innen die Anmeldung mit einem Microsoft-Konto. Der folgende Codeausschnitt zeigt, wie Sie die
SecurityFilterChain
konfigurieren können, um Microsoft Entra ID für die Authentifizierung und Autorisierung zu konfigurieren.@Configuration(proxyBeanMethods = false) @EnableWebSecurity @EnableMethodSecurity public class AadOAuth2LoginSecurityConfig { @Bean SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.apply(AadWebApplicationHttpSecurityConfigurer.aadWebApplication()) .and() .authorizeHttpRequests() .requestMatchers(EndpointRequest.to("health")).permitAll() .anyRequest().authenticated() .and() .logout(logout -> logout .deleteCookies("JSESSIONID", "XSRF-TOKEN") .clearAuthentication(true) .invalidateHttpSession(true)); return http.build(); } } ...
Ziehen Sie temporären Zugriff auf den Speicher vor. Verwenden Sie temporäre Berechtigungen, um sich vor unbefugtem Zugriff und Verstößen, wie Shared Access Signatures (SASs) zu schützen. Verwenden Sie SASs für die Benutzerdelegierung, um bei der Gewährung eines temporären Zugriffs die Sicherheit zu maximieren. Dies ist die einzige SAS, die Microsoft Entra ID-Anmeldeinformationen verwendet und keinen permanenten Speicherkontoschlüssel erfordert.
Erzwingen Sie die Autorisierung in Azure. Verwenden Sie Azure RBAC, um Benutzeridentitäten am wenigsten Berechtigungen zuzuweisen. Azure RBAC bestimmt, auf welche Azure-Ressourcen die Identitäten einen Zugriff haben, welche Aktionen sie für diese Ressourcen ausführen und auf welche Bereiche sie zugreifen können.
Vermeiden Sie dauerhaft erhöhte Berechtigungen. Verwenden Sie Microsoft Entra Privileged Identity Management, um Just-in-Time-Zugriff für privilegierte Vorgänge zu gewähren. Entwickler benötigen beispielsweise häufig Zugriff auf die Administratorebene, um Datenbanken zu erstellen/zu löschen, Tabellenschemas zu ändern und Benutzerberechtigungen zu ändern. Mit einem Just-in-Time-Zugriff erhalten Benutzeridentiäten temporäre Berechtigungen für die Ausführung privilegierter Aufgaben.
Implementieren verwalteter Identitäten
Verwenden Sie verwaltete Identitäten für alle Azure-Dienste, die verwaltete Identitäten unterstützen. Eine verwaltete Identität ermöglicht Azure-Ressourcen (Workloadidentitäten), sich bei anderen Azure-Diensten zu authentifizieren und mit anderen Azure-Diensten zu interagieren, ohne Anmeldeinformationen zu verwalten. Hybrid- und Legacysysteme können lokale Authentifizierungslösungen beibehalten, um die Migration zu vereinfachen, sollten aber so schnell wie möglich zu verwalteten Identitäten wechseln. Befolgen Sie die folgenden Empfehlungen, um verwaltete Identitäten zu implementieren:
Wählen Sie den richtigen Typ der verwalteten Identität aus. Ziehen Sie vom Benutzer zugewiesene verwaltete Identitäten vor, wenn Sie über zwei oder mehr Azure-Ressourcen verfügen, die denselben Satz von Berechtigungen benötigen. Diese Einrichtung ist effizienter als das Erstellen von vom System zugewiesenen verwalteten Identitäten für jede dieser Ressourcen und das Zuweisen der gleichen Berechtigungen für alle. Verwenden Sie andernfalls vom System zugewiesene verwaltete Identitäten.
Konfigurieren Sie die geringsten Berechtigungen. Verwenden Sie Azure RBAC, um nur die Berechtigungen zu gewähren, die für die Ausführung kritisch sind, z. B. CRUD-Aktionen in Datenbanken oder den Zugriff auf Geheimnisse. Die Berechtigungen für Workloadidentitäten sind persistent. Sie können Workloadidentitäten daher keine kurzfristigen oder Just-in-Time-Berechtigungen gewähren. Wenn Azure RBAC ein bestimmtes Szenario nicht abdeckt, ergänzen Sie Azure RBAC mit Zugriffsrichtlinien auf der Azure-Dienstebene.
Sichern Sie verbleibende geheime Schlüssel. Speichern Sie alle verbleibenden geheimen Schlüssel in Azure Key Vault. Laden Sie Geheimnisse aus Key Vault beim Starten der Anwendung, nicht während jeder einzelnen HTTP-Anforderung. Der Hochfrequenzzugriff innerhalb von HTTP-Anforderungen kann die Transaktionsgrenzen von Key Vault überschreiten. Speichern Sie Anwendungskonfigurationen in Azure App Configuration.
Umgebungen in der richtigen Größe
Verwenden Sie die Leistungsstufen (SKUs) von Azure-Diensten, die die Anforderungen jeder Umgebung erfüllen, ohne dass sie übermäßig groß sind. Um Ihre Umgebungen auf die richtige Größe zu bringen, befolgen Sie diese Empfehlungen:
Schätzen der Kosten Mit dem Azure-Preisrechner können Sie die Kosten für jede Umgebung abschätzen.
Kostenoptimierung in Produktionsumgebungen. Produktionsumgebungen benötigen SKUs, die den Vereinbarungen zum Servicelevel (Service Level Agreements, SLA), Features und der Skalierung gerecht werden, die für die Produktion erforderlich sind. Überwachen Sie die Ressourcenauslastung kontinuierlich, und passen Sie SKUs an die tatsächlichen Leistungsanforderungen an.
Kostenoptimierung von Vorproduktionsumgebungen. Vorproduktionsumgebungen sollten Ressourcen mit niedrigeren Kosten verwenden, nicht benötigte Dienste deaktivieren und Rabatte wie Azure Dev/Test-Preise anwenden. Stellen Sie sicher, dass Vorproduktionsumgebungen der Produktion ausreichend ähnlich sind, um Risiken zu vermeiden. Diese Balance sorgt dafür, dass Tests wirksam bleiben, ohne unnötige Kosten entstehen zu lassen.
Definieren Sie SKUs mithilfe der Infrastruktur als Code (IaC). Implementieren Sie IaC, um die richtigen SKUs basierend auf der Umgebung dynamisch auszuwählen und bereitzustellen. Dieser Ansatz verbessert die Konsistenz und vereinfacht die Verwaltung.
Die Referenzimplementierung verfügt über einen optionalen Parameter, der verschiedene SKUs bereitstellt. Ein Umgebungsparameter weist die Terraform-Vorlage an, Entwicklungs-SKUs auszuwählen.
azd env set APP_ENVIRONMENT prod
Implementieren automatischer Skalierung
Durch die automatische Skalierung wird sichergestellt, dass eine Web-App stabil, reaktionsfähig bleibt und dynamische Workloads effizient verarbeiten kann. Befolgen Sie die folgenden Empfehlungen, um die automatische Skalierung zu implementieren:
Automatisieren Sie die horizontale Skalierung. Verwenden Sie Azure-Autoskalierung AutoScale, um die horizontale Skalierung in Produktionsumgebungen zu automatisieren. Konfigurieren Sie automatische Skalierungsregeln, um basierend auf wichtigen Leistungsmetriken zu skalieren, damit Ihre Anwendung unterschiedliche Lasten verarbeiten kann.
Verfeinern von Skalierungstriggern. Beginnen Sie mit der CPU-Auslastung als ersten Skalierungsauslöser, wenn Sie mit den Skalierungsanforderungen Ihrer Anwendung nicht vertraut sind. Verfeinern Sie Ihre Skalierungstrigger, um weitere Metriken wie RAM, Netzwerkdurchsatz und Datenträger-E/A einzuschließen. Das Ziel besteht darin, das Verhalten Ihrer Webanwendung für eine bessere Leistung anzupassen.
Stellen Sie einen Skalierungspuffer bereit. Stellen Sie Ihre Skalierungsschwellen so ein, dass sie vor Erreichen der maximalen Kapazität ausgelöst werden. Konfigurieren Sie die Skalierung beispielsweise so, dass sie bei einer CPU-Auslastung von 85 % erfolgt, anstatt zu warten, bis sie 100 % erreicht. Dieser proaktive Ansatz trägt dazu bei, die Leistung aufrechtzuerhalten und potenzielle Engpässe zu vermeiden.
Automatische Ressourcenbereitstellung
Verwenden Sie die Automatisierung, um Azure-Ressourcen und -Code in allen Umgebungen bereitzustellen und zu aktualisieren. Befolgen Sie die nachstehenden Empfehlungen:
Verwenden Sie Infrastructure-as-Code. Stellen Sie Infrastructure-as-Code über CI/CD-Pipelines (Continuous Integration und Continuous Delivery) bereit. Azure verfügt über vorgefertigte Vorlagen für Bicep, ARM (JSON) und Terraform für jede Azure-Ressource.
Verwenden SIe eine Pipeline für Continuous Integration (CI) bzw. Continuous Deployment (CD) Verwenden Sie eine CI/CD-Pipeline, um Code aus der Quellcodeverwaltung in Ihren verschiedenen Umgebungen bereitzustellen, z. B. Test, Staging und Produktion. Nutzen Sie Azure-Pipelines, wenn Sie mit Azure DevOps- oder GitHub-Aktionen für GitHub-Projekte arbeiten.
Integrieren Sie Komponententests. Priorisieren Sie die Ausführung und Übergabe aller Komponententests innerhalb Ihrer Pipeline, bevor Sie eine Bereitstellung für App Services durchführen. Integrieren Sie Codequalitäts- und Abdeckungstools wie SonarQube, um eine umfassende Testabdeckung zu erzielen.
Verwenden Sie ein Simulationsframework. Verwenden Sie Simulationsframeworks für Tests mit externen Endpunkten. Mit diesen Frameworks können Sie simulierte Endpunkte erstellen. Auf diese Weise müssen Sie keine echten externen Endpunkte konfigurieren und können einheitliche Testbedingungen in allen Umgebungen sicherstellen.
Führen Sie Sicherheitsüberprüfungen durch. Verwenden Sie statische Anwendungssicherheitstests (SAST), um Sicherheitsfehler und Codierungsfehler im Quellcode zu finden. Führen Sie außerdem eine Softwarekompositionsanalyse (SCA) durch, um Bibliotheken und Komponenten von Drittanbietern auf Sicherheitsrisiken zu untersuchen. Tools für diese Analysen sind direkt in GitHub und Azure DevOps integriert.
Konfigurieren der Überwachung
Implementieren Sie die Anwendungs- und Plattformüberwachung, um die betriebliche Exzellenz und Leistungsfähigkeit Ihrer Web-App zu verbessern. Befolgen Sie die folgenden Empfehlungen, um die Überwachung zu implementieren:
Sammeln Sie Anwendungstelemetriedaten. Verwenden Sie die die automatische Instrumentierung in Azure Application Insights, um Telemetriedaten der Anwendung zu sammeln, z. B. Anforderungsdurchsatz, durchschnittliche Anforderungsdauer, Fehler und Abhängigkeitsüberwachung, ohne Codeänderungen. Spring Boot registriert mehrere Kernmetriken in Application Insights, z. B. Java Virtual Machine (JVM), CPU, Tomcat und andere. Application Insights sammelt automatisch aus Protokollierungsframeworks wie Log4j und Logback. Die Referenzimplementierung verwendet beispielsweise Application Insights, die als Teil der
app_settings
-Konfiguration von App Service über Terraform aktiviert sind. (siehe folgenden Code)app_settings = { APPLICATIONINSIGHTS_CONNECTION_STRING = var.app_insights_connection_string ApplicationInsightsAgent_EXTENSION_VERSION = "~3" ... }
Weitere Informationen finden Sie unter:
Erstellen Sie benutzerdefinierte Anwendungsmetriken. Implementieren Sie codebasierte Instrumentierung, um benutzerdefinierte Anwendungstelemetrie zu erfassen, indem Sie das Application Insights SDK und dessen API hinzufügen.
Überwachen Sie die Plattform. Aktivieren Sie die Diagnose für alle unterstützten Dienste, und senden Sie Diagnosen an dasselbe Ziel wie die Anwendungsprotokolle für die Korrelation. Azure-Dienste erstellen Plattformprotokolle automatisch, speichern sie jedoch nur, wenn Sie die Diagnose aktivieren. Aktivieren Sie Diagnoseeinstellungen für jeden Dienst, der Diagnose unterstützt. Die Referenzimplementierung verwendet Terraform, um die Azure-Diagnose für alle unterstützten Dienste zu aktivieren. Mit dem folgenden Terraform-Code werden die Diagnoseeinstellungen für App Service konfiguriert.
# Configure Diagnostic Settings for App Service resource "azurerm_monitor_diagnostic_setting" "app_service_diagnostic" { name = "app-service-diagnostic-settings" target_resource_id = azurerm_linux_web_app.application.id log_analytics_workspace_id = var.log_analytics_workspace_id #log_analytics_destination_type = "AzureDiagnostics" enabled_log { category_group = "allLogs" } metric { category = "AllMetrics" enabled = true } }
Bereitstellen der Referenzimplementierung
Die Referenzimplementierung führt Entwickler durch eine simulierte Migration von einer lokalen Java-Anwendung zu Azure, wobei die erforderlichen Änderungen während der ersten Einführungsphase hervorgehoben werden. In diesem Beispiel wird eine CAMS-Webanwendung (Customer Account Management System) für das fiktive Unternehmen Contoso Fiber verwendet. Contoso Fiber hat die folgenden Ziele für ihre Webanwendung festgelegt:
- Implementieren kostengünstiger, aber hochwertiger Codeänderungen
- Erreichen eines Servicelevel-Ziels (Service Level Objective, SLO) von 99,9 %
- Einführung von DevOps-Verfahren
- Entwicklung kostenoptimierter Umgebungen
- Verbesserung von Zuverlässigkeit und Sicherheit
Contoso Fiber hat festgestellt, dass seine lokale Infrastruktur keine kostengünstige Lösung für das Erreichen dieser Ziele darstellte. Das Unternehmen kam zu dem Schluss, dass die Migration ihrer CAMS-Webanwendung zu Azure die kostengünstigste Möglichkeit war, die unmittelbaren und zukünftigen Ziele zu erreichen. Die folgende Architektur stellt den Endzustand der Implementierung des zuverlässigen Web-App-Musters von Contoso Fiber dar.
Abbildung 4: Architektur der Referenzimplementierung: Laden Sie eine Visio-Datei dieser Architektur herunter.