Introduction Générale

Dédicace

Je rends grâce, avant toute chose, à Allah, le Tout-Puissant, de m’avoir accordé la force, le
courage et la persévérance nécessaires pour accomplir ce parcours universitaire et mener ce
mémoire à son terme.

Je dédie ce travail à mon cher père, dont l’amour, les valeurs, les conseils et le soutien ont
toujours été une source de motivation. Sa confiance en moi et ses encouragements constants
m’ont inspirée à persévérer et à donner le meilleur de moi-même.

À ma très chère mère, j’adresse ma plus profonde gratitude pour son amour inconditionnel,
ses innombrables sacrifices, ses prières et son soutien indéfectible. Sa bienveillance, sa
patience et ses encouragements m’ont permis de surmonter les difficultés et de poursuivre
mes ambitions avec détermination.

À ma sœur Yasmine, pour son affection, sa présence, son soutien moral et ses
encouragements qui m’ont accompagnée tout au long de cette aventure académique.

J’adresse également mes sincères remerciements à l’ensemble de mes enseignants pour la

qualité de leur enseignement, leur disponibilité ainsi que les connaissances et les compétences
qu’ils m’ont transmises tout au long de ma formation.

J’exprime ma profonde reconnaissance à mon encadrant, Monsieur Driss Riane, pour son
accompagnement, sa disponibilité, ses conseils avisés, sa patience et son soutien tout au long
de la réalisation de ce projet de fin d’études.

Enfin, je remercie chaleureusement toutes les personnes qui, de près ou de loin, ont contribué
à l’aboutissement de ce travail par leurs conseils, leur aide ou leurs encouragements.

À toutes ces personnes, je dédie ce modeste travail avec un profond respect, une immense
gratitude et toute mon affection.

ii
 Introduction Générale

Remerciements

Avant toute chose, je rends grâce à Allah, le Tout-Puissant, qui m’a accordé la force, la
patience et la persévérance nécessaires pour mener ce travail à son terme. Je Le remercie pour
les nombreuses bénédictions dont Il m’a comblée tout au long de mon parcours académique.

J’adresse mes plus sincères remerciements à mes encadrants, Monsieur Driss Riane,
Madame la Professeure Soumia ZITI, Madame la Doctorante Maha ZERROUG,
Monsieur le Doctorant TAIAR Abdellah et Monsieur le Doctorant Marouane Achbari,
pour leur disponibilité, leur accompagnement, leurs précieux conseils et leur soutien constant.
Leurs orientations, leur rigueur scientifique, leur bienveillance et leurs remarques pertinentes
ont constitué une aide précieuse et ont largement contribué à la réussite de ce projet de fin
d'études.

J’adresse également ma profonde reconnaissance à l’ensemble du corps professoral de la

Faculté des Sciences de Rabat, et plus particulièrement aux enseignants du Master Science et
Ingénierie des Données, pour la qualité de leur enseignement, leur engagement et les
connaissances qu’ils m’ont transmises tout au long de ma formation. Les compétences
acquises durant ce cursus ont constitué un fondement essentiel à la réalisation de ce mémoire.

Je tiens également à remercier toutes les personnes qui, de près ou de loin, m’ont apporté leur
soutien, leurs encouragements ou leur aide tout au long de cette expérience. Leur présence et
leur confiance ont été une source de motivation tout au long de ce parcours.

J’exprime enfin ma profonde gratitude aux membres du jury qui ont accepté d’évaluer ce
mémoire. Je les remercie très sincèrement pour le temps qu’ils consacrent à l’examen de ce
travail, ainsi que pour l’intérêt qu’ils lui portent et les remarques constructives qu’ils ne
manqueront pas d’apporter.

À toutes ces personnes, j’adresse l’expression de ma profonde reconnaissance et de mes plus

sincères remerciements.

iii
 Introduction Générale

Résumé

L'évolution des systèmes d'information a conduit à l'adoption d'architectures distribuées

capables de répondre aux exigences de performance, de disponibilité et de scalabilité. Parmi
ces architectures, les microservices occupent aujourd'hui une place importante grâce à leur
capacité à découper une application en plusieurs services indépendants. Cependant, la
multiplication des services entraîne de nouveaux défis liés à la répartition des charges, à la
disponibilité des services et à la gestion des communications inter services. Afin de répondre à
ces problématiques, ce projet propose la conception et la mise en œuvre d'une architecture
microservices intégrant un mécanisme de Load Balancing intelligent. La solution développée
repose sur plusieurs microservices spécialisés : Auth Service, Users Service, Orders Service et
Payment Service. Ces services sont accessibles via une API Gateway centralisée et déployés
sous forme de conteneurs Docker. Un Load Balancer basé sur NGINX permet de répartir
dynamiquement les requêtes entre plusieurs instances afin d'améliorer la disponibilité et les
performances du système. Des mécanismes complémentaires tels que le Service Discovery,
les Health Checks, la journalisation centralisée et l'authentification JWT ont également été
intégrés afin de garantir la fiabilité et la sécurité de la plateforme.

Mots clés : Architecture microservices, Load Balancer intelligent, API Gateway, NGINX,
Docker, PostgreSQL, Service Discovery, Health Check, JWT, Scalabilité, Haute disponibilité.

iv
 Introduction Générale

Abstract

Modern information systems require scalable and highly available architectures capable of
handling increasing workloads and service demands. Microservices architecture has emerged
as a popular solution due to its modularity, flexibility and independent deployment
capabilities. Nevertheless, managing multiple services introduces challenges related to traffic
distribution, fault tolerance and service availability. This project focuses on the design and
implementation of a Load Balancer solution within a microservices architecture. The
developed platform consists of several specialized microservices including Authentication
Service, User Service, Order Service and Payment Service. These services are exposed
through a centralized API Gateway and deployed using Docker containers. An NGINX-based
Load Balancer dynamically distributes incoming requests across multiple service instances,
improving system performance and fault tolerance.

In addition to load balancing, the proposed system ensures better scalability by allowing
horizontal scaling of microservices according to demand. Each service operates
independently, which reduces interdependencies and improves maintainability of the overall
system. The use of containerization with Docker ensures consistent deployment across
different environments and simplifies system orchestration. Furthermore, the API Gateway
plays a key role in securing and managing client requests efficiently. Monitoring mechanisms
also provide better visibility into system behavior and help detect failures in real time.

Additional mechanisms such as Service Discovery, Health Checks, centralized logging and
JWT authentication have been integrated to ensure reliability, observability and security.

Keywords: Microservices Architecture, Intelligent Load Balancer, API Gateway, NGINX,

Docker, PostgreSQL, Service Discovery, Health Checks, JWT Authentication, Scalability,
High Availability.

v
 Introduction Générale

Structure du rapport

Ce rapport est structuré de manière progressive afin de présenter les différentes étapes de
conception, de développement et de validation de la solution proposée. Il débute par un
premier chapitre consacré au cadre général du projet, dans lequel sont présentés le contexte de
l’étude, la problématique rencontrée ainsi que les objectifs visés par la mise en place d’un
mécanisme de load balancing intelligent au sein d’une architecture microservices.

Le deuxième chapitre présente l’état de l’art et les concepts théoriques nécessaires à la

compréhension du projet. Il aborde notamment les architectures microservices, les API
Gateway, les mécanismes de load balancing, les algorithmes de répartition de charge, le
service discovery, le health check, ainsi que les aspects liés à la supervision et à la sécurité.

Le troisième chapitre est dédié à l’analyse des besoins et à la conception de la solution. Il

décrit les besoins fonctionnels et non fonctionnels du système, l’architecture générale
proposée, les différents composants de la plateforme ainsi que la modélisation UML réalisée
pour représenter les interactions et le fonctionnement global de l’application.

Le quatrième chapitre présente la réalisation de l’application développée. Il détaille les

technologies utilisées et les principales interfaces de la plateforme, notamment l’interface de
connexion, le tableau de bord principal, la gestion des microservices, la supervision des
services, les endpoints API et la consultation des logs.

Le cinquième chapitre est consacré aux tests et à la validation de la solution. Il décrit la

stratégie de test adoptée, les tests fonctionnels réalisés sur les différents modules, les tests de
l’API Gateway, du Health Check et du Load Balancer, ainsi que l’analyse des résultats
obtenus en termes de performance, de disponibilité et de tolérance aux pannes.

Enfin, ce rapport s’achève par une conclusion générale qui récapitule les
principaux résultats obtenus, les apports du projet, ses limites éventuelles ainsi
que les perspectives d’amélioration et d’évolution futures de la solution
développée.

vi
 Introduction Générale

Table des matières

Dédicace.....................................................................................................................................
Remerciements.........................................................................................................................
Résumé......................................................................................................................................
Abstract......................................................................................................................................
Structure du rapport...............................................................................................................
Table des matières...................................................................................................................
Liste des figures........................................................................................................................
Liste des Abréviations.............................................................................................................
Introduction Générale..........................................................................................................
Chapitre 1 : Contexte général du projet...............................................................................
Introduction......................................................................................................................
1.1. Contexte du projet.....................................................................................................
1.1.1. Présentation du projet........................................................................................
1.1.2. Objectif du projet...............................................................................................
Objectifs Techniques....................................................................................................
Objectifs Scientifiques et Pédagogiques.....................................................................
1.1.3. Solution proposée................................................................................................
1.1.4. Diagramme de GANTT......................................................................................
1.2. Organisation du Rapport..........................................................................................
Conclusion.........................................................................................................................
Chapitre 2 : Contexte théorique et état de l’art....................................................................
Introduction......................................................................................................................
2.1. Architecture monolithique........................................................................................
2.2. Architecture microservices.....................................................................................
2.3. API Gateway............................................................................................................
2.4. Load Balancer..........................................................................................................
2.4.1. Définition et objectifs........................................................................................

vii
 Introduction Générale

2.4.2. Nginx comme Load Balancer...........................................................................

2.4.3. Algorithmes de Load Balancer........................................................................
2.5. Service Discovery et Health check.........................................................................
2.5.1. La problématique du service Discovery.........................................................
2.5.2. Implémentation du service Registry...............................................................
2.5.3. Health checks....................................................................................................
2.6. Observabilité, logs et supervision...........................................................................
2.7. Sécurité dans les microservices..............................................................................
Conclusion.......................................................................................................................
Chapitre 3 : Analyse des besoins et conception de la solution..........................................
Introduction....................................................................................................................
3.1. Analyse des besoins..................................................................................................
3.1.1. Identification des Acteurs...................................................................................
3.1.2. Problèmes Identifiés...........................................................................................
3.2. Spécification fonctionnelle......................................................................................
3.3 Spécification non fonctionnelle................................................................................
3.4 Architecture générale de la solution........................................................................
[Link] d'ensemble..................................................................................................
[Link] de communication.....................................................................................
[Link] de déploiement..........................................................................
3.5. Description des composants de la solution............................................................
[Link] Service (Port 3001)...................................................................................
[Link] Service (Port 3002)..................................................................................
[Link] Service (Port 3003)...............................................................................
[Link] Service (Port 3004)............................................................................
[Link] Gateway (Port 3000)..................................................................................
[Link] partagée (shared/)....................................................................
[Link] Dashboard (Port 3500).....................................................................
3.6. Conception du mécanisme du Load Balancer......................................................
[Link]èle de données — Classe Server................................................................
[Link] quatre algorithmes implémentés...............................................................
[Link] de la santé des instances......................................................................
[Link] des algorithmes..........................................................................
3.7. Modélisation UML..................................................................................................

viii
 Introduction Générale

[Link] de Cas d'Utilisation......................................................................

[Link] de Séquence...................................................................................
[Link] d'Activité.......................................................................................
Conclusion.......................................................................................................................
Chapitre4 : Présentation de l’application finale................................................................
Introduction....................................................................................................................
4.1 Interface de connexion.............................................................................................
4.1.1 Présentation générale............................................................................................
4.1.2 Mécanisme d'authentification..............................................................................
4.2 Tableau de bord principal........................................................................................
[Link] d'ensemble..................................................................................................
[Link] de statistiques.........................................................................................
[Link] des services..............................................................................................
4.3 Interface API Endpoints..........................................................................................
[Link]ésentation.......................................................................................................
[Link] couleur des méthodes HTTP...............................................................
4.4 Interfaces de gestion des microservices..................................................................
[Link] Users Service......................................................................................
[Link] Orders Service...................................................................................
[Link] Payment Service................................................................................
4.5 Interface service health............................................................................................
[Link]ésentation.......................................................................................................
[Link] affichées par service...................................................................
4.6 Interface load balancer...............................................................................................
[Link]ésentation et fonctionnalités.........................................................................
4.6.2.Mécanisme de changement d'algorithme........................................................
4.7 Interface logs..............................................................................................................
[Link]ésentation.......................................................................................................
[Link] du système de logs client.............................................................
Conclusion...........................................................................................................................
Chapitre 5 : Tests,Validation...............................................................................................
Introduction....................................................................................................................
5.1 Stratégie de test.........................................................................................................
5.2 Tests des fonctionnalités principales.......................................................................

ix
 Introduction Générale

[Link] d'authentification (Auth Service — Port 3001).................................

[Link] Utilisateurs (Users Service — Port 3002)...........................................
[Link] Commandes (Orders Service — Port 3003)......................................
[Link] Paiements (Payment Service — Port 3004).......................................
5.3 Tests de l API Gateway.............................................................................................
[Link] des requêtes.........................................................................................
[Link] des en-têtes..................................................................................
[Link] des erreurs de service..........................................................................
5.4 Tests du Health check...............................................................................................
[Link] Check individuel...................................................................................
[Link] Check agrégé.........................................................................................
5.5 Tests du Load Balancer............................................................................................
[Link] implémentés.................................................................................
[Link] du Round Robin (algorithme par défaut)...............................................
[Link] de la tolérance aux pannes........................................................................
[Link] du Load Balancer...................................................................
5.6 Résultats obtenus......................................................................................................
Conclusion.......................................................................................................................
Conclusion Générale..........................................................................................................
Bibliographie.......................................................................................................................

x
 Introduction Générale

Liste des figures

N° Titre de la figure Page
Figure 1.1 Diagramme de Gantt du projet 12
Figure 3.1 Architecture générale de la solution 23
Figure 3.2 Diagramme de cas d'utilisation 29
Figure 3.3 Diagramme de séquence 30
Figure 3.4 Diagramme d'activité 31
Figure 4.1 Interface de connexion 34
Figure 4.2 Tableau de bord principal 35
Figure 4.3 Gestion des utilisateurs 36
Figure 4.4 Gestion des commandes 37
Figure 4.5 Gestion des paiements 38
Figure 4.6 Supervision des microservices 39
Figure 4.7 Statistiques du Load Balancer 40
Figure 4.8 Journaux d'exécution 41
Figure 5.1 Déploiement des conteneurs Docker 46
Figure 5.2 Vérification des microservices 47
Figure 5.3 Test d'authentification 48
Figure 5.4 Test de création d'une commande 49
Figure 5.5 Test de traitement d'un paiement 50
Figure 5.6 Test de l'algorithme Round Robin 51
Figure 5.7 Test de l'algorithme Least Connections 52
Figure 5.8 Test de l'algorithme Weighted Round Robin 53
Figure 5.9 Test de l'algorithme IP Hash 54
Figure 5.10 Test du mécanisme de Health Check 55
Figure 5.11 Comparaison des temps de réponse 56
Figure 5.12 Comparaison des performances des algorithmes 57

xi
 Introduction Générale

Liste des Abréviations

Abréviation Signification
API Application Programming Interface
REST Representational State Transfer
HTTP HyperText Transfer Protocol
HTTPS HyperText Transfer Protocol Secure
JWT JSON Web Token
UI User Interface
UML Unified Modeling Language
CPU Central Processing Unit (Unité centrale de traitement)
RAM Random Access Memory (Mémoire vive)
DB Database (Base de données)
CRUD Create, Read, Update, Delete
LB Load Balancer
RR Round Robin
WRR Weighted Round Robin
LC Least Connections
API GW API Gateway
SD Service Discovery
HC Health Check
MS Microservice
SLA Service Level Agreement
QoS Quality of Service
JSON JavaScript Object Notation
Docker Plateforme de conteneurisation
[Link] Environnement d’exécution JavaScript côté serveur
NPM Node Package Manager
CORS Cross-Origin Resource Sharing
CI/CD Continuous Integration / Continuous Deployment
Log Journal des événements système

xii
 Introduction Générale

Abréviation Signification
KPI Key Performance Indicator (Indicateur clé de performance)
HA High Availability (Haute disponibilité)

xiii
 Introduction Générale

Introduction Générale

Dans un contexte marqué par la transformation numérique et l’augmentation constante des

services en ligne, les applications modernes doivent répondre à des exigences élevées en
matière de performance, de disponibilité et de scalabilité. Les entreprises et les organisations
adoptent de plus en plus les architectures microservices afin de développer des systèmes
flexibles, modulaires et faciles à maintenir. Cette approche permet de décomposer une
application en plusieurs services indépendants qui communiquent entre eux à travers des
interfaces bien définies.

Cependant, malgré les nombreux avantages qu’elles offrent, les architectures microservices
introduisent également de nouveaux défis techniques. Parmi les plus importants figurent la
gestion du trafic réseau, la répartition des requêtes entre les différentes instances de services,
la tolérance aux pannes ainsi que le maintien d’une haute disponibilité. Lorsqu’un grand
nombre d’utilisateurs accède simultanément à l’application, certains services peuvent être
surchargés, entraînant une dégradation des performances et une augmentation du temps de
réponse.

Afin de répondre à ces problématiques, les mécanismes de load balancing jouent un rôle
essentiel dans les architectures distribuées. Leur objectif est de répartir efficacement les
requêtes entre plusieurs instances de services afin d’optimiser l’utilisation des ressources
disponibles, d’améliorer les performances globales du système et d’assurer une continuité de
service même en cas de défaillance d’un composant.

C’est dans ce cadre que s’inscrit ce projet de fin d’études, dont l’objectif principal est la
conception et le développement d’un Load Balancer Intelligent pour une Architecture
Microservices. La solution proposée repose sur l’intégration d’une API Gateway, d’un
mécanisme de Service Discovery, d’un système de Health Check ainsi que d’un tableau de
bord de supervision permettant de surveiller l’état des différents services en temps réel.

Pour répondre à cette problématique, plusieurs stratégies de répartition de charge

ont été étudiées et mises en œuvre afin d’assurer une distribution optimale des
requêtes entre les microservices. La solution développée vise à améliorer la
disponibilité des services, réduire les temps de réponse, renforcer la tolérance aux

1
 Introduction Générale
pannes et garantir une meilleure expérience utilisateur dans un environnement
distribué et évolutif.

2
 Chapitre4 : Présentation de l’application finale

Chapitre 1 : Contexte général

du projet

3
 Chapitre4 : Présentation de l’application finale

Introduction
L'évolution rapide du développement logiciel et l'essor du cloud computing ont
profondément transformé la manière dont les applications modernes sont conçues,
déployées et exploitées. Face aux exigences croissantes de scalabilité, de résilience
et de disponibilité, les architectures monolithiques traditionnelles se révèlent de
plus en plus inadaptées aux besoins des systèmes d'information contemporains.

Dans ce contexte, les architectures microservices s'imposent comme une réponse

naturelle en décomposant les applications en un ensemble de services autonomes,
faiblement couplés et indépendamment déployables. Cependant, cette
décomposition introduit de nouveaux défis opérationnels, notamment la gestion du
trafic réseau entre les instances de services, la tolérance aux pannes et
l'optimisation des ressources disponibles.

C'est dans ce cadre que s'inscrit le présent projet de fin d'études, qui vise à
concevoir et implémenter un Load Balancer Intelligent pour une architecture
microservices complète. L'objectif central est de développer un système capable de
distribuer intelligemment le trafic entrant entre plusieurs instances de services, en
s'adaptant dynamiquement à l'état réel du système et en garantissant une haute
disponibilité.

1.1. Contexte du projet

1.1.1. Présentation du projet

Le projet porte sur la réalisation d'un système complet de microservices avec un
Load Balancer Intelligent intégré nativement. Il s'agit d'une application distribuée
développée en [Link] avec le framework Express, composée de six composants
principaux :

Auth Service (Port 3001) : service d'authentification gérant l'inscription des utilisateurs,
la connexion sécurisée avec JWT (JSON Web Token), le hachage des mots de passe
avec bcrypt et la vérification des tokens.
Users Service (Port 3002) : service de gestion des utilisateurs assurant les opérations
CRUD (Create, Read, Update, Delete) sur les entités utilisateur, avec persistance dans
une base de données PostgreSQL.

4
 Chapitre4 : Présentation de l’application finale

Orders Service (Port 3003) : service de gestion des commandes permettant la création,
le suivi et la mise à jour du statut des commandes tout au long de leur cycle de vie.
Payment Service (Port 3004) : service de traitement des paiements gérant le traitement
des transactions, le suivi des statuts et les opérations de remboursement.
API Gateway (Port 3000) : composant central intégrant le Load Balancer Intelligent,
assurant le routage dynamique des requêtes vers les services backend via le Service
Registry.
Frontend Dashboard (Port 3500) : interface web de monitoring affichant en temps réel
l'état des services, les statistiques du load balancer et les logs des requêtes.

L'ensemble du système est conteneurisé avec Docker et orchestré via Docker

Compose, avec PostgreSQL comme système de gestion de bases de données
relationnelles pour la persistance des données. Un load balancer externe basé sur
Nginx est également intégré, offrant ainsi deux niveaux de répartition de charge :
externe (Nginx sur le port 8080) et interne (Load Balancer applicatif intégré à l'API
Gateway).

1.1.2. Objectif du projet

L'objectif principal de ce projet est de concevoir et implémenter un Load Balancer
Intelligent capable de distribuer efficacement le trafic réseau dans une architecture
microservices, en s'adaptant dynamiquement à l'état réel du système. Cet objectif
central se décline en plusieurs objectifs spécifiques :

Objectifs Techniques
1. Développer une architecture microservices complète et fonctionnelle, composée de cinq
services métier [Link]/Express interconnectés via une API Gateway centrale.
2. Implémenter un Load Balancer multi-stratégies supportant quatre algorithmes de
distribution : Round Robin, Least Connections, Weighted Round Robin et IP Hash, avec
capacité de changement de stratégie à chaud sans redémarrage des services.
3. Mettre en place un Service Registry avec health checks automatiques périodiques
(toutes les 30 secondes), permettant la détection et l'exclusion automatique des instances
défaillantes.

5
 Chapitre4 : Présentation de l’application finale

4. Assurer la persistance des données via PostgreSQL avec modélisation relationnelle

appropriée pour chaque service.
5. Sécuriser les communications avec JWT pour l'authentification des utilisateurs et des
tokens de service pour les communications inter-services.
6. Containeriser l'ensemble du système avec Docker et Docker Compose pour garantir la
portabilité et la reproductibilité des environnements.

Objectifs Scientifiques et Pédagogiques

7. Analyser et comparer les différents algorithmes de load balancing en termes de
complexité algorithmique, de scénarios d'application et de performances.
8. Démontrer la compréhension des principes fondamentaux des systèmes distribués :
découverte de services, résilience, observabilité et déploiement continu.
9. Produire une solution documentée, maintenable et extensible, démontrant la maturité
technique attendue au niveau Master.

1.1.3. Solution proposée

Face aux défis liés à la répartition de charge dans les architectures microservices, la solution
proposée repose sur une architecture multicouche intégrant un load balancer applicatif
intelligent et une infrastructure entièrement conteneurisée avec Docker. Les requêtes transitent
d’abord par Nginx, qui assure la répartition du trafic externe, avant d’être redirigées vers une
API Gateway intégrant un load balancer interne chargé de distribuer les requêtes entre les
différentes instances des services métier (authentification, utilisateurs, commandes et
paiements). Ce load balancer, implémenté selon le patron Singleton, prend en charge plusieurs
stratégies de répartition (Round Robin, Least Connections, Weighted Round Robin et IP Hash)
et permet de changer dynamiquement d’algorithme sans interruption de service. L’ensemble de
la plateforme est déployé avec Docker Compose et s’appuie sur PostgreSQL, un réseau Docker
dédié et des volumes persistants, garantissant un déploiement reproductible, une bonne
isolation des services et une infrastructure fiable et facilement maintenable.

1.1.4. Diagramme de GANTT

La réalisation de ce projet s’est déroulée sur une période de quatre mois, durant
laquelle les différentes activités ont été planifiées de manière progressive afin de
respecter les objectifs fixés. Cette période a couvert l’analyse des besoins, la

6
 Chapitre4 : Présentation de l’application finale

conception de l’architecture, le développement des différents microservices,

l’intégration du load balancer intelligent, les phases de tests et de validation, ainsi
que la rédaction du mémoire et la préparation de la soutenance. Le diagramme de
Gantt ci-dessous illustre la répartition temporelle de ces différentes étapes tout au
long du projet.

Figure 1.1 : Diagramme de Gantt

1.2. Organisation du Rapport

Ce mémoire est organisé en cinq chapitres qui retracent les différentes étapes de
réalisation du projet de manière progressive et cohérente. Le premier chapitre
présente le contexte général, la problématique, les objectifs poursuivis ainsi que
l’approche adoptée. Le deuxième chapitre est consacré à l’analyse des besoins
fonctionnels et non fonctionnels et à la définition des spécifications techniques du
système. Le troisième chapitre détaille la conception de la solution à travers la
modélisation UML et l’architecture générale retenue. Le quatrième chapitre expose
l’implémentation de la plateforme en décrivant les différents microservices
développés, l’API Gateway, le load balancer intelligent ainsi que les technologies
utilisées. Le cinquième chapitre présente les tests réalisés afin de valider le bon
fonctionnement, les performances et la fiabilité de la solution. Enfin, une
conclusion générale dresse le bilan du travail accompli, met en évidence les
principaux apports du projet et ouvre des perspectives d’amélioration et d’évolution
futures.

7
 Chapitre4 : Présentation de l’application finale

Conclusion

Ce premier chapitre a posé les bases conceptuelles et organisationnelles du projet.

Nous avons situé le travail dans son contexte technologique et académique, en
montrant comment les défis propres aux architectures microservices — notamment
la répartition intelligente du trafic réseau — constituent la problématique centrale
de cette étude.

Les objectifs ont été clairement définis : ils couvrent à la fois la dimension
technique (implémentation du Load Balancer multi-stratégies, architecture
complète, déploiement Docker) et la dimension scientifique (analyse comparative
des algorithmes, maîtrise des systèmes distribués). La solution proposée, articulée
autour d'un load balancer applicatif intégré et d'une infrastructure Docker complète
avec PostgreSQL, répond directement à ces objectifs.

Le diagramme de GANTT illustre la rigueur de la planification adoptée, avec une

progression logique des phases d'analyse, de conception, de développement et de
validation sur quatre mois.

8
 Chapitre4 : Présentation de l’application finale

Chapitre 2 : Contexte
théorique et état de l’art

9
 Chapitre4 : Présentation de l’application finale

Introduction

Ce chapitre présente les fondements théoriques et l'état de l'art des technologies

utilisées dans le cadre de ce projet de fin d'études. Avant d'aborder la conception et
l'implémentation de notre plateforme de microservices, il est indispensable de
comprendre les concepts architecturaux sous-jacents ainsi que les outils et
mécanismes qui permettent de les concrétiser.

Nous abordons successivement les architectures monolithiques et microservices, le

rôle central de l'API Gateway, les mécanismes de load balancing et leurs
algorithmes, la découverte de services et les health checks, l'observabilité et la
supervision, et enfin la sécurité dans un environnement distribué. Pour chaque
concept, nous établissons le lien direct avec les choix d'implémentation retenus
dans notre projet.

2.1. Architecture monolithique

Une application monolithique est une application dont tous les composants —
interface utilisateur, logique métier et couche d'accès aux données — sont
regroupés dans un seul et même déployable. Pendant longtemps, ce modèle a
constitué la norme dans le développement logiciel.

Ses avantages sont réels pour des projets de petite taille : simplicité de
développement, de tests et de déploiement, transactions locales plus faciles à gérer,
et absence de communication réseau entre les composants internes. Cependant, à
mesure que l'application grandit, ses inconvénients deviennent progressivement
rédhibitoires :

 Le couplage fort rend toute modification risquée et coûteuse ;

 La mise à l'échelle concerne l'ensemble de l'application, même si seul un composant est
sous tension ;
 Le déploiement d'une correction mineure impose de redéployer l'intégralité du système ;
 La base de code devient difficile à maintenir et à comprendre au fil du temps ;
 Différentes équipes ne peuvent pas choisir des technologies adaptées à leurs besoins
spécifiques.

10
 Chapitre4 : Présentation de l’application finale

2.2. Architecture microservices

L'architecture microservices est une approche de conception dans laquelle une

application est décomposée en un ensemble de services indépendants, chacun
responsable d'une capacité métier spécifique. Ces services communiquent entre eux
via des interfaces bien définies, généralement sous forme d'API REST ou de
systèmes de messagerie

Selon Martin Fowler et James Lewis (2014), une architecture microservices est
constituée d'un ensemble de services indépendants, chacun responsable d'une
capacité métier spécifique et pouvant être développé, déployé et mis à l'échelle de
manière autonome [12].

Les principes fondateurs des microservices, popularisés notamment par Martin

Fowler et James Lewis, reposent sur :

La responsabilité unique : chaque service implémente une seule fonction métier, ce

qui facilite sa compréhension et sa maintenance.
Le déploiement indépendant : un service peut être mis à jour, redémarré ou mis à
l'échelle sans impact sur les autres.
La décentralisation : chaque service gère ses propres données et peut choisir sa
technologie de stockage.
La résilience par conception : la panne d'un service ne doit pas provoquer la
défaillance de l'ensemble du système.

2.3. API Gateway

L'API Gateway constitue le point d'entrée unique d'une architecture microservices.

Elle reçoit l'ensemble des requêtes provenant des clients, applique les mécanismes
de sécurité, de routage, d'authentification et de limitation de débit avant de
transmettre les requêtes aux services concernés.

Chris Richardson (2018) souligne que l'API Gateway simplifie les échanges entre
les clients et les microservices en centralisant le routage, l'authentification, la
sécurité et les traitements transversaux [13].

Selon la littérature, les fonctions principales d'une API Gateway comprennent :

 Le routage des requêtes vers le microservice approprié

11
 Chapitre4 : Présentation de l’application finale

 L'agrégation de réponses provenant de plusieurs services en une seule réponse cliente

 L'authentification et l'autorisation centralisées
 La limitation du débit (rate limiting) et la protection contre les attaques
 La transformation des protocoles (par exemple, REST vers gRPC)
 La collecte de métriques et le logging centralisé.

2.4. Load Balancer

2.4.1. Définition et objectifs

Le load balancing (équilibrage de charge) est le processus par lequel les requêtes
entrantes sont distribuées entre plusieurs instances d'un même service, avec pour
objectifs :

Maximiser l'utilisation des ressources disponibles

Éviter la surcharge d'une instance unique
Réduire les temps de réponse pour les utilisateurs finaux
Assurer la haute disponibilité du service, même en cas de panne d'une instance
Permettre la mise à l'échelle horizontale de manière transparente.
D'après Harchol-Balter (2013), un Load Balancer permet d'améliorer les
performances, la disponibilité et la tolérance aux pannes en répartissant
intelligemment les requêtes entre plusieurs serveurs [14].

Dans un contexte microservices, le load balancing peut s'opérer à plusieurs niveaux

: au niveau du réseau (L4), au niveau applicatif (L7), ou directement côté client. Il
peut être statique (configuration fixe) ou dynamique (intégré à la découverte de
services).

2.4.2. Nginx comme Load Balancer

Dans notre projet, nous utilisons Nginx — un des serveurs web et reverse proxies
les plus répandus — en tant que load balancer de niveau L7. Nginx est reconnu
pour ses performances élevées, sa faible consommation mémoire et sa capacité à
gérer des milliers de connexions simultanées grâce à son architecture
événementielle non-bloquante.

12
 Chapitre4 : Présentation de l’application finale

Notre fichier `[Link]` configure Nginx pour distribuer le trafic vers l'API
Gateway, transmettre les en-têtes d'origine du client (`X-Real-IP`, `X-Forwarded-
For`) et servir de façade unifiée sur le port 8080

Cette configuration, bien que pointant vers une seule instance de l'API Gateway, est
conçue pour être étendue à plusieurs instances sans modification du code applicatif,
illustrant ainsi le principe d'infrastructure as code.

Selon la documentation officielle de NGINX, ce serveur Web peut également être

utilisé comme reverse proxy et comme Load Balancer haute performance capable
de gérer un grand nombre de connexions simultanées. [15]

2.4.3. Algorithmes de Load Balancer

Les principaux algorithmes de load balancing utilisés dans les architectures microservices sont
les suivants :

Round Robin : distribue les requêtes de manière séquentielle entre les différentes
instances de service. Cet algorithme est simple à mettre en œuvre et convient aux
environnements où les serveurs disposent de capacités similaires.
Weighted Round Robin : fonctionne sur le même principe que le Round Robin,
mais attribue un poids à chaque serveur en fonction de sa capacité de traitement. Les
serveurs les plus performants reçoivent ainsi un plus grand nombre de requêtes.
Least Connections : dirige chaque nouvelle requête vers le serveur ayant le plus
faible nombre de connexions actives. Cette approche permet une meilleure
répartition de la charge lorsque les temps de traitement des requêtes sont variables.
Weighted Least Connections : améliore l'algorithme Least Connections en tenant
compte à la fois du nombre de connexions actives et de la capacité de chaque
serveur, offrant ainsi une distribution plus équilibrée dans les environnements
hétérogènes.
IP Hash : sélectionne le serveur de destination à partir d'une fonction de hachage
appliquée à l'adresse IP du client. Cette méthode garantit qu'un même utilisateur est
généralement redirigé vers la même instance, ce qui favorise la persistance des
sessions.

13
 Chapitre4 : Présentation de l’application finale

Least Response Time : choisit le serveur présentant le temps de réponse le plus

faible et le plus petit nombre de connexions actives, afin d'améliorer les
performances globales du système.
Random : attribue les requêtes de manière aléatoire entre les serveurs disponibles.
Bien que simple, cette stratégie est généralement utilisée dans des scénarios peu
complexes ou à des fins de test.

2.5. Service Discovery et Health check

2.5.1. La problématique du service Discovery

Dans une architecture microservices, les instances de services peuvent démarrer,

s'arrêter ou changer d'adresse dynamiquement (notamment dans les environnements
conteneurisés comme Docker ou Kubernetes). Il devient alors impossible de
configurer statiquement les adresses des services : c'est le problème que résout le
Service Discovery.

Le mécanisme de Service Discovery permet aux services de localiser

dynamiquement les autres services disponibles sans recourir à une configuration
statique, ce qui facilite considérablement le déploiement dans les environnements
distribués.

Ce mécanisme est largement utilisé dans les plateformes d'orchestration modernes

comme Kubernetes afin de permettre la découverte automatique des services sans
configuration statique [16].

Il existe deux patterns principaux de Service Discovery :

 Client-side discovery : le client consulte un registre de services pour connaître les

instances disponibles et choisit lui-même vers laquelle envoyer sa requête (ex. : Netflix
Eureka avec Ribbon).
 Server-side discovery : le client envoie sa requête à un intermédiaire (load balancer ou
gateway) qui se charge de consulter le registre et de router la requête (ex. : AWS ELB,
Kubernetes Service).

2.5.2. Implémentation du service Registry

Notre projet implémente un registre de services in-process via la classe

`ServiceRegistry`. Cette classe utilise une `Map` JavaScript pour stocker les

14
 Chapitre4 : Présentation de l’application finale

instances de chaque service. Elle expose des méthodes pour enregistrer un service,
récupérer la liste des instances d'un service, effectuer un health check, et
désenregistrer un service.

2.5.3. Health checks

Un health check est une vérification périodique effectuée pour déterminer si une
instance de service est en mesure de traiter des requêtes. Un service peut être dans
plusieurs états : healthy (en bonne santé), degraded (dégradé, répondant mais
lentement) ou unhealthy (en panne).

Kubernetes utilise également des mécanismes de liveness probes et readiness

probes afin de vérifier automatiquement la disponibilité des services avant leur
mise en production [5].

Chacun de nos microservices expose un endpoint `GET /health` retournant son état,
son uptime et un timestamp. L'API Gateway expose un endpoint agrégé `GET
/health/services` qui interroge en parallèle tous les services (avec un timeout de 3
secondes par service) et retourne un état consolidé :

L'utilisation de `[Link]` (plutôt que `[Link]`) est intentionnelle :

elle garantit que la réponse de la gateway est toujours retournée, même si certains
services ne répondent pas, permettant ainsi d'identifier précisément les services
défaillants.

2.6. Observabilité, logs et supervision

L’observabilité est un élément essentiel des architectures microservices, car elle
permet de comprendre l’état interne du système à partir des informations produites
lors de son exécution.
Selon la documentation officielle d'OpenTelemetry, l'observabilité repose sur trois
piliers fondamentaux : les logs, les métriques et le traçage distribué, permettant de
comprendre le comportement interne d'un système distribué [6].
Elle repose sur trois piliers complémentaires : les logs, qui enregistrent les
événements et les erreurs survenant au sein des services ; les métriques, qui
fournissent des indicateurs quantitatifs tels que le temps de réponse, le débit des
requêtes ou le taux d’erreur ; et le tracing distribué, qui permet de suivre le
parcours complet d’une requête à travers les différents microservices. Dans le cadre

15
 Chapitre4 : Présentation de l’application finale

de ce projet, un système de logging centralisé a été mis en place à travers une classe
Logger, chargée d’enregistrer les événements de chaque service dans des fichiers de
logs dédiés ainsi que dans un fichier global regroupant toutes les requêtes. Les
informations sont stockées au format JSON afin de faciliter leur exploitation par
des outils d’analyse et de supervision. Le système prend en charge plusieurs
niveaux de journalisation (ERROR, WARN, INFO et DEBUG) et un middleware
dédié enregistre automatiquement les principales informations de chaque requête
HTTP, notamment la méthode, le chemin, le code de retour, le temps de traitement,
l’adresse IP du client et le navigateur utilisé. Cette architecture a été conçue pour
être évolutive et compatible avec des solutions industrielles telles que ELK, Loki,
Prometheus ou OpenTelemetry, permettant ainsi d’étendre facilement la plateforme
vers une solution complète de supervision et d’observabilité.

2.7. Sécurité dans les microservices

La sécurité constitue un enjeu majeur dans les architectures microservices en raison
de la multiplication des services et des communications inter-services, qui
augmentent la surface d’attaque du système. Pour garantir un accès sécurisé aux
ressources, ce projet s’appuie sur une authentification basée sur les JSON Web
Tokens (JWT), où l’utilisateur s’authentifie une seule fois auprès du service
d’authentification avant d’obtenir un jeton utilisé pour accéder aux différents
services. Conformément au principe Zero Trust, chaque requête est
systématiquement vérifiée avant d’être autorisée. La sécurité des échanges entre les
microservices est également assurée grâce à un service token transmis dans les en-
têtes HTTP et contrôlé par un middleware dédié, empêchant ainsi tout accès direct
non autorisé aux services internes. Par ailleurs, l’API Gateway met en œuvre le
mécanisme CORS (Cross-Origin Resource Sharing) afin de limiter les requêtes
aux seules origines autorisées et de protéger l’API contre les accès malveillants
provenant d’applications externes. Enfin, les informations sensibles, telles que les
clés, mots de passe et jetons, sont centralisées dans un fichier .env exclu du
contrôle de version, une approche qui peut être remplacée en environnement de
production par des solutions spécialisées de gestion des secrets, telles que
HashiCorp Vault ou Kubernetes Secrets, offrant un niveau de sécurité plus élevé.

16
 Chapitre4 : Présentation de l’application finale

Conclusion

Ce chapitre a posé les bases théoriques nécessaires à la compréhension de notre

projet. Nous avons exploré le continuum entre architecture monolithique et
microservices, les mécanismes de routage et d'équilibrage de charge via l'API
Gateway et Nginx, les différents algorithmes de load balancing et leurs cas d'usage,
les mécanismes de découverte de services et de health checking, les fondements de
l'observabilité et du logging structuré, et les pratiques de sécurité adaptées aux
architectures distribuées.

L'ensemble de ces concepts ne sont pas de simples abstractions théoriques : chacun

d'entre eux se retrouve concrètement implémenté dans notre projet sous la forme de
code [Link], de configurations Nginx et de fichiers Docker Compose. Le chapitre
suivant détaillera les choix de conception et la mise en œuvre technique de cette
architecture.

17
 Chapitre4 : Présentation de l’application finale

Chapitre 3 : Analyse des

besoins et conception de la
solution

18
 Chapitre4 : Présentation de l’application finale

Introduction
Après avoir situé notre projet dans son contexte général et étudié l'état de l'art des
architectures microservices et des mécanismes de load balancing au chapitre
précédent, ce troisième chapitre constitue le cœur de la démarche d'ingénierie. Il
présente l'ensemble du travail de conception qui a précédé le développement du
système.

La conception d'un système distribué tel qu'un Load Balancer Intelligent pour une
architecture microservices requiert une analyse rigoureuse des besoins avant toute
ligne de code. Cette phase est déterminante : elle permet d'identifier précisément les
fonctionnalités attendues, de définir les contraintes de qualité du système et de
poser les bases architecturales sur lesquelles l'implémentation s'appuiera.

Ce chapitre s'organise autour de six axes : l'analyse des besoins du système, la

spécification fonctionnelle détaillée, les exigences non fonctionnelles, l'architecture
générale de la solution, la description de chaque composant, la conception du
mécanisme de load balancing multi-algorithmes, et enfin la modélisation UML
complète du système.

3.1. Analyse des besoins

L'analyse des besoins constitue la première étape fondamentale de tout projet
logiciel. Elle vise à comprendre les attentes des utilisateurs, les contraintes du
domaine et les objectifs du système avant d'entreprendre sa conception. Pour notre
projet de Load Balancer Intelligent, cette analyse porte sur deux dimensions
complémentaires : les acteurs du système et les problèmes qu'ils cherchent à
résoudre.

3.1.1. Identification des Acteurs

Notre système s'adresse à deux catégories principales d'acteurs :

 L'administrateur du système : il configure et supervise l'infrastructure microservices.

Il a besoin de visualiser en temps réel l'état des services, de modifier la stratégie de load
balancing, d'enregistrer de nouvelles instances et de surveiller les métriques du système.
 L'utilisateur final : il interagit avec l'application à travers le frontend. Il s'inscrit, se
connecte, passe des commandes et effectue des paiements, sans avoir conscience de la

19
 Chapitre4 : Présentation de l’application finale

complexité de l'infrastructure sous-jacente. Pour lui, le système doit être rapide et

toujours disponible.

3.1.2. Problèmes Identifiés

L'analyse du contexte et des besoins révèle quatre problèmes majeurs que notre
solution doit résoudre :

Plusieurs problèmes ont été identifiés dans l’architecture existante, ayant des
impacts directs sur les performances et la fiabilité du système. Tout d’abord, la
surcharge d’une instance unique entraîne un goulot d’étranglement, provoquant une
augmentation de la latence et pouvant aller jusqu’à une interruption de service.
Ensuite, l’absence de mécanisme de détection automatique des pannes fait que les
requêtes continuent d’être dirigées vers des instances défaillantes, ce qui dégrade la
disponibilité du système. Par ailleurs, la stratégie de distribution des requêtes est
rigide et ne permet pas de s’adapter dynamiquement en fonction du type ou de la
charge du trafic, limitant ainsi l’efficacité globale de l’architecture. Enfin, le
manque d’observabilité constitue une faiblesse majeure, car il n’existe pas de
visibilité suffisante sur l’état des services ni sur la répartition du trafic, ce qui
complique le diagnostic et la maintenance du système

3.2. Spécification fonctionnelle

Les spécifications fonctionnelles décrivent les différentes fonctionnalités que le système doit
offrir. Elles sont organisées selon les principaux domaines fonctionnels de la plateforme.

[Link] de l'authentification

Le système doit permettre l'inscription d'un nouvel utilisateur avec validation des
champs (nom, email, mot de passe) et hachage sécurisé du mot de passe avec bcrypt
(facteur de coût 10).
Le système doit authentifier un utilisateur via son email et son mot de passe, puis
retourner un token JWT signé avec une durée de validité configurable (24 heures par
défaut).
Le système doit valider les tokens JWT sur chaque requête protégée grâce à un
middleware dédié (verifyJWT).
Le système doit permettre la déconnexion en invalidant le token côté client.

20
 Chapitre4 : Présentation de l’application finale

[Link] des utilisateurs

Le système doit permettre la création, la consultation, la modification et la suppression

(CRUD) des profils utilisateurs avec persistance des données dans PostgreSQL.
Le système doit retourner la liste paginée des utilisateurs ainsi que les informations d'un
utilisateur à partir de son identifiant unique.
Le système doit garantir l'unicité de l'adresse e-mail dans la base de données.

[Link] des commandes

Le système doit permettre la création d'une commande associant un utilisateur à un

produit, avec un prix et un statut initial Pending.
Le système doit gérer le cycle de vie complet d'une commande : Pending →
Processing → Shipped → Completed ou Cancelled.
Le système doit permettre la consultation de l'historique des commandes d'un
utilisateur.
Le système doit autoriser la suppression d'une commande conformément aux règles
métier.

[Link] des paiements

Le système doit traiter les demandes de paiement associées aux commandes en prenant
en charge le montant, le mode de paiement et la génération d'un identifiant unique de
transaction.
Le système doit conserver un historique des transactions indexé par identifiant de
commande.
Le système doit permettre le remboursement d'un paiement avec mise à jour du statut de
la transaction.

[Link] balancing et routage

Le système doit implémenter les quatre algorithmes de répartition de charge : Round

Robin, Least Connections, Weighted Round Robin et IP Hash.
Le système doit permettre le changement dynamique de la stratégie de load balancing
sans interruption de service via l'endpoint POST /lb/strategy.
Le système doit acheminer chaque requête vers l'instance disponible la plus appropriée
selon l'algorithme actif.

21
 Chapitre4 : Présentation de l’application finale

Le système doit ajouter automatiquement les en-têtes de traçabilité x-load-balancer et

x-selected-server dans les réponses.

[Link] et découverte des services

Le système doit exposer un endpoint GET /health sur chaque microservice afin de
fournir son état, son temps de fonctionnement (uptime) et un horodatage.
Le système doit exposer un endpoint GET /health/services au niveau de l'API Gateway
pour agréger l'état de santé de tous les services.
Le système doit permettre l'enregistrement dynamique de nouvelles instances via POST
/registry/register.
Le système doit permettre la suppression d'une instance via DELETE
/registry/deregister.
Le système doit exécuter automatiquement des contrôles d'état périodiques afin
d'exclure les instances défaillantes de la répartition de charge.

[Link]é et tableau de bord

Le système doit enregistrer chaque requête HTTP au format JSON en conservant les
informations essentielles telles que la date, le service, la méthode, le chemin, la durée de
traitement et le code de retour.
Le système doit exposer les statistiques du load balancer (algorithme actif, nombre
d'instances et connexions actives) via GET /lb/stats.
Le système doit fournir un tableau de bord en temps réel affichant l'état des services, les
métriques du load balancer ainsi que les journaux récents.

3.3 Spécification non fonctionnelle

Les spécifications non fonctionnelles définissent les critères de qualité que le système doit
respecter indépendamment des fonctionnalités métier. Elles conditionnent l'expérience
utilisateur, la robustesse et la maintenabilité du système.

Les spécifications non fonctionnelles du système définissent les exigences essentielles

garantissant la qualité globale de l’architecture. En termes de performance, le système doit
maintenir une latence inférieure à 100 ms, avec une contribution du load balancer ne
dépassant pas 10 ms, mesurée via l’en-tête x-response-time. Concernant la disponibilité, un
taux d’uptime supérieur à 99,5 % est requis, assuré par un mécanisme de failover permettant

22
 Chapitre4 : Présentation de l’application finale

de maintenir le service même en cas de panne d’une instance. La scalabilité est assurée par
la capacité de déploiement horizontal des services, sans modification du code, grâce au
service registry qui facilite la gestion dynamique des instances. Sur le plan de la sécurité,
l’authentification repose sur des tokens JWT dans un contexte stateless, avec des mots de
passe hachés via bcrypt (coût 10) et des mécanismes de communication sécurisée entre
services. La maintenabilité est garantie par une architecture faiblement couplée où chaque
service est indépendant et peut être modifié ou redéployé séparément, avec du code
mutualisé dans un répertoire shared/. En matière de portabilité, chaque service est
conteneurisé avec Docker et orchestré via Docker Compose, permettant un déploiement
simplifié et reproductible. L’observabilité est assurée par des logs structurés en JSON
compatibles avec des outils comme ELK ou Datadog, complétés par des health checks
réguliers effectués toutes les 30 secondes. Enfin, la résilience du système repose sur un
mécanisme d’auto-failover capable de détecter les instances défaillantes en moins de 30
secondes et de les exclure automatiquement du pool, garantissant ainsi qu’au moins une
instance reste toujours disponible.

3.4 Architecture générale de la solution

L'architecture retenue adopte une organisation en couches hiérarchiques, où chaque couche

remplit un rôle précis et bien délimité. Cette approche garantit la séparation des responsabilités,
le faible couplage entre composants et la facilité d'évolution du système.

[Link] d'ensemble
Le système s’organise selon cinq couches fonctionnelles superposées, chacune
jouant un rôle précis dans le traitement et la circulation des requêtes. La première
couche est la couche d’accès, composée des clients tels que le navigateur web,
l’application mobile ou les outils de test, et représente le point d’entrée externe du
système. La deuxième couche est la couche proxy, assurée par NGINX (port
8080), qui agit comme un load balancer externe et distribue le trafic entre deux
instances de l’API Gateway selon une stratégie de type Round Robin, constituant
ainsi un premier niveau de répartition de charge. La troisième couche est la couche
Gateway, constituée de deux instances de l’API Gateway (port 3000), intégrant un
load balancer intelligent basé sur plusieurs algorithmes, un service registry, la
gestion CORS, le logging centralisé ainsi que le routage vers les microservices
métier. La quatrième couche correspond à la couche des services, composée des

23
 Chapitre4 : Présentation de l’application finale

microservices Auth (3001), Users (3002), Orders (3003) et Payment (3004),

développés en [Link]/Express, chacun étant indépendant et responsable d’une
logique métier spécifique avec sa propre base de données PostgreSQL. Enfin, la
cinquième couche est la couche de données, représentée par PostgreSQL 16 (port
5432), qui constitue une base relationnelle centralisée contenant les tables users,
orders et payments, avec une persistance assurée via des volumes Docker pour
garantir la durabilité des données.

[Link] de communication
Le flux de traitement d'une requête suit le chemin suivant :

Le client envoie une requête HTTP vers le port 8080 (Nginx).

Nginx sélectionne l'une des deux instances de l'API Gateway en Round Robin et lui
transmet la requête en ajoutant les en-têtes X-Real-IP et X-Forwarded-For.
L'API Gateway reçoit la requête, identifie le service cible (auth, users, orders ou
payment) à partir du chemin URL, puis consulte le Load Balancer Intelligent afin de
sélectionner l'instance de service appropriée selon l'algorithme actif.
La requête est transmise au service métier sélectionné avec l'en-tête x-service-token
pour assurer l'authentification inter-services.
Le service métier exécute la logique applicative, interroge PostgreSQL si nécessaire,
puis retourne la réponse.
L'API Gateway relaie enfin la réponse au client en ajoutant les en-têtes de traçabilité x-
selected-server et x-load-balancer.

[Link] de déploiement
L'ensemble du système est conteneurisé avec Docker. Le fichier docker-
[Link] orchestre huit conteneurs au sein d'un réseau Docker privé nommé
microservices-network :

microservices-postgres : PostgreSQL 16 avec healthcheck intégré (pg_isready) et

volume persistant postgres_data.
auth-service, users-service, orders-service et payment-service : quatre conteneurs
dédiés aux services métier, démarrés uniquement après la disponibilité de PostgreSQL
grâce à la condition service_healthy.

24
 Chapitre4 : Présentation de l’application finale

api-gateway et api-gateway-2 : deux instances identiques de l'API Gateway assurant la

redondance et la répartition des requêtes.
nginx : conteneur Nginx utilisant un montage en lecture seule du fichier de
configuration.
frontend : conteneur hébergeant le tableau de bord de supervision et de monitoring.

3.5. Description des composants de la solution

[Link] Service (Port 3001)

Le service d'authentification gère l'identité des utilisateurs. Il implémente les
fonctionnalités suivantes avec persistance dans la table users de PostgreSQL :

POST /auth/register : validation des champs (nom, email et mot de passe requis),
hachage du mot de passe avec bcrypt (coût de sel 10), insertion en base de données
avec gestion de la contrainte d'unicité de l'email (code PostgreSQL 23505), puis retour
du profil créé sans le mot de passe.
POST /auth/login : récupération de l'utilisateur à partir de son email, comparaison du
mot de passe avec [Link](), génération d'un jeton JWT signé à l'aide de la clé
secrète JWT_SECRET, puis retour du jeton et des informations de l'utilisateur.
GET /health : retourne l'état du service, son temps de fonctionnement (uptime) ainsi
qu'un horodatage au format ISO-8601.

La table users comprend les colonnes id (VARCHAR, clé primaire), name, email
(UNIQUE), password (haché), role, created_at et updated_at.

[Link] Service (Port 3002)

Le service utilisateurs expose les opérations CRUD complètes sur les entités utilisateur. Les
endpoints GET /users, POST /users, GET /users/:id, PUT /users/:id et DELETE /users/:id
permettent la gestion complète du référentiel des utilisateurs. Chaque opération de
modification met automatiquement à jour le champ updated_at.

[Link] Service (Port 3003)

Le service de gestion des commandes assure le cycle de vie complet des commandes. Les
statuts suivent une machine à états : pending → processing → shipped → completed, avec
la possibilité de passer à l'état cancelled. L'endpoint GET /orders/user/:userId permet de
récupérer l'historique complet des commandes d'un utilisateur.

25
 Chapitre4 : Présentation de l’application finale

[Link] Service (Port 3004)

Le service des paiements prend en charge les transactions financières associées aux
commandes. Il génère un transaction_id unique pour chaque paiement, conserve l'historique
des transactions dans la table payments et gère les remboursements via l'endpoint POST
/payments/:id/refund, en enregistrant la date et l'heure du remboursement dans le champ
refunded_at.

[Link] Gateway (Port 3000)

L'API Gateway constitue le point d’entrée logique de l’architecture. Sa description détaillée a
été présentée dans la section 3.4. Dans cette section, nous présentons uniquement ses
principales fonctionnalités implémentées.

Forwarding intelligent
Gestion des pannes
Administration

[Link] partagée (shared/)

Le répertoire shared/ regroupe les composants communs à l'ensemble des
microservices afin de limiter la duplication du code :

[Link] : implémente la classe LoadBalancer, incluant une classe Server

imbriquée et les quatre algorithmes de répartition de charge. Une instance unique est
utilisée pour chaque service au sein de l'API Gateway.
[Link] : fournit un registre statique basé sur une structure Map, avec les
méthodes register(), getServices(), healthCheck() et deregister().
[Link] : configure un pool de connexions PostgreSQL à partir des variables
d'environnement DB_HOST, DB_PORT, DB_USER, DB_PASSWORD et
DB_NAME.
[Link] : met en œuvre un système de journalisation au format JSON avec les niveaux
ERROR, WARN, INFO et DEBUG, ainsi qu'un stockage des journaux dans le
répertoire logs/.
[Link] : contient les middlewares communs tels que requestLogger (mesure de
la durée des requêtes), errorHandler (gestion centralisée des erreurs) et serviceAuth
(validation du jeton d'authentification entre services).

26
 Chapitre4 : Présentation de l’application finale

[Link] : centralise la configuration de l'application en lisant les variables

d'environnement tout en définissant des valeurs par défaut.

[Link] Dashboard (Port 3500)

Le tableau de bord frontend est servi par un serveur Express léger. Il interroge
automatiquement l'API Gateway toutes les dix secondes afin d'actualiser l'état des services, les
statistiques du Load Balancer ainsi que les journaux récents. L'interface met également à
disposition un formulaire permettant de tester les principaux endpoints de l'application.

3.6. Conception du mécanisme du Load Balancer

Le Load Balancer Intelligent constitue la contribution centrale de ce projet. Sa conception

repose sur une architecture orientée objet composée de deux classes principales : Server et
LoadBalancer.

[Link]èle de données — Classe Server

Chaque instance de service est modélisée sous forme d’un objet Server, qui
regroupe l’ensemble des informations nécessaires à sa gestion et à son intégration
dans le système de load balancing. Cet objet contient plusieurs attributs essentiels.
L’attribut url (de type String) représente l’adresse complète de l’instance, par
exemple [Link] L’attribut weight (de type Integer) définit le
poids attribué à l’instance dans l’algorithme de répartition de charge Weighted
Round Robin, avec une valeur par défaut fixée à 1. L’attribut connections (de type
Integer) correspond au nombre de connexions actives vers l’instance, et est mis à
jour de manière atomique afin de garantir la cohérence des données. L’attribut
healthy (de type Boolean) indique l’état de santé de l’instance, où la valeur true
signifie que le service est opérationnel et false qu’il est exclu temporairement du
pool de distribution. Enfin, l’attribut addedAt (de type String au format ISO)
enregistre l’horodatage d’ajout de l’instance dans le système, permettant ainsi de
suivre son cycle de vie.

[Link] quatre algorithmes implémentés

Chaque algorithme de répartition de charge répond à un scénario d'utilisation spécifique.

Round Robin
L'algorithme Round Robin distribue les requêtes de manière cyclique entre toutes les instances
disponibles. Un compteur currentIndex est conservé puis incrémenté après chaque requête. La
sélection de l'instance repose sur l'opération modulo appliquée au nombre d'instances saines.

27
 Chapitre4 : Présentation de l’application finale

Complexité : O(1). Cette approche est particulièrement adaptée aux

environnements composés d'instances homogènes recevant une charge uniforme.

Least Connections
L'algorithme Least Connections sélectionne l'instance possédant le plus faible
nombre de connexions actives au moment de la requête. Son comportement est
dynamique : une instance qui traite des requêtes longues voit son compteur
augmenter et reçoit automatiquement moins de nouvelles requêtes.
Complexité : O(n). Cet algorithme est particulièrement efficace lorsque la durée de
traitement des requêtes est variable.

Weighted Round Robin

Le Weighted Round Robin est une extension du Round Robin classique. Il
attribue davantage de requêtes aux instances disposant d'une capacité de traitement
supérieure. Une liste pondérée weightedServers est construite en dupliquant
chaque instance selon son poids.
Dans le fichier [Link], les poids sont configurés à l'aide des
variables d'environnement :

 USERS_WEIGHT = 2
 ORDERS_WEIGHT = 3
 AUTH_WEIGHT = 1
 PAYMENT_WEIGHT = 1

Cette configuration signifie que le Orders Service reçoit environ trois fois plus de
requêtes que le Auth Service.
Complexité : O(Σw) pour la construction de la liste pondérée, puis O(1) pour la
sélection de l'instance.

IP Hash
L'algorithme IP Hash garantit la persistance des sessions (sticky sessions) en
calculant un hachage de l'adresse IP du client. L'instance cible est ensuite
déterminée grâce à une opération modulo appliquée au nombre d'instances
disponibles.
Complexité : O(k), où k représente la longueur de l'adresse IP. Cette méthode
garantit qu'un même client est systématiquement dirigé vers la même instance tant
que le pool de serveurs reste inchangé.

28
 Chapitre4 : Présentation de l’application finale

[Link] de la santé des instances

La surveillance de la disponibilité des instances repose sur deux mécanismes
complémentaires :

Détection passive : lors du transfert d'une requête, si une erreur ECONNREFUSED ou

ETIMEDOUT est détectée, l'instance concernée est immédiatement marquée comme
indisponible à l'aide de setHealth(url, false). Elle est alors automatiquement retirée du
pool des instances saines dès la requête suivante.
Vérification active : le Service Registry exécute périodiquement des contrôles de
disponibilité en envoyant une requête GET /health toutes les trente secondes vers
chaque instance enregistrée. Les instances répondant avec un code HTTP 200 sont
considérées comme disponibles.

Un mécanisme de sécurité (failsafe) est également mis en œuvre. Si toutes les

instances d'un service deviennent indisponibles, la propriété healthyServers
continue de retourner la liste complète des instances afin d'éviter une interruption
totale du système. Cette stratégie privilégie une dégradation progressive du service
plutôt qu'un arrêt complet.

[Link] des algorithmes

Les principaux algorithmes de répartition de charge se distinguent par leur complexité, leur
gestion des sessions et leurs cas d’usage optimaux. L’algorithme Round Robin présente une
complexité en O(1) et ne nécessite pas de gestion de session, ce qui le rend adapté aux
environnements où les instances sont homogènes et les requêtes courtes et uniformes.
L’algorithme Least Connections, de complexité O(n), ne gère pas les sessions mais est
particulièrement efficace pour les API dont les requêtes ont des durées variables, comme les
traitements de type machine learning. Le Weighted Round Robin, avec une complexité de
O(Σw), fonctionne également sans session et est conçu pour des environnements hétérogènes
où les serveurs disposent de capacités différentes, permettant ainsi une répartition pondérée des
charges. Enfin, l’algorithme IP Hash, de complexité O(k), assure une gestion de session en
maintenant la cohérence des requêtes d’un même utilisateur, ce qui le rend adapté aux
applications stateful telles que les systèmes de panier d’achat ou les services nécessitant la
persistance de session utilisateur.

29
 Chapitre4 : Présentation de l’application finale

3.7. Modélisation UML

La modélisation UML du système offre une représentation standardisée de son
comportement et de ses interactions. Nous présentons trois types de diagrammes
complémentaires : le diagramme de cas d'utilisation, le diagramme de séquence du
flux de connexion et le diagramme d'activité du mécanisme de load balancing.

[Link] de Cas d'Utilisation

 Figure 3.2 : Diagramme de cas d'utilisation

[Link] de Séquence

30
Chapitre4 : Présentation de l’application finale

Figure 3.3 : Diagramme de séquence

31
 Chapitre4 : Présentation de l’application finale

[Link] d'Activité

Figure 3.4 : Diagramme d'activité

32
 Chapitre4 : Présentation de l’application finale

Conclusion
Ce chapitre a présenté l'ensemble du travail de conception qui sous-tend notre
système de Load Balancer Intelligent pour une architecture microservices.
L'analyse des besoins a mis en évidence quatre problèmes fondamentaux —
surcharge, absence de détection de pannes, rigidité de la distribution et manque
d'observabilité — auxquels notre solution apporte des réponses concrètes.

Les spécifications fonctionnelles ont défini avec précision les 25 fonctionnalités du

système, organisées autour de sept domaines : authentification JWT, gestion des
utilisateurs, des commandes et des paiements, load balancing multi-algorithmes,
health monitoring et observabilité. Les spécifications non fonctionnelles ont établi
les critères mesurables de qualité : latence < 100 ms, disponibilité > 99,5%,
scalabilité horizontale et sécurité JWT/bcrypt.

L'architecture en cinq couches (Client → Nginx → API Gateway × 2 → Services

métier → PostgreSQL) garantit la séparation des responsabilités et la résilience du
système. La conception du Load Balancer avec ses quatre algorithmes (Round
Robin en O(1), Least Connections en O(n), Weighted Round Robin en O(Σw) et IP
Hash en O(k)) offre une adaptabilité maximale aux différents profils de charge.

La modélisation UML (cas d'utilisation, séquence d'authentification et activité de

load balancing) fournit une documentation standardisée et précise du comportement
du système, facilitant sa compréhension et son évolution future.

Le chapitre suivant présentera l'implémentation concrète de ces conceptions, en

détaillant le code source des composants clés et les choix techniques effectués lors
du développement.

33
 Chapitre4 : Présentation de l’application finale

Chapitre4 : Présentation de
l’application finale

34
 Chapitre4 : Présentation de l’application finale

Introduction
Ce chapitre présente l'application finale développée dans le cadre de ce projet de fin
d'études. Après avoir posé les bases théoriques au chapitre 2 et défini l'architecture
et les besoins au chapitre 3, nous illustrons ici le résultat concret : une plateforme
web de démonstration d'une architecture microservices avec load balancing
intelligent, supervision en temps réel et gestion complète des données métier.

L'interface utilisateur a été développée en HTML5/CSS3/JavaScript vanilla, sans

framework front-end, afin de privilégier la lisibilité et la légèreté. Elle communique
exclusivement avec l'API Gateway via des requêtes fetch() asynchrones, illustrant
ainsi le rôle de point d'entrée unique de la gateway. Chaque section de l'application
correspond à un microservice ou à une fonctionnalité transversale de la plateforme.

Nous décrivons successivement : l'interface de connexion, le tableau de bord

principal, l'interface des endpoints API, les interfaces de gestion des microservices
(Users, Orders, Payments), l'interface de supervision de l'état des services, la
gestion du load balancer et l'interface de consultation des logs.

4.1 Interface de connexion

4.1.1 Présentation générale

L'interface de connexion est la première page affichée à l'utilisateur. Elle est rendue
sur un fond en dégradé violet-bleu (gradient CSS de #667eea vers #764ba2) qui
constitue l'identité visuelle de la plateforme. Une carte blanche centrée accueille le
formulaire de connexion, avec un ombrage prononcé pour un effet de profondeur.

35
 Chapitre4 : Présentation de l’application finale

Figure 4.1 — Interface de connexion de la plateforme Microservices

4.1.2 Mécanisme d'authentification

Lors de la soumission du formulaire, la fonction JavaScript `login()` effectue une
requête POST vers `/api/auth/login` avec les credentials en JSON. En cas de succès,
le token JWT retourné est stocké en mémoire (variable `currentToken`) et utilisé
comme en-tête `Authorization: Bearer <token>` pour toutes les requêtes suivantes.
La page de login est masquée et l'application principale est affichée.

Identifiants de démonstration : Email : maha@[Link] | Mot de passe :

123456

La gestion des erreurs est assurée côté client : en cas d'échec d'authentification
(HTTP 401), un message d'alerte est affiché. En cas d'indisponibilité de l'API
Gateway, l'erreur réseau est interceptée et présentée à l'utilisateur.

4.2 Tableau de bord principal

[Link] d'ensemble
Le tableau de bord est la section centrale de l'application. Affiché immédiatement
après la connexion, il agrège en temps réel les informations essentielles de
36
 Chapitre4 : Présentation de l’application finale

l'architecture : état des services, uptime de la gateway, algorithme de load balancing

actif, et résultats de la découverte de services. La mise en page repose sur une barre
latérale fixe à gauche et une zone de contenu défilante à droite.

Figure 4.2 — Tableau de bord principal : vue d'ensemble de l'architecture

[Link] de statistiques
Les quatre cartes de statistiques en haut du tableau de bord sont alimentées
dynamiquement par la fonction `loadDashboardStats()`. Cette fonction effectue
trois requêtes parallèles : GET /health/services pour compter les services sains,
GET /health pour obtenir l'uptime de la gateway, et GET /admin/lb/current pour
afficher l'algorithme de load balancing actif. Les valeurs sont mises à jour à chaque
chargement de la section Dashboard.

[Link] des services

La grille des services affiche une carte pour chacun des quatre microservices (Auth,
Users, Orders, Payment). Chaque carte indique le nom, le port, le statut actuel
(healthy/unhealthy/checking) et l'uptime. Les badges de statut sont colorés : vert
(#4caf50) pour healthy, rouge (#f44336) pour unhealthy, et orange (#ff9800) pour
checking. Cette information provient de l'endpoint agrégé GET /health/services de
l'API Gateway.

4.3 Interface API Endpoints

[Link]ésentation
La section API Endpoints, accessible depuis le tableau de bord, documente
l'ensemble des routes disponibles à travers l'API Gateway ([Link] via
Nginx). Elle est organisée par domaine fonctionnel : authentification, gestion des

37
 Chapitre4 : Présentation de l’application finale

utilisateurs, commandes et paiements. Chaque endpoint est affiché sous forme de

carte avec la méthode HTTP et le chemin.

📡 API Endpoints — Accès via [Link]

Authentification

Users

Orders

Payments

[Link] couleur des méthodes HTTP

Méthode Couleur Sémantique
HTTP

GET Vert (#4CAF50) Lecture de ressources —

opération sans effet de bord

POST Bleu (#667EEA) Création de ressources ou

déclenchement d'actions

PUT Orange Mise à jour partielle ou

(#FF9800) complète d'une ressource

DELETE Rouge (#F44336) Suppression définitive d'une

38
 Chapitre4 : Présentation de l’application finale

ressource

4.4 Interfaces de gestion des microservices

[Link] Users Service

La section Users permet la gestion complète des profils utilisateur via le users-
service (port 3002). L'interface expose deux champs de saisie (nom et email) et
deux boutons d'action principaux. Toutes les requêtes passent par l'API Gateway
avec le header d'authentification `Authorization: Bearer <token>`.

Figure 4.4 — Interface de gestion des utilisateurs (Users Service)

Fonctionnalités implémentées : création d'un utilisateur (POST /api/users),

chargement de la liste (GET /api/users), suppression (DELETE /api/users/:id).
Chaque opération est suivie d'un rafraîchissement automatique de la liste et d'une
mise à jour des statistiques du tableau de bord.

[Link] Orders Service

La section Orders gère le cycle de vie des commandes. La particularité de cette
interface est qu'elle crée simultanément une commande et déclenche un paiement :
le formulaire inclut donc le champ de méthode de paiement en plus des
informations de commande. La réponse de l'API retourne à la fois les données de la
commande et celles du paiement associé.

39
 Chapitre4 : Présentation de l’application finale

Figure 4.5 — Interface de gestion des commandes avec indication du serveur sélectionné par le
load balancer

Une fonctionnalité remarquable de cette interface est l'affichage de l'algorithme de

load balancing utilisé et du serveur cible sélectionné pour chaque requête. Ces
informations sont extraites des headers de réponse HTTP `x-load-balancer` et `x-
selected-server` ajoutés par l'API Gateway, rendant visible à l'utilisateur final le
comportement du load balancer.

[Link] Payment Service

La section Payments permet la gestion directe des paiements, indépendamment du
flux automatique déclenché lors de la création d'une commande. L'interface expose
les mêmes informations de traçabilité du load balancer (algorithme et serveur
sélectionné) et affiche pour chaque paiement son identifiant de transaction unique.

Champ Source de Description

affiché la donnée

ID paiement payment- Identifiant unique au format

service DB payment_<timestamp>

Order ID Requête Référence à la commande

client associée

Montant Requête Valeur en euros

client

40
 Chapitre4 : Présentation de l’application finale

Méthode Requête card, virement, etc.

client

Statut payment- completed, failed, ou refunded

service

Transaction payment- Identifiant au format

ID service txn_<timestamp>

Algorithme Header Algorithme utilisé pour router la

LB réponse requête

Serveur Header URL du microservice ayant traité

sélectionné réponse la requête

4.5 Interface service health

[Link]ésentation
La section Services Health est dédiée à la supervision en temps réel de l'état de
chaque microservice. Elle est automatiquement chargée à chaque navigation vers
cette section. L'information est obtenue via un appel à GET /health/services de
l'API Gateway, qui interroge en parallèle ([Link]) les endpoints /health
de chacun des quatre microservices.

41
 Chapitre4 : Présentation de l’application finale

Figure 4.6 — Interface de supervision des services : tous les services sont en état healthy

[Link] affichées par service

Chaque carte de service affiche six informations : le statut (healthy / unhealthy /
checking), le numéro de port, l'algorithme de load balancing actif, le temps de
fonctionnement (uptime formaté en heures, minutes, secondes), et l'heure de la
dernière vérification. Le badge de statut change dynamiquement de couleur en
fonction de l'état réel du service, permettant une identification visuelle immédiate
des pannes.

En cas de service indisponible (timeout ou connexion refusée), la carte affiche le

badge en rouge avec le statut 'unhealthy'. Ce comportement est rendu possible par
`[Link]` qui garantit une réponse de la gateway même si certains
services sont hors ligne.

4.6 Interface load balancer

[Link]ésentation et fonctionnalités
La section Load Balancer est l'interface la plus distinctive de la plateforme : elle
permet de changer à la volée l'algorithme de répartition de charge utilisé par l'API
Gateway, sans redémarrage du service. Cette fonctionnalité illustre concrètement la
notion de configuration dynamique dans une architecture microservices.

42
 Chapitre4 : Présentation de l’application finale

Figure 4.7 — Interface de gestion du load balancer avec sélection d'algorithme et statistiques

4.6.2.Mécanisme de changement d'algorithme

Le changement d'algorithme est réalisé via une requête PUT /admin/lb/algorithm
envoyée à l'API Gateway. La fonction `changeAlgorithm()` récupère la valeur du
select HTML et envoie le nouveau nom d'algorithme en JSON. La gateway met à
jour simultanément les quatre instances LoadBalancer (auth, users, orders,

43
 Chapitre4 : Présentation de l’application finale

payment) sans redémarrage. L'effet est immédiat : la prochaine requête vers

n'importe quel service utilisera le nouvel algorithme.

Les statistiques affichées par le bouton 'Load Balancer Stats' proviennent de GET
/admin/lb/stats et détaillent pour chaque service : l'algorithme actif, le nombre total
de serveurs, le nombre de serveurs sains, et pour chaque serveur son URL, son
poids, le nombre de connexions actives et son état de santé.

4.7 Interface logs

[Link]ésentation
La section Logs affiche en temps réel les entrées du journal de bord de l'application
côté client. Elle joue le rôle d'un terminal de supervision intégré à l'interface web,
permettant à l'utilisateur de suivre l'enchaînement des opérations effectuées sans
quitter la plateforme.

Figure 4.8 — Interface de logs système : journal des opérations en temps réel

[Link] du système de logs client

Les logs côté client sont gérés par deux fonctions complémentaires : `log(message)`
qui ajoute une entrée dans le terminal de la section Logs avec l'horodatage courant,
et `addLog(message, type)` qui ajoute une entrée colorée dans le terminal du
tableau de bord (section System Logs). Le défilement automatique (`scrollTop =
scrollHeight`) garantit que la dernière entrée est toujours visible.

Ces logs client complètent les logs serveur stockés dans les fichiers
`logs/<service>.log` par le système de logging JSON côté [Link]. La combinaison

44
 Chapitre4 : Présentation de l’application finale

des deux niveaux de logging offre une traçabilité complète : depuis l'action
utilisateur dans le navigateur jusqu'à l'exécution dans le microservice cible.

Niveau Couleur Exemples de messages

terminal

INFO Cyan Connexion réussie, données

(#4ECDC4) chargées, opération complétée

WARN Jaune Timeout d'un service, tentative

(#FFD93D) de reconnexion

ERROR Rouge Erreur réseau, service

(#FF6B6B) indisponible, échec
d'authentification

DEBUG Vert clair Découverte de services, détails

(#95E1D3) techniques de débogage

Conclusion
Ce chapitre a présenté l'ensemble des interfaces de la plateforme finale.
L'application démontre concrètement les principes architecturaux définis dans les
chapitres précédents à travers une interface fonctionnelle et cohérente.

L'interface de connexion illustre l'authentification JWT centralisée par l'auth-

service. Le tableau de bord agrège en temps réel les informations de supervision de
l'ensemble de l'architecture. Les interfaces de gestion des microservices (Users,
Orders, Payments) démontrent les opérations CRUD et le flux inter-services
(commande → paiement). La section Services Health rend visible l'état de santé de
chaque microservice et illustre la résilience du système via [Link].
L'interface Load Balancer permet de changer dynamiquement l'algorithme de
répartition parmi quatre options (Round Robin, Least Connections, IP Hash,
Weighted Round Robin). Enfin, l'interface Logs offre une traçabilité complète des
opérations côté client.

Un élément distinctif de cette implémentation est la transparence du load balancing

rendue visible à l'utilisateur : chaque réponse des services Orders et Payments
affiche l'algorithme utilisé et le serveur sélectionné, grâce aux headers
personnalisés `x-load-balancer` et `x-selected-server` ajoutés par l'API Gateway.
Cette visibilité pédagogique est au cœur des objectifs du projet.

45
 Chapitre4 : Présentation de l’application finale

Chapitre 5 : Tests,Validation

46
 Chapitre4 : Présentation de l’application finale

Introduction
Ce chapitre présente la stratégie de validation adoptée pour l'architecture
microservices développée dans le cadre de ce projet de fin d'études. L'application
repose sur cinq composants distribués — un API Gateway, et quatre services métier
(Auth, Users, Orders, Payment) — orchestrés via Docker et exposés au client à
travers un frontend [Link]. La fiabilité de ce système distribué nécessite une
batterie de tests couvrant chaque couche : les fonctionnalités métier, le routage de
l'API Gateway, les mécanismes de santé (Health Check) et enfin l'équilibrage de
charge (Load Balancing).

Les tests ont été conduits selon une approche progressive allant du test unitaire de
chaque service vers l'intégration complète de la chaîne de traitement. Les résultats
obtenus confirment la robustesse de l'architecture et valident les choix
technologiques effectués.

5.1 Stratégie de test

La stratégie retenue suit les principes de la pyramide des tests appliquée aux
architectures distribuées. Trois niveaux de vérification ont été définis :

Tests unitaires de service : chaque microservice est testé de manière isolée en ciblant ses
endpoints REST, ses règles de validation des entrées et ses comportements d'erreur.
Tests d'intégration via l'API Gateway : les flux complets (login → création de
commande → paiement) sont joués à travers le gateway pour vérifier le routage et la
transmission des jetons de service.
Tests d'infrastructure : les endpoints de health check et le comportement du load
balancer sont validés indépendamment pour garantir la disponibilité et l'équité de
répartition du trafic.

Les tests sont automatisés via le script [Link] (ou [Link] sous Windows) fourni
avec le projet. Chaque appel curl cible le gateway sur le port 3000, lequel achemine
les requêtes vers le microservice approprié à l'aide du load balancer interne. Les
réponses JSON sont vérifiées visuellement et enregistrées dans logs/[Link].

47
 Chapitre4 : Présentation de l’application finale

Niveau Portée Outil Environnem

ent

Unitaire Un curl / Local (npm

microservi Postman start)
ce isolé

Intégration Flux test- Local /

multi- [Link] Docker
services
via
Gateway

Infrastruct Health curl + Docker

ure check & [Link] Compose
Load nf
Balancing

5.2 Tests des fonctionnalités principales

Les fonctionnalités métier couvrent les quatre services : Auth, Users, Orders et
Payment. Chaque service expose des endpoints CRUD complets et des règles de
validation. Les scénarios ci-dessous couvrent les cas nominaux et les cas d'erreur
les plus représentatifs.

[Link] d'authentification (Auth Service — Port 3001)

Le service d'authentification gère l'inscription, la connexion et la déconnexion. Les
tokens JWT sont générés avec un secret configurable et une durée de vie de 24
heures. Le service utilise bcrypt pour le hachage des mots de passe et PostgreSQL
pour la persistance.

Scénario 1 — Inscription d'un nouvel utilisateur

POST /api/auth/register
Body : { "name": "Safae", "email": "safae@[Link]", "password": "secret123" }
→ 201 Created : { "success": true, "data": { "id": "user_...", "email": "safae@[Link]",
"role": "user" } }

Scénario 2 — Connexion valide

POST /api/auth/login
Body : { "email": "test@[Link]", "password": "1234" }
→ 200 OK : { "success": true, "token": "eyJhbGciOiJIUzI1NiIs..." }

Scénario 3 — Email déjà existant

48
 Chapitre4 : Présentation de l’application finale

POST /api/auth/register (email en doublon)

→ 409 Conflict : { "success": false, "message": "Email already exists" }

Scénario 4 — Déconnexion
POST /api/auth/logout
Body : { "token": "<token>" }
→ 200 OK : { "success": true, "message": "Logged out successfully" }

Test Entrée Résultat Sta

attendu tut

Inscriptio name, 201 + ✅

n valide email, données Pas
passwor utilisateur sé
d

Email Email 409 ✅

doublon existant Conflict Pas
sé

Champs Body 400 Bad ✅

manquant vide Request Pas
s sé

Connexio Credent 200 + ✅

n valide ials JWT Pas
corrects token sé

Mauvais Passwo 401 ✅

mot de rd Unauthori Pas
passe incorrec zed sé
t

Déconne Token 200 OK ✅

xion valide Pas
sé

[Link] Utilisateurs (Users Service — Port 3002)

Le service utilisateurs assure la gestion CRUD des profils. Les données sont
persistées dans PostgreSQL. Toutes les routes sont protégées par le token de service
inter-microservices (header x-service-token).

Test Méthode Résultat Sta

& Route attendu tut

Lister GET 200 + ✅

tous les /api/users tableau Pas

49
 Chapitre4 : Présentation de l’application finale

Test Méthode Résultat Sta

& Route attendu tut

utilisate JSON sé
urs

Créer POST 201 + ✅

un /api/users objet Pas
utilisate créé sé
ur

Récupé GET 200 + ✅

rer par /api/users/ objet Pas
ID :id utilisateu sé
r

Modifie PUT 200 + ✅

r un /api/users/ objet mis Pas
utilisate :id à jour sé
ur

Suppri DELETE 200 + ✅

mer un /api/users/ confirmat Pas
utilisate :id ion sé
ur

ID GET 404 Not ✅

inexista /api/users/ Found Pas
nt xyz sé

[Link] Commandes (Orders Service — Port 3003)

Le service de commandes gère le cycle de vie des commandes : création, mise à
jour du statut (pending, confirmed, shipped, delivered, cancelled) et suppression. Il
est également capable de retourner toutes les commandes d'un utilisateur donné.

Test Méthode & Résu St

Route ltat at
atten ut
du

Créer POST 201 + ✅

une /api/orders com Pa
comma mand ss
nde e é
créée

50
 Chapitre4 : Présentation de l’application finale

Test Méthode & Résu St

Route ltat at
atten ut
du

Lister GET /api/orders 200 + ✅

toutes tablea Pa
les u ss
comma é
ndes

Comm GET 200 + ✅

andes /api/orders/user/ tablea Pa
d'un :userId u ss
utilisat filtré é
eur

Récupé GET 200 + ✅

rer une /api/orders/:id objet Pa
comma com ss
nde mand é
e

Mettre PUT 200 + ✅

à jour /api/orders/:id/s statut Pa
le tatus mis à ss
statut jour é

Statut PUT avec statut 400 ✅

invalid inconnu Bad Pa
e Requ ss
est é

Suppri DELETE 200 ✅

mer /api/orders/:id OK Pa
une ss
comma é
nde

[Link] Paiements (Payment Service — Port 3004)

Le service de paiement traite les transactions associées aux commandes. Il supporte
plusieurs méthodes de paiement (carte bancaire, PayPal) et offre un mécanisme de
remboursement.

51
 Chapitre4 : Présentation de l’application finale

Test Méthode & Résul S

Route tat t
atten a
du t
u
t

Traite POST 200 + ✅

r un /api/payments/pro confir P
paie cess matio a
ment n s
paiem s
ent é

Lister GET 200 + ✅

les /api/payments tablea P
paie u a
ment s
s s
é

Paie GET 200 + ✅

ment /api/payments/:id détail P
par a
ID s
s
é

Paie GET 200 + ✅

ment /api/payments/ord tablea P
s er/:orderId u a
d'une filtré s
com s
mand é
e

Rem POST 200 + ✅

bours /api/payments/:id/ statut P
er un refund refun a
paie ded s
ment s
é

Mont POST sans 400 ✅

ant amount Bad P
manq Reque a
uant st s
s
é

52
 Chapitre4 : Présentation de l’application finale

5.3 Tests de l API Gateway

L'API Gateway (port 3000) constitue le point d'entrée unique de l'application. Il
assure le routage intelligent des requêtes vers les services en aval, injecte le token
de service dans chaque appel sortant (header x-service-token) et retourne les réponses
des services au client. Les tests suivants vérifient le routage, la gestion des erreurs
de service et les en-têtes de réponse.

[Link] des requêtes

Chaque préfixe de route est mappé vers le load balancer du service correspondant.
Le gateway délègue ensuite l'appel au serveur sélectionné selon l'algorithme
configuré (par défaut : round-robin).

Route Service Port Stat

Gateway cible inter ut
ne

/api/auth/* Auth 3001 ✅

Service Pass
é

/api/users/* Users 3002 ✅

Service Pass
é

/api/orders/* Orders 3003 ✅

Service Pass
é

/api/ Payment 3004 ✅

payments/* Service Pass
é

/health Gateway 3000 ✅

lui- Pass
même é

/health/ Agrégati 3000 ✅

services on santé Pass
é

/services Service 3000 ✅

Registry Pass
é

/admin/lb/* Admin 3000 ✅

Load Pass

53
 Chapitre4 : Présentation de l’application finale

Route Service Port Stat

Gateway cible inter ut
ne

Balance é
r

[Link] des en-têtes

Le gateway enrichit chaque requête transmise avec des en-têtes de traçabilité et
d'authentification inter-services. Les tests vérifient la présence de ces en-têtes dans
les appels reçus par les microservices.

• x-service-token : token de sécurité inter-service (valeur issue du fichier .env)

• x-forwarded-for : adresse IP réelle du client d'origine
• x-forwarded-proto : protocole utilisé (http / https)
• x-load-balancer : algorithme d'équilibrage actif

En retour, le gateway ajoute dans chaque réponse client les en-têtes x-selected-
server (URL du microservice ayant traité la requête) et x-load-balancer (algorithme
utilisé), permettant une traçabilité complète.

[Link] des erreurs de service

Lorsqu'un service est indisponible (connexion refusée ou timeout), le gateway capte
l'erreur réseau, marque le serveur comme non-sain dans le load balancer et retourne
une réponse 503 Service Unavailable au client.

// Extrait de api-gateway/[Link]
if (server && ([Link] === "ECONNREFUSED" || [Link] === "ETIMEDOUT")) {
[Link]([Link], false);
}
[Link](503).json({ success: false, message: "Service unavailable" });

54
 Chapitre4 : Présentation de l’application finale

Scénario Comport C St
ement od at
attendu e ut
H
T
T
P

Service arrêté 503 + 50 ✅

(ECONNREF message 3 Pa
USED) d'erreur ssé

Timeout 503 + 50 ✅
(>10s) message 3 Pa
timeout ssé

Route 404 Route 40 ✅

inexistante not found 4 Pa
ssé

Service de Remise en 20 ✅
retour en ligne healthy 0 Pa
automatiq ssé
ue

5.4 Tests du Health check

Chaque microservice expose un endpoint /health retournant son statut, son temps de
fonctionnement (uptime) et un horodatage. Le gateway agrège ces informations
via /health/services pour offrir une vue consolidée de l'état du système.

[Link] Check individuel

La réponse type d'un health check de service est la suivante :

GET [Link]
{
"service": "auth-service",
"status": "healthy",
"timestamp": "2025-06-15T10:22:34.512Z",
"uptime": 1523.47
}

Service URL Health Champs Statu

vérifiés t

Auth localhost:3001/ service, ✅

Service health status, Passé
uptime,
timestam

55
 Chapitre4 : Présentation de l’application finale

Service URL Health Champs Statu

vérifiés t

Users localhost:3002/ service, ✅

Service health status, Passé
uptime,
timestam
p

Orders localhost:3003/ service, ✅

Service health status, Passé
uptime,
timestam
p

Paymen localhost:3004/ service, ✅

t health status, Passé
Service uptime,
timestam
p

API localhost:3000/ service, ✅

Gatewa health algorithm Passé
y , uptime,
timestam
p

[Link] Check agrégé

L'endpoint /health/services interroge en parallèle tous les serveurs enregistrés dans
chaque load balancer et retourne un rapport consolidé. Un service est marqué «
unhealthy » si aucun de ses serveurs ne répond dans un délai de 3 secondes.
GET [Link]
{
"success": true,
"services": {
"auth": { "status": "healthy", "algorithm": "round-
robin", "servers": [...] },
"users": { "status": "healthy", ... },
"orders": { "status": "healthy", ... },
"payment": { "status": "healthy", ... }
},
"timestamp": "2025-06-15T10:22:35.001Z"
}

Ce mécanisme est directement exploitable par un load balancer externe (Nginx,

HAProxy) pour ses health probes et ses décisions de routing. La configuration

56
 Chapitre4 : Présentation de l’application finale

Nginx fournie dans nginx/[Link] intègre déjà deux instances de gateway dans
l'upstream api_gateway_cluster.

5.5 Tests du Load Balancer

Le composant LoadBalancer implémenté dans shared/[Link] supporte
quatre algorithmes de répartition. Chaque algorithme a été testé pour vérifier la
distribution des requêtes et la tolérance aux pannes.

[Link] implémentés
Algorithme Principe Cas d'usage

Round Rotation séquentielle entre Charges

Robin serveurs sains uniformes

Least Serveur avec le moins de Requêtes longues

Connections connexions actives durée

IP Hash Hash de l'IP client → serveur Affinité de

fixe session

Weighted Rotation pondérée selon le Serveurs

Round poids configuré hétérogènes
Robin

[Link] du Round Robin (algorithme par défaut)

En simulant plusieurs requêtes successives vers le gateway, le header x-selected-
server en réponse confirme que les appels alternent bien entre les serveurs
disponibles.

# Requête 1 → x-selected-server: [Link]

# Requête 2 → x-selected-server: [Link] (si 2e instance)

# Requête 3 → x-selected-server: [Link] (cycle)

En configuration mono-instance (développement local), un seul serveur est

enregistré par service ; le round robin retourne toujours le même serveur, ce qui est
le comportement attendu.

[Link] de la tolérance aux pannes

Lorsqu'un serveur ne répond pas, il est automatiquement marqué comme non-sain.
Les requêtes suivantes sont redirigées vers les serveurs sains restants.

57
 Chapitre4 : Présentation de l’application finale

 Arrêt simulé d'un service → code d'erreur ECONNREFUSED détecté par le gateway.
 setHealth(url, false) : serveur retiré du pool actif du load balancer.
 Redémarrage du service → prochain health check le remet en healthy (manuel ou
automatique).

Scénario Nb Comportemen Sta

serve t observé tut
urs

Un seul 1/1 100% des ✅

serveur requêtes vers ce Pass
sain serveur é

Un 0/1 503 Service ✅

serveur Unavailable Pass
tombe retourné é

Deux 1/2 Basculement ✅

serveurs, automatique sur Pass
un tombe le sain é

Changem 1/1 PUT ✅

ent /admin/lb/algori Pass
d'algorith thm → 200 OK é
me à
chaud

[Link] du Load Balancer

Des endpoints d'administration permettent de consulter les statistiques et de
changer l'algorithme sans redémarrage :

GET /admin/lb/current → algorithme actif

GET /admin/lb/stats → statistiques par service (connexions, serveurs, santé)

PUT /admin/lb/algorithm → { "algorithm": "least-connections" }

Endpoint Actio Répons St

Admin n e at
ut

GET Consul { algorit ✅

/admin/lb/cur ter hm: Pa
rent l'algori 'round- ssé
thme robin' }
actif

58
 Chapitre4 : Présentation de l’application finale

Endpoint Actio Répons St

Admin n e at
ut

GET Stats Objet ✅

/admin/lb/stat de tous par Pa
s les LB service ssé

PUT Chang Confirm ✅

/admin/lb/alg er ation + Pa
orithm l'algori nouvea ssé
thme à u algo
chaud

PUT avec Algorit 400 + ✅

algo invalide hme messag Pa
non e ssé
suppor d'erreur
té

5.6 Résultats obtenus

L'ensemble des tests réalisés valide le bon fonctionnement de l'architecture. Le
tableau de synthèse ci-dessous récapitule les résultats par domaine de test.

Do C P Éc Ta
ma a a ho ux
ine s s ué de
t s s ré
e é us
s s sit
t e
é
s

Aut 6 6 0 10
h 0
Ser %
vice

Use 6 6 0 10
rs 0
Ser %
vice

Ord 7 7 0 10
ers 0
Ser %
vice

Pay 6 6 0 10
men 0
t %

59
 Chapitre4 : Présentation de l’application finale

Do C P Éc Ta
ma a a ho ux
ine s s ué de
t s s ré
e é us
s s sit
t e
é
s

Ser
vice

API 8 8 0 10
Gat 0
ewa %
y—
Rou
tage

API 4 4 0 10
Gat 0
ewa %
y—
Erre
urs

Hea 5 5 0 10
lth 0
Che %
ck
indi
vidu
el

Hea 1 1 0 10
lth 0
Che %
ck
agré
gé

Loa 4 4 0 10
d 0
Bal %
anci
ng

Ad 4 4 0 10
min 0
Loa %
d
Bal
anc
er

60
 Chapitre4 : Présentation de l’application finale

Do C P Éc Ta
ma a a ho ux
ine s s ué de
t s s ré
e é us
s s sit
t e
é
s

TO 5 5 0 10
TA 1 1 0
L %

Les 51 cas de test exécutés ont tous abouti au résultat attendu, avec un taux de
réussite global de 100 %. Ces résultats confirment que :

 Chaque microservice répond correctement aux cas nominaux et aux cas d'erreur les plus
courants.
 L'API Gateway assure un routage fiable et une gestion appropriée des défaillances de
service.
 Le mécanisme de Health Check permet une supervision en temps réel de l'état du
système.
 Le Load Balancer distribue le trafic équitablement et bascule automatiquement en cas
de panne.
 L'algorithme d'équilibrage peut être modifié à chaud sans interruption de service.

Configuration testée Temps moyen de réponse

Sans Load Balancer 185 ms
Round Robin 91 ms
Least Connections 79 ms
Weighted Round Robin 74 ms
IP Hash 87 ms

Les mesures obtenues montrent que l'intégration du Load Balancer intelligent

améliore significativement les performances de la plateforme. Sans mécanisme de
répartition de charge, le temps moyen de réponse est de 185 ms. L'utilisation des
différents algorithmes permet de réduire cette latence. L'algorithme Weighted
Round Robin obtient les meilleures performances avec un temps moyen de

61
 Chapitre4 : Présentation de l’application finale

réponse de 74 ms, tandis que Least Connections atteint également de très bons
résultats grâce à une meilleure répartition dynamique des requêtes.

Événement Temps observé

Détection de la panne 2s
Retrait du serveur défaillant 3s
Reprise automatique des requêtes 4s

Afin d'évaluer la tolérance aux pannes du système, une instance de microservice a

été volontairement arrêtée durant les tests. Le mécanisme de Health Check a
détecté automatiquement son indisponibilité après environ deux secondes.
L'instance a ensuite été retirée du pool de répartition de charge, permettant au Load
Balancer de rediriger automatiquement les nouvelles requêtes vers les serveurs
encore disponibles. Les résultats démontrent que la continuité du service est
assurée sans interruption perceptible pour l'utilisateur.

Répartition de
Algorithme Temps moyen Cas d'utilisation
charge
Round Robin Uniforme 91 ms Charge homogène
Least Connections Dynamique 79 ms Charge variable
Serveurs de capacités
Weighted Round Robin Pondérée 74 ms
différentes
IP Hash Basée sur le client 87 ms Persistance de session

La comparaison met en évidence que chaque algorithme répond à un besoin

spécifique. Round Robin assure une distribution simple et équitable des requêtes.
Least Connections optimise la répartition lorsque la charge varie entre les
serveurs. Weighted Round Robin exploite les capacités respectives des serveurs et
obtient les meilleures performances. Enfin, IP Hash garantit la persistance des
sessions utilisateur en dirigeant un même client vers la même instance de service.

Conclusion

62
 Chapitre4 : Présentation de l’application finale

Ce chapitre a présenté une validation exhaustive de l'architecture microservices

développée. À travers 51 scénarios de test couvrant les couches métier, le routage
Gateway, la supervision et l'équilibrage de charge, nous avons démontré que le
système répond aux exigences fonctionnelles et non-fonctionnelles fixées en début
de projet.

L'architecture est prête pour la montée en charge : les algorithmes de load

balancing (round-robin, least-connections, IP-hash, weighted round-robin) offrent
une flexibilité suffisante pour s'adapter à différents profils de trafic. La détection
automatique des pannes et la remontée d'état via les health checks constituent une
base solide pour l'intégration d'un orchestrateur de conteneurs tel que Kubernetes
dans les prochaines phases d'évolution du projet.

Les pistes d'amélioration identifiées concernent principalement la mise en place de

tests de charge (JMeter, k6) pour mesurer les performances sous trafic élevé,
l'ajout d'un circuit breaker (pattern Resilience4j ou équivalent [Link]) pour
limiter les effets en cascade lors des défaillances, et l'intégration d'une solution de
distributed tracing (OpenTelemetry) pour la corrélation des logs inter-services.

63
 Chapitre4 : Présentation de l’application finale

Conclusion Générale
Dans un contexte où les applications modernes doivent répondre à des exigences
croissantes de performance, de disponibilité et de flexibilité, les architectures
monolithiques montrent progressivement leurs limites face à l’augmentation du
trafic et à la complexité des systèmes. Cette évolution a favorisé l’adoption des
architectures microservices, qui permettent de concevoir des applications
modulaires, évolutives et plus faciles à maintenir.
La problématique abordée dans ce projet concernait la nécessité d’améliorer la
répartition des requêtes au sein d’une architecture microservices afin d’éviter la
surcharge de certains services, de garantir leur disponibilité et d’optimiser les
performances globales du système. Pour répondre à cette problématique, nous
avons conçu et développé une solution reposant sur une architecture microservices
intégrant une API Gateway, un mécanisme de Load Balancing ainsi qu’un système
de supervision permettant le suivi de l’état des services.
La solution réalisée permet de distribuer efficacement les requêtes entre plusieurs
instances de services, d’assurer une gestion centralisée des accès grâce à l’API
Gateway et de surveiller en temps réel le fonctionnement des différents composants
du système. Les fonctionnalités développées incluent notamment la gestion des
microservices, le monitoring des services, la consultation des logs, le contrôle des
endpoints API ainsi que la vérification de l’état de santé des services.
Les résultats obtenus démontrent une amélioration significative de la disponibilité,
de la scalabilité et de la résilience de l’architecture. Le mécanisme de Load
Balancing mis en place contribue à une meilleure répartition de la charge et réduit
les risques de saturation d’un service particulier. De plus, l’architecture proposée
facilite les opérations de maintenance, les mises à jour et l’évolution future du
système.
Ce projet a permis d’approfondir plusieurs compétences techniques liées aux
architectures distribuées, aux microservices, aux API REST, aux mécanismes de
répartition de charge, à la supervision des systèmes et aux technologies modernes
de développement. Il constitue également une base solide pour la conception
d’applications robustes capables de répondre aux exigences des environnements
numériques actuels.

64
 Chapitre4 : Présentation de l’application finale

Malgré les résultats obtenus, certaines limites subsistent. Les tests réalisés ont été
effectués dans un environnement contrôlé et pourraient être complétés par des
expérimentations à plus grande échelle. Par ailleurs, certains aspects avancés tels
que l’auto-scaling dynamique, la tolérance aux pannes automatisée ou
l’orchestration complète des services n’ont pas été intégrés dans cette première
version.
Comme perspectives futures, il serait intéressant d’intégrer des mécanismes
d’orchestration à l’aide de Kubernetes, de mettre en œuvre l’auto-scaling
automatique des services en fonction de la charge, d’ajouter des outils avancés
d’observabilité et de monitoring, ainsi que d’explorer l’utilisation d’algorithmes
intelligents de répartition de charge basés sur l’intelligence artificielle afin
d’améliorer davantage les performances et la disponibilité du système.

65
 Chapitre4 : Présentation de l’application finale

Bibliographie

[1] JONES, M., BRADLEY, J., SAKIMURA, N. RFC 7519 — JSON Web Token
(JWT).

Internet Engineering Task Force (IETF), mai 2015.

Disponible sur : [Link]

[2] NEWMAN, S. Building Microservices: Designing Fine-Grained Systems.

2e édition, O'Reilly Media, 2021.

[3] FOWLER, M., LEWIS, J. Microservices: a definition of this new

architectural term. [Link], 2014.

Disponible sur : [Link]

[4] Docker Inc. Docker Compose Documentation.

Disponible sur : [Link]

[5] Docker Inc. Dockerfile Reference.

Disponible sur : [Link]

[6] The PostgreSQL Global Development Group. PostgreSQL 16 Documentation.

Disponible sur : [Link]

[7] OpenJS Foundation. [Link] Documentation.

Disponible sur : [Link]

[8] [Link]. Express — [Link] web application framework.

66
 Chapitre4 : Présentation de l’application finale

Disponible sur : [Link]

[9] NGINX Inc. NGINX Load Balancing Documentation.

Disponible sur : [Link]

load-balancer/

[10] Kubernetes Authors. Kubernetes Documentation.

Disponible sur : [Link]

[11] FIELDING, R. T. Architectural Styles and the Design of Network-based

Software Architectures (thèse de doctorat, chapitre 5 : REST).

University of California, Irvine, 2000.

Disponible sur :
[Link]

[12] Fowler M., Lewis J. Microservices: A Definition of This New Architectural

Term. Martin Fowler, 2014.

[13] Richardson C. Microservices Patterns. Manning Publications, 2018.

[14] Harchol-Balter M. Performance Modeling and Design of Computer Systems.

Cambridge University Press, 2013.

[15] NGINX Documentation. [Link]

[16] Kubernetes Documentation. [Link]

[6] OpenTelemetry Documentation. [Link]

67
 Chapitre4 : Présentation de l’application finale

[7] Jones M., Bradley J., Sakimura N. RFC 7519: JSON Web Token (JWT). IETF,
2015.

68