Explorer l’architecture des microservices
De nos jours, il est fréquent d’entendre le terme microservices. Un microservice est un composant logiciel autonome, déployable de manière indépendante et évolutif.
Ils sont petits, focalisés sur une seule chose qu’ils font bien et peuvent s’exécuter de manière autonome. Si un microservice change, il ne devrait pas avoir d’impact sur les autres microservices de votre paysage.
En choisissant une architecture de microservices, vous allez créer un paysage de services qui peuvent être développés, testés et déployés séparément. Cela implique d’autres risques et de la complexité.
Si vous vous chargez de la création, il est préférable de suivre les interfaces et la façon dont elles interagissent. Et vous devez gérer plusieurs cycles de vie d’application au lieu d’un.
Dans une application traditionnelle, nous pouvons souvent voir une architecture multicouche.
Une couche avec l’interface utilisateur, une couche avec la logique métier et les services, et une couche avec les services de données.
Il existe parfois des équipes dédiées à l’interface utilisateur et au back-end. Quand une chose doit être modifiée, elle doit l’être dans toutes les couches.
Lors du passage à une architecture de microservices, toutes ces couches font partie du même microservice.
Seul le microservice contient une fonction spécifique.
L’interaction entre les microservices se fait de manière asynchrone.
Ils ne s’appellent pas directement, mais utilisent des mécanismes asynchrones comme des files d’attente ou des événements.
Chaque microservice a son cycle de vie et son pipeline de livraison continue. Si vous les avez créés correctement, vous pouvez déployer de nouvelles versions des microservices sans impacter les autres parties du système.
L’architecture de microservices n’est absolument pas un prérequis pour la livraison continue, mais des composants logiciels plus petits favorisent l’implémentation d’un pipeline entièrement automatisé.