Conception architecturale de microservices à l’aide de blogs / blogs Spring Boot Perficient

Qu’est-ce que l’architecture des microservices ?

Le développement de logiciels d’architecture de microservices suit une approche architecturale et organisationnelle dans laquelle de petits services indépendants communiquent entre eux via des API bien définies.

Présentation de l’architecture des microservices

L’architecture des microservices fournit un ensemble de règles et de directives pour développer un projet comme un ensemble de services faiblement couplés/découplés, et cela peut être implémenté à l’aide de Spring Boot + Spring Cloud + Netflix et de nombreux autres outils.

Dans ce projet, nous développerons chaque module en tant que microservice distinct à l’aide des contrôleurs Spring Rest et de l’environnement Spring Boot.

Serveur R&D

Une fois le projet de microservices prêt, il sera déployé dans un environnement cloud comme AWS/Azure/Google Cloud, etc., avec des outils DevOps comme Jenkins avec CI/CD, Docker, Ansible, Kubernetes ou d’autres outils.

Après avoir développé chaque microservice en tant qu’application/projet Spring Rest distinct, vous devez le publier dans un endroit commun appelé serveur R&D comme Netflix Eureka Server/Apache Zookeeper, etc.

Sur le serveur R&D, un microservice peut localiser un autre microservice et l’utiliser pour communiquer via le même serveur. Un microservice peut localiser et se connecter à d’autres microservices uniquement lorsqu’il est publié sur un serveur R&D.

Serveur de configuration

Le serveur de configuration, tel que GitHub ou GitLab, peut être utilisé pour stocker les propriétés communes avec les mêmes valeurs de plusieurs microservices.

Disjoncteur

L’interface utilisateur/le tableau de bord de l’administrateur doit être informé si des exceptions se produisent lors de l’exécution d’un seul microservice avec l’aide de disjoncteurs comme Netflix Hystrix et Resilience4J.

Client d’équilibrage de charge

Si un microservice est plus demandé, nous autorisons la création dynamique de plusieurs instances. Dans cette situation, pour récupérer la bonne instance avec moins de facteur de charge provenant d’autres microservices, nous utilisons un client Load Balancer (LBC) comme Ribbon, Feign Client, HTTP LoadBalancer, etc.

Intégrations

Puisque nous développons chaque microservice en tant qu’application Spring Rest dans l’environnement Spring Boot, nous pouvons intégrer ces applications de microservices à de nombreuses autres fonctionnalités telles que les MQ (Message Queue), le courrier, la mise en cache, le traitement par lots, etc.

Interaction avec la base de données

Les microservices peuvent interagir avec le logiciel de base de données SQL à l’aide de Spring Data JPA et avec le logiciel de base de données NoSQL à l’aide des modules Spring Data NoSQL tels que Spring Data MongoDB, Spring Data Cassendra, etc.

Interface utilisateur/tableau de bord de l’administrateur Spring Boot

Nous surveillons et gérons tous les microservices du projet à l’aide de l’interface utilisateur/du tableau de bord d’administration Spring Boot, qui a été créé avec l’aide de Spring Boot Actuators et est utile pour fournir des fonctionnalités non fonctionnelles telles que des mesures de santé sur le projet.

Journalisation et traçage distribués

Étant donné que le projet contient plusieurs microservices interagissant les uns avec les autres, nous devons effectuer des activités de journalisation et de traçage sur les multiples microservices selon les besoins. Avec la prise en charge d’outils de journalisation et de traçage distribués tels que Sleuth et Zipkin, Kibana, Splunk, etc., nous pouvons gérer et surveiller efficacement les interactions entre les microservices. Cela nous aidera à identifier et à résoudre tout problème pouvant survenir lors de la communication entre les microservices.

Application frontale

Les microservices du projet peuvent avoir différents types de clients (applications frontales), applications mobiles, applications Web MVC, applications tierces, technologies d’interface utilisateur, etc.

Passerelle API

Pour utiliser tous ces microservices et outils des différents types de clients (applications frontales), nous avons besoin d’un point d’entrée/sortie commun comme une passerelle API comme Netflix Zuul/Kong, etc., et de fonctionnalités éprouvées pour appliquer des filtres, des routeurs et des sécurités comme SSO (authentification unique).

Parfois, la communication synchrone n’est pas suffisante entre les microservices car la communication synchrone doit activer les microservices pour participer à l’interaction. Pour surmonter ce problème, nous choisissons la communication asynchrone basée sur les messages utilisant la prise en charge de MQ (Message Queue) comme Kafka, RabitMQ, ActiveMQ et JMS.

Communication synchrone

La communication synchrone signifie que deux parties en communication doivent être en mode actif à la fois. L’application client doit attendre que l’application serveur fournisse un résultat/une réponse pour générer une autre demande pour effectuer des opérations côté client.

Comme illustré ci-dessus, le client n’est pas libre de générer la requête suivante ou d’effectuer des opérations côté client jusqu’à ce que la réponse donnée liée à la requête revienne à l’application client depuis l’application serveur.

Remarque : Par défaut, toutes les communications sont des communications synchrones

a) du navigateur vers l’application Web.

b) API Rest à API Rest à l’aide du modèle Rest, etc.

Communication asynchrone

La communication asynchrone se produit lorsque deux parties en communication n’ont pas besoin d’être dans un état actif. Ici, l’application client est libre de générer la requête suivante ou d’effectuer des opérations côté client sans attendre une réponse donnée liée à la requête.

Exemple:

• Navigateur vers application Web utilisant Ajax
• Application Java vers Java utilisant des messages JMS, Active MQ, Rest API vers Rest application utilisant des messages (Kafka, JMS)