Où doit aller le disjoncteur ?
Je développe une nouvelle API REST et j'ai vu certains projets placer le disjoncteur dans le fichier Controller
. J'avais l'habitude de le placer dans le DAO
.
La première différence que je peux dire est que le placer dans le DAO
est que chaque service qui consomme ce tiers sera ouvert dans le scénario d'erreur. Et le placer dans le Controller
, ouvrirait ÉVENTUELLEMENT toutes les routes qui consomment ce tiers ; donc ce ne sera pas tout de suite. Mais le deuxième choix (dans le Controller
) semble plus facile à maintenir.
Une recommandation sur où devrait-il aller?
Réponses
Il y a deux parties dans cette réponse. La première partie a déjà été abordée par Robert Harvey dans son commentaire :
- Selon le catalogue de modèles de microservices de Chris Richardson, le disjoncteur doit se trouver dans un proxy pour le service distant. La passerelle API est un bon endroit pour cela.
- Une autre alternative est la découverte côté serveur, surtout si la stratégie de récupération implique de trouver d'autres instances en cours d'exécution du même service.
Mais il y a une deuxième partie. L'objectif du disjoncteur est d'échouer rapidement si le service est détecté comme étant indisponible, au lieu d'accumuler des étapes qui échoueront plus tard, créant beaucoup de frustration. Ainsi le disjoncteur ne prend tout son sens que si le service consommateur est prêt à réagir à la coupure :
- Peut-être que le service distant est indispensable, et que le service consommateur peut décider de se mettre en attente (ie disjoncteur interne).
- Peut-être que le service distant n'est pas indispensable, et le service consommateur pourrait décider de continuer à servir, mais en mode dégradé.
- (les disjoncteurs basés sur la découverte de services n'échoueront probablement pas mais trouveront un autre service fonctionnel et les consommateurs ne le remarqueront pas).
D'un point de vue général, ce type de choix dans le comportement relève de la responsabilité du contrôleur : le contrôleur coordonne entre les éléments du service, et est capable d'adapter le traitement en fonction de l'information "fail".
Cependant, si dans votre cas, il ne s'agit que d'obtenir des données d'ailleurs et si votre stratégie de traitement des erreurs est toujours la même (pas de différence entre essentiel et non essentiel ; par exemple, essayez d'utiliser une valeur en cache si disponible et échouez dans le cas contraire) vous pourrait parfaitement décider de le mettre dans le dao à mon humble avis.