Architecture des microservices - Introduction

Microservice est une méthodologie de développement d'applications basée sur les services. Dans cette méthodologie, les grandes applications seront divisées en plus petites unités de service indépendantes. Le microservice est le processus de mise en œuvre de l'architecture orientée services (SOA) en divisant l'ensemble de l'application en un ensemble de services interconnectés, où chaque service ne répond qu'à un seul besoin métier.

Le concept du micro

Dans une architecture orientée services, des progiciels entiers seront subdivisés en petites unités commerciales interconnectées. Chacune de ces petites unités commerciales communiquera entre elles en utilisant différents protocoles pour offrir une entreprise prospère au client. Maintenant, la question est de savoir en quoi l'architecture de microservice (MSA) diffère de SOA? En un mot, SOA est un modèle de conception et Microservice est une méthodologie de mise en œuvre pour implémenter SOA ou nous pouvons dire que Microservice est un type de SOA.

Voici quelques règles que nous devons garder à l'esprit lors du développement d'une application orientée Microservice.

• Independent - Chaque microservice doit être déployable indépendamment.

• Coupling - Tous les microservices doivent être faiblement couplés les uns aux autres de sorte que les changements dans l'un n'affectent pas l'autre.

• Business Goal - Chaque unité de service de l'ensemble de l'application doit être la plus petite et capable de fournir un objectif commercial spécifique.

Prenons un exemple de portail d'achat en ligne pour comprendre le microservice en profondeur. Maintenant, décomposons tout ce portail E-commerce en petites unités commerciales telles que la gestion des utilisateurs, la gestion des commandes, l'enregistrement, la gestion des paiements, la gestion des livraisons, etc. Une commande réussie doit passer par tous ces modules dans un délai spécifique Cadre. Voici l'image consolidée des différentes unités commerciales associées à un système de commerce électronique.

Chacun de ces modules métier doit avoir sa propre logique métier et ses propres parties prenantes. Ils communiquent avec d'autres logiciels de fournisseurs tiers pour certains besoins spécifiques, ainsi qu'entre eux. Par exemple, la gestion des commandes peut communiquer avec la gestion des utilisateurs pour obtenir des informations sur les utilisateurs.

Maintenant, étant donné que vous exécutez un portail d'achat en ligne avec toutes ces unités commerciales mentionnées précédemment, vous avez besoin d'une application de niveau entreprise composée de différentes couches telles que front-end, back-end, base de données, etc. Si votre application n'est pas mise à l'échelle et complètement développé dans un seul fichier de guerre, alors il sera appelé comme une application monolithique typique. Selon IBM, une application monolithique typique doit posséder la structure de module suivante en interne où un seul point de terminaison ou application sera responsable de traiter toutes les demandes des utilisateurs.

Dans l'image ci-dessus, vous pouvez voir différents modules tels que Base de données pour stocker différents utilisateurs et données d'entreprise. Sur le front-end, nous avons différents appareils sur lesquels nous restituons généralement les données utilisateur ou professionnelles à utiliser. Au milieu, nous avons un package qui peut être un fichier EAR ou WAR déployable qui accepte la demande de la fin des utilisateurs, le traite à l'aide des ressources et le restitue aux utilisateurs. Tout ira bien jusqu'à ce que les entreprises souhaitent des modifications dans l'exemple ci-dessus.

Considérez les scénarios suivants dans lesquels vous devez modifier votre application en fonction des besoins de l'entreprise.

L'unité commerciale a besoin de quelques modifications dans le module «Recherche». Ensuite, vous devez modifier l'ensemble du processus de recherche et redéployer votre application. Dans ce cas, vous redéployez vos autres unités sans aucun changement.

Maintenant encore, votre unité commerciale a besoin de quelques changements dans le module «Check out» pour inclure l'option «portefeuille». Vous devez maintenant changer votre module «Check out» et redéployer le même dans le serveur. Attention, vous redéployez les différents modules de vos progiciels, alors que nous n'y avons apporté aucune modification. Voici le concept d'architecture orientée services plus spécifique à l'architecture Microservice. Nous pouvons développer notre application monolithique de telle manière que chaque module du logiciel se comporte comme une unité indépendante, capable de gérer une seule tâche métier de manière indépendante.

Prenons l'exemple suivant.

Dans l'architecture ci-dessus, nous ne créons aucun fichier ear avec un service compact de bout en bout. Au lieu de cela, nous divisons différentes parties du logiciel en les exposant en tant que service. N'importe quelle partie du logiciel peut facilement communiquer entre elles en utilisant les services respectifs. C'est ainsi que le microservice joue un grand rôle dans les applications Web modernes.

Comparons notre exemple de panier dans la ligne de microservice. Nous pouvons décomposer notre panier dans les différents modules tels que «Recherche», «Filtre», «Paiement», «Panier», «Recommandation», etc. Si nous voulons créer un portail de panier, nous devons créer le modules mentionnés ci-dessus de manière à pouvoir se connecter les uns aux autres pour vous offrir une bonne expérience de magasinage 24h / 24 et 7j / 7.

Avantages désavantages

Voici quelques points sur les avantages de l'utilisation de microservice au lieu d'utiliser une application monolithique.

Avantages

• Small in size- Microservices est une implémentation du modèle de conception SOA. Il est recommandé de conserver votre service autant que vous le pouvez. Fondamentalement, un service ne doit pas effectuer plus d'une tâche commerciale, il sera donc évidemment de petite taille et facile à entretenir que toute autre application monolithique.

• Focused- Comme mentionné précédemment, chaque microservice est conçu pour fournir une seule tâche métier. Lors de la conception d'un microservice, l'architecte doit se préoccuper du point focal du service, qui est son livrable. Par définition, un microservice doit être de nature full stack et doit s'engager à fournir une seule propriété commerciale.

• Autonomous- Chaque microservice doit être une unité commerciale autonome de l'ensemble de l'application. Par conséquent, l'application devient plus faiblement couplée, ce qui contribue à réduire les coûts de maintenance.

• Technology heterogeneity- Microservice prend en charge différentes technologies pour communiquer entre elles dans une seule unité commerciale, ce qui aide les développeurs à utiliser la bonne technologie au bon endroit. En mettant en œuvre un système hétérogène, on peut obtenir un maximum de sécurité, de rapidité et un système évolutif.

• Resilience- La résilience est une propriété d'isolement d'une unité logicielle. Microservice suit un niveau élevé de résilience dans la méthodologie de construction, par conséquent, chaque fois qu'une unité tombe en panne, cela n'a pas d'impact sur l'ensemble de l'entreprise. La résilience est une autre propriété qui implémente un système hautement évolutif et moins couplé.

• Ease of deployment- Comme toute l'application est sous-divisée en petites unités, chaque composant doit être de nature à pile complète. Tous peuvent être déployés dans n'importe quel environnement très facilement avec moins de complexité de temps contrairement aux autres applications monolithiques du même type.

Voici quelques points sur les inconvénients de l'architecture des microservices.

Désavantages

• Distributed system- En raison de l'hétérogénéité technique, différentes technologies seront utilisées pour développer différentes parties d'un microservice. Un vaste ensemble de professionnels qualifiés est nécessaire pour prendre en charge ce grand logiciel distribué hétérogène. Par conséquent, la distribution et l'hétérogénéité constituent l'un des principaux inconvénients de l'utilisation des microservices.

• Cost - Le microservice est coûteux, car vous devez maintenir un espace serveur différent pour différentes tâches métier.

• Enterprise readiness- L'architecture des microservices peut être considérée comme un conglomérat de différentes technologies, car la technologie évolue de jour en jour. Par conséquent, il est assez difficile de rendre une entreprise d'application de microservices prête à être comparée au modèle de développement logiciel conventionnel.

Microservice sur SOA

Le tableau suivant répertorie certaines fonctionnalités de SOA et Microservice, soulignant l'importance de l'utilisation de microservice sur SOA.