En vous référant à cet article, vous pourrez vous faire une meilleure idée de l'architecture Microservice et quand l'utiliser. De plus, cet article comprend le contenu suivant.

◼ Abréviations de l'article

◼ Présentation

◼ Écosystème de microservices

◼ Architecture Monolith vs Architecture Microservice

◼ Les défis des microservices

◼ Quand utiliser les microservices

Abréviations

• API : Interface de programmation d'applications
• MS : Microservice
• NoSQL : Pas seulement SQL
• RTE : Environnement d'exécution

L'architecture de microservices est une approche du développement d'applications dans laquelle une grande application est construite comme une suite de services modulaires (cela signifie qu'il (microservice) est un type d'architecture d'application où l'application est développée comme une collection de services). Chaque module prend en charge un objectif commercial spécifique et utilise une interface simple et bien définie pour communiquer avec d'autres ensembles de services. De plus, il existe un minimum de services de gestion centralisée, qui peuvent être écrits dans différents langages de programmation tels que java, python, etc., et utiliser différentes technologies de stockage de données telles que relationnel et NoSQL dans l'architecture des microservices.

Il existe certaines fonctionnalités / caractéristiques clés des microservices comme suit.

• Hautement maintenable et testable
• Librement couplé (communiquer via une interface)
• Déployable indépendamment
• Organisé autour des capacités métiers
• Détenu par une petite équipe (équipe interfonctionnelle)

En général, le système Microservices contient les entités répertoriées suivantes. Certaines de ces entités sont des phases de développement logiciel standard et certaines d'entre elles sont des processus spécifiques aux microservices qui fourniront l'épine dorsale d'un système de microservices efficace.

Équilibreur de charge

La principale responsabilité de l'équilibreur de charge est de répartir la charge entrante entre de nombreuses instances de microservices. Il existe principalement 2 types d'équilibreurs de charge appelés découverte de client (équilibreur de charge côté client) et découverte de serveur (équilibreur de charge côté serveur). Dans la découverte du client, le client communique avec le registre de service et effectue l'équilibrage de charge. À cause de cela, le client doit connaître le registre des services. Dans la découverte du serveur, le client parle à l'équilibreur de charge et l'équilibreur de charge parle au registre de service. Par conséquent, le service client n'a pas besoin de connaître le registre des services. En regardant les diagrammes suivants, vous pouvez mieux comprendre ces 2 types d'équilibreur de charge.

Serveur de découverte de services

La fonctionnalité de découverte de service permet aux microservices de s'auto-enregistrer au démarrage au lieu de suivre manuellement les microservices déployés actuellement et les hôtes et ports dont nous avons besoin. Par conséquent, si MS1 veut parler avec MS2, MS1 obtient d'abord les détails du service de registre qui appartient au paysage, puis parle avec MS2. De plus, lorsqu'il y a un autre MS appelé MS3 qui a été up ou down dans le même paysage, le service de registre sera mis à jour automatiquement.

Passerelle API

La passerelle API est un serveur. C'est un point d'entrée unique dans un système. API Gateway encapsule l'architecture système interne. Il fournit une API adaptée à chaque client. Il a également d'autres responsabilités telles que l'authentification, la surveillance, l'équilibrage de charge, la mise en cache, la mise en forme et la gestion des demandes et la gestion des réponses statiques. API Gateway est également responsable du routage des demandes, de la composition et de la traduction du protocole. Toutes les requêtes faites par le client passent par l'API Gateway. Après cela, la passerelle API achemine les demandes vers le microservice approprié.

La passerelle API gère la demande de l'une des deux manières suivantes :

• Il a acheminé ou transmis les requêtes au service approprié.
• Répartition (répartition) d'une demande vers plusieurs services.

Nous savons maintenant que de nombreux microservices s'exécutent sur différents nœuds dans le même écosystème. Par conséquent, nous devons les surveiller ensemble dans un seul système. Le tableau de bord Hystrix et le tableau de bord d'administration de démarrage Spring sont quelques exemples d'outils de surveillance. Il existe cinq principes de surveillance des microservices comme suit :

• Surveillez les conteneurs et ce qu'ils contiennent.
• Alerte sur les performances du service.
• Surveillez les services élastiques et multi-sites.
• Surveillez les API.
• Surveiller la structure organisationnelle

Lorsque nous mettons en œuvre des microservices, ils s'exécutent sur différents RTE tels que JRE et Node.js, car la mise en œuvre des microservices peut être effectuée à l'aide de différentes technologies. Aussi, vous savez que ces microservices sont déployés de manière polyglotte. Par conséquent, les nœuds ne connaissent pas le RTE du microservice déployé et nous devons l'installer manuellement dans chaque nœud. Mais en ce qui concerne la conteneurisation, nous emballons notre RTE avec notre microservice. Par conséquent, nous pouvons exécuter les microservices partout sans tenir compte du RTE et nous pouvons gérer et mettre à jour ces services facilement.

Disjoncteur

C'est une entité très importante dans l'écosystème des microservices. La plupart du temps, cela est défini comme un modèle. À des fins de compréhension, cela ressemble à peu près au disjoncteur de votre maison. Il vous protège du désastre et il arrête la propagation du problème survenu. Le même scénario se produit ici (disjoncteur dans MS) en ce qui concerne les microservices. Supposons que le client envoie une requête au microservice fournisseur et que pendant que la réponse arrive, il y a un problème de connexion. En raison de cela, le client attend une réponse depuis longtemps et cela peut également affecter d'autres services. Depuis l'architecture du disjoncteur, le canal problématique est rejeté et le problème d'attente précédent est résolu. De plus, il existe trois états différents de disjoncteur appelés fermés, ouvert et semi-ouvert.

Architecture monolithique vs architecture microservice

Prix

• Monolithique : plus élevé une fois le projet mis à l'échelle
• Microservice : supérieur au premier stade de développement

• Monolithique : Une base de code et une base de données unifiées pour l'ensemble du produit
• Microservice : plusieurs fichiers de code ; chaque service gère une base et un stockage de données

• Monolithique : Toute la base de code doit être déployée
• Microservice : Chaque microservice est déployé individuellement

• Monolithique : la même pile de code
• Microservce : différentes piles (langue, environnement d'exécution, etc.)

Il y a quelques défis lorsque nous traitons des microservices comme suit.

• Communication inter-processus (via réseau)
• Opérations distribuées
• Un grand nombre de prestations
• Exiger plus d'automatisation

Nous avons maintenant une bonne compréhension des microservices et de leurs défis. Voyons quels scénarios conviennent pour les microservices.

• L'entreprise souhaite créer immédiatement un code propre et lisible et éviter la dette technique
• L'entreprise dispose de ressources humaines pour le développement de microservices
• L'entreprise privilégie les gains à long terme plutôt que les avantages à court terme
• Une équipe de développeurs utilise différentes piles et outils technologiques
• La plate-forme doit être hautement évolutive et s'étendre à différents marchés