EDGE MICROSERVICES

SPRING CLOUD CONFIG

 1. Spring Cloud : Edge Services
1. Spring Cloud Config
2. Service Discovery Eureka
PLAN DU 3. Ribbon Load Balancer

COURS 4. API Gateay Zuul

5. Zipkin

2. Spring Cloud Config : Configuration

Externalisée
3. Mise en œuvre de microservices basés sur
Spring Cloud Config
 EDGE MICROSERVICES
▪ Les Edge Microservices sont des microservices techniques spécialisés dans l'orchestration des microservices responsables de la logique applicative et métier.

▪ Les Edge Microservices les plus populaires sont ceux publiés et utilisés par Netflix pour sa plateforme puis par la communauté de spring cloud.

▪ Ils sont en grande partie regroupés sous Spring Cloud, et disposent de fonctionnalités pour fonctionner nativement ensemble.

▪ Ces Edge Microservices répondent chacun à un problème particulier.

▪ Ci-après les principaux Edge Services que nous allons détailler dans les prochains chapitres:

1.Spring Cloud Server Config

2.Eureka Service Dicovery & Registry

3.ZuuL API Gateway ou Proxy

4.Spring Ribbons

5.Spring Actuator

6.Spring ZipKin
 EDGE MICROSERVICES

▪ Exemple de mise en œuvre des microservices

▪ Un point d’entrée unique de l’application

▪ Orchestration des différents microservices

▪ Cette architecture et orchestration ne seraient pas

possible d’il n’y avait pas les Edge Services

 EDGE MICROSERVICES

▪ Exemple de déploiement des microservices

ORCHESTRATION DES MICROSERVICES
ORCHESTRATION MICROSERVICES
 EDGE MICROSERVICES SPRING CLOUD CONFIG

1. La configuration Spring Cloud Config

▪ Les microservices et leurs différentes instances reposent sur des fichiers de configuration tels que

application.properties.

▪ Quelques problématiques : Changement des propriétés et déploiement à chaud/froid ? Blocage lors des mises à

jour applicative ? Redémarrage ?

▪ La solution Spring Cloud Config permet de centraliser tous les fichiers de configuration dans un dépôt GIT, et se

positionne comme serveur de fichiers de configuration : @EnableConfigServer

▪ Quand un fichier de configuration est mis à jour dans le dépôt GIT, Spring Cloud Config se met à servir cette

nouvelle version, obligeant le microservice à le prendre en compte à la volée.

 EDGE MICROSERVICES EUREKA

2. Le Service d’enregistrement et le Service Discovery Eureka

▪ En cas de grande charge sur l’application, on va ajouter plusieurs instances d'un microservice.

▪ Comment garder la trace des URL des différentes instances disponibles, ainsi que leurs états ?

▪ 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.
 EDGE MICROSERVICES ZUUL
4. API Gateway/Proxy ZUUL

▪ Exemple d’une application e-commerce:

▪ L'affichage d'une fiche produit repose sur des dizaines de microservices. Il y aura des microservices pour : les images, le

pricing, les recommandations, les textes et caractéristiques des produits, un comparateur, la livraison, etc.

▪ Quand le client voudra afficher cette fiche produit, il devra faire appel à tous ces microservices.

▪ Cela implique de les identifier, de repérer leurs instances, de s'authentifier auprès de chacun d'entre eux pour accéder aux

ressources, de transformer le résultat reçu pour qu'il soit adapté au type d'appareil, etc.

▪ Comment résoudre cette complexité ?

▪ La solution est d'installer un point d'entrée unique vers les microservices : L’API Gateway ou Proxy

▪ L'API Gateway proposée s'appelle ZUUL : plusieurs avantages tels que la sécurité (plus besoin de sécuriser

chaque microservice), il suffit d'imposer les règles d'authentification et de sécurité à ZUUL.

▪ Zuul peut être considéré comme un proxy inverse (Reverse Proxy) qui sert de point d’entrée à tous les

micorservices constituant l’application.

 EDGE MICROSERVICES RIBBON

3. L'équilibrage de la charge (Load Balancing) Ribbon

▪ Les microservices sont découplés et autonomes. Quand on a plusieurs instances d'un microservice, il faut

équilibrer la charge entre celles-ci.

▪ On ne peut pas utiliser un équilibreur de charge central classique, car celui-ci limiterait la résilience de l’application

en créant un SPOF (Single Point Of Failure) : Point de défaillance unique

▪ Comment permettre à chaque microservice de faire appel à un autre directement, sans être dépendant d'un Load

Balancer central ?

▪ La solution est Ribbon : ce load Balancer côté client est capable d'indiquer directement, depuis le microservice,

quelle instance du microservice distant appeler.

▪ Zuul utilise Ribbon en interne pour appeler les URL distantes et les clients Ribbon sont par défaut chargés de

manière LAZY par Spring Cloud lors du premier appel.

 EDGE MICROSERVICES ACTUATOR

3. Spring boot Actuator

▪ Spring Boot Actuator ajoute à chaque microservice un ensemble de fonctionnalités permettant de les

débugger, de les surveiller de recharger la configuration à chaud …

▪ Spring Boot Actuator n'est pas un Edge Microservice en soi, mais une dépendance à ajouter au

microservice qu’on voudrait surveiller :

▪ La configuration d’Actuator se fait via la ligne management.endpoints.web.exposure.include=* : Expose

l’ensemble des services disponoibles (~24)

▪ Actuator expose des endpoints/API qui fournissent des données sur des aspects du microservice
EDGE MICROSERVICES ACTUATOR
management.endpoints.web.exposure.include=*
 EDGE MICROSERVICES ACTUATOR

3. Exemple avec le service « Refresh »

▪ management.endpoints.web.exposure.include=refresh

▪ localhost:9001/actuator/refresh → Request method 'GET' not

supported] : il faut utiliser la méthode POST au lieu de GET

▪ localhost:9001/actuator/refresh → Request method 'GET' not

supported] : il faut utiliser la méthode POST au lieu de GET

▪ Appel de l’API via Postman :

→ Résultat : présenter les propriétés qui ont été modifiées

depuis le dernier commit

 EDGE MICROSERVICES ACTUATOR

3. Exemple du service «health»

▪ Permet de tester si le microservice est opérationnel.

▪ Utilisé dans la surveillance en temps réel des instances en cours d'exécution des microservices

via un check régulier de cet endpoint

▪ Cet endpoint fonctionne en analysant le retour de toutes les classes qui héritent

de HealthIndicator,

▪ Chacune de ces classes doit effectuer ses tests, et dire si le service est UP ou DOWN.

▪ Il est possible de créer son propre indicateur afin de tester si le microservice fonctionne

correctement en fonction des critères contextuels du microservice : Exemple du microservice-

produit
 EDGE MICROSERVICES ZIPKIN

5. Le traçage des requêtes Zipkin

▪ Dans une architecture microservice, la requête doit traverser plusieurs microservices avant d'aboutir.

▪ Par exemple dans une application m-commerce, dans laquelle la requête de demande de paiement envoyée par le client

déclenche dans le Microservice-produits une autre requête vers le Microservice-commandes, afin de mettre à jour le statut de la

commande.

▪ Si une erreur est retournée, il est difficile de savoir si elle s'est produite au niveau du Microservice-produits ou au niveau du

Microservice-commandes.

▪ Quel serait la situation si la requête devait traverser 25 microservices avant d'aboutir !

▪ Comment identifier le microservice posant problème ?

▪ Zipkin permet de suivre les requêtes de microservice en microservice, et consulte les différentes réponses et

interactions afin de cibler directement le problème.

 CONFIGURATION NON EXTERNALISÉE

▪ Use case (1) : Microservice produit avec sa propre configuration (non

externalisée)

▪ Créer une valeur limite du nombre de produits à retourner quand on

fait appel à l'URI /Produits

▪ Au niveau du fichier « application.properties » Ajouter la propriété :

mes-configs.limitDeProduits= 4

▪ Veiller à ce que tous les noms des propriétés soient précédés d'un
préfixe afin qu'elles soient identifiables: Dans notre cas, le préfixe est
mes-configs

▪ Afin de récupérer les valeurs que nous avons indiqué dans

application.properties , on va utiliser @ConfigurationProperties dans
une classe de configuration dédiée ApplicationPropertiesConfiguration
 CONFIGURATION NON EXTERNALISÉE

▪ @Component : demande à Spring de scanner cette

classe à la recherche de configurations.

▪ @ConfigurationProperties("mes-configs") : précise que

cette classe de configuration va récupérer des propriétés
dans application.properties dont le préfixe est mes-
configs.

▪ Déclarer des propriétés avec les mêmes noms que celles

du fichier de configuration. Dans notre cas, il s'agit de
limitDeProduits

▪ Il suffit de retourner dans le contrôleur pour accéder aux

valeurs de manière simple.
 CONFIGURATION NON EXTERNALISÉE

▪ Accéder aux valeurs de la configuration du

microservice à partir du Controller.

▪ appProperties.getLimitDeProduits() va retourner le
chiffre 4 défini dans le fichier de configuration.

▪ On le passe subList qui coupe une liste donnée à la

limite donnée en 2e argument.

▪ http://localhost:8080/Accueil, va retourner les 4

premiers produits
 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE
▪ Afin d'externaliser les fichiers de configuration, on va se baser sur les « Edge Microservice » appelé Spring Cloud Config qui
se positionne comme serveur de distribution des fichiers de configuration.

▪ Placer tous les fichiers de configuration dans un dépôt GIT. Grâce à des conventions de nommage de fichiers, Spring Cloud
Config est capable de savoir quel fichier va servir à quel microservice, en se basant sur le nom du microservice.

▪ Pour modifier plus tard la configuration d'un microservice, il suffira de pousser les changements dans le GIT. Spring Cloud
Config se mettra à servir la nouvelle version. Pas besoin d'arrêter les microservice !
 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE
▪ Architecture :
 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE

▪ Créer le dépôt GIT dans lequel iront les fichiers de configuration:

mcommerce-config-repo: https://github.com/xxxx69/mcommerce-
config-repo.git

▪ Au niveau de la machine locale, créer le nouveau dossier config-

server-repo « D:\workspace_2022\config-server-repo»

▪ Mettre dans ce dossier les fichiers de configuration des microservices.

▪ Optionnel : Créer un projet sur Eclisme et y mettre les fichiers de

configurations de MS.

▪ le dom du fichier est « microservice-produit.properties » et doit

correspondre exactement au nom donné au Microservice-produits
dans application.properties.

▪ Grâce à cette correspondance de noms que le serveur de

configuration fera le lien entre ce fichier et le microservice
correspondant.
 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE

▪ Couper le contenu de « application.properties » du Microservice-produits, excepté le nom de celui-ci, et coller le

tout dans le nouveau fichier créé :

microservice-produits.properties

▪ Dans application.properties du Microservice-produits, il reste :

 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE
• Pointer vers le dossier créé. cd config-server-repo/
• Initialiser un nouveau dépôt GIT local que nous allons pousser plus tard vers le distant :
• git init
 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE
• Ajoutez les fichiers du dossier au GIT :git add

• https://github.com/xxxx69/mcommerce-config-repo.git

• Git commit puis git push du fichier

 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE
• git push -u origin master
• https://github.com/settings/tokens
• User name : xxxx69 + Token et non pas le mot de passe
• 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
SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE
 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE
• Branch : master
 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE
• Création du serveur de configuration à partir de Spring Initializr, : se baser sur le starter Spring Cloud Config

spring.cloud.compatibility-verifier.enabled=false
spring.application.name=config-server
server.port:9101
spring.cloud.config.server.git.uri=https://github.com/xxxx69/mcommerce-config-repo.git
spring.cloud.config.server.git.default-label=master

• Convention : Tous les Edge Microservices seront sur des ports commençant par 91.
• Celui de config-server est donc 9101. N'oubliez pas de renseigner également son nom (config-server).
 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE
• Ajouter l’annotation @EnableConfigServer pour indiquer que ce microservice comme étant un serveur de
configuration

• http://localhost:9101/microservice-produits/default
• Si ça ne marche pas : procéder par les changements suivants
 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE
• Changer la brache git par défaut de main à master (si besoin)

• http://localhost:9101/microservice-produits/default/master
 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE

• Le serveur de configuration Spring Cloud Config est allé chercher le fichier de configuration dans le GIT, et

expose une API qui répond à l'URL "/nom-du-microservice/default/brach".

• Il fournit ensuite sous format JSON toutes les configurations présentes dans le fichier.
 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE

{
"name": "microservice-produits",
"profiles": [
"default"
],
"label": "master",
"version": "bab20a2dba3c077a8e0c96914908ee9d2018a9fb",
"state": null,
"propertySources": [
{
"name": "https://github.com/xxxx69/mcommerce-config-repo.git/microservice-produits.properties",
"source": {
"server.port": "9001",
"spring.jpa.show-sql": "true",
"spring.h2.console.enabled": "true",
"spring.datasource.sql-script-encoding": "UTF-8",
"management.endpoints.web.expose": "info, health, refresh",
"mes-configs.limitDeProduits": "3"
}
}
]
}
 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE

• Lier le Microservice-produit au serveur de configuration Spring Cloud Config:

• Pour rappel, on a le dépôt Git relié à notre serveur Spring Cloud Config
• On va demander au Microservice-produits de récupérer le contenu de ces fichiers de configuration
depuis le serveur de configuration externalisé et non pas en interne
• Ajouter la dépendance dans pom.xml du Microservice-produits: <!-- to avoid : No spring.config.import
property has been defined -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>

• Renommer « application.properties » en « bootstrap.properties.»

• Démarrage Microservice-produit

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

 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE
• Résultat final au niveau du microservice-produits Chargement de la configuration externalisée

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

Located environment: name=microservice-produits, BootstrapPropertySource {name='bootstrapProperties-
https://github.com/xxxx69/mcommerce-config-repo.git/microservice-
produits.properties'}]com.mproduits.MproduitsApplication
Spring Data JPA repositories. Found 1 JPA repository interfaces.Tomcat initialized with port(s): 9001 (http)Starting service
[Tomcat]Starting Servlet engine: [Apache Tomcat/9.0.80]
Initializing Spring embedded WebApplicationContextH2 console available at '/h2-console’.
Database available at 'jdbc:h2:mem:9fc696fd-ad51-439a-9c56-4564786a80e6’
H2DialectHibernate: drop table if exists product CASCADE Hibernate: drop sequence if exists create sequence
hibernate_sequence start with 1 increment by 1
Hibernate: create table product (id integer not null, description varchar(255), image varchar(255), prix double, titre
varchar(255), primary key (id)).
Tomcat started on port(s): 9001 (http) with context path ''com.mproduits.MproduitsApplication : Started
MproduitsApplication in 7.046 seconds (JVM running for 7.32)
 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE
• Résultat final au niveau du microservice-produits Chargement de la configuration externalisée

http://localhost:9001/Produits
 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE
• http://localhost:9001/Produits
• On obtient une liste de 3 produits uniquement et qui correspond à la configuration du microservice
 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE

• Actualisation la configuration du microservice : Spring Actuator

• Au niveau du projet local « config-server-repo » modifier la valeur de mes-configs.limitDeProduits= 4

• Faire un commit et un push vers le repo Git. Appeler http://localhost:9001/Produits

• On obtient toujours la même liste de 3 produits uniquement et qui correspond à la configuration initiale du

microservice → Pourquoi le microservice n’a pas en compte la nouvelle valeur de configuration : « 4 » ?

• Réponse : La configuration est chargée une seule fois au démarrage du microservice, pour des raisons de

performance.

• Spring Cloud Config offre la possibilité de demander au microservice de s'actualiser et de recharger le fichier

de configuration : Envoyer un signal de « Refresh ».

• Ajouter Spring Actuator au microservice, qui expose un URI /refresh permettant de forcer la réactualisation des

valeurs de configuration.
 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE
• Actualisation la configuration du microservice : Spring Actuator
• Ajoutez Spring Actuator dans le pom.xml de Microservice-produits :
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

• Ajouter dans « bootstrap.properties » (ou dans le fichier

correspondant dans GIT) l’entée ci-dessous, afin d’exposer
l’endpoint refresh d'Actuator :
management.endpoints.web.exposure.include=refresh
• Indiquer aux beans de se rafraichir à chaque fois qu'un
événement Refresh est lancé. :
• Ajouter l'annotation @RefreshScope à la classe de gestion de la
configuration du MS « ApplicationPropertiesConfiguration.java »
• Redémarrer le MS
 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE
• Actualisation la configuration du microservice : Spring Actuator

• http://localhost:9001/Produits --> Affichage de 4 produits

 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE
• Actualisation la configuration du microservice : Spring Actuator
• Refaire la même opération : augmenter le nombre à 5 (Commit puis push) → rien ne se passe
• Déclenchez alors un événement Refresh en envoyant une requête POST à
• http://localhost:9001/actuator/refresh via Postman qui indique exactement la propriété qui a changé:
 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE
• Actualisation la configuration du microservice : Spring Actuator

• http://localhost:9001/Produits --> Affichage de 5 produits

 SPRING CLOUD CONFIG : CONFIGURATION EXTERNALISÉE

▪ En résumé :

▪ « application.properties » peut être utilisé pour stocker des constantes auxquelles on peut accéder

grâce à un bean annoté avec @ConfigurationProperties .

▪ Config-Server permet de récupérer les fichiers de configuration dans un dépôt, et de les servir aux

microservices en se basant sur leurs noms.

▪ Pour récupérer automatiquement ces configurations, il suffit d’ajouter le starter spring-cloud-starter-

config, et de renommer application.properties en bootstrap.properties.

▪ Pour actualiser à la volée la configuration d’un microservice en l’obligeant à récupérer une version

fraîche du fichier .properties, il suffit d’envoyer un POST vers l'endpoint /refresh exposé par Spring

Actuator.