Behandeln von Teilfehlern

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

In verteilten Systemen wie microservices-basierten Anwendungen besteht ein immer vorhandenes Risiko von Teilfehlern. Beispielsweise kann ein einzelner Microservice/Container fehlschlagen oder möglicherweise nicht verfügbar sein, um für kurze Zeit zu reagieren, oder ein einzelner virtueller Computer oder Server kann abstürzen. Da Clients und Dienste separate Prozesse sind, kann ein Dienst möglicherweise nicht rechtzeitig auf die Anforderung eines Clients reagieren. Der Dienst kann überlastet sein und sehr langsam auf Anforderungen reagieren oder aufgrund von Netzwerkproblemen einfach nicht für kurze Zeit zugänglich sein.

Betrachten Sie beispielsweise die Seite "Bestelldetails" aus der Beispielanwendung "eShopOnContainers". Wenn der Bestell-Microservice nicht reagiert, während der Benutzer versucht, eine Bestellung abzugeben, würde eine fehlerhafte Implementierung des Clientprozesses (die MVC-Webanwendung) die Threads auf unbestimmte Zeit blockieren, wenn der Clientcode beispielsweise synchrone RPCs ohne Timeout verwendet und auf eine Antwort wartet. Neben der Erstellung einer schlechten Benutzererfahrung verbraucht jede nicht reagierende Wartezeit einen Thread oder blockiert einen Thread, und Threads sind in hoch skalierbaren Anwendungen äußerst wertvoll. Wenn es viele blockierte Threads gibt, könnte der Anwendungslauf schließlich keine Threads mehr zur Verfügung stehen haben. In diesem Fall kann die Anwendung global nicht mehr reagieren, sondern nur teilweise nicht mehr reagieren, wie in Abbildung 8-1 dargestellt.

Abbildung 8-1. Teilweise Fehler aufgrund von Abhängigkeiten, die sich auf die Verfügbarkeit von Servicethreads auswirken

In einer großen Microservices-basierten Anwendung kann jeder Teilfehler verstärkt werden, insbesondere, wenn die meisten internen Microservices-Interaktionen auf synchronen HTTP-Aufrufen basieren (was als Antimuster betrachtet wird). Überlegen Sie sich ein System, das Millionen eingehender Anrufe pro Tag empfängt. Wenn Ihr System über ein schlechtes Design verfügt, das auf langen Ketten synchroner HTTP-Aufrufe basiert, können diese eingehenden Aufrufe zu vielen millionen ausgehenden Anrufen führen (angenommen, ein Verhältnis von 1:4) zu Dutzenden interner Mikroservices als synchrone Abhängigkeiten. Diese Situation ist in Abbildung 8-2 dargestellt, insbesondere Abhängigkeit #3, die eine Kette startet und Abhängigkeit #4 aufruft, die dann #5 aufruft.

Abbildung 8-2. Auswirkungen eines falschen Designs mit langen Ketten von HTTP-Anforderungen

Intermittierende Fehler werden in einem verteilten und cloudbasierten System garantiert, auch wenn jede Abhängigkeit selbst über eine hervorragende Verfügbarkeit verfügt. Es ist eine Tatsache, die Sie berücksichtigen müssen.

Wenn Sie keine Techniken entwerfen und implementieren, um fehlertoleranz zu gewährleisten, können auch kleine Ausfallzeiten verstärkt werden. Wegen dieser ausbreitenden Wirkung würden zum Beispiel 50 Abhängigkeiten mit einer Verfügbarkeit von 99,99% für mehrere Stunden im Monat ausfallen. Wenn eine Microservice-Abhängigkeit fehlschlägt, während eine hohe Anzahl von Anforderungen verarbeitet wird, kann dieser Fehler alle verfügbaren Anforderungsthreads in jedem Dienst schnell gesättigt und die gesamte Anwendung abstürzen.

Abbildung 8-3. Teilweiser Ausfall, der von Mikroservices mit langen Ketten synchroner HTTP-Aufrufe verstärkt wird

Um dieses Problem zu minimieren, ermutigt Sie diese Anleitung im Abschnitt "Asynchrone Microservice-Integration zur Förderung der Autonomie von Microservices", die asynchrone Kommunikation zwischen den internen Microservices zu verwenden.

Darüber hinaus ist es wichtig, dass Sie Ihre Microservices und Clientanwendungen entwerfen, um Teilfehler zu behandeln, d. h. um robuste Microservices und Clientanwendungen zu erstellen.

ZurückWeiter