Circuit Breaker-Pattern

Das Circuit-Breaker-Muster hilft, Fehler zu behandeln, für deren Behebung unterschiedlich viel Zeit benötigt wird, wenn eine Anwendung eine Verbindung zu einem Remotedienst oder einer Ressource herstellt. Ein Schaltkreisschalter blockiert vorübergehend den Zugriff auf einen fehlerhaften Dienst, nachdem fehler erkannt wurden. Diese Aktion verhindert wiederholte erfolglose Versuche, damit das System effektiv wiederhergestellt werden kann. Dieses Muster kann die Stabilität und Resilienz einer Anwendung verbessern.

Kontext und Problem

In einer verteilten Umgebung können Aufrufe von Remoteressourcen und -diensten aufgrund vorübergehender Fehler fehlschlagen. Vorübergehende Fehler umfassen überkommissionierte oder vorübergehend nicht verfügbare Ressourcen, langsame Netzwerkverbindungen oder Timeouts. Diese Fehler korrigieren sich in der Regel nach kurzer Zeit. Um diese Fehler zu verwalten, sollten Sie eine Cloudanwendung so entwerfen, dass sie eine Strategie wie das Wiederholungsmuster verwendet.

Unvorhergesehene Ereignisse können Fehler verursachen, deren Behebung länger dauert. Diese Fehler können im Schweregrad von einem teilweisen Verbindungsverlust bis zu einem vollständigen Dienstausfall reichen. In diesen Situationen sollte eine Anwendung nicht kontinuierlich einen Vorgang wiederholen, der unwahrscheinlich ist, dass er erfolgreich ist. Stattdessen sollte die Anwendung den fehlgeschlagenen Vorgang schnell erkennen und den Fehler entsprechend behandeln.

Wenn ein Dienst ausgelastet ist, kann ein Fehler in einem Teil des Systems zu kaskadierenden Fehlern führen. Sie können beispielsweise einen Vorgang konfigurieren, der einen Dienst aufruft, um ein Timeout zu implementieren. Wenn der Dienst innerhalb dieses Zeitraums nicht reagiert, antwortet der Vorgang mit einer Fehlermeldung.

Diese Strategie kann jedoch gleichzeitige Anforderungen an denselben Vorgang blockieren, bis der Timeoutzeitraum abläuft. Diese blockierten Anforderungen enthalten möglicherweise wichtige Systemressourcen, z. B. Arbeitsspeicher, Threads und Datenbankverbindungen. Dieses Problem kann Ressourcen ausschöpfen, was möglicherweise andere nicht zusammenhängende Teile des Systems fehlschlägt, die dieselben Ressourcen verwenden müssen.

In diesen Situationen sollte ein Vorgang sofort fehlschlagen und nur versuchen, den Dienst aufzurufen, wenn er wahrscheinlich erfolgreich ist. Um dieses Problem zu beheben, legen Sie einen kürzeren Timeout fest. Stellen Sie jedoch sicher, dass das Timeout lang genug ist, damit der Vorgang den größten Teil der Zeit erfolgreich ist.

Lösung

Das Schaltkreistrennmuster verhindert, dass eine Anwendung wiederholt versucht, einen Vorgang auszuführen, der wahrscheinlich fehlschlägt. Mit diesem Muster kann die Anwendung weiterhin ausgeführt werden, ohne darauf zu warten, dass der Fehler behoben wird oder ohne unnötige CPU-Zyklen darauf zu verwenden festzustellen, ob der Fehler dauerhaft ist. Das Schaltkreisbrechermuster ermöglicht es einer Anwendung auch zu erkennen, wann der Fehler aufgelöst wird. Wenn der Fehler behoben ist, kann die Anwendung versuchen, den Vorgang erneut aufzurufen.

Hinweis

Das "Circuit Breaker"-Muster dient einem anderen Zweck als der Retry-Mechanismus. Das Wiederholungsmuster ermöglicht es einer Anwendung, einen Vorgang erneut auszuführen, wobei erwartet wird, dass er letztendlich erfolgreich ist. Das Schaltkreistrennmuster verhindert, dass eine Anwendung einen Vorgang ausführt, der wahrscheinlich fehlschlägt. Eine Anwendung kann diese beiden Muster kombinieren, indem sie das Wiederholungsmuster verwendet, um einen Vorgang über einen Trennschalter aufzurufen. Die Wiederholungslogik sollte jedoch alle Ausnahmen berücksichtigen, die der Schaltkreistrennschalter zurückgibt, und die Wiederholungsversuche beenden, wenn der Schaltkreisschalter angibt, dass ein Fehler nicht vorübergehend ist.

Ein Trennschalter fungiert als Proxy für Vorgänge, bei denen möglicherweise Fehler auftreten. Der Proxy sollte die Anzahl der letzten Fehler überwachen und anhand dieser Informationen entscheiden, ob der Vorgang fortgesetzt oder sofort eine Ausnahme zurückgegeben werden soll.

Sie können den Proxy als Zustandsautomat implementieren, der die folgenden Zustände enthält. Diese Zustände imitieren die Funktionalität eines Elektrischen Schaltkreisschalters:

• Geschlossen: Die Anforderung aus der Anwendung wird an den Vorgang weitergeleitet. Der Proxy hält die Anzahl der jüngsten Fehler fest. Wenn der Aufruf des Vorgangs nicht erfolgreich ist, erhöht der Proxy diese Anzahl. Wenn die Anzahl der letzten Fehler einen angegebenen Schwellenwert innerhalb eines bestimmten Zeitraums überschreitet, wird der Proxy in den Zustand "Öffnen" versetzt und ein Timeout-Timer gestartet. Wenn der Timer abläuft, wird der Proxy in den Halb-Offen-Zustand versetzt.

  Hinweis

  Während des Timeouts versucht das System, das Problem zu beheben, das den Fehler verursacht hat, bevor die Anwendung den Vorgang erneut versuchen kann.

• Offen: Die Anforderung der Anwendung schlägt sofort fehl, und eine Ausnahme wird an die Anwendung zurückgegeben.

• Halb geöffnet: Eine begrenzte Anzahl von Anforderungen aus der Anwendung darf passieren und den Vorgang aufrufen. Wenn diese Anforderungen erfolgreich sind, geht der Schaltkreisschalter davon aus, dass der Fehler, der den Fehler verursacht hat, behoben ist, und der Schaltkreisschalter in den geschlossenen Zustand wechselt. Der Fehlerindikator wird zurückgesetzt. Wenn eine Anforderung fehlschlägt, geht der Schutzschalter davon aus, dass der Fehler weiterhin vorhanden ist, sodass er in den Offen-Zustand zurückgesetzt wird. Es startet den Timeout-Timer neu, damit sich das System von dem Fehler erholen kann.

  Hinweis

  Der Half-Open-Zustand verhindert, dass ein wiederhergestellter Dienst plötzlich mit Anforderungen überflutet wird. Wenn ein Dienst wiederhergestellt wird, kann er möglicherweise ein begrenztes Volumen von Anforderungen unterstützen, bis die Wiederherstellung abgeschlossen ist. Doch während die Wiederherstellung läuft, kann eine Flut von Arbeiten dazu führen, dass der Dienst eine Zeitüberschreitung erleidet oder erneut ausfällt.

Das folgende Diagramm zeigt die Zählvorgänge für jeden Status.

Das Diagramm zeigt drei Abschnitte, die als geschlossen, halb geöffnet und geöffnet gekennzeichnet sind. Der geschlossene Zustand enthält die Aktion zum Zurücksetzen des Fehlerzählers. Wenn der Vorgang erfolgreich ist, wird ein Ergebnis zurückgegeben, andernfalls gibt der Inkrementfehlerzähler einen Fehler zurück. Der halboffene Zustand beinhaltet die Aktion zum Zurücksetzen des Erfolgszählers. Wenn der Vorgang erfolgreich ist, gibt der Inkrementierungserfolgsindikator ein Ergebnis zurück, andernfalls wird ein Fehler zurückgegeben. Der offene Zustand beinhaltet die Aktionen zum Starten des Timeout-Timers und zur Rückgabe eines Fehlers. Ein Pfeil vom geschlossenen zum geöffneten Zustand gibt an, dass der Fehlerschwellenwert erreicht ist. Ein Pfeil vom geöffneten bis zum halb geöffneten Zustand gibt an, dass der Timeouttimer abgelaufen ist. Ein Pfeil vom halb geöffneten zum geschlossenen Zustand zeigt an, dass der Erfolgsanzahl-Schwellenwert erreicht ist. Ein Pfeil vom halboffenen zum offenen Zustand zeigt an, dass der Vorgang fehlgeschlagen ist.

Der Fehlerindikator für den Zustand "Geschlossen " ist zeitbasiert. Sie wird in regelmäßigen Abständen automatisch zurückgesetzt. Dieses Design verhindert, dass der Schaltkreisschalter in den Zustand "Öffnen " wechselt, wenn gelegentlich Fehler auftreten. Der Fehlerschwellenwert löst den Zustand "Öffnen" nur aus, wenn während eines angegebenen Intervalls eine bestimmte Anzahl von Fehlern auftritt.

Der Erfolgsindikator für den Halböffentlichen Zustand zeichnet die Anzahl der erfolgreichen Versuche auf, den Vorgang aufzurufen. Der Schutzschalter kehrt nach einer bestimmten Anzahl erfolgreicher, aufeinanderfolgender Operationsaufrufe in den Zustand Geschlossen zurück. Wenn ein Aufruf fehlschlägt, wechselt der Schutzschalter sofort in den Zustand geöffnet, und der Erfolgszähler wird beim nächsten Wechsel in den halbgeöffneten Zustand zurückgesetzt.

Hinweis

Die Systemwiederherstellung basiert auf externen Vorgängen, z. B. dem Wiederherstellen oder Neustart einer fehlerhaften Komponente oder reparieren einer Netzwerkverbindung.

Das Trennschalter-Muster sorgt für Stabilität, während sich das System nach einem Fehler erholt und die Auswirkungen auf die Leistung minimiert. Sie kann dabei helfen, die Reaktionszeit des Systems aufrechtzuerhalten. Dieses Muster lehnt schnell eine Anforderung für einen Vorgang ab, der wahrscheinlich fehlschlagen wird, anstatt darauf zu warten, dass der Vorgang abläuft oder nie zurückkommt. Wenn der Schaltkreisschalter jedes Mal ein Ereignis auslöst, wenn er den Zustand ändert, können diese Informationen helfen, den Status der geschützten Systemkomponente zu überwachen oder einen Administrator zu benachrichtigen, wenn ein Schaltkreisschalter in den Zustand "Öffnen " wechselt.

Sie können dieses Muster an verschiedene Arten von Fehlern anpassen. Sie können zum Beispiel einen Schutzschalter mit einem ansteigenden Timeout-Timer versehen. Sie können den Leistungsschalter zunächst für ein paar Sekunden in den Aus-Zustand versetzen. Wenn der Fehler nicht behoben wird, erhöhen Sie das Timeout auf ein paar Minuten, und passen Sie es entsprechend an. In einigen Fällen kann der 'Öffnen'-Zustand anstatt einen Fehler zurückzugeben und eine Ausnahme auszulösen, einen für die Anwendung sinnvollen Standardwert zurückgeben.

Hinweis

Traditionell basieren Schaltschalter auf vorkonfigurierte Schwellenwerte, z. B. Fehleranzahl und Timeoutdauer. Dieser Ansatz führte zu einem deterministischen, aber manchmal suboptimalen Verhalten.

Adaptive Techniken, die KI und maschinelles Lernen verwenden, können Schwellenwerte basierend auf Echtzeit-Datenverkehrsmustern, Anomalien und historischen Fehlerraten dynamisch anpassen. Dieser Ansatz verbessert Resilienz und Effizienz.

Probleme und Überlegungen

Berücksichtigen Sie beim Implementieren dieses Musters die folgenden Faktoren:

• Ausnahmebehandlung: Eine Anwendung, die einen Vorgang über einen Schaltkreistrennschalter aufruft, muss die Ausnahmen verarbeiten können, wenn der Vorgang nicht verfügbar ist. Die Ausnahmeverwaltung basiert auf der Anwendung. Beispielsweise kann eine Anwendung ihre Funktionalität vorübergehend beeinträchtigen, einen alternativen Vorgang aufrufen, um dieselbe Aufgabe auszuführen oder dieselben Daten abzurufen, oder melden Sie die Ausnahme an den Benutzer, und bitten Sie sie, es später erneut zu versuchen.

• Arten von Ausnahmen: Die Gründe für einen Anforderungsfehler können im Schweregrad variieren. Eine Anforderung kann z. B. fehlschlagen, weil ein Remotedienst abstürzt und mehrere Minuten zum Wiederherstellen benötigt, oder weil ein überladener Dienst zu einem Timeout führt. Ein Schaltkreisschalter kann möglicherweise die Arten von Ausnahmen untersuchen, die auftreten, und seine Strategie basierend auf der Art dieser Ausnahmen anpassen. Es könnte zum Beispiel eine größere Anzahl von Timeout-Ausnahmen erforderlich sein, um den Leistungsschalter in den Zustand Offen zu versetzen, als die Anzahl der durch den nicht verfügbaren Dienst verursachten Ausfälle.

• Überwachung: Ein Kreisunterbrecher sollte sowohl fehlgeschlagene als auch erfolgreiche Anforderungen klar erkennen lassen, damit die Betriebsteams den Zustand des Systems beurteilen können. Verwenden Sie verteiltes Tracing für durchgängige Transparenz über alle Dienste hinweg.

• Wiederherstellbarkeit: Sie sollten den Schaltkreistrennschalter so konfigurieren, dass es mit dem wahrscheinlichen Wiederherstellungsmuster des zu schützenden Vorgangs übereinstimmt. Wenn der Schaltkreisschalter beispielsweise für einen längeren Zeitraum im Zustand "Öffnen " verbleibt, kann er Ausnahmen auslösen, auch wenn der Grund für den Fehler behoben ist. Ebenso kann ein Schaltkreisschalter schwanken und die Reaktionszeiten von Anwendungen reduzieren, wenn er zu schnell vom Zustand "Öffnen " in den Halb-Offen-Zustand wechselt.

• Fehlgeschlagene Operationstests: Im Offen Zustand kann ein Schaltschalter anstelle eines Timers regelmäßig den Remotedienst oder die Ressource anpingen, um festzustellen, ob diese verfügbar ist, bevor er in den Teilweise offen Zustand wechselt. Dieser Ping kann entweder versuchen, einen zuvor fehlgeschlagenen Vorgang aufzurufen, oder einen speziellen Integritätsprüfungsvorgang verwenden, den der Remotedienst bereitstellt. Weitere Informationen finden Sie unter Überwachungsmuster für den Integritätsendpunkt.

• Manuelle Außerkraftsetzung: Wenn die Wiederherstellungszeit für einen fehlerhaften Vorgang extrem variabel ist, sollten Sie eine manuelle Zurücksetzungsoption bereitstellen, mit der ein Administrator einen Schaltkreistrennschalter schließen und den Fehlerzähler zurücksetzen kann. Ebenso kann ein Administrator einen Schaltkreistrenner in den Zustand "Öffnen " erzwingen und den Timeouttimer neu starten, wenn der geschützte Vorgang vorübergehend nicht verfügbar ist.

• Gleichzeitigkeit: Eine große Anzahl gleichzeitiger Instanzen einer Anwendung kann auf denselben Schaltkreistrennschalter zugreifen. Die Implementierung sollte keine gleichzeitigen Anforderungen blockieren oder übermäßigen Aufwand für die einzelnen Aufrufe eines Vorgangs verursachen.

• Ressourcendifferenzierung: Achten Sie darauf, wenn Sie einen einzelnen Schaltkreistrennschalter für einen Ressourcentyp verwenden, wenn möglicherweise mehrere zugrunde liegende unabhängige Anbieter vorhanden sind. Beispielsweise kann in einem Datenspeicher, der mehrere Shards enthält, ein Shard vollständig zugänglich sein, während ein anderes vorübergehendes Problem auftritt. Wenn die Fehlerantworten in diesen Szenarien zusammengeführt werden, versucht eine Anwendung möglicherweise, auf einige Shards zuzugreifen, auch wenn ein Fehler wahrscheinlich ist. Und der Zugang zu anderen Scherben könnte blockiert werden, auch wenn es wahrscheinlich ist, dass es gelingt.

• Beschleunigte Stromkreisunterbrechung: Manchmal kann eine Fehlerreaktion genug Informationen enthalten, um den Schutzschalter sofort auszulösen und für eine minimale Zeitspanne ausgelöst zu lassen. Die Fehlerantwort einer freigegebenen Ressource, die überladen ist, kann z. B. darauf hinweisen, dass die Anwendung stattdessen in einigen Minuten erneut versuchen soll, anstatt sofort erneut zu versuchen.

• Multiregion-Bereitstellungen: Sie können einen Schaltkreisschalter für einzelne Regionen oder Multiregion-Bereitstellungen entwerfen. Für den Einsatz in mehreren Regionen verwenden Sie globale Load Balancer oder benutzerdefinierte Strategien zur Unterbrechung von Verbindungen, die eine kontrollierte Ausfallsicherung, eine Optimierung der Latenzzeiten und die Einhaltung gesetzlicher Vorschriften gewährleisten.

• Dienstgitterschalter: Sie können Schaltkreisbrecher auf der Anwendungsebene oder als quergeschnittenes, abstrahiertes Feature implementieren. Zum Beispiel unterstützen Dienstnetze häufig die Unterbrechung von Stromkreisen als Seitenwagen oder als eigenständige Funktion, ohne dass der Anwendungscode geändert werden muss.

  Hinweis

  Ein Dienst kann HTTP 429 (zu viele Anforderungen) zurückgeben, wenn er den Client drosselt, oder HTTP 503 (Dienst nicht verfügbar), wenn der Dienst nicht verfügbar ist. Die Antwort kann weitere Informationen enthalten, z. B. die erwartete Dauer der Verzögerung.

• Fehlgeschlagene Wiederholung der Anforderung: Im Zustand Offen kann ein Schutzschalter nicht nur schnell versagen, sondern auch die Details jeder Anforderung an ein Journal aufzeichnen und dafür sorgen, dass diese Anforderungen erneut abgespielt werden, wenn die entfernte Ressource oder der entfernte Dienst verfügbar wird.

• Unangemessene Time-outs bei externen Diensten: Ein Circuit Breaker schützt Anwendungen möglicherweise nicht vollständig vor Ausfällen in externen Diensten, die lange Time-out-Zeiten haben. Wenn das Timeout zu lang ist, kann ein Thread, der einen Schaltkreisschalter ausführt, für einen längeren Zeitraum blockiert werden, bevor der Schaltkreisschalter angibt, dass der Vorgang fehlgeschlagen ist. Während dieser Zeit können viele andere Anwendungsinstanzen auch versuchen, den Dienst über den Schaltkreistrennschalter aufzurufen und zahlreiche Threads zu binden, bevor sie alle fehlschlagen.

• Anpassungsfähigkeit zur Berechnungsdiversifizierung: Schaltkreisbrecher sollten unterschiedliche Computeumgebungen berücksichtigen, von serverlosen bis zu containerisierten Workloads, bei denen Faktoren wie Kaltstarts und Skalierbarkeit die Fehlerbehandlung beeinflussen. Adaptive Ansätze können Strategien basierend auf dem Computetyp dynamisch anpassen, wodurch die Resilienz über heterogene Architekturen hinweg gewährleistet wird.

Wann dieses Muster verwendet werden soll

Verwenden Sie dieses Muster in folgenden Fällen:

• Sie möchten kaskadierende Fehler verhindern, indem Sie übermäßige Remotedienstaufrufe oder Zugriffsanforderungen an eine freigegebene Ressource beenden, wenn diese Vorgänge wahrscheinlich fehlschlagen.

• Sie möchten den Datenverkehr intelligent basierend auf Echtzeitfehlersignalen weiterleiten, um die Resilienz in mehreren Regionen zu verbessern.

• Sie möchten vor langsamen Abhängigkeiten schützen, damit Sie Ihre Ziele auf Dienstebene beibehalten und Leistungseinbußen von Diensten mit hoher Latenz vermeiden können.

• Sie möchten zeitweilige Konnektivitätsprobleme verwalten und Anforderungsfehler in verteilten Umgebungen reduzieren.

Dieses Muster ist möglicherweise nicht geeignet, wenn:

• Sie müssen den Zugriff auf lokale private Ressourcen in einer Anwendung verwalten, z. B. Speicherdatenstrukturen. In dieser Umgebung sorgt ein Schaltkreisschalter für mehr Aufwand für Ihr System.

• Sie müssen sie als Ersatz für die Behandlung von Ausnahmen in der Geschäftslogik Ihrer Anwendungen verwenden.

• Bekannte Wiederholungsalgorithmen sind ausreichend, und Ihre Abhängigkeiten sind für die Behandlung von Wiederholungsmechanismen konzipiert. In diesem Szenario kann ein Schaltkreisschalter in Ihrer Anwendung Ihrem System unnötige Komplexität hinzufügen.

• Das Warten auf einen Rücksetzschalter führt möglicherweise zu inakzeptablen Verzögerungen.

• Sie haben eine nachrichten- oder ereignisgesteuerte Architektur, denn diese leitet fehlgeschlagene Nachrichten oft an eine Warteschlange für manuelle oder zeitversetzte Verarbeitung weiter. Integrierte Fehlerisolation und Wiederholungsmechanismen sind häufig ausreichend.

• Die Wiederherstellung nach einem Ausfall wird auf Infrastruktur- oder Plattformebene verwaltet, z. B. mit Zustandsprüfungen in globalen Load Balancern oder Service Meshes.

Workloadentwurf

Bewerten Sie, wie Sie das Circuit Breaker-Muster im Design eines Workloads verwenden können, um die Ziele und Prinzipien zu erreichen, die in den Azure Well-Architected Framework-Säulenbehandelt werden. Die folgende Tabelle enthält Anleitungen dazu, wie dieses Muster die Ziele jeder Säule unterstützt.

Säule	So unterstützt dieses Muster die Säulenziele
Zuverlässigkeitsentwurfsentscheidungen helfen Ihrer Arbeitsauslastung, ausfallsicher zu werden und sicherzustellen, dass sie nach auftreten eines Fehlers wieder in einen voll funktionsfähigen Zustand versetzt wird.	Dieses Muster hilft, eine fehlerhafte Abhängigkeit daran zu hindern, eine Überlastung zu verursachen. Verwenden Sie dieses Muster, um eine sanfte Degradation der Arbeitslast auszulösen. Kombinieren Sie Schutzschalter mit automatischer Wiederherstellung, um eine Selbsterhaltung und Selbstheilung zu gewährleisten. - RE:03 Fehlermodusanalyse - Vorübergehende Fehler - RE:07 Selbsterhaltung
Performance Efficiency hilft Ihrem Workload durch Optimierungen bei Skalierung, Daten und Code, die Anforderungen effizient zu erfüllen .	Dieses Muster vermeidet den Ansatz "Retry-on-Error", der zu einer übermäßigen Ressourcennutzung während der Wiederherstellung der Abhängigkeit führen und die Leistung einer Abhängigkeit, die eine Wiederherstellung versucht, überlasten kann. - PE:07-Code und -Infrastruktur - PE:11 Antworten auf Live-Probleme

Wenn dieses Muster Kompromisse innerhalb einer Säule einführt, sollten Sie sie gegen die Ziele der anderen Säulen berücksichtigen.

Beispiel

In diesem Beispiel wird das Circuit Breaker-Muster implementiert, um Kontingentüberschreitungen mit dem kostenlosen Lebenszeittarif von Azure Cosmos DB zu verhindern. Diese Ebene ist in erster Linie für nicht kritische Daten vorgesehen und wird in einem Kapazitätsplan ausgeführt, der ein bestimmtes Kontingent von Ressourceneinheiten pro Sekunde zuweist. Bei saisonalen Ereignissen kann die Nachfrage die bereitgestellte Kapazität übersteigen, was zu 429 Reaktionen führen kann.

Wenn Nachfragespitzen auftreten, erkennen und benachrichtigen Azure Monitor-Warnungen mit dynamischen Schwellenwerten die Betriebs- und Verwaltungsteams, dass die Datenbank mehr Kapazität benötigt. Gleichzeitig löst ein Schutzschalter aus, der anhand historischer Fehlermuster abgestimmt wurde, um kaskadierende Ausfälle zu verhindern. In diesem Zustand fährt die Anwendung reibungslos herunter, indem sie Standard- oder zwischengespeicherte Antworten zurückgibt. Die Anwendung informiert die Benutzer über die vorübergehende Nichtverfügbarkeit bestimmter Daten und bewahrt dabei die Gesamtsystemstabilität.

Diese Strategie verbessert die Widerstandsfähigkeit im Einklang mit der geschäftlichen Begründung. Sie steuert Kapazitätserhöhungen, sodass Arbeitsauslastungsteams Kostenerhöhungen bewusst verwalten und die Servicequalität beibehalten können, ohne unerwartet die Betriebskosten zu erhöhen. Nach dem Nachlassen der Nachfrage oder wenn eine erhöhte Kapazität bestätigt ist, wird der Leitungsschutzschalter zurückgesetzt, und die Anwendung kehrt zu voller Funktionalität zurück, die sowohl den technischen als auch den finanziellen Zielen entspricht.

Das Diagramm besteht aus drei primären Abschnitten. Der erste Abschnitt enthält zwei Webbrowsersymbole. Das erste Symbol zeigt eine voll funktionsfähige Benutzeroberfläche an, und das zweite Symbol zeigt eine beeinträchtigte Benutzererfahrung mit einer Bildschirmwarnung an, um das Problem für Benutzer anzuzeigen. Der zweite Abschnitt wird in ein gestricheltes Linienrechteck eingeschlossen, das in zwei Gruppen unterteilt ist. Die oberste Gruppe umfasst die Workloadressourcen, App Service und Azure Cosmos DB. Pfeile von beiden Webbrowsersymbolen zeigen auf die App Service-Instanz, die eingehende Anforderungen vom Client darstellt. Darüber hinaus verweisen Pfeile aus der App Service-Instanz auf azure Cosmos DB, die Dateninteraktionen zwischen den Anwendungsdiensten und der Datenbank angeben. Ein weiterer Pfeil führt von der App Service-Instanz zurück zu sich selbst und symbolisiert den Mechanismus zur Unterbrechung der Stromzufuhr. Diese Schleife bedeutet, dass das System, wenn eine 429 Too Many Requests-Antwort erkannt wird, auf die Bereitstellung von Antworten aus dem Zwischenspeicher zurückgreift, wodurch sich die Benutzerfreundlichkeit verschlechtert, bis die Situation geklärt ist. Die untere Gruppe dieses Abschnitts konzentriert sich auf Beobachtbarkeit und Alarmierungen. Azure Monitor sammelt Daten aus den Azure-Ressourcen in der obersten Gruppe. Azure Monitor verbindet sich auch mit einem Warnregel-Symbol. Der dritte Abschnitt zeigt den Skalierbarkeitsworkflow, der ausgelöst wird, wenn die Warnung ausgelöst wird. Ein Pfeil verbindet das Benachrichtigungssymbol mit den Genehmigenden, was angibt, dass die Benachrichtigung zur Überprüfung an sie gesendet wird. Ein weiterer Pfeil führt von den Genehmigern zu einer Entwicklungskonsole, die den Genehmigungsprozess für die Skalierung der Datenbank angibt. Schließlich erstreckt sich ein weiterer Pfeil von der Entwicklungskonsole auf Azure Cosmos DB, der die Aktion der Skalierung der Datenbank als Reaktion auf die Überlastungsbedingung darstellt.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Fluss A: Geschlossener Status

• Das System funktioniert normal, und alle Anfragen erreichen die Datenbank, ohne 429 HTTP-Antworten zurückzugeben.

• Der Schaltkreistrennschalter bleibt geschlossen, und es sind keine Standard- oder zwischengespeicherten Antworten erforderlich.

Fluss B: Offener Zustand

1. Wenn der Schaltkreistrennschalter die erste 429 Antwort empfängt, wird er in einen Geöffneten Zustand versetzt.

2. Nachfolgende Anforderungen werden sofort kurzgeschlossen, wodurch Standardantworten oder Antworten aus dem Zwischenspeicher zurückgegeben und die Benutzer über die vorübergehende Verschlechterung informiert werden. Die Anwendung ist vor weiterer Überladung geschützt.

3. Azure Monitor empfängt Protokolle und Telemetriedaten und wertet sie anhand dynamischer Schwellenwerte aus. Eine Warnung wird ausgelöst, wenn die Bedingungen der Warnungsregel erfüllt sind.

4. Eine Aktionsgruppe benachrichtigt das Betriebsteam proaktiv über den Überlastungszustand.

5. Nach der Genehmigung des Workloadteams kann das Betriebsteam den bereitgestellten Durchsatz erhöhen, um die Überlastung zu verringern oder die Skalierung zu verzögern, wenn die Last natürlich abnimmt.

Fluss C: Halbgeöffneter Zustand

1. Nach einem vordefinierten Timeout wechselt der Schaltkreisschalter in einen Halb-Offen-Zustand , der eine begrenzte Anzahl von Testanforderungen zulässt.

2. Wenn diese Testanforderungn erfolgreich sind und keine 429-Antworten zurückkommen, wird der Unterbrecher in den Zustand Geschlossen zurückgesetzt und der normale Betrieb kehrt zu Fluss A zurück. Bleiben die Fehler bestehen, kehrt der Unterbrecher in den Zustand Offen oder Fluss B zurück.

Komponenten

• Azure App Service hostt die Webanwendung, die als primären Einstiegspunkt für Clientanforderungen dient. Der Anwendungscode implementiert die Logik, die Richtlinien für den Schaltkreistrennschalter erzwingt, und liefert Standardantworten oder zwischengespeicherte Antworten, wenn der Schaltkreis geöffnet ist. Diese Architektur trägt dazu bei, überlastete Systeme zu verhindern und die Benutzerfreundlichkeit bei Spitzenanforderungen oder Fehlern aufrechtzuerhalten.

• Azure Cosmos DB ist einer der Datenspeicher der Anwendung. Es stellt nicht-kritische Daten über den freien Tarif bereit, der ideal für kleine Produktionsaufgaben ist. Der Schaltkreistrennmechanismus hilft dabei, den Datenverkehr während hoher Nachfrageperioden auf die Datenbank zu beschränken.

• Azure Monitor fungiert als zentrale Überwachungslösung. Es aggregiert alle Aktivitätsprotokolle, um eine umfassende End-to-End-Observability zu gewährleisten. Azure Monitor empfängt Protokolle und Telemetriedaten von App Service und wichtige Metriken von Azure Cosmos DB (z. B. die Anzahl der 429 Antworten) für Aggregation und Analyse.

• Azure Monitor-Warnungen werden mit Warnungsregeln gegen dynamische Schwellenwerte abgewogen, um potenzielle Ausfälle basierend auf historischen Daten zu identifizieren. Vordefinierte Warnungen benachrichtigen das Betriebsteam, wenn Schwellenwerte verletzt werden.

  Manchmal genehmigt das Workloadteam möglicherweise eine Erhöhung des bereitgestellten Durchsatzes, aber das Betriebsteam geht davon aus, dass das System eigenständig wiederhergestellt werden kann, da die Last nicht zu hoch ist. In diesen Fällen läuft das Zeitlimit des Schutzschalters auf natürliche Weise ab. Während dieser Zeit, wenn die 429 Antworten aufhören, erkennt die Schwellenwertermittlung die verlängerten Ausfälle und schließt sie vom Lernalgorithmus aus. Daher wartet der Schwellenwert beim nächsten Auftreten einer Überladung auf eine höhere Fehlerrate in Azure Cosmos DB, wodurch die Benachrichtigung verzögert wird. Diese Anpassung ermöglicht es dem Schaltkreisschalter, das Problem ohne sofortige Warnung zu behandeln, was die Kosten und die Betriebseffizienz verbessert.

Verwandte Ressourcen

• Das Muster Zuverlässige Web-App wendet das Circuit Breaker-Pattern auf Webanwendungen an, die in der Cloud betrieben werden.

• Das Wiederholungsmuster beschreibt, wie eine Anwendung erwartete temporäre Fehler behandeln kann, wenn sie versucht, eine Verbindung mit einem Dienst oder einer Netzwerkressource herzustellen, indem sie einen Vorgang, der zuvor fehlgeschlagen war, transparent wiederholen.

• Das Muster Überwachungsmuster für den Integritätsendpunkt beschreibt, wie ein Kreisunterbrecher den Zustand eines Dienstes testen kann, indem er eine Anforderung an einen Endpunkt sendet, den der Dienst bereitstellt. Der Dienst sollte Informationen zurückgeben, die den Status angibt.