Odpowiedź.

W architekturach rozproszonych obsługa błędów powinna być scentralizowana, przewidywalna i odporna na różne rodzaje awarii, które są nieuniknione podczas pracy z usługami sieciowymi. Zaleca się stosowanie takich wzorców jak Retry, Circuit Breaker, Timeout, Fallback oraz scentralizowane logowanie/monitoring.

Zasady:

• Każda usługa powinna lokalnie obsługiwać błędy i zwracać poprawne statusy i komunikaty;
• Sieć jest zawodna — wszystkie wywołania między usługami powinny mieć limity czasowe i wyraźne SLA;
• Aby zapobiec awariom kaskadowym i szybkim powtarzającym się błędom, wprowadza się Circuit Breaker.

Przykład Circuit Breaker w Pythonie z użyciem biblioteki 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: zwróć zastępcze dane lub błąd
    response = 'Fallback data'

Kluczowe cechy:

• Ochrona przed awariami kaskadowymi i "przeciążeniem" obciążenia
• Jednolite zasady obsługi błędów i logowania
• Możliwość automatycznego przywracania po awariach (Self-healing)

Pytania z podstępem.

Czy można przy błędach zwracać klientowi wszystkie szczegóły wyjątku?

Nie. Szczegóły wyjątków nie mogą być ujawniane — to zagrożenie dla bezpieczeństwa. W odpowiedziach zwracamy tylko ogólne informacje, szczegóły techniczne logujemy w systemach wewnętrznych.

Czy wystarczy po prostu wdrożyć "retry" przy błędach sieciowych między usługami?

Nie, "czysty" retry może pogorszyć problem — zaleca się wdrażanie strategii z backoff (rosnącym opóźnieniem), a nie sztywnych powtórzeń.

Czy lepiej przechowywać logi na lokalnym dysku każdego mikroserwisu?

Nie. Najlepszym rozwiązaniem jest scentralizowane zbieranie logów (na przykład za pomocą ELK, Loki, Grafana), aby wszystkie logi były dostępne do wyszukiwania i analizy w jednym punkcie.