SPRING CLOUD NETFLIX:

SERVICE DISCOVERY EUREKA

 1. Spring Cloud : Edge Services
1. Spring Cloud Config/ Actuator
2. Service Discovery Eureka
PLAN DU
3. Mise en place du service Eureka
COURS
4. Spring Cloud Consul
5. Ribbon Load Balancer
6. API Gateway Zuul
7. Hystrix
8. Zipkin
 SERVICE DISCOVERY : EUREKA

▪ Quand l’application répond à une montée en charge et que plusieurs microservices

et plusieurs instances de chaque microservice sont instanciées/clonées, il est vital
de pouvoir garder un registre de toutes les instances disponibles afin de distribuer la
charge entre celles-ci.

▪ Comment garder la trace des URL des différentes instances disponibles, ainsi que
leurs états ? → Eureka Server de Netflix remplit cette fonction.

▪ Eureka est le serveur et client de Découverte/Discovery du service Netflix.

▪ Le Discovery Services est l'un des principes clés d'une architecture basée sur les
microservices.
 SERVICE DISCOVERY : EUREKA

▪ Une fois en place, les instances des microservices viennent s'enregistrer (Service

Registration) dans le registre d'Eureka. Par la suite et pour appeler un microservice,

il suffira de piocher dans cette liste d'instances qu'Eureka expose via une API REST.

▪ Eureka offre également un client capable de réaliser des opérations de récupération

(Discovery) des listes d'instances.

▪ Le serveur peut être configuré et déployé pour être hautement disponible (cluster

mode), chaque serveur répliquant l'état des services enregistrés sur les autres.
 EDGE MICROSERVICES EUREKA

▪ Eureka se propose en Annuaire ou « naming server » : @EnableEurekaServer

▪ Grâce à une annotation de Eureka, toute nouvelle instance du microservice va être

enregistrée auprès d'Eureka : @EnableDiscoveryClient

▪ Le client va consulter ce registre pour trouver les instances disponibles d'un

microservice donné.

▪ Eureka s'occupe également de vérifier régulièrement si chaque instance enregistrée est

toujours disponible, afin de mettre à jour son registre en éliminant celles qui n'existent

plus.
 SERVICE DISCOVERY : EUREKA

▪ Remarquez que :

▪ La possibilité d’avoir un

« Cluster mode » du

Serveur Eureka

▪ Eureka Server utilise les

services de Spring Cloud

Config Server pour

Externaliser sa

configuration Configuration
 EUREKA SERVER
▪ Utiliser le starter Spring cloud Discovery
 EUREKA SERVER
▪ Externalisez le fichier de configuration en créant un fichier eureka-server.properties dans config-server-repo.

server.port= 9102
spring.application.name=eureka-server
eureka.client.registerWithEureka=false
eureka.client.fetchRegistry=false

▪ On définit le port sur lequel Eureka Server sera accessible : 9102

▪ eureka.client.serviceUrl.defaultZone : quand on utilise le client Eureka pour accéder au registre d'Eureka, on doit

renseigner cette ligne de configuration pour pointer vers l'URL d'Eureka.

▪ registerWithEureka : pourquoi renseigner l'URL d'Eureka si ce microservice est déjà enregistré dans Eureka ?
→ Eureka offre la possibilité de se répliquer en plusieurs instances ; on peut pointer vers d'autres instances
d'Eureka.
→ Ce mode s'appelle "cluster mode". Comme nous n'allons utiliser qu'un seul serveur Eureka, nous allons
pointer vers sa propre URL.

▪ eureka.client.registerWithEureka et eureka.client.fetchRegistry sont tous les 2 à false, étant donné que nous

n'allons pas utiliser Eureka en mode cluster.

 EUREKA SERVER : GESTION DU REGISTRE DES INSTANCES DES MICROSERVICES.

▪ Lors du démarrage, les microservices déclenchent un appel REST avec le serveur Eureka pour s'auto-enregistrer dans le

registre d'instance du serveur. Lorsqu'un arrêt progressif se produit après utilisation, les microservices déclenchent un

autre appel REST afin que le serveur puisse effacer toutes les données liées à l'appelant.

▪ Pour gérer les arrêts clients inattendus, Eureka server attend des Heartbeats du client à des intervalles spécifiques.

C’est ce qu’on appelle le « Renewal ». Si Eureka server cesse de recevoir le signal de présence pendant une durée

spécifiée, il commencera à expulser les instances jugées obsolètes

▪ Le mécanisme qui arrête l'expulsion des instances lorsque les Heartbeats sont inférieurs au seuil attendu est appelé

« self-preservation ». Cela peut se produire dans le cas d'une mauvaise partition réseau, où les instances sont toujours

actives, mais ne sont tout simplement pas accessibles pendant un moment ou dans le cas d'un arrêt brutal du client.

▪ Lorsque le serveur active le mode « self-preservation », il suspend l'expulsion de l'instance jusqu'à ce que le taux de

renouvellement repasse au-dessus du seuil attendu. Dans ce mode, le serveur Eureka cesse d'expirer les instances si

les instances restantes tombent en panne.

 EUREKA SERVER : GESTION DU REGISTRE DES INSTANCES DES MICROSERVICES.

▪ Lorsque le serveur active le mode « self-preservation »,

 EUREKA SERVER : GESTION DU REGISTRE DES INSTANCES DES MICROSERVICES.
▪ Lorsque le serveur active le mode « self-preservation »,
 EUREKA SERVER : GESTION DU REGISTRE DES INSTANCES DES MICROSERVICES.

▪ eureka.server.enable-self-preservation : configuration pour désactiver self-preservation – la valeur

par défaut est true

▪ eureka.server.expected-client-renewal-interval-seconds : le serveur attend des Heartbeats du client

à un intervalle configuré avec cette propriété – la valeur par défaut est 30

▪ eureka.instance.lease-expiration-duration-in-seconds : indique le temps en secondes pendant

lequel le serveur Eureka attend depuis qu'il a reçu le dernier Heartbeat d'un client avant de pouvoir

supprimer ce client de son registre - la valeur par défaut est 90

▪ eureka.server.eviction-interval-timer-in-ms : cette propriété indique au serveur Eureka d'exécuter

une tâche à cette fréquence pour expulser les clients expirés – la valeur par défaut est de 60

secondes.
 EUREKA SERVER : GESTION DU REGISTRE DES INSTANCES DES MICROSERVICES.

▪ eureka.server.renewal-percent-threshold : sur la base de cette propriété, le serveur calcule les

Heartbeats attendus par minute de tous les clients enregistrés – la valeur par défaut est 0,85

▪ eureka.server.renewal-threshold-update-interval-ms : cette propriété indique au serveur

Eureka d'exécuter une tâche à cette fréquence pour calculer les battements de cœur attendus

de tous les clients enregistrés à cette minute – la valeur par défaut est de 15 minutes.

▪ Le serveur définit le seuil de renouvellement « Renews threshold » qu'il doit recevoir. Si à un

moment donné, les renouvellements tombent en dessous du pourcentage configuré pour cette

valeur (inférieur à 85 % en 15 minutes), le serveur arrête les instances qui expirent pour

protéger les informations de registre d'instance actuelles.

 EUREKA SERVER : GESTION DU REGISTRE DES INSTANCES DES MICROSERVICES.
▪ Exemple avec 6 MS
▪ Renews threshold : 11 =~ 2 * 6* 0,85
▪ Renews ( last min) : 12 = 2 * 6
 EUREKA SERVER : GESTION DU REGISTRE DES INSTANCES DES MICROSERVICES.

▪ eureka.server.renewal-percent-threshold : sur la base de cette propriété, le serveur calcule les

Heartbeats attendus par minute de tous les clients enregistrés – la valeur par défaut est 0,85
 EUREKA SERVER

▪ Vérifier que Eureka Server a été bien enregistré dans notre Spring Cloud Config Server

http://localhost:9101/eureka-server/master
 EUREKA SERVER
▪ Config-server doit être lancé, puis lancer Eureka Server.

: Fetching config from server at : http://localhost:9101

: Located property source: {name='bootstrapProperties-https://github.com/abdel69/mcommerce-config-repo.git/eureka-
server.properties'}]
c.m.e.EurekaserverApplication : No active profile set, falling back to 1 default profile: "default"
: Tomcat initialized with port(s): 9102 (http)
: Starting Servlet engine: [Apache Tomcat/9.0.82]
: Initiating Jersey application, version 'Jersey: 1.19.4 05/24/2017 03:20 PM'
: Using JSON encoding codec LegacyJacksonJson
: Eureka HTTP Client uses Jersey
: Discovery Client initialized at timestamp 1697913061490 with initial instances count: 0
: Exposing 1 endpoint(s) beneath base path '/actuator'
: Registering application EUREKA-SERVER with eureka with status UP
: Started Eureka Server
: Tomcat started on port(s): 9102 (http) with context path ''
: Started EurekaserverApplication in 6.019 seconds (JVM running for 6.316)
 EUREKA SERVER
▪ Config-server doit être lancé, puis lancer Eureka Server. et Accéder à http://localhost:9102/
 EUREKA CLIENT
▪ Afin que les différents microservices commencent à s'enregistrer dans le serveur Eureka, ils doivent ajouter le client

Eureka à chacun d'entre eux.

1. Au niveau du Microservices-produits → dans le pom.xml ajoutez cette dépendance :

<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

2. Ajoutez ensuite la ligne à microservice-produits.properties dans le dépôt :

#Eureka :indique l'URL d'Eureka à laquelle il faut s'enregistrer:

eureka.client.serviceUrl.defaultZone: http://localhost:9102/eureka/

3. Ajoutez l'annotation @EnableDiscoveryClient dans la classe principale du micoservice Produit MproduitsApplication

 EUREKA CLIENT

▪ Au démarrage de Eureka Server on remarque :

Registered instance MICROSERVICE-PRODUITS/@IP-machine:microservice-produits:9001 with status

UP (replication=false)

▪ Le microservice est enregistré avec un statut "UP" indiquant qu'il est en fonction.

▪ Si vous arrêtez le Microservice-produits, vous verrez qu'Eureka le détecte immédiatement, et le supprime du

registre !
 EUREKA CLIENT
▪ Le service micorservice produit s’est bien enregistré
 PROJET CONSUL DE HASHICORP

▪ « Consul » est un projet développé par l’entreprise « HashiCorp »,

constitué d’un ensemble de composants qui fournissent des fonctionnalités de découverte et de configuration de

services, à l’échelle d’une infrastructure.

▪ HashiCorp est une société de logiciels fondée en 2012 avec un modèle commercial Freemium basée à San

Francisco, en Californie.

▪ HashiCorp fournit des outils et des produits qui permettent aux développeurs, opérateurs et professionnels de la

sécurité de provisionner, sécuriser, exécuter et connecter une infrastructure de cloud. HashiCorp propose des

bibliothèques sources disponibles et des produits propriétaires.

 PROJET CONSUL
▪ « Consul » combine les fonctionnalités suivantes:

1. Service Discovery:

Les clients Consul enregistrent des services comme une base de

données ou une API. D’autres clients peuvent ainsi utiliser Consul afin
de découvrir dynamiquement l’emplacement de ces services via des
requêtes DNS ou REST API.

2. Health Check:

Les Clients Consul publient des Healh Checks associés aussi bien à des
applications, du plus simple (Etat de la base de données, Réponse valide
du Web Service) au plus complexe (Nombre d’utilisateurs/sessions
actives, temps de réponse moyen des requêtes), mais aussi à des états
des machines (Consommation Mémoire, utilisation CPU).

Ces informations servent à la fois au monitoring du cluster ainsi qu’au

système de découverte afin d’éviter de router des requêtes vers des
nœuds inaccessibles.

3.Key/Value Store

Les applications peuvent utiliser Consul comme un système de stockage

clé/valeur hiérarchique au travers d’une simple API REST.
 ARCHITECTURE HCP CONSUL
▪ HashiCorp Cloud Platform (HCP) Consul connecte les composants hébergés et maintenus dans des environnements cloud
gérés par HashiCorp avec des composants hébergés et maintenus dans des environnements cloud gérés par les
utilisateurs.

▪ Le shéma suivant décrit l'architecture d'un déploiement HCP Consul qui contient à la fois un cluster géré par HashiCorp et
un cluster autogéré :
 FONCTIONNEMENT DE CONSUL

▪ Consul est construit autour d’un exécutable, l’Agent, qui est utilisable au travers deux configurations, les « Serveurs » et les « Clients »:

▪ L’Agent

L’agent est un daemon qui s’exécute sur tous les membres du cluster Consul. Un agent peut s’exécuter en mode ‘Client’ ou ‘Serveur’.

Tous les agents exposent les interfaces DNS et REST. Ils sont aussi responsables de l’exécution des HealhChecks et maintiennent la
synchronisation des services.

▪ Clients

Les Clients sont des agents dont les seuls rôles sont de faire suivre les requêtes aux Serveurs et de participer au ‘LAN GOSSIP’. Ils ne
consomment donc que peu de ressources locales et réseaux.

▪ Serveur

Au nombre minimum de trois par Datacenter, les Serveurs ont la charge de participer à la gestion du consensus au travers de l’algorithme
RAFT (RAFT quorum) pour la gestion de la tolérance aux pannes et au performance du système, monitorer l’état du cluster, faire suivre les

requêtes aux leaders et aux autres datacenters, répondre aux requêtes et participer aux échanges du ‘WAN GOSSIP’.
 EUREKA CLIENT SPRING CLOUD CONSUL

▪ Le projet Spring Cloud Consul fournit des intégrations Consul pour les applications Spring Boot via la

configuration automatique.

▪ Avec quelques annotations, on peut rapidement activer et configurer les modèles courants au sein de

l’application et créer de grands systèmes distribués avec des composants basés sur Consul.

▪ Fonctionnalités de Spring Cloud Consul :

▪ Registry/Discovery and Config Services: les instances peuvent être enregistrées auprès de l'agent Consul et les

clients peuvent découvrir les instances à l'aide de beans gérés par Spring : spring-cloud-starter-consul-discovery et spring-

cloud-starter-consul-config .

▪ Prend en charge Spring Cloud LoadBalancer : un équilibreur de charge côté client fourni par Spring Cloud

(équivalent à Ribbon)

▪ Prend en charge API Gateway, un routeur dynamique et un filtre via Spring Cloud Gateway (équivalent à Zuul)

▪ Configuration distribuée : utilisation du magasin de clés/valeurs Consul

EUREKA CLIENT SPRING CLOUD CONSUL

▪ Lorsque un microservice s'exécute, il se connecte à l'agent Consul exécuté sur le port local 8500 par défaut.

▪ Les propriétés correspondantes sont spring.cloud.consul.host et spring.cloud.consul.host port

▪ Lorsqu'un microservice s'inscrit auprès de Consul, il fournit des métadonnées le concernant telles que l'hôte et

le port, l'identifiant. Un Check HTTP est créée par défaut et Consul atteint ce Endpoint via /actuator/health

toutes les 10 secondes. Si la vérification de l'état échoue, l'instance de service est marquée comme critique

▪ On peut utiliser DiscoveryClient Builder pour

récupérer les données des services et des instances

de Consul:
Service Registry

1 2

Spring cloud