Circuit Breakers : résilience à la latence et à l’échec

Pourquoi les Circuit Breakers et Resilience4j ?

Les Circuit Breakers répondent à une problématique qui devient de plus en plus présente.

De nos jours, les systèmes informatiques sont de plus en plus découpés en services d’API.
Le Graal de ce découpage étant l’architecture distribuée en micro-services.
Un geste métier peut être rempli par une succession d’appels à des APIs bien distinctes.

Cela permet de mieux découper le système afin d’y travailler à plusieurs petites équipes Agile.
Toujours dans un souci de répondre plus rapidement aux nouveaux défis rencontrés par l’entreprise.
Mais cela permet aussi de mieux séparer le code pour qu’il soit plus maintenable et évolutif.

Par contre, ce mode de fonctionnement a l’inconvénient de fragiliser les gestes métiers.
Les gestes sont alors à la merci de problèmes réseaux ou d’indisponibilités de services.
On multiplie ici le nombre de possibilités d’échec.

Le meetup Circuit Breakers / Resilienc4j

Ce meetup a été l’occasion de découvrir la bibliothèque Resilience4j : résilience pour Java.
Nous avons vu ce qu’elle nous offre pour pallier ces inconvénients.
Enfin, nous avons vu son intégration avec Spring Boot.

Cet article résume une présentation orale lors d’un meetup.
Plus de détails sont disponibles dans les slides en bas de l’article.

Les Design Patterns de résilience

Les design patterns proposés pour gagner en stabilité ont été décrits :

• Bulkhead pour compartimenter une API lente.
  On en limitera le nombre d’appels concurrents afin qu’elle n’impacte pas les autres ;
• Rate-Limiter pour limiter le nombre d’appels par seconde a une API.
  À utiliser pour les APIs ne pouvant en supporter plus ;
• Retry pour réessayer un appel d’API idempotente qui aura échoué de manière transitoire.
  Et ainsi présenter moins d’erreurs à l’utilisateur ;
• Time-Limiter pour abandonner un appel à une API qui met un temps anormalement long à répondre ;
• Circuit-Breaker pour détecter les échecs d’une API et lui laisser le temps de récupérer.
  Après trop d’échecs, et pendant une certaine durée, on appellera par exemple beaucoup moins une API trop sollicitée.
  Ainsi, cette API aura le temps de mieux absorber la charge.
  Elle sera re-testée à faible dose avant de la déclarer comme de nouveau disponible ou pas.

Nous avons vu la configuration via Spring Boot, avec des illustrations des effets de chaque propriété.

Intégration avec Spring Boot

Nous avons vu la configuration via Spring Boot.
Et chaque propriété a été illustrée pour en comprendre ses effets.

De même, les annotations Java nécessaires à l’utilisation de cette bibliothèque ont été décrites.
Ainsi que l’ordre dans lequel ces annotations sont appliquées dans le code qu’on développe.

Show Time !

Pour terminer la conférence, nous avons eu droit à une démonstration d’un cas d’utilisation dans l’un de nos projets lillois.

Plus en détails

Vous trouverez bien sûr de plus amples détails dans les slides de la présentation :