Strategien zum Umgang mit Teilversagen

Tipp

Dieser Inhalt ist ein Auszug aus dem eBook .NET Microservices Architecture for Containerized .NET Applications, verfügbar auf .NET Docs oder als kostenlose herunterladbare PDF, die offline gelesen werden kann.

PDF herunterladen

Verwenden Sie zum Behandeln von Teilfehlern eine der hier beschriebenen Strategien.

Verwenden Sie asynchrone Kommunikation (z. B. nachrichtenbasierte Kommunikation) über interne Microservices hinweg. Es ist dringend ratsam, keine langen Ketten synchroner HTTP-Aufrufe über die internen Microservices hinweg zu erstellen, da das falsche Design schließlich die Hauptursache für schlechte Ausfälle wird. Abgesehen von der Front-End-Kommunikation zwischen den Clientanwendungen und der ersten Ebene der Mikroservices oder feinkörnigen API-Gateways wird empfohlen, nach dem anfänglichen Anforderungs-/Antwortzyklus, nur noch eine asynchrone (nachrichtenbasierte) Kommunikation über die internen Mikroservices hinweg zu nutzen. Letztendliche Konsistenz und ereignisgesteuerte Architekturen helfen, Welleneffekte zu minimieren. Diese Ansätze erzwingen eine höhere Ebene der Mikroserviceautonomie und verhindern daher das hier erwähnte Problem.

Wiederholungen mit exponentiellem Backoff verwenden: Diese Technik hilft, kurze und intermittierende Ausfälle zu vermeiden, indem Anrufe eine bestimmte Anzahl von Malen wiederholt werden, falls der Dienst nur für eine kurze Zeit nicht verfügbar war. Dies kann aufgrund von zeitweiligen Netzwerkproblemen auftreten oder wenn ein Microservice/Container in einen anderen Knoten in einem Cluster verschoben wird. Werden diese Wiederholungen jedoch nicht ordnungsgemäß mit Trennschaltern entworfen, kann dies die Welleneffekte verschärfen und letztendlich zu einem Denial-of-Service-Angriff (DoS) führen.

Netzwerktimeouts umgehen: Clients sollten so konzipiert werden, dass sie nicht auf unbestimmte Zeit blockiert sind und Timeouts beim Warten auf einer Antwort verwenden. Durch die Verwendung von Timeouts wird sichergestellt, dass Ressourcen niemals unbegrenzt gebunden sind.

Verwenden Sie das Circuit Breaker Pattern. Bei diesem Ansatz verfolgt der Clientprozess die Anzahl der fehlgeschlagenen Anforderungen. Wenn die Fehlerrate einen konfigurierten Grenzwert überschreitet, wird ein "Schutzschalter" ausgelöst, sodass weitere Versuche sofort fehlschlagen. (Wenn eine große Anzahl von Anforderungen fehlschlägt, ist der Dienst nicht verfügbar und das Senden von Anforderungen ist sinnlos.) Nach einem Timeoutzeitraum sollte der Client es erneut versuchen und, wenn die neuen Anforderungen erfolgreich sind, den Schaltkreisschalter schließen.

Stellen Sie Fallbacks bereit. Bei diesem Ansatz führt der Clientprozess Fallbacklogik aus, wenn eine Anforderung fehlschlägt, z. B. das Zurückgeben zwischengespeicherter Daten oder eines Standardwerts. Dies ist ein Ansatz, der für Abfragen geeignet ist und komplexer für Updates oder Befehle ist.

Beschränken Sie die Anzahl der in die Warteschlange gestellten Anforderungen. Clients sollten auch eine obere Grenze für die Anzahl der offenen Anforderungen auferlegen, die ein Client-Microservice an einen bestimmten Dienst senden kann. Wenn der Grenzwert erreicht wurde, ist es wahrscheinlich sinnlos, zusätzliche Anforderungen zu stellen, und diese Versuche sollten sofort fehlschlagen. Im Hinblick auf die Implementierung kann die Polly Bulkhead Isolation-Richtlinie verwendet werden, um diese Anforderung zu erfüllen. Dieser Ansatz ist im Wesentlichen ein Parallelisierungsregler mit SemaphoreSlim als Implementierung. Außerdem ist eine "Warteschlange" außerhalb des Sperrkopfs zulässig. Sie können überschüssige Last bereits vor der Ausführung reduzieren (z. B. weil die Kapazität als ausgelastet angesehen wird). Dadurch wird die Reaktion auf bestimmte Fehlerszenarien schneller als bei einem Schaltschalter, da der Schaltkreisschalter auf die Fehler wartet. Das BulkheadPolicy-Objekt in Polly gibt an, wie voll der Bulkhead und die Warteschlange sind, und bietet Überlaufereignisse an, damit er auch für die automatisierte horizontale Skalierung verwendet werden kann.

Weitere Ressourcen

• Resilienzmuster
  https://learn.microsoft.com/azure/architecture/framework/resiliency/reliability-patterns

• Hinzufügen von Resilienz und Optimieren der Leistung
  https://learn.microsoft.com/previous-versions/msp-n-p/jj591574(v=pandp.10)

• Bulkhead: GitHub-Repository. Implementierung mit Polly-Richtlinie.
  https://github.com/App-vNext/Polly/wiki/Bulkhead

• Entwickeln robuster Anwendungen für Azure
  https://learn.microsoft.com/azure/architecture/framework/resiliency/app-design

• Behandeln vorübergehender Fehler
  https://learn.microsoft.com/azure/architecture/best-practices/transient-faults

ZurückWeiter