Cours MS Architectures Web Distribuées Intro+ first MS.pptx

1
Architectures Web Distribuées
Rihab IDOUDI

2 Architecture logicielle : Définitions
 L'architecture logicielle définit la structure fondamentale qui guidera l'ensemble
du développement. Elle établit les règles globales que suivra le système.
 Caractéristiques clés
• Établit la structure globale du système
• Définit les frontières et les interactions entre composants
• Répond aux exigences non-fonctionnelles principales
 Objectifs principaux
• Gérer la complexité des grands systèmes
• Assurer la scalabilité horizontale et verticale
• Garantir la maintenabilité à long terme

4 Plan
 D’une Architecture Monolithique Vers une Architecture micro-services
 Création du premier MS
 Containerisation des MS avec Docker et Docker Compose
 Implémentation du serveur de découverte Eureka
 Implémentation de l’API Gateway
 Implémentation du Config Service

5
Langage bas niveau
Sous programmes: Procédures, fonctions (Basic, Pascal,
C, Fortran,..)
Objet = Etat+ Comportement + Identité Concepts
fondamentaux : Objet, classe, Héritage, polymorphisme,
encapsulation (C++, JAVA, C#, ..)
Objets distribués sur plusieurs machines Middlewares :
(RMI, CORBA, JMS, …)
Objets distribués, réutilisables, configurables,
Interchangeables, évolutifs: Conteneur (EJB, Spring)
Composant disponibles à d’autres applications distantes
hétérogènes via des protocoles (http) transportant des
données: XML, JSON => SOAP et REST
Microservices distribués, scalabilité, division en unités
plus petites
Programmation Orientée
Microservices

6
D’une Architecture Monolithique Vers une
Architecture micro-services
 Une application monolithique est souvent une grande application développée en un seul Bloc. Une seule et
unique application est développée pour un problème donné aussi grand qu’il soit.
 Avantages
Simplicité de mise en place.
Un seul code-base.
Efficience à petite échelle.
Latence Applicative.
 Base de données monolithiques (Avantages)
Simplicité de mise en place.
Facilité de requête et de jointure.
Un seul schéma, un seul déploiement.
Efficience à petite échelle.

7
• Centralisation de tous les besoins fonctionnels
• Une seule technologies
• Pour chaque modification
• Test de régression
• Redéploiement de l’app
• Difficulté d’évolution au niveau fonctionnel
• Livraison en bloc(attente de client pour commencer
à voir les premiers versions)
• Mise en prod prend beaucoup de temps
• Difficile à tester
• Performance (sociabilité)

8 D’une Architecture Monolithique Vers une
 Les principaux problèmes des application monolithiques:
 Centralisation de toutes les fonctionnalités
 La nécessité d’utiliser une seule technologies
 Chaque modification nécessite:
 Tester la non régression
 Redéploiement de toute l’application
 Complexité de l’évolution fonctionnel
 Livraison en bloc (LE client attend beaucoup de temps pour avoir les premières versions)

9
Comment assurer la haute disponibilité des applications ?
Comment répondre rapidement aux nouvelles fonctionnalités métiers et faire évoluer
les applications d’une façon très fréquente ?
Comment être indépendant des technologies utilisées tout en sachant que ces
technologies évoluent très vite ?

10
Les Micro Services
 Les micro services suivent une approche d’architecture et de développement d’une
application composée de petits services.
 L’idée étant de découper un grand problèmes en petites unités implémentée sous forme de
micro services.
 Chaque microservice est responsable d’un domaine fonctionnel
 Chaque microservice est développé, testé, et déployé séparément des autres
 Chaque microservice tourne dans un processus séparé
 L’interaction entre les différents microservices est via un protocole léger, le plus souvent à
base de ressource HTTP (tel que REST –REpresentational State Transfer- par exemple).
 En les combinant ces microservices peuvent réaliser des opérations complexes.
 Chaque microservice peut être conçu à l’aide d’une technologie ou langage différente

11 Les Micro Services
 La séparation physique renforce le couplage faible entre ces microservices
 Indépendance relative entre les différents équipes qui développent les différents
microservices (en partant du principe que les APIs qu’ils exposent sont définis à l’avance).
 Facilité des tests et du déploiement ou de la livraison continue.
 Ces MS doivent de préférence être organisés autours des compétences métier, de
déploiement automatique, d'extrémités intelligentes et de contrôle décentralisé des
technologies et des données

12
Comparaison des 2 architectures
Design guidé par la technologie
(Design dictated by Technology)
Design guidé par le domaine métier
(Design dictated by Business domain)
Storag
e
User
Interface
Business logic User
Interface
login
catalo
g
Order
Storag
e
Storag
e
Storag
e

13 Les Micro Services
 Un microservice peut être considéré comme une application entière qui
combine les trois couches « Métier», « DAO» et «Controller »

15 Intégration des micro-services :
Pour intégrer les micro-services dans le cadre d’une même application, il est nécessaire de
mettre en place des services techniques fournis par le Framework permettant de développer
les architectures micro-services comme Spring Cloud.
 Discovery Service :
 Représente un annuaire permettant d’enregistrer la localisation de toutes les instances des micro-
services de l’application.
 Au démarrage, chaque micro-service se connecte à ce micro-service pour enregistrer le nom du
micro-service et l’URI du micro-service incluant l’adresse IP de la machine et le numéro de port.
 Un exemple de Discovery service fourni par Spring Cloud est Eureka Discovery, une
implémentation de NetFlix.

 Gateway Service :
 Pour interagir avec l’application, toutes les requêtes des applications frontend web doivent être envoyées au service
Gateway.
 Le service Gateway se charge d’acheminer cette requête vers le bon micro-service implémentant la
fonctionnalité de la requête.
 Pour chaque requête, le service Gateway extrait le nom de du micro-service de la requête entrante et
interroge le service Discovery pour récupérer l’URI du micros-service (IP, Port) sachant son nom pour
dispatche la requête vers l’URI du micro-service.
 Pour mettre en place une Gateway, avec Spring Cloud, il existe deux modèles : un Modèle classique
Multi Threads avec des entrées sorties bloquantes implémenté par ZUUL Proxy ; une implémentation de
NetFlix et un autre modèle réactif plus performant, Single Thread avec des entrée sorties non bloquantes
proposé par Spring Cloud à savoir Spring Cloud Gateway.

 Config service:
 Ce service technique offre un mécanisme qui permet de centraliser la configuration de l’ensemble des
micro-services dans un unique repository.
 Ce service gère un fichier de configuration globale qui regroupe toutes les propriétés de configuration
communes à tous les micro-services et des fichiers de configuration relatifs à chaque micro-service dans
lequel chaque micro-service trouve ses particularités de configuration.
 Au démarrage, chaque micro-service commence par contacter ce service pour récupérer sa
configuration avant de continuer le démarrage. Quand une mise à jour est apportée à la configuration,
les micro-services reçoivent la nouvelle configuration à chaud. Ce qui permet de reconfigurer les micro-
services à chaud en évitant par conséquent le redémarrage des services.

19 Framework Spring -Rappel
 Spring est un framework permettant la création des applications d’entreprise
 Spring Boot est un outil permettant de simplifier le développement des applications
autonome de type Spring à travers:
 Centralisation de la configurations dans un fichier application.properties
 Simplification de la gestion des dépendances avec Maven
 Fournir un conteneur de servlet embarqué ‘(Tomcat, Jetty)

20 Spring Boot taillé pour les Microservices
 Spring Boot se prête parfaitement au développement de Microservices par ses nombreux
atouts :
 Génération d’un microservice packagé sous forme d’un JAR. Ce JAR inclue le serveur web
(conteneur de Servlets ou Netty). Le microservice ne nécessite qu’une simple JVM pour
s’exécuter.
 Diminution de la base de code par un allègement important de la configuration des
différents frameworks (Spring MVC, Spring Data JPA…). Spring Boot détecte les frameworks
présents dans le classpath et les configure automatiquement. Des starters additionnels
viennent étendre cette fonctionnalité.
 Monitoring et gestion des microservices en Production au travers d’endpoint REST exposés à
l’aide des Actuator.

21
Création du premier
micro service

22 Premier MS
 Nous visons à créer un premier microservice de gestion des candidats dans une entreprise.
 Soit l’entité suivante représentant un candidat:
 Le microservice Gestion candidats va se charger des fonctionnalités suivantes :
- Afficher tous les candidats
- Afficher un candidat par son id ou son nom
- Ajouter/modifier/supprimer un candidat

24
 Ajouter les dépendances nécessaires
Rajoutez aussi la
dépendance
Spring Data Rest
<dependency>
<groupId>org.springframework.b
oot</groupId>
<artifactId>spring-boot-starter-
data-rest</artifactId>
</dependency>

25
Les dépendances à rajouter
 Spring web: Build web, including RESTful applications, using Spring MVC, uses Apache Tomcat as
the default embedded container.
 Spring Data JPA: A framwork to persist data in Relational Databases using Hibernate
 H2 Database: provides a fast in-memory database that supports JDBC API and R2DBC access.
 Lombok: Java annotation library which helps to reduce boilerplate code.
 Spring Boot DevTools: provides fast application restarters, liveReload and configurations for
enhanced development experience.
 Eureka Discovery Client: a REST based service for locating services for the purpose of load
balancing and failover of middle-tier servers.
 Actuator: supports built n or custom endpoints that let you monitor and manage your application
such as application health, metrics, sessions, etc.

26
Microservie: Gestion-Candidats
 le module comporte 4 classes :
 la classe main du microservice annotée avec l’annotation @SpringBootApplication ainsi que
l’annotation Spring Cloud @EnableDiscoveryClient dont nous verrons l’intérêt par la suite.
 Candidat : entité JPA représentant un candidat
 Candidat Repository: interface Spring Data JPA annoté @Repository et permettant d’accéder aux
candidats stockées dans une base relationnelle (H2 ou MySQL).
 Candidat Resource : contrôleur REST exposant une API pour créer candidat et les lister.
L’usage d’annotations Lombok permet d’alléger le code, mais n’a rien d’obligatoire.

27
 Création de l’entité Candidat

28  Créer l’interface Repository permettant de gérer l’entité Candidat

33
 Démarrer le projet puis accéder à la base de données: http://localhost:8081/h2

34
Accéder à l’adresse http://localhost:8081/candidats

35 Travail à faire :
 Implémentez un deuxième microservice (dans un nouveau projet spring boot) qui se charge de la
gestion des jobs et ayant comme entité Job représentée comme suit:
 Ce deuxième microservice prendra en charge les fonctionnalités suivantes:
- Afficher tous les jobs
- Afficher un job par son id ou son nom
- La modification de l’état de poste :
o Etat= oui (si poste disponible)
o Etat= non (si poste est occupé).

Cours MS Architectures Web Distribuées Intro+ first MS.pptx

Contenu connexe

Similaire à Cours MS Architectures Web Distribuées Intro+ first MS.pptx

Dernier

Cours MS Architectures Web Distribuées Intro+ first MS.pptx