© Liashko/Shutterstock.com
Entwickler Magazin
Resilienz in verteilten Systemen mit Istio oder Hystrix

O Resilience, where art thou?

Je verteilter ein Softwaresystem konzipiert wird, desto mehr sollte über Resilienz nachgedacht werden. Durch die Verteilung kann es immer wieder zu Fehlersituationen beim Aufruf der beteiligten Kommunikationspartner kommen. Um die Auswirkungen dieser Fehler möglichst gering zu halten oder eventuell ganz zu vermeiden, ist es mittlerweile üblich, mit den notwendigen Resilienzpatterns zu arbeiten. Ob man sich besser via Service-Mesh-Werkzeug oder Framework um die Resilienz kümmert? Beide Ansätze haben etwas für sich.

Michael Hofmann


Die meisten Probleme bei der verteilten Kommunikation kommen aus der Infrastruktur, wie zum Beispiel Abbrüche in der Netzwerkverbindung oder langsame Antwortzeiten bis hin zu Time-outs beim Aufruf eines anderen Service, um nur ein paar Beispiele zu nennen. Es existieren seit Jahren eine Menge Frameworks für jede gängige Programmiersprache, um diese Aufrufe abzusichern. Seit Kurzem entstehen allerdings auch sogenannte Service-Mesh-Tools, die den Einsatz von gängigen Resilienzpatterns ermöglichen. Stellt sich also die Frage, warum man Resilienz durch Programmierung in den Services erreichen soll, wenn man die Probleme der Infrastruktur auch in der Infrastruktur selbst, nämlich im Service Mesh, beheben kann.

Notwendigkeit der Resilienz in verteilten Systemen

Die Notwendigkeit von resilienter Kommunikation in verteilten Systemen ist sicherlich nicht neu. Die bekannteste Sammlung von Fehleinschätzungen, die Liste der „Fallacies of Distributed Computing“ [1], wurde schon um die Jahrtausendwende veröffentlicht. Doch jahrelang hat man sich in Projekten nicht sehr intensiv damit beschäftigt. Das lag unter anderem sicherlich daran, dass eher monolithische Systeme entstanden sind, bei denen diese Probleme nicht an erster Stelle standen. Der neue Trend, Systeme für die Cloud zu entwickeln, also Cloud-native, rückt diese Infrastrukturprobleme wieder in den Fokus. Auch in Projekten entsteht mehr und mehr das Mindset, sich diesen Problemen von Anfang an zu widmen.

Frameworks helfen

Eine Möglichkeit, Resilienz zu erreichen, ist der Einsatz von Frameworks. Die bekanntesten Vertreter im Java-Bereich sind zum Beispiel Hystrix [2], Resilience4j [3], Failsafe [4] und MicroProfile Fault Tolerance [5]. All diese Frameworks bieten mehr oder weniger Hilfe bei der Umsetzung folgender Resilienzpatterns an:

Time-out Retry Fallback Circuit Breaker Bulkhead

Bei Time-out, Retry, Circuit Breaker und Bulkhead muss der Entwickler im Grunde nur seine Aufrufmethode annotieren oder entsprechend absichern, und schon verläuft die Kommunikation fehlertoleranter. Hier ein Beispiel für einen Circuit Breaker, implementiert mit MicroProfile Fault Tolerance:

@CircuitBreaker(requestVolumeThreshold = 10, failureRatio = 0.5, delay = 1000, successThreshold = 2)public MyResult callServiceB() {...}

In einem rollierenden Fenster von zehn aufeinanderfolgenden Aufrufen (requestVolumeThreshold) wird ab einer Fehlerquote von 50 Prozent (failureRatio) der Circuit Breaker in den Status open versetzt. Nachfolgende Auf...

Entwickler Magazin
Resilienz in verteilten Systemen mit Istio oder Hystrix

O Resilience, where art thou?

Je verteilter ein Softwaresystem konzipiert wird, desto mehr sollte über Resilienz nachgedacht werden. Durch die Verteilung kann es immer wieder zu Fehlersituationen beim Aufruf der beteiligten Kommunikationspartner kommen. Um die Auswirkungen dieser Fehler möglichst gering zu halten oder eventuell ganz zu vermeiden, ist es mittlerweile üblich, mit den notwendigen Resilienzpatterns zu arbeiten. Ob man sich besser via Service-Mesh-Werkzeug oder Framework um die Resilienz kümmert? Beide Ansätze haben etwas für sich.

Michael Hofmann


Die meisten Probleme bei der verteilten Kommunikation kommen aus der Infrastruktur, wie zum Beispiel Abbrüche in der Netzwerkverbindung oder langsame Antwortzeiten bis hin zu Time-outs beim Aufruf eines anderen Service, um nur ein paar Beispiele zu nennen. Es existieren seit Jahren eine Menge Frameworks für jede gängige Programmiersprache, um diese Aufrufe abzusichern. Seit Kurzem entstehen allerdings auch sogenannte Service-Mesh-Tools, die den Einsatz von gängigen Resilienzpatterns ermöglichen. Stellt sich also die Frage, warum man Resilienz durch Programmierung in den Services erreichen soll, wenn man die Probleme der Infrastruktur auch in der Infrastruktur selbst, nämlich im Service Mesh, beheben kann.

Notwendigkeit der Resilienz in verteilten Systemen

Die Notwendigkeit von resilienter Kommunikation in verteilten Systemen ist sicherlich nicht neu. Die bekannteste Sammlung von Fehleinschätzungen, die Liste der „Fallacies of Distributed Computing“ [1], wurde schon um die Jahrtausendwende veröffentlicht. Doch jahrelang hat man sich in Projekten nicht sehr intensiv damit beschäftigt. Das lag unter anderem sicherlich daran, dass eher monolithische Systeme entstanden sind, bei denen diese Probleme nicht an erster Stelle standen. Der neue Trend, Systeme für die Cloud zu entwickeln, also Cloud-native, rückt diese Infrastrukturprobleme wieder in den Fokus. Auch in Projekten entsteht mehr und mehr das Mindset, sich diesen Problemen von Anfang an zu widmen.

Frameworks helfen

Eine Möglichkeit, Resilienz zu erreichen, ist der Einsatz von Frameworks. Die bekanntesten Vertreter im Java-Bereich sind zum Beispiel Hystrix [2], Resilience4j [3], Failsafe [4] und MicroProfile Fault Tolerance [5]. All diese Frameworks bieten mehr oder weniger Hilfe bei der Umsetzung folgender Resilienzpatterns an:

Time-out Retry Fallback Circuit Breaker Bulkhead

Bei Time-out, Retry, Circuit Breaker und Bulkhead muss der Entwickler im Grunde nur seine Aufrufmethode annotieren oder entsprechend absichern, und schon verläuft die Kommunikation fehlertoleranter. Hier ein Beispiel für einen Circuit Breaker, implementiert mit MicroProfile Fault Tolerance:

@CircuitBreaker(requestVolumeThreshold = 10, failureRatio = 0.5, delay = 1000, successThreshold = 2)public MyResult callServiceB() {...}

In einem rollierenden Fenster von zehn aufeinanderfolgenden Aufrufen (requestVolumeThreshold) wird ab einer Fehlerquote von 50 Prozent (failureRatio) der Circuit Breaker in den Status open versetzt. Nachfolgende Auf...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang