Dans les architectures distribuées, le traitement des erreurs doit être centralisé, prévisible et résistant à divers types de pannes, qui sont inévitables lors de l'utilisation de services réseau. Il est recommandé d'utiliser des modèles tels que Retry, Circuit Breaker, Timeout, Fallback et la journalisation/monitoring centralisés.
Principes :
Exemple de Circuit Breaker en Python avec la bibliothèque 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 : retourner un stub ou une erreur response = 'Données de secours'
Caractéristiques clés :
Peut-on donner au client tous les détails de l'exception en cas d'erreur ?
Non. Les détails des exceptions ne doivent pas être divulgués — c'est une menace pour la sécurité. Dans les réponses, nous ne renvoyons que des informations générales, les détails techniques étant enregistrés dans des systèmes internes.
Un simple "retry" est-il suffisant en cas d'erreurs réseau entre services ?
Non, un "retry" pur peut aggraver le problème — il est préférable de mettre en œuvre une stratégie avec un backoff (délai croissant), plutôt que des tentatives de répétition rigides.
Les journaux devraient-ils être stockés sur le disque local de chaque microservice ?
Non. La meilleure option est la collecte centralisée des journaux (par exemple, en utilisant ELK, Loki, Grafana), afin que tous les journaux soient accessibles pour la recherche et l'analyse à un seul point.