Antwort.

In verteilten Architekturen sollte die Fehlerbehandlung zentralisiert, vorhersehbar und widerstandsfähig gegenüber verschiedenen Arten von Ausfällen sein, die unvermeidlich bei der Arbeit mit Netzwerkdiensten auftreten. Es wird empfohlen, Muster wie Retry, Circuit Breaker, Timeout, Fallback und zentralisiertes Logging/M monitoring zu verwenden.

Prinzipien:

• Jeder Dienst sollte Fehler lokal behandeln und korrekte Status- und Fehlermeldungen zurückgeben;
• Das Netzwerk ist unzuverlässig – alle Aufrufe zwischen den Diensten sollten Timeouts und klare SLAs haben;
• Um Kaskadenausfälle und schnelle wiederholte Fehler zu vermeiden, wird der Circuit Breaker implementiert.

Beispiel für einen Circuit Breaker in Python mit der Bibliothek pybreaker:

import pybreaker
import requests
breaker = pybreaker.CircuitBreaker(fail_max=3, reset_timeout=60)
@breaker
def get_data():
    return requests.get('http://service/api/data', timeout=3)
try:
    response = get_data()
except pybreaker.CircuitBreakerError:
    # fallback: Rückgabe eines Stubs oder eines Fehlers
    response = 'Fallback data'

Wesentliche Merkmale:

• Schutz vor Kaskadenausfällen und "Lastverschiebung"
• Einheitliche Richtlinien für die Fehlerbehandlung und das Logging
• Möglichkeit der automatischen Wiederherstellung nach Ausfällen (Self-healing)

Fangfragen.

Kann man bei Fehlern dem Client alle Details der Ausnahme zurückgeben?

Nein. Die Details von Ausnahmen dürfen nicht offengelegt werden – das ist ein Sicherheitsrisiko. In den Antworten geben wir nur allgemeine Informationen zurück, technische Details werden in interne Systeme protokolliert.

Reicht es aus, einfach "retry" bei Netzwerkfehlern zwischen den Diensten zu implementieren?

Nein, ein "reines" Retry kann das Problem verschärfen – es ist wünschenswert, eine Strategie mit Backoff (zunehmender Verzögerung) und nicht starre Wiederholungsversuche zu implementieren.

Sollten Logs besser auf der lokalen Festplatte jedes Mikrodienstes gespeichert werden?

Nein. Die beste Lösung ist der zentrale Log-Sammelstelle (zum Beispiel mit ELK, Loki, Grafana), damit alle Logs an einem zentralen Ort für Suche und Analyse verfügbar sind.