Blog

Brève introduction à Circuit Breaker, API Gateway, BFF, Saga, CQRS, Event-Driven et plus encore.

Pour créer des logiciels évolutifs, l’ingénieur/architecte logiciel doit choisir la bonne architecture, en particulier lorsqu’il s’agit de créer des logiciels/applications d’entreprise.

L’architecture monolithique est généralement le premier choix de la plupart des ingénieurs parce qu’elle est facile et qu’elle n’a pas à gérer la complexité des systèmes distribués, car une application entière se trouve dans la même base de code géante lorsqu’il s’agit d’une livraison agile de logiciels ; l’application monolithique n’est peut-être pas le bon choix parce que lorsqu’on apporte une petite modification au code, il faut re-déployer une application entière, ce qui peut prendre du temps, et l’autre chose est que l’on ne peut même pas mettre à l’échelle les composants/services individuels.

Une erreur dans un module, une fonctionnalité ou un service peut affecter la disponibilité de l’ensemble de l’application et c’est la raison pour laquelle l’architecture microservice vient à la rescousse.

Voici les 10 modèles de microservices que vous devriez connaître en tant qu’ingénieurs logiciels.

1. API Gateway : C’est le point d’entrée pour accéder à tous les microservices et nous pouvons mettre en œuvre des préoccupations transversales telles que la sécurité, la limitation du débit et l’équilibre de la charge. Nous pouvons utiliser Spring Cloud Zuul,Spring Cloud Gateway, Azure API Gateway (mais il en existe plusieurs) pour mettre cela en œuvre.
2. Service discovery: Il permet aux services de se retrouver par l’intermédiaire d’un nom plutôt que d’une adresse IP. Pourquoi pas l’IP ? Parce que l’IP change souvent au moment de l’exécution en raison de la fréquence à laquelle les conteneurs sont lancés et détruits. Nous pouvons utiliser Spring Cloud Eureka ou le service Kubernetes pour implémenter cela.
3. Circuit breaker ou Disjoncteur (lol) : Ce modèle est très utile pour traiter les erreurs transitoires. Par exemple, lorsque le service a appelle le service b et que ce dernier n’est pas disponible (dépassement de délai), il peut renvoyer un résultat de cache comme réponse par défaut ou se rabattre sur une requête à un autre service d’aide pour obtenir le résultat et permettre au service b de se rétablir sans essayer de lui adresser d’autres requêtes. Nous pouvons utiliser Hystrix ou Resilient4J pour faire cela.
4. CQRS : nous pouvons séparer les commandes-COMMAND (écriture) et les QUERY-requêtes (lecture), ce qui signifie que nous pouvons concevoir une table de base de données optimisant l’écriture et la lecture différemment pour l’extensibilité.
5. …

Source : Lawal Alao