Introduction

Ce rapport présente un mini-projet de gestion des rendez-vous et consultations médicales, développé avec une architecture microservices utilisant Spring Boot. L'objectif est d'optimiser la gestion des rendez-vous médicaux en adoptant une approche modulaire et scalable. Nous explorons le processus de conception, d'implémentation et de déploiement, mettant en avant les avantages de l'architecture microservices dans ce contexte spécifique. Ce rapport offre un aperçu des choix technologiques, des défis rencontrés et des perspectives d'amélioration continue. L'approche choisie vise à moderniser et à rendre plus efficace la gestion des rendez-vous médicaux.

Objectifs

L'objectif principal de ce projet est de concevoir et de mettre en œuvre une application modulaire et évolutive pour la gestion des rendez-vous et consultations médicales.

Développer deux services distincts, le premier pour gérer les informations des patients et des médecins, et le deuxième pour gérer les rendez-vous et les consultations.

- Assurer l'intégration et la communication efficace entre les services à l'aide de l'API Gateway et des clients REST.

Utiliser un registre de services pour la découverte et l'enregistrement des services.
Mettre en place un serveur de configuration pour la gestion centralisée des configurations de services.
Garantir la sécurité, la fiabilité et la disponibilité de l'application.

Table of Content

Introduction
Objectifs
Table of Content
Conception & Architecture
Contenu application
Documentation des Tests avec Swagger UI
Conclusion

Conception & Architecture

Diagramme de classes :

Le diagramme montre quatre entités principales : Patient, Medecin, RendezVous, et Consultation. Les Patients peuvent avoir plusieurs RendezVous, chaque RendezVous est pour un Patient et un Medecin spécifique, et à chaque RendezVous correspond une Consultation unique.
Architecture Microservices :

L'application reçoit des requêtes HTTP d'une partie cliente qui interagit avec le système via une API Gateway. Le système est divisé en deux services principaux : le premier service gère les médecins et les patients, et le deuxième service gère les rendez-vous et les consultations. Chaque service interagit avec sa propre base de données.

Il existe également des composants de support tels que la configuration centralisée (Config Server) et l'enregistrement des services (Service Registry ou Discovery Service). Cela indique une structure conçue pour la résilience, la scalabilité et la gestion efficace des configurations et des services dans un environnement de microservices.

voici les services de projet, sachant que:

first service : Service de Gestion des Patients et Médecins.

second service : Service de Gestion des Rendez-vous et Consultations.

Technologies Utilisées :

Contenu application

I.First Service :

Entities:
Repository:
Web:
application.properties:
```
spring.application.name=first-service
server.port=8081
spring.config.import=optional:configserver:http://localhost:9999/}
```
Pour importer la configuration à partir du serveur de configuration situé à http://localhost:9999/. Le si le serveur de configuration n'est pas disponible ou ne peut pas être contacté, l'application ne s'arrêtera pas ou ne renverra pas d'erreur.

II.Second Service :

Entities:
Repository:
Model:

le package model contient toutes les classes dont nous aurons besoin dans le 2ème service à partir du 1er service (ce ne sont pas des entités JPA).
Client:

FirstServiceRestClient : est un client Feign utilisé pour interagir avec un service distant. Elle appartient au deuxième service (SECOND-SERVICE) et communique avec le premier service (FIRST-SERVICE). Les méthodes définies dans cette interface correspondent aux points de terminaison du premier service pour récupérer des informations sur les patients et les médecins.

@FeignClient(name = "FIRST-SERVICE") : Spécifie que cette interface est un client Feign pour le service nommé "FIRST-SERVICE".
Services:

on retrouve ici toutes les fonctionnalités CRUD pour créer, supprimer mettre à jour et manipuler toutes les entités de notre service.

pour casser la relation entre FIRST-SERVICE et SECOND-SERVICE (OneToMany), nous obtenons les models dont nous avons besoin en utilisant le firstservicerestclient et les intégrons dans le notre service
Web:

application.properties:

spring.application.name=second-service
server.port=8082
spring.config.import=optional:configserver:http://localhost:9999/}
feign.client.config.default.loggerLevel=full

Note: nous devons ajouter ces annotations à la classe SecondServiceApplication: @EnableDiscoveryClient @EnableFeignClients

III.Gateway Service :

Le service Gateway agit comme un intermédiaire qui simplifie la complexité des interactions entre le client et les microservices.

GatewayServiceApplication:

@SpringBootApplication
public class GatewayServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(GatewayServiceApplication.class, args);
    }
    @Bean
    DiscoveryClientRouteDefinitionLocator dynamicRoutes(ReactiveDiscoveryClient rdc,DiscoveryLocatorProperties dlp){
        return new DiscoveryClientRouteDefinitionLocator(rdc,dlp);
    }
}

application.properties:

spring.application.name=gateway-service
server.port=8888
spring.config.import=optional:configserver:http://localhost:9999/

application.yml:

spring:
cloud:
    gateway:
    routes:
        - id: r1
        uri: http://localhost:8081/
        predicates:
            - Path=/medecins/**
        - id: r2
        uri: http://localhost:8082/
        predicates:
            - Path=/rendezVous/**
application:
    name: gateway-service
server:
port: 8888

Ce fichier .yml est une configuration pour le Gateway Service Il définit des règles de routage pour le service passerelle (API Gateway).

IV.Discovery Service :

Les microservices interrogent le Discovery Service pour trouver les instances disponibles d'autres services auxquels ils souhaitent faire appel. Cela facilite la communication dynamique et l'équilibrage de charge entre les services, et pour une meilleure tolérance aux pannes. Les outils populaires pour le service de découverte incluent Eureka de Netflix que nous utilisons dans notre application.

DiscoveryServiceApplication:

@SpringBootApplication
@EnableEurekaServer
public class DiscoveryServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(DiscoveryServiceApplication.class, args);
    }
}

application.properties:

spring.application.name=discovery-service
server.port=8761
#dont register server itself as client
eureka.client.fetch-registry=false
# does not register itself in the service registry
eureka.client.register-with-eureka=false

voici le server d'Eureka:

@EnableEurekaServer : pour activer la fonctionnalité du serveur Eureka dans une application Spring Boot. Lorsqu'elle est appliquée à la classe principale d'un projet Spring Boot, elle indique que l'application agira en tant que serveur Eureka.

V.Config Service :

ConfigServiceApplication:

@SpringBootApplication
@EnableConfigServer
public class ConfigServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConfigServiceApplication.class, args);
    }
}

application.properties:

spring.application.name=config-service
server.port=9999
#spring.cloud.config.server.git.uri=file://${user.home}/config
spring.cloud.discovery.enabled=true
#spring.cloud.config.server.git.default-label=master
spring.cloud.config.server.git.uri=file:///C:/Users/RPC/Desktop/Mini-Projet/microservices/config

config(dossier):

pour fournir un support de configuration centralisé et externe aux applications, nous mettons le fichier de configuration de chaque service(configurations de base de données...) dans le répertoire de **config**.

| service | properties |
| ----------- | ----------- |
| first-service | ![](./screens/prop1.png) |
| second-service | ![](./screens/prop2.png) |
| application.properties | ![](./screens/prop3.png) |

Documentation des Tests avec Swagger UI

avant d'exécuter tous les services pour tester les API et leurs méthodes, nous ajoutons le package d'openAPI au pom.xml du chaque service (first-service & second-service) afin d'obtenir une interface UI:

<dependency>
    <groupId>org.springdoc</groupId>
    <artifactId>springdoc-openapi-starter-webmvc-ui</artifactId>
    <version>2.3.0</version>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-validation</artifactId>
    <version>3.2.1</version>
</dependency>

Note: nous avons ajouté quelques données dans les deux services pour tester et visualiser.

1. Service de Gestion des Patients et Médecins:

Nous pouvons accéder à l'API en utilisant cette URL (depuis le Gateway) :

Patient :

Afficher tous les patients

Ajouter un patient

Afficher un patient par son identifiant

Mettre à jour un patient

Supprimer un patient
Medecin :

Afficher tous les medecins

Ajouter un medecin

Afficher un medecin par son identifiant

Mettre à jour un medecin

Supprimer un medecin

Afficher un Medecin par son nom

2. Service de Gestion des Rendez-vous et Consultations:

Nous pouvons accéder à l'API en utilisant cette URL (depuis le Gateway) :

RendezVous :

Afficher tous les rendezVous

Ajouter un rendezVous

Afficher un rendezVous par son identifiant

Mettre à jour un rendezVous

Supprimer un rendezVous
Consultation :

Afficher tous les consultations

Ajouter une consultation

Afficher une consultation par son identifiant

Mettre à jour une consultation

Supprimer une consultation

Conclusion

L'approche microservices adoptée pour la conception de l'application de gestion des rendez-vous et consultations médicales a démontré une amélioration significative de la modularité et de la scalabilité du système. Grâce à la séparation des préoccupations, chaque service peut être développé, déployé et mis à jour indépendamment, permettant une maintenance et une évolution plus aisées de l'application. L'utilisation d'une API Gateway a simplifié l'interaction entre les clients et les services, tandis que l'intégration du registre de services et du serveur de configuration a renforcé la cohérence et la fiabilité de la configuration.

vous pouvez trouver le code source du projet dans mon github : Microservices-Mini-Projet

ouchaour/Microservices-Mini-Projet

Introduction

Objectifs

Table of Content

Conception & Architecture

Contenu application

I.First Service :

II.Second Service :

III.Gateway Service :

IV.Discovery Service :

V.Config Service :

Documentation des Tests avec Swagger UI

1. Service de Gestion des Patients et Médecins:

Afficher tous les patients

Ajouter un patient

Afficher un patient par son identifiant

Mettre à jour un patient

Supprimer un patient

Afficher tous les medecins

Ajouter un medecin

Afficher un medecin par son identifiant

Mettre à jour un medecin

Supprimer un medecin

Afficher un Medecin par son nom

2. Service de Gestion des Rendez-vous et Consultations:

Afficher tous les rendezVous

Ajouter un rendezVous

Afficher un rendezVous par son identifiant

Mettre à jour un rendezVous

Supprimer un rendezVous

Afficher tous les consultations

Ajouter une consultation

Afficher une consultation par son identifiant

Mettre à jour une consultation

Supprimer une consultation

Conclusion