Spring Cloud et Netflix Eureka 
La clé d'une architecture microservices scalable

Spring Cloud et Netflix Eureka La clé d'une architecture microservices scalable

1- Introduction

Les architectures microservices sont devenues la norme pour les applications modernes, permettant une scalabilité et une résilience accrue. Cependant, elles introduisent aussi de nouveaux défis : comment gérer la communication entre les services, assurer la découverte dynamique et centraliser la configuration ? C'est là qu'interviennent Spring Cloud et Netflix Eureka.

1.1    Spring Cloud : un écosystème pour les microservices

Spring Cloud est un ensemble d’outils basés sur Spring Boot, conçu pour faciliter le développement d’architectures distribuées. Il apporte des solutions aux problématiques clés des microservices :

  • Gestion des configurations avec Spring Cloud Config
  • Découverte des services avec Netflix Eureka
  • Routage et passerelle API avec Spring Cloud Gateway
  • Résilience avec Hystrix (Circuit Breaker)

1.2    Netflix Eureka : le registre des microservices

Eureka est un service de découverte qui permet aux microservices de s’enregistrer et de se découvrir dynamiquement sans dépendre de configurations statiques. Il fonctionne sur un principe client-serveur :

  • Eureka Server : Stocke et met à jour dynamiquement les instances de microservices.
  • Eureka Client : Permet aux microservices de s’enregistrer et d’interroger le registre pour trouver d’autres services.

2- Evolution du modèle monolithe au modèle micro service

Dans les années précédentes et même pour certains projets en cours, les applications sont sous forme d’un gros bloc qu’on appelle monolithe. Lors du passage au modèle microservices, nous avons divisé ce monolithe en plusieurs microservices. Ces microservices communiquent entre eux via des API REST, service de messages, base de données, etc.

Dans cet article, nous allons pointer du doigt la communication via API REST

Le schéma ci-dessous montre que chaque service doit connaitre son environnement :

-          Sur lui-même. Exemple : son nom, environnement et numéro de port

-          Sur les autres services. Exemple : Leur urls, credentials ou autres propriétés

Article content

Le changement d’une propriété peut affecter plusieurs services, impliquant leur redémarrage ou leur redéploiement. Ce qui entraîne une dégradation ou interruption du service.

L’alternative étudiée dans cet article est proposée par le modèle Spring Cloud grâce à une configuration décentralisée et un changement des propriétés en temps réel grâce à Rabbit MQ

3- Présentation de la solution

Imaginons une architecture e-commerce avec deux services : Panier ( cart ) et Produit ( item ).

 

Article content

Nous avons ici 6 outils essentiels

3.1    Gestionnaire de source :

Représenté ici par l’outil GitHub ( peut être couplé avec Vault pour l’externalisation des secrets et autres informations sensibles )

Ce repository peut contenir plusieurs fichiers de configurations :

Un fichier de propriétés application.yml commun aux services. Contenant par ex :

-          L’Url du service de discovery

-          Les informations de connexion et pattern de nom des queues Rabbit MQ

 

Article content

Un fichier de propriété par service global ou/et par environnement

 

Article content

Le service cart-service a besoin du :

-          Le port du service

-          L’Url du service éditique

-          Le niveau de log d’un package

-          La propriété client Eureka

Article content

Le service de discovey ( Eureka ) a besoin du :

-          Le port du service

Article content

Le service Gateway a besoin du :

-          Le port du service

-          Les noms des services

-          Les routes des services

-          La propriété client Eureka

Article content

3.2    Config Server :

Ce service est le premier à démarrer. Il fait le lien entre la configuration git et les microsservices.

A chaque démarrage d’un service ( Discevery, Gateway, Cart, Item ), ce dernier se connecte en premier au Config Server pour connaitre ses paramètres de démarrage

Lorsqu’un fichier de configuration est modifié, un Web Hook est envoyé par GitHub au Config Server. Ce dernier envoie un message dans la queue Rabbit MQ du service concerné

Article content

3.3    Eureka Discovery Server :

Ce service est le deuxième à démarrer. Il permet d’enregistrer les services

Il doit connaitre :

-          L’URL du Config Server

-          Son environnement de déploiement ainsi que son nom afin que le Config Server

identifie quel fichier de propriétés utiliser

Article content

3.4    Gateway Server

Ce service est le troisième à démarrer. Il permet de gérer la communication entre services

Il doit connaitre :

-          L’URL du Config Server

-          Son environnement de déploiement ainsi que son nom afin que le Config Server

identifie quel fichier de propriétés utiliser

Article content

3.5    Cart Service et Item Service

Ces composants sont les services finaux. Ils communiquent entre eux via le Gateway Server

Aucun d’eux ne connait l’URL de l’autre. Grace à ce mécanisme leur adresse IP et leur ports peuvent changer sans impacter l’exécution des services

Ils doivent connaitre :

-          L’URL du Config Server

-          Leur environnement de déploiement ainsi que leur nom afin que le Config Server

identifie quel fichier de propriétés utiliser

Article content

 

   3.6 Message Provider

Représenté ici par Rabbit MQ. Il est possible aussi d’utiliser Kafka

Il permet au Config Server de partager les changements de configuration avec les composants concernés.

A chaque démarrage d’un service ( Discevery, Gateway, Cart, Item ), ce dernier crée une queue Rabbit MQ afin de recevoir les changements de configuration le concernant  

 

Article content


4- Avantages et inconvénients

  

Article content

5- Conclusion

Spring Cloud et Netflix Eureka sont des alliés puissants pour les architectures microservices.

·         Configuration : Décentralisée et en temps réel

·         Scalabilité : Ajout dynamique de nouvelles instances sans mise à jour manuelle.

·         Résilience : Redondance et découverte automatique des services en cas de panne.

·         Flexibilité : Intégration fluide avec d’autres outils de l’écosystème Spring.

Ex : Consul ( vs Eureka ), Hystrix , Sleuth, Circuit Breaker, Rate limitter

·         Enregistrement : Dynamique, autonome et anonymisation des adresses IP et des ports

La combinaison de ces composants facilite le développement, le déploiement et la gestion des microservices, permettent aux entreprises de développer des applications modernes, résilientes et évolutives.

Cette solution s’appuie sur une architecture dynamique, hautement évolutive et Cloud-Ready.

 El Hadi ELOUARET


💬 Et vous ? Avez-vous déjà utilisé Spring Cloud dans vos projets ? Quels défis avez-vous rencontrés ? Partagez votre expérience en commentaire !


To view or add a comment, sign in

Others also viewed

Explore topics