|
|
@@ -0,0 +1,123 @@
|
|
|
1
|
+# 1. Partie backend: application orientée microservices
|
|
|
2
|
+## 1.1. Introduction
|
|
|
3
|
+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.
|
|
|
4
|
+
|
|
|
5
|
+* **Scénario nominal**: Un utilisateur est affecté à une adresse <> **Scénario alternatif**: Si l’adresse n’existe pas, erreur.
|
|
|
6
|
+* **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.
|
|
|
7
|
+* ++ des contrôles d'intégrités pour le fonctionnement de l'application.
|
|
|
8
|
+
|
|
|
9
|
+
|
|
|
10
|
+L’application est consistituée de deux types microservices:
|
|
|
11
|
+
|
|
|
12
|
+* Quatre microservices métiers pour le fonctionnement de l’application.
|
|
|
13
|
+* Deux services intermédiaires pour faire fonctionner les microservices métiers.
|
|
|
14
|
+
|
|
|
15
|
+Les répertoires des microservices métiers:
|
|
|
16
|
+
|
|
|
17
|
+* address-microservice
|
|
|
18
|
+* employee-microservice
|
|
|
19
|
+* company-microservice
|
|
|
20
|
+* project-microservice
|
|
|
21
|
+
|
|
|
22
|
+Les répertoires des microservices qui font fonctionner les microservices métiers:
|
|
|
23
|
+
|
|
|
24
|
+* spring-cloud-gateway-service
|
|
|
25
|
+* eureka-discovery-service
|
|
|
26
|
+
|
|
|
27
|
+Le répertoire de déploiement contenant un fichier docker-compose pour créer et agencer les images dockers des tous ces microservices:
|
|
|
28
|
+* application-deployment
|
|
|
29
|
+
|
|
|
30
|
+Chaque microservice métier possède ses propres ressources:
|
|
|
31
|
+
|
|
|
32
|
+* Sa base de données
|
|
|
33
|
+* Son propre code source
|
|
|
34
|
+* Son propre fichier de configuration
|
|
|
35
|
+* Ses propres dépendances
|
|
|
36
|
+* etc.
|
|
|
37
|
+
|
|
|
38
|
+La figure  présente le diagramme de classe de l'application.
|
|
|
39
|
+
|
|
|
40
|
+## 1.3. Communication entre microservices
|
|
|
41
|
+Les microservices communiquent entre eux pour le fonctionnement de l'applications.
|
|
|
42
|
+* **user-microservice** a besoin de **address-microservice** pour persister un utlisateur.
|
|
|
43
|
+- **project-microservice** a de **user-microservice** et **company-microservice** pour périsiter un projet.
|
|
|
44
|
+
|
|
|
45
|
+Pour faire communiquer les microservices, nous utilisons le pattern **Spring Cloud OpenFeign**. On peut voir l'architechure Spring Cloud de l'application backend [ici](https://drive.google.com/file/d/1h3lWg0P7VCq8ne-zRsr9Bq56VfKE-dsK/view?usp=sharing).
|
|
|
46
|
+
|
|
|
47
|
+#### Pourquoi Spring Cloud OpenFeign plutôt que Spring Boot RestTemplate?
|
|
|
48
|
+
|
|
|
49
|
+Spring Cloud OpenFeign présente plusieurs avantages:
|
|
|
50
|
+* 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.
|
|
|
51
|
+
|
|
|
52
|
+* **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.
|
|
|
53
|
+
|
|
|
54
|
+## 1.4. Déploiement des microservices
|
|
|
55
|
+1. Construction d'une image docker pour chaque microservice avec un simple fichier Dockerfile placé à la racine du dossier du microservice.
|
|
|
56
|
+2. Lancement avec un fichier **docke-compose** de la stack des microservices composant toute l'application backend.
|
|
|
57
|
+
|
|
|
58
|
+### 1.4.1. Lancement de l'application backend
|
|
|
59
|
+1) Créer un répertoire que l'on nomme à son choix, **projet-microservices** par exemple.
|
|
|
60
|
+
|
|
|
61
|
+2) Cloner le git suivant de l'application dans ce répertoire:
|
|
|
62
|
+- Dans le terminal, se placer dans ce répetoire.
|
|
|
63
|
+- Saisir`git clone`: https://gitea.natan.fr/placidenduwayo/projects-management-microservices-backend.git.
|
|
|
64
|
+
|
|
|
65
|
+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**.
|
|
|
66
|
+
|
|
|
67
|
+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.
|
|
|
68
|
+
|
|
|
69
|
+Pour en savoir sur docker et docker-compose, voir les liens  et [docker-compose](https://docs.docker.com/compose/)
|
|
|
70
|
+
|
|
|
71
|
+ 3) Dans le terminal:
|
|
|
72
|
+ - Se placer dans le sous-répertoire **application-deployment** du répertoire **projet-microservice**.
|
|
|
73
|
+ - Le fichier **docker-compose** sous ce répertoire application-deployment agence les images à créer via leurs Dockerfiles
|
|
|
74
|
+ - Saisir la ligne de commandes :`docker-compose build`:
|
|
|
75
|
+ - `docker-compose build` builde les sources de chaque microservice
|
|
|
76
|
+ - Ensuite, à partir du Dockerfile de chaque microservice, il créera des images docker pour les microservices
|
|
|
77
|
+
|
|
|
78
|
+Après le build de l'application backend:
|
|
|
79
|
+- Toujours dans le répertoire des microservices
|
|
|
80
|
+- Saisir la ligne de commande: `docker-compose up`. Cette ligne de commande va lancer toutes les images agencées dans le fichier docker-compose
|
|
|
81
|
+
|
|
|
82
|
+### 1.5. Services intermédiaires
|
|
|
83
|
+Les services **eureka-discovery-server** et **spring-cloud-gateway-service** sont de simples applications.
|
|
|
84
|
+- Le service spring-cloud-gateway-service n'expose aucun Endpoint.
|
|
|
85
|
+- Le service eureka-discovery-server expose un seul endepoint http://localhost:8761 pour explorer les microservices enregistrés
|
|
|
86
|
+
|
|
|
87
|
+### 1.5.1. eureka-discovery-server
|
|
|
88
|
+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**.
|
|
|
89
|
+
|
|
|
90
|
+Le lien suivant présente la documentation de ce service d'annuaire [eureka service registration](https://spring.io/guides/gs/service-registration-and-discovery/).
|
|
|
91
|
+
|
|
|
92
|
+### 1.5.2. spring-cloud-gateway
|
|
|
93
|
+
|
|
|
94
|
+- 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.
|
|
|
95
|
+- 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**.
|
|
|
96
|
+- 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.
|
|
|
97
|
+- Si la gateway trouve le service demandé, le client peut commencer à consommer le microservice.
|
|
|
98
|
+
|
|
|
99
|
+La figure suivante présente l'architecture et le fonctionnement de l'application :.
|
|
|
100
|
+
|
|
|
101
|
+# 2. Partie frontend: application Angular
|
|
|
102
|
+Le côté frontend est une application Angular (Angular 13). Le repository de cette application frontend peut être trouvé sur le lien suivant: [frontend](https://gitea.natan.fr/placidenduwayo/projects-management-microservices-frontend.git)
|
|
|
103
|
+
|
|
|
104
|
+Pour communiquer avec la partie backend, dans le fichier `environment.ts` d'Angular nous y configurons l'addresse du service gateway avec les noms des microservices pour la backend:
|
|
|
105
|
+
|
|
|
106
|
+```
|
|
|
107
|
+export const environment = {
|
|
|
108
|
+ ADDRESSES_SERVER:"http://localhost:8888/ADDRESS-MICROSERVICE",
|
|
|
109
|
+ USERS_SERVER:"http://localhost:8888/USER-MICROSERVICE",
|
|
|
110
|
+ COMPANIES_SERVER:"http://localhost:8888/COMPANY-MICROSERVICE",
|
|
|
111
|
+ PROJECTS_SERVER:"http://localhost:8888/PROJECT-MICROSERVICE"
|
|
|
112
|
+
|
|
|
113
|
+};
|
|
|
114
|
+```
|
|
|
115
|
+
|
|
|
116
|
+# 3. Lancement de l'application fullstack:
|
|
|
117
|
+- cloner la partie backend: `git clone` https://gitea.natan.fr/placidenduwayo/projects-management-microservices-backend.git
|
|
|
118
|
+ - suivre la procédure décrite plus haut et lancer la partie backend
|
|
|
119
|
+- cloner la partie frontend: `git clone` https://gitea.natan.fr/placidenduwayo/projects-management-microservices-frontend.git
|
|
|
120
|
+ - Installer les dépendances nécessaires pour la gestion du store et des effects
|
|
|
121
|
+ - Installer le framework Primeng pour la gestion des styles
|
|
|
122
|
+ - Lancer la partie frontend: npm start
|
|
|
123
|
+
|
