Empfehlungen zum Umgang mit vorübergehenden Fehlern

Diese Anleitung beschreibt die Empfehlungen zum Umgang mit vorübergehenden Fehlern in Ihren Cloud-Anwendungen. Alle Anwendungen, die mit Remotediensten und -ressourcen kommunizieren, müssen auf vorübergehende Fehler reagieren. Dies gilt insbesondere für Anwendungen, die in der Cloud ausgeführt werden, wo diese Art von Fehler aufgrund der Art der Umgebung und der Konnektivität über das Internet häufiger auftreten kann. Zu vorübergehenden Fehlern zählen der kurzzeitige Verlust der Netzwerkverbindung zu Komponenten und Diensten, die vorübergehende Nichtverfügbarkeit eines Dienstes und Timeouts, die auftreten, wenn ein Dienst ausgelastet ist. Diese Fehler beheben sich häufig von selbst. Wenn die Aktion also nach einer angemessenen Verzögerung wiederholt wird, ist die Wahrscheinlichkeit groß, dass sie erfolgreich ist.

Dieser Artikel enthält allgemeine Anleitungen für die vorübergehende Fehlerbehandlung. Informationen zum Implementieren von Wiederholungsversuchen in Ihrem Anwendungscode zur Behandlung vorübergehender Fehler finden Sie im Wiederholungsmuster und beim Verwenden von Azure-Diensten, finden Sie in den Anleitungen zur Wiederholung für Azure-Dienste.

Vorübergehende Fehler

Vorübergehende Fehler können in jeder Umgebung, auf jeder Plattform oder jedem Betriebssystem und in jeder Art von Anwendung auftreten. Bei Lösungen, die auf lokaler lokaler Infrastruktur ausgeführt werden, werden die Leistung und Verfügbarkeit der Anwendung und ihrer Komponenten in der Regel über teure und häufig nicht genutzte Hardwareredundanz verwaltet, und Komponenten und Ressourcen befinden sich in der Nähe. Dieser Ansatz macht Fehler weniger wahrscheinlich, aber vorübergehende Fehler können weiterhin auftreten, da Ausfälle durch unvorhergesehene Ereignisse wie externe Stromversorgungs- oder Netzwerkprobleme oder durch Notfallszenarien verursacht werden können.

Cloudhosting, einschließlich privater Cloudsysteme, kann eine höhere Gesamtverfügbarkeit bieten, indem gemeinsam genutzte Ressourcen, Redundanz, automatisches Failover und dynamische Ressourcenzuordnung über viele Ressourcenberechnungsknoten hinweg verwendet werden. Aufgrund der Art der Cloudumgebungen sind vorübergehende Fehler jedoch wahrscheinlicher. Hierfür gibt es mehrere Gründe:

• Viele Ressourcen in einer Cloudumgebung werden gemeinsam genutzt, und der Zugriff auf diese Ressourcen unterliegt der Einschränkung, um die Ressourcen zu schützen. Einige Dienste verweigern Verbindungen, wenn die Last auf eine bestimmte Ebene steigt, oder wenn eine maximale Durchsatzrate erreicht wird, um die Verarbeitung vorhandener Anforderungen zu ermöglichen und die Leistung des Diensts für alle Benutzer aufrechtzuerhalten. Die Drosselung trägt dazu bei, die Dienstqualität für Nachbarn und andere Mandanten aufrechtzuerhalten, die die freigegebene Ressource verwenden.

• Cloudumgebungen verwenden eine große Anzahl von handelsüblichen Hardwareeinheiten. Sie liefern Leistung, indem sie die Last dynamisch über mehrere Computereinheiten und Infrastrukturkomponenten verteilen. Sie liefern Zuverlässigkeit durch automatisches Recycling oder Ersetzen fehlgeschlagener Einheiten. Aufgrund dieser dynamischen Natur können vorübergehende Fehler und temporäre Verbindungsfehler gelegentlich auftreten.

• Es gibt häufig mehr Hardwarekomponenten, einschließlich der Netzwerkinfrastruktur wie Router und Lastenausgleichsgeräte, zwischen der Anwendung und den ressourcen und Diensten, die sie verwendet. Diese zusätzliche Infrastruktur kann gelegentlich zusätzliche Verbindungslatenz und vorübergehende Verbindungsfehler verursachen.

• Netzwerkbedingungen zwischen dem Client und dem Server können variabel sein, insbesondere wenn die Kommunikation das Internet überschreitet. Auch an lokalen Standorten können hohe Verkehrslasten die Kommunikation verlangsamen und zeitweilige Verbindungsausfälle verursachen.

Vorübergehende Fehler können die wahrgenommene Verfügbarkeit einer Anwendung erheblich beeinträchtigen, selbst wenn diese unter allen vorhersehbaren Umständen gründlich getestet wurde. Um sicherzustellen, dass in der Cloud gehostete Anwendungen zuverlässig funktionieren, müssen Sie sicherstellen, dass sie auf die folgenden Herausforderungen reagieren können:

• Die Anwendung muss in der Lage sein, Fehler zu erkennen, wenn sie auftreten, und zu bestimmen, ob es sich wahrscheinlich um vorübergehende oder lang anhaltende Fehler handelt oder ob es sich um endgültige Ausfälle handelt. Verschiedene Ressourcen geben beim Auftreten eines Fehlers wahrscheinlich unterschiedliche Antworten zurück, und diese Antworten können je nach Kontext des Vorgangs auch variieren. Die Reaktion auf einen Fehler beim Lesen aus dem Speicher kann sich beispielsweise von der Reaktion auf einen Fehler unterscheiden, wenn Daten in den Speicher geschrieben werden. Viele Ressourcen und Dienste verfügen über gut dokumentierte vorübergehende Fehlerverträge. Wenn solche Informationen jedoch nicht verfügbar sind, kann es schwierig sein, die Art des Fehlers zu ermitteln und ob es wahrscheinlich vorübergehend sein wird.

• Die Anwendung muss in der Lage sein, den Vorgang zu wiederholen, wenn sie feststellt, dass es sich wahrscheinlich um einen vorübergehenden Fehler handelt. Außerdem muss nachverfolgt werden, wie oft der Vorgang wiederholt wird.

• Die Anwendung muss für Wiederholungsversuche eine geeignete Strategie verwenden. Die Strategie gibt an, wie oft die Anwendung einen erneuten Versuch unternehmen soll, wie lange zwischen den einzelnen Versuchen gewartet werden soll und welche Maßnahmen nach einem fehlgeschlagenen Versuch zu ergreifen sind. Die angemessene Anzahl von Versuchen und die Zeitspanne zwischen den einzelnen Versuchen sind oft schwer zu bestimmen. Die Strategie variiert je nach Ressourcentyp und den aktuellen Betriebsbedingungen der Ressource und der Anwendung.

Die folgenden Richtlinien können Ihnen dabei helfen, geeignete Mechanismen zur Behandlung vorübergehender Fehler für Ihre Anwendungen zu entwerfen.

Implementieren von Wiederholungsversuchen

Ermitteln Sie, ob ein integrierter Wiederholungsmechanismus vorhanden ist

• Viele Dienste stellen ein SDK oder eine Clientbibliothek bereit, die einen vorübergehenden Fehlerbehandlungsmechanismus enthält. Die verwendete Wiederholungsrichtlinie ist normalerweise auf die Art und Anforderungen des Zieldienstes zugeschnitten. Alternativ können REST-Schnittstellen für Dienste Informationen zurückgeben, die Ihnen bei der Entscheidung helfen, ob ein erneuter Versuch angebracht ist und wie lange vor dem nächsten Wiederholungsversuch gewartet werden soll.

• Sie sollten den integrierten Wiederholungsmechanismus verwenden, sofern einer verfügbar ist, es sei denn, Sie haben spezifische und gut verständliche Anforderungen, für die ein anderes Wiederholungsverhalten angemessener ist.

Bestimmen Sie, ob der Vorgang für einen erneuten Versuch geeignet ist

• Führen Sie Wiederholungsvorgänge nur durch, wenn die Fehler vorübergehend sind (normalerweise durch die Art des Fehlers angezeigt) und wenn zumindest eine gewisse Wahrscheinlichkeit besteht, dass der Vorgang bei einer Wiederholung erfolgreich ist. Es gibt keinen Punkt beim Wiederholen von Vorgängen, die einen ungültigen Vorgang versuchen, z. B. eine Datenbankaktualisierung auf ein Element, das nicht vorhanden ist, oder eine Anforderung an einen Dienst oder eine Ressource, die einen schwerwiegenden Fehler verursacht hat.

• Implementieren Sie im Allgemeinen Wiederholungsversuche nur, wenn Sie die volle Wirkung der Aktion bestimmen können und wann die Bedingungen gut verstanden und überprüft werden können. Andernfalls sollte man den aufrufenden Code dazu bringen, Wiederholungsversuche zu implementieren. Bedenken Sie, dass sich die von Ressourcen und Diensten außerhalb Ihrer Kontrolle zurückgegebenen Fehler im Laufe der Zeit weiterentwickeln können und Sie Ihre Logik zur Erkennung vorübergehender Fehler möglicherweise überarbeiten müssen.

• Wenn Sie Dienste oder Komponenten erstellen, sollten Sie Fehlercodes und Meldungen implementieren, mit denen Clients ermitteln können, ob fehlgeschlagene Vorgänge erneut ausgeführt werden sollen. Geben Sie insbesondere an, ob der Client den Vorgang wiederholen soll (z. B. durch Zurückgeben eines isTransient-Werts ), und schlagen Sie eine geeignete Verzögerung vor dem nächsten Wiederholungsversuch vor. Wenn Sie einen Webdienst erstellen, sollten Sie die Rückgabe benutzerdefinierter Fehler in Betracht ziehen, die in Ihren Dienstverträgen definiert sind. Obwohl generische Clients diese Fehler möglicherweise nicht lesen können, sind sie bei der Erstellung von benutzerdefinierten Clients nützlich.

Festlegen einer angemessenen Anzahl von Wiederholungsversuchen und eines angemessenen Intervalls

• Optimieren Sie die Anzahl der Wiederholungsversuche und das Intervall entsprechend der Art des Anwendungsfalls. Wenn Sie es nicht oft genug wiederholen, kann die Anwendung den Vorgang nicht abschließen und schlägt wahrscheinlich fehl. Wenn Sie es zu oft erneut versuchen oder zu kurze Intervalle zwischen den Versuchen lassen, kann die Anwendung Ressourcen wie Threads, Verbindungen und Arbeitsspeicher über längere Zeiträume blockieren, was sich negativ auf die Gesundheit der Anwendung auswirkt.

• Passen Sie die Werte für das Zeitintervall und die Anzahl der Wiederholungsversuche an die Art des Vorgangs an. Wenn der Vorgang beispielsweise Teil einer Benutzerinteraktion ist, sollte das Intervall kurz sein und nur wenige Wiederholungsversuche durchgeführt werden. Mit diesem Ansatz können Sie vermeiden, dass Benutzer auf eine Antwort warten, die offene Verbindungen enthält und die Verfügbarkeit für andere Benutzer verringern kann. Wenn der Vorgang Teil eines lang ausgeführten oder kritischen Workflows ist, bei dem das Abbrechen und Neustarten des Prozesses teuer oder zeitaufwendig ist, empfiehlt es sich, länger zwischen den Versuchen zu warten und mehr Zeit zu versuchen.

• Bedenken Sie, dass das Bestimmen der geeigneten Intervalle zwischen den Wiederholungsversuchen der schwierigste Teil beim Entwerfen einer erfolgreichen Strategie ist. Typische Strategien verwenden die folgenden Arten von Wiederholungsintervallen:

  • Exponentielles Zurücksetzen. Die Anwendung wartet vor dem ersten Wiederholungsversuch eine kurze Zeit und erhöht dann die Zeit zwischen jedem weiteren Wiederholungsversuch exponenziell. Beispielsweise kann der Vorgang nach 3 Sekunden, 12 Sekunden, 30 Sekunden usw. wiederholt werden. Um diese Strategie weiter zu verbessern, können Sie *Jitter* zum exponentiellen Back-off hinzufügen. Jitter führt eine zufällige Verzögerung für jeden Wiederholungsversuch ein, was dazu beiträgt zu verhindern, dass mehrere Clients gleichzeitig erneut versuchen, was Lastspitzen verursachen könnte.

  • Inkrementelle Intervalle. Die Anwendung wartet kurz auf den ersten Wiederholungsversuch und erhöht dann schrittweise die Zeit zwischen jedem weiteren Versuch. Beispielsweise kann der Vorgang nach 3 Sekunden, 7 Sekunden, 13 Sekunden usw. wiederholt werden.

  • Regelmäßige Intervalle. Zwischen jedem Versuch wartet die Anwendung gleich lange. Beispielsweise kann der Vorgang alle 3 Sekunden erneut ausgeführt werden.

  • Sofortiger Wiederholungsversuch. Manchmal ist ein vorübergehender Fehler kurz, möglicherweise durch ein Ereignis wie eine Netzwerkpaketkollision oder einen Anstieg in einer Hardwarekomponente verursacht. In diesem Fall ist das erneute Wiederholen des Vorgangs sofort geeignet, da es möglicherweise erfolgreich ist, wenn der Fehler in der Zeit gelöscht wird, in der die Anwendung zum Zusammenstellen und Senden der nächsten Anforderung benötigt wird. Es sollte jedoch nie mehr als ein sofortiger Wiederholungsversuch erfolgen. Sie sollten auf alternative Strategien zurückgreifen, wie etwa exponentielles Back-off oder Fallbackaktionen, wenn der sofortige Wiederholungsversuch fehlschlägt.

  • Randomisierung. Jede der zuvor aufgeführten Wiederholungsstrategien kann eine Randomisierung enthalten, um zu verhindern, dass mehrere Instanzen des Clients gleichzeitig nachfolgende Wiederholungsversuche starten. Beispielsweise kann eine Instanz den Vorgang nach 3 Sekunden, 11 Sekunden, 28 Sekunden usw. wiederholen, während eine andere Instanz den Vorgang nach 4 Sekunden, 12 Sekunden, 26 Sekunden usw. wiederholen kann. Randomisierung ist eine nützliche Technik, die mit anderen Strategien kombiniert werden kann.

• Verwenden Sie als allgemeine Richtlinien eine exponentielle Back-Off-Strategie mit Jitter für die Hintergrundvorgänge und setzen Sie auf sofortige oder regelmäßige Intervall-Wiederholungsstrategien für interaktive Vorgänge. In beiden Fällen sollten Sie die Verzögerung und die Anzahl der Wiederholungsversuche so wählen, dass die maximale Latenz für alle Wiederholungsversuche innerhalb der erforderlichen End-to-End-Latenzanforderung liegt.

• Berücksichtigen Sie die Kombination aller Faktoren, die zum gesamthöchsten Timeout für einen wiederholten Vorgang beitragen. Diese Faktoren umfassen die Zeit, die für eine fehlgeschlagene Verbindung erforderlich ist, um eine Antwort zu erzeugen (in der Regel durch einen Timeoutwert im Client festgelegt), die Verzögerung zwischen Wiederholungsversuchen und die maximale Anzahl von Wiederholungsversuchen. Die Summe aller dieser Zeiten kann zu langen Gesamtbetriebszeiten führen, insbesondere wenn Sie eine exponenzielle Verzögerungsstrategie verwenden, bei der das Intervall zwischen den Wiederholungsversuchen nach jedem Fehler schnell zunimmt. Wenn ein Prozess eine bestimmte Service-Level-Vereinbarung (SLA) erfüllen muss, muss die gesamte Betriebszeit einschließlich aller Timeouts und Verzögerungen innerhalb der im SLA definierten Grenzen liegen.

• Setzen Sie keine zu aggressiven Wiederholungsstrategien ein. Dabei handelt es sich um Strategien, deren Intervalle zu kurz sind oder deren Wiederholungsversuche zu häufig erfolgen. Sie können sich nachteilig auf die Zielressource oder den Zieldienst auswirken. Diese Strategien verhindern möglicherweise, dass sich die Ressource oder der Dienst aus ihrem überlasteten Zustand erholt, und blockieren oder verweigern weiterhin Anfragen. Dieses Szenario führt zu einem Teufelskreis, in dem immer mehr Anfragen an die Ressource oder den Dienst gesendet werden. Folglich wird die Fähigkeit zur Regeneration weiter verringert.

• Berücksichtigen Sie das Timeout der Vorgänge, wenn Sie Wiederholungsintervalle auswählen, um das Starten eines nachfolgenden Versuchs sofort zu vermeiden (z. B. wenn der Timeoutzeitraum dem Wiederholungsintervall ähnelt). Überlegen Sie außerdem, ob Sie den gesamten möglichen Zeitraum (das Timeout plus die Wiederholungsintervalle) unter einer bestimmten Gesamtzeit beibehalten müssen. Wenn ein Vorgang ein ungewöhnlich kurzes oder langes Timeout aufweist, kann das Timeout beeinflussen, wie lange gewartet werden soll und wie oft der Vorgang wiederholt werden soll.

• Verwenden Sie den Typ der Ausnahme und alle darin enthaltenen Daten oder die Fehlercodes und Nachrichten, die vom Dienst zurückgegeben werden, um die Anzahl der Wiederholungen und das Intervall zwischen diesen zu optimieren. Beispielsweise können einige Ausnahmen oder Fehlercodes (wie der HTTP-Code 503, „Dienst nicht verfügbar“, mit einem „Retry-After“-Header in der Antwort) angeben, wie lange der Fehler andauern könnte, oder dass der Dienst fehlgeschlagen ist und auf keinen weiteren Versuch reagiert.

• Erwägen Sie die Verwendung eines Dead-Letter-Queue-Ansatzes, um sicherzustellen, dass keine Informationen aus den eingehenden Aufträgen verloren gehen, nachdem alle Wiederholungsversuche ausgeschöpft wurden.

Anti-Muster vermeiden

• Vermeiden Sie in den meisten Fällen Implementierungen, die doppelte Ebenen von Wiederholungscode enthalten. Vermeiden Sie Designs, die kaskadierende Wiederholungsmechanismen enthalten oder die Wiederholungsversuche in jeder Phase eines Vorgangs implementieren, der eine Hierarchie von Anforderungen umfasst, es sei denn, Sie verfügen über bestimmte Anforderungen, die dies erfordern. Verwenden Sie in diesen Ausnahmefällen Richtlinien, die eine übermäßige Anzahl von Wiederholungsversuchen und Verzögerungen verhindern, und stellen Sie sicher, dass Sie die Konsequenzen verstehen. Angenommen, eine Komponente stellt eine Anfrage an eine andere, die dann auf den Zieldienst zugreift. Wenn Sie bei beiden Aufrufen eine Wiederholung mit einer Anzahl von drei implementieren, gibt es für den Dienst insgesamt neun Wiederholungsversuche. Viele Dienste und Ressourcen implementieren einen integrierten Wiederholungsmechanismus. Sie sollten untersuchen, wie Sie diese Mechanismen deaktivieren oder ändern können, wenn Sie Wiederholungsversuche auf einer höheren Ebene implementieren müssen.

• Implementieren Sie niemals einen Mechanismus für endlose Wiederholungsversuche. Dadurch kann es passieren, dass sich die Ressource oder der Dienst nicht von einer Überlastungssituation erholt und die Drosselung und Ablehnung von Verbindungen über einen längeren Zeitraum anhält. Verwenden Sie eine endliche Anzahl von Wiederholungen, oder implementieren Sie ein Muster wie den Circuit Breaker, um dem Dienst eine Wiederherstellung zu ermöglichen.

• Führen Sie einen sofortigen Wiederholungsversuch niemals mehr als einmal durch.

• Vermeiden Sie die Verwendung eines regulären Wiederholungsintervalls, wenn Sie auf Dienste und Ressourcen in Azure zugreifen, insbesondere, wenn sie eine hohe Anzahl von Wiederholungsversuchen haben. Der beste Ansatz in diesem Szenario ist eine exponentielle Back-Off-Strategie mit einer schaltkreisbrechenden Funktion.

• Verhindern, dass mehrere Instanzen desselben Clients oder mehrere Instanzen verschiedener Clients gleichzeitig Wiederholungsversuche senden. Wenn dieses Szenario wahrscheinlich eintritt, führen Sie die Randomisierung in die Wiederholungsintervalle ein.

Testen von Wiederholungsstrategien und Implementierung

• Testen Sie Ihre Wiederholungsstrategie unter möglichst vielen verschiedenen Bedingungen, insbesondere wenn sowohl die Anwendung als auch die von ihr verwendeten Zielressourcen oder -dienste extrem ausgelastet sind. Um das Verhalten während des Tests zu überprüfen, können Sie:

  • Schließen Sie vorübergehende Fehler in Ihre Chaos engineering- und Fehlereinspritzverfahren ein, indem Sie sie absichtlich in Ihre Nichtproduktions- und Produktionsumgebungen einführen. Senden Sie beispielsweise ungültige Anfragen oder fügen Sie Code hinzu, der Testanfragen erkennt und mit unterschiedlichen Fehlertypen antwortet.

  • Erstellen Sie ein Modell der Ressource oder des Dienstes, das eine Reihe von Fehlern zurückgibt, die auch der echte Dienst zurückgeben könnte. Decken Sie alle Fehlertypen ab, die durch Ihre Wiederholungsstrategie erkannt werden sollen.

  • Erzwingen Sie bei benutzerdefinierten Diensten, die Sie erstellen und bereitstellen, das Auftreten vorübergehender Fehler, indem Sie den Dienst vorübergehend deaktivieren oder überlasten. (Versuchen Sie nicht, gemeinsam genutzte Ressourcen oder Dienste in Azure zu überlasten.)

  • Verwenden Sie Bibliotheken oder Lösungen, die netzwerkdatenverkehr abfangen und ändern, um ungünstige Szenarien aus Ihren automatisierten Tests zu replizieren. Beispielsweise können die Tests zusätzliche Roundtripzeiten hinzufügen, Pakete verwerfen, Kopfzeilen modifizieren oder sogar den Inhalt der Anforderung selbst verändern. Auf diese Weise können deterministische Tests einer Teilmenge der Fehlerbedingungen auf vorübergehende Fehler und andere Arten von Fehlern durchgeführt werden.

  • Wenn Sie die Widerstandsfähigkeit einer Client-Webanwendung gegenüber vorübergehenden Fehlern testen, nutzen Sie die Entwicklertools des Browsers oder die Möglichkeit Ihres Test-Frameworks, Netzwerkanforderungen zu simulieren oder blockieren.

  • Führen Sie hohen Lastfaktor und gleichzeitige Tests durch, um sicherzustellen, dass der Wiederholungsmechanismus und die Strategie unter diesen Bedingungen ordnungsgemäß funktionieren. Mithilfe dieser Tests wird außerdem sichergestellt, dass sich der Wiederholungsversuch nicht negativ auf den Betrieb des Clients auswirkt oder zu einer Kreuzkontamination zwischen den Anforderungen führt.

Verwalten von Wiederholungsrichtlinienkonfigurationen

• Eine Wiederholungsrichtlinie ist eine Kombination aller Elemente Ihrer Wiederholungsstrategie. Er definiert den Erkennungsmechanismus, der bestimmt, ob ein Fehler wahrscheinlich vorübergehend ist, den Typ des zu verwendenden Intervalls (z. B. normale, exponentielle Back-off und Randomisierung), die tatsächlichen Intervallwerte und die Anzahl der Wiederholungen.

• Implementieren Sie Wiederholungen an vielen Stellen, auch in der einfachsten Anwendung und in jeder Ebene komplexerer Anwendungen. Anstatt die Elemente jeder Richtlinie an mehreren Orten hart einzucodieren, sollten Sie einen zentralen Punkt verwenden, um alle Richtlinien zu speichern. Speichern Sie z. B. Werte wie das Intervall und die Wiederholungsanzahl in Anwendungskonfigurationsdateien, lesen Sie sie zur Laufzeit, und erstellen Sie programmgesteuert die Wiederholungsrichtlinien. Dadurch wird es einfacher, die Einstellungen zu verwalten und die Werte zu ändern und zu optimieren, um auf sich ändernde Anforderungen und Szenarien zu reagieren. Entwerfen Sie das System jedoch so, dass die Werte gespeichert werden, anstatt eine Konfigurationsdatei jedes Mal erneut zu lesen, und verwenden Sie geeignete Standardwerte, wenn die Werte nicht aus der Konfiguration abgerufen werden können.

• Speichern Sie die Werte, die zum Erstellen der Wiederholungsrichtlinien zur Laufzeit im Konfigurationssystem der Anwendung verwendet werden, damit Sie sie ändern können, ohne die Anwendung neu starten zu müssen.

• Nutzen Sie integrierte oder standardmäßige Wiederholungsstrategien, die in den von Ihnen verwendeten Client-APIs verfügbar sind, aber nur, wenn sie für Ihr Szenario geeignet sind. Diese Strategien sind typischerweise allgemeiner Natur. In manchen Szenarien reichen sie möglicherweise aus, was Sie brauchen, in anderen bieten sie jedoch nicht alle Optionen, die Ihren spezifischen Anforderungen entsprechen. Um die am besten geeigneten Werte zu ermitteln, müssen Sie Tests durchführen, um zu verstehen, wie sich die Einstellungen auf Ihre Anwendung auswirken.

Protokollieren und Verfolgen vorübergehender und dauerhafter Fehler

• Integrieren Sie als Teil Ihrer Wiederholungsstrategie die Ausnahmebehandlung und andere Instrumente, die Wiederholungsversuche protokollieren. Gelegentliche vorübergehende Fehler und Wiederholungsversuche sind zu erwarten und stellen kein Anzeichen für ein Problem dar. Eine regelmäßige und steigende Anzahl von Wiederholungsversuchen ist jedoch häufig ein Hinweis auf ein Problem, das zu einem Fehler führen oder die Leistung und Verfügbarkeit der Anwendung beeinträchtigen könnte.

• Protokollieren Sie vorübergehende Fehler als Warneinträge und nicht als Fehlereinträge, damit Überwachungssysteme sie nicht als Anwendungsfehler erkennen, die möglicherweise falsche Warnungen auslösen.

• Sie sollten in Ihren Protokolleinträgen ggf. einen Wert speichern, der angibt, ob Wiederholungsversuche durch eine Drosselung des Dienstes oder durch andere Fehlertypen (z. B. Verbindungsfehler) verursacht werden, damit Sie diese bei der Datenanalyse unterscheiden können. Eine Erhöhung der Anzahl der Drosselungsfehler ist häufig ein Indikator für einen Entwurfsfehler in der Anwendung oder die Notwendigkeit, zu einem Premium-Dienst zu wechseln, der dedizierte Hardware bietet.

• Erwägen Sie das Messen und Protokollieren der gesamt verstrichenen Zeiten für Vorgänge, die einen Wiederholungsmechanismus enthalten. Diese Metrik ist ein guter Indikator für die Gesamtwirkung vorübergehender Fehler auf Benutzerantwortzeiten, Prozesslatenz und die Effizienz von Anwendungsanwendungsfällen. Protokollieren Sie auch die Anzahl der Wiederholungen, die auftreten, damit Sie die Faktoren verstehen können, die zur Reaktionszeit beitragen.

• Erwägen Sie die Implementierung eines Telemetrie- und Überwachungssystems, das Warnungen auslösen kann, wenn die Anzahl und Rate der Fehler, die durchschnittliche Anzahl der Wiederholungsversuche oder die insgesamt bis zum Erfolg von Vorgängen verstrichene Zeit zunimmt.

Verwalten von Vorgängen, die ständig fehlschlagen

• Überlegen Sie, wie Sie mit Vorgängen umgehen, die weiterhin bei jedem Versuch fehlschlagen. Situationen wie diese sind unvermeidlich.

  • Obwohl eine Wiederholungsstrategie die maximale Anzahl der Versuche festlegt, in denen ein Vorgang wiederholt werden soll, verhindert sie nicht, dass die Anwendung den Vorgang mit derselben Anzahl von Versuchen erneut durchführt. Wenn z. B. ein Auftragsverarbeitungsdienst mit einem schwerwiegenden Fehler fehlschlägt, der ihn dauerhaft außer Betrieb nimmt, könnte die Wiederholungsstrategie möglicherweise eine Verbindungszeitüberschreitung erkennen und dies als einen vorübergehenden Fehler betrachten. Der Code wiederholt den Vorgang mit einer bestimmten Anzahl von Malen und gibt dann auf. Wenn ein anderer Kunde jedoch einen Auftrag abgibt, wird der Vorgang erneut versucht, obwohl er jedes Mal fehlschlägt.

  • Um kontinuierliche Wiederholungen für Vorgänge zu verhindern, die kontinuierlich fehlschlagen, sollten Sie die Implementierung des Schaltkreistrennmusters in Betracht ziehen. Wenn Sie dieses Muster verwenden, wenn die Anzahl der Fehler innerhalb eines angegebenen Zeitfensters einen Schwellenwert überschreitet, kehren Anforderungen sofort als Fehler an den Aufrufer zurück, und es gibt keinen Versuch, auf die fehlgeschlagene Ressource oder den Dienst zuzugreifen.

  • Die Anwendung kann den Dienst regelmäßig, in unregelmäßigen Abständen und mit großen Intervallen zwischen den Anforderungen testen, um festzustellen, wann er verfügbar wird. Ein angemessenes Intervall hängt von Faktoren wie der Kritikalität des Vorgangs und der Art der Dienstleistung ab. Es kann zwischen einigen Minuten und mehreren Stunden dauern. Wenn der Test erfolgreich ist, kann die Anwendung den Normalbetrieb wieder aufnehmen und Anforderungen an den neu wiederhergestellten Dienst weiterleiten.

  • In der Zwischenzeit können Sie möglicherweise auf eine andere Instanz des Diensts (vielleicht in einem anderen Rechenzentrum oder in einer anderen Anwendung) zurückgreifen, einen ähnlichen Dienst verwenden, der kompatible (vielleicht einfachere) Funktionen bietet, oder einige alternative Vorgänge ausführen, basierend auf der Hoffnung, dass der Dienst in Kürze verfügbar ist. Beispielsweise kann es angebracht sein, Anforderungen für den Dienst in einer Warteschlange oder Datenspeicher zu speichern und sie später erneut zu versuchen. Oder Sie können den Benutzer möglicherweise zu einer alternativen Instanz der Anwendung umleiten, die Leistung der Anwendung beeinträchtigen, aber dennoch eine akzeptable Funktionalität bieten, oder nur eine Nachricht an den Benutzer zurückgeben, um anzugeben, dass die Anwendung derzeit nicht verfügbar ist.

Optimierung der Implementierung von Wiederholungsmechanismen

• Wenn Sie die Werte für die Anzahl der Wiederholungsversuche und die Wiederholungsintervalle für eine Richtlinie festlegen, berücksichtigen Sie, ob der Vorgang für den Dienst oder die Ressource Teil eines Vorgangs mit langer Ausführungsdauer oder eines Vorgangs mit mehreren Schritten ist. Es kann schwierig oder teuer sein, alle anderen operativen Schritte zu entschädigen, die bereits erfolgreich waren, wenn ein Fehler auftritt. In diesem Fall kann ein sehr langes Intervall und eine große Anzahl von Wiederholungen akzeptabel sein, solange diese Strategie keine anderen Vorgänge blockiert, indem knappe Ressourcen gehalten oder gesperrt werden.

• Überlegen Sie, ob ein erneuter Versuch desselben Vorgangs zu Inkonsistenzen in den Daten führen könnte. Wenn einige Teile eines mehrstufigen Prozesses wiederholt werden und die Vorgänge nicht idempotent sind, können Inkonsistenzen auftreten. Wenn beispielsweise ein Vorgang, der einen Wert erhöht, wiederholt wird, wird ein ungültiges Ergebnis erzeugt. Das Wiederholen eines Vorgangs, der eine Nachricht an eine Warteschlange sendet, kann zu einer Inkonsistenz im Nachrichtenverbraucher führen, wenn der Verbraucher keine doppelten Nachrichten erkennen kann. Um diese Szenarien zu verhindern, entwerfen Sie jeden Schritt als idempotenten Vorgang. Weitere Informationen finden Sie unter Idempotenzmuster.

• Berücksichtigen Sie den Umfang der wiederholten Vorgänge. Beispielsweise könnte es einfacher sein, Wiederholungscode auf einer Ebene zu implementieren, die mehrere Vorgänge umfasst und sie alle wiederholt, wenn einer fehlschlägt. Dies kann jedoch zu Idempotenzproblemen oder unnötigen Rollback-Vorgängen führen.

• Wenn Sie einen Wiederholungsbereich auswählen, der mehrere Vorgänge umfasst, berücksichtigen Sie die gesamtlatenz aller Vorgänge, wenn Sie Wiederholungsintervalle bestimmen, wenn Sie die verstrichenen Zeiten des Vorgangs überwachen und bevor Sie Warnungen für Fehler auslösen.

• Überlegen Sie, wie sich Ihre Wiederholungsstrategie auf Nachbarn und andere Mandanten in einer freigegebenen Anwendung auswirken kann, und wenn Sie freigegebene Ressourcen und Dienste verwenden. Aggressive Wiederholungsrichtlinien können dazu führen, dass für diese anderen Benutzer und Anwendungen, die die Ressourcen und Dienste gemeinsam nutzen, immer mehr vorübergehende Fehler auftreten. Ebenso kann Ihre Anwendung von den Von anderen Benutzern der Ressourcen und Dienste implementierten Wiederholungsrichtlinien betroffen sein. Für unternehmenskritische Anwendungen möchten Sie möglicherweise Premiumdienste verwenden, die nicht freigegeben sind. Dadurch erhalten Sie mehr Kontrolle über die Last und die konsequente Drosselung dieser Ressourcen und Dienste, was dazu beitragen kann, die zusätzlichen Kosten zu rechtfertigen.

Azure-Unterstützung

Die meisten Azure-Dienste und Client-SDKs bieten einen Wiederholungsmechanismus. Diese Mechanismen unterscheiden sich jedoch, da jeder Dienst unterschiedliche Merkmale und Anforderungen aufweist und jeder Wiederholungsmechanismus auf den jeweiligen Dienst abgestimmt ist. In diesem Abschnitt werden die Features des Wiederholungsmechanismus für einige häufig verwendete Azure-Dienste zusammengefasst.

Example

Ein Beispiel, das viele der in diesem Artikel erläuterten Muster verwendet, finden Sie unter zuverlässiges Web-App-Muster für .NET . Es gibt auch eine Referenzimplementierung auf GitHub.

Verwandte Links

• Trennschalter-Muster
• Wiederholungsmuster
• Drosselungsmuster
• Muster „Kompensierende Transaktion“
• Ein Blogbeitrag zu idempotenzmustern
• Verbindungsresilienz
• Einfügen von Pseudodiensten
• Dead-Letter-Queue-Muster

Zuverlässigkeitscheckliste

Lesen Sie die vollständigen Empfehlungen.