Verteilte Systeme mit Node.js

Kapitel 8. Resilienz

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

In diesem Kapitel geht es um die Resilienz von Anwendungen, d.h. die Fähigkeit, Situationen zu überstehen, die sonst zu einem Ausfall führen könnten. Im Gegensatz zu anderen Kapiteln, die sich auf Dienste außerhalb des Node.js-Prozesses konzentrierten, geht es in diesem Kapitel hauptsächlich um den Prozess selbst.

Anwendungen sollten gegen bestimmte Arten von Ausfällen resistent sein. Wenn ein nachgeschalteter Dienst wie web-api nicht mit einem vorgeschalteten Dienst wie recipe-api kommunizieren kann, gibt es viele Möglichkeiten. Vielleicht sollte er die ausgehende Anfrage wiederholen, oder er sollte auf die eingehende Anfrage mit einem Fehler antworten. Aber in jedem Fall ist ein Absturz nicht die beste Option. Wenn die Verbindung zu einer zustandsabhängigen Datenbank unterbrochen wird, sollte die Anwendung wahrscheinlich versuchen, die Verbindung wiederherzustellen, während sie auf eingehende Anfragen mit einer Fehlermeldung antwortet. Wird dagegen die Verbindung zu einem Caching-Dienst unterbrochen, ist es vielleicht am besten, dem Kunden wie gewohnt zu antworten, wenn auch auf eine langsamere, "degradierte" Weise.

In vielen Fällen ist es notwendig, dass eine Anwendung abstürzt. Wenn ein Fehler auftritt, mit dem ein Techniker nicht gerechnet hat - oft ist er global für den Prozess und nicht mit einer einzelnen Anfrage verbunden ...