projects-management-microservices-backend

1. Partie backend: application orientée microservices

1.1. Introduction

Nous mettons en place une application orientée microservices avec Spring MVC et Spring Cloud OpenFeign. Simulation d’un scénario de gestion de projets.

• Scénario nominal: Un utilisateur est affecté à une adresse <> Scénario alternatif: Si l’adresse n’existe pas, erreur.
• Scénario nominal: Un projet est affecté à un utilisateur et une société <> Scénario alternatif: Si l’utilisateur et / ou la société n’existent pas, erreur.
• ++ des contrôles d’intégrités pour le fonctionnement de l’application.

L’application est consistituée de deux types microservices:

• Quatre microservices métiers pour le fonctionnement de l’application.
• Deux services intermédiaires pour faire fonctionner les microservices métiers.

Les répertoires des microservices métiers:

• address-microservice
• employee-microservice
• company-microservice
• project-microservice

Les répertoires des microservices qui font fonctionner les microservices métiers:

• spring-cloud-gateway-service
• eureka-discovery-service

Le répertoire de déploiement contenant un fichier docker-compose pour créer et agencer les images dockers des tous ces microservices:

• application-deployment

Chaque microservice métier possède ses propres ressources:

• Sa base de données
• Son propre code source
• Son propre fichier de configuration
• Ses propres dépendances
• etc.

La figure présente le diagramme de classe de l’application.

1.3. Communication entre microservices

Les microservices communiquent entre eux pour le fonctionnement de l’applications.

• user-microservice a besoin de address-microservice pour persister un utlisateur.
• project-microservice a de user-microservice et company-microservice pour périsiter un projet.

Pour faire communiquer les microservices, nous utilisons le pattern Spring Cloud OpenFeign. L’architechure d’enregistrement et de découverte des microservice de l’application backend peut se présenter ainsi: architecture

Pourquoi Spring Cloud OpenFeign plutôt que Spring Boot RestTemplate?

Spring Cloud OpenFeign présente plusieurs avantages:

• Avec RestTemplate, un microservice qui a besoin d’appeler un autre microservice doit écrire en dur l’url de ce dernier dans son code source. <> Spring Cloud OpenFeign fournit l’autoconfiguration des microservices. Les microservices métiers s’enregistrent dans un service d’annuaire, un client qui a besoin de consommer un microservice métier donne le nom de ce dernier à la gateway qui le cherche à sa place. ==> le client n’a pas besoin de connâitre l’adresse complète du microservice qu’il veut consommer.

• RestTemplate met en question l’évolutivité de l’application. En effet, RestTemplate se base sur une classe dans laquelle on écrit en dur l’url complète du microservice que l’autre microservice veut appeler. Ainsi, s’il arrive que le microservice change d’url, on est obligé de modifier le code source de la classe dans l’autre microservice qui utilise le premier microservice. <> Spring Cloud OpenFeign assure l’évolutivité de l’application grâce à l’autoconfiguration des microservices métiers. En effet, OpenFeign est basé sur une interface qu’il marque comme un service. Spring Cloud OpenFein avec le server d’enregistrement, permet aux microservices de s’autoenregistrer.

1.4. Déploiement des microservices

1. Construction d’une image docker pour chaque microservice avec un simple fichier Dockerfile placé à la racine du dossier du microservice.
2. Lancement avec un fichier docke-compose de la stack des microservices composant toute l’application backend.

Lancement de l’application backend

1) Créer un répertoire que l’on nomme à son choix, projet-microservices par exemple.

2) Cloner le git suivant de l’application dans ce répertoire:

• Dans le terminal, se placer dans ce répetoire.
• Saisirgit clone: https://gitea.natan.fr/placidenduwayo/projects-management-microservices-backend.git

Les microservices métiers, les microservices intermédiaires et application-deployment (le répertoire pour déployer l’application) sont téléchargés dans ce répertoire projet-microservices.

Il faut avoir les application Docker et Docker-compose installées sur la machine. Docker pour créer les images docker des microservices et docker-compose pour agencer et lancer en une seule ligne de commandes les images de toute l’application.

Pour en savoir sur docker et docker-compose, voir les liens et docker-compose

3) Dans le terminal:

• Se placer dans le sous-répertoire application-deployment du répertoire projet-microservice.
• Le fichier docker-compose sous ce répertoire application-deployment agence les images à créer via leurs Dockerfiles
• Saisir la ligne de commandes :docker-compose build:
  • docker-compose build builde les sources de chaque microservice
  • Ensuite, à partir du Dockerfile de chaque microservice, il créera des images docker pour les microservices

Après le build de l’application backend:

• Toujours dans le répertoire des microservices
• Saisir la ligne de commande: docker-compose up. Cette ligne de commande va lancer toutes les images agencées dans le fichier docker-compose

1.5. Services intermédiaires

Les services eureka-discovery-server et spring-cloud-gateway-service sont de simples applications.

• Le service spring-cloud-gateway-service n’expose aucun Endpoint.
• Le service eureka-discovery-server expose un seul endepoint http://localhost:8180 pour explorer les microservices enregistrés

1.5.1. eureka-discovery-server

Ce service joue le rôle de serveur d’annuaire des microservices. eureka-discovery-server est lancé en premier. Lorsqu’ils sont lancés, les microservices métiers et le service gateway s’enregistrent dans le serveur d’annuaire. Ils s’enregistrent par leur nom configuré dans leur fichier de configuration application.properties.

Le lien suivant présente la documentation de ce service d’annuaire eureka service registration.

1.5.2. spring-cloud-gateway

• Le service gateway spring-cloud-gateway-service peut être lancé avant ou après les microservices métiers. Ce service sert de gateway entre le frontend et le serveur d’annuaire qui contient les noms des microservices métiers.
• Dans la requête HTTP, le client a juste besoin de connaître l’adresse de la gateway et le nom du microservice qu’il veut consommer. Sa requête est de la forme: http://gateway-address:gateway-port/NOM-MICROSERVICE/endpoint.
• Le service gateway va chercher dans le serveur d’annuaire (ici nous avons utilisé Eureka de Netflix) le nom du microservice que le client HTTP a spécifié dans sa requête.
• Si la gateway trouve le service demandé, le client peut commencer à consommer le microservice.

2. Partie frontend: application Angular

Le côté frontend est une application Angular (Angular 13). Le repository de cette application frontend peut être trouvé sur le lien suivant: frontend

Pour communiquer avec la partie backend, dans le fichier environment.ts d’Angular nous y configurons l’adresse du service gateway avec les noms des microservices pour la backend:

export const environment = {
  ADDRESSES_SERVER:"http://localhost:8181/ADDRESS-MICROSERVICE",
  USERS_SERVER:"http://localhost:8181/USER-MICROSERVICE",
  COMPANIES_SERVER:"http://localhost:8181/COMPANY-MICROSERVICE",
  PROJECTS_SERVER:"http://localhost:8181/PROJECT-MICROSERVICE"

};

3. Lancement de l’application fullstack:

3.1. La partie backend

• Cloner la partie backend: git clone https://gitea.natan.fr/placidenduwayo/projects-management-microservices-backend.git

• Lancer l’application backend en suivant la procédure décrite au sous titre 1.4 Déploiement des microservices.

  3.2. La partie frontend

• cloner la partie frontend: git clone https://gitea.natan.fr/placidenduwayo/projects-management-microservices-frontend.git

• Suivre la procédure telle que détaillée dans le README du repository

• Aller sur http://localhost:4200

  •