SYSTÈMES RÉPARTIS
SYSTÈMES RÉPARTIS
1.Définition :
1. Un ensemble d'ordinateurs interconnectés travaillant de manière
coordonnée pour atteindre un objectif commun.
2. Exemples concrets : systèmes de réservation en ligne, plateformes de
streaming, réseaux sociaux.
2.Pourquoi utiliser des systèmes répartis ?
1. Scalabilité : Capacité à évoluer en fonction des besoins (ajout de nœuds).
2. Tolérance aux pannes : Redondance des composants pour augmenter la
fiabilité.
3. Performances accrues : Répartition des charges pour optimiser les temps
de réponse.
CARACTÉRISTIQUES ET
PROPRIÉTÉS DES SYSTÈMES
RÉPARTIS
1.Caractéristiques principales :
1. Transparence : L'utilisateur ne perçoit pas le caractère réparti du système
(localisation, accès, échec, etc.).
2. Scalabilité : Adaptabilité à la croissance des utilisateurs et des données.
3. Hétérogénéité : Capacité à intégrer des matériels et logiciels divers.
4. Concurrence : Multiples processus ou utilisateurs accédant aux ressources
simultanément.
2.Propriétés importantes :
1. Fiabilité et tolérance aux pannes : Gestion des pannes de manière
transparente.
2. Consistance : Maintenir une vue cohérente des données malgré les
modifications concurrentes.
3. Disponibilité : Assurer un service continu même en cas de défaillance.
QU'EST-CE QU'UN
MIDDLEWARE ?
MIDDLEWARE
• Définition : Un logiciel intermédiaire qui connecte
des applications ou services distribués, facilitant
leur communication et leur interaction.
• Exemples : CORBA, Java RMI, REST APIs, Kafka.
•Objectif principal : Abstraire la complexité
des systèmes distribués pour simplifier le
développement et l'intégration d'applications.
POURQUOI UTILISER UN
MIDDLEWARE ?
•Avantages du Middleware : •Problématiques résolues :
• Abstraction des • Gestion des transactions.
communications réseau. • Sécurité des
• Interopérabilité entre communications.
systèmes hétérogènes. • Tolérance aux pannes.
• Simplification du
développement
d'applications distribuées.
ARCHITECTURE DU
MIDDLEWARE
•Composants clés :
• Interface API : Fournit des services standardisés aux applications.
• Serveur de Middleware : Gère les communications entre clients et
serveurs.
• Modules supplémentaires : Sécurité, gestion des transactions,
journalisation.
•Architecture en couches :
• Couche transport, couche communication, couche services d’application.
TYPES DE
MIDDLEWARE
MIDDLEWARE ORIENTÉ
COMMUNICATION
•RPC (Remote Procedure Call) :
• Appel de fonctions à distance comme si elles étaient locales.
• Avantage : Simplicité d'utilisation.
• Inconvénient : Faible tolérance aux pannes.
•RMI (Remote Method Invocation) :
• Spécifique à Java, permet d'invoquer des méthodes sur des objets distants.
MIDDLEWARE ORIENTÉ
MESSAGERIE
•Message-Oriented Middleware (MOM) :
• Permet la communication asynchrone via des files d'attente (queues).
• Exemples : RabbitMQ, ActiveMQ.
• Cas d'utilisation : Applications nécessitant une forte tolérance aux pannes
(ex. systèmes financiers).
•Pub/Sub (Publish/Subscribe) :
• Découplage entre les producteurs et les consommateurs.
• Exemple : Kafka pour la diffusion d'événements en temps réel.
MIDDLEWARE ORIENTÉ
OBJETS
•CORBA (Common Object Request Broker Architecture) :
• Standard pour les applications orientées objets distribuées.
• Avantage : Indépendant du langage de programmation.
• Inconvénient : Complexité et surcoût en termes de performance.
•DCOM (Distributed Component Object Model) :
• Développé par Microsoft pour les applications Windows.
MIDDLEWARE BASÉ SUR
LES SERVICES
•APIs RESTful :
• Utilisation de HTTP pour la communication entre services.
• Avantage : Facilité d’utilisation et adoption généralisée.
•gRPC (Google Remote Procedure Call) :
• Basé sur HTTP/2, offre des performances optimisées pour les microservices.
• Cas d'utilisation : Services nécessitant une faible latence.
POUR LE FUTUR
•Avancées récentes :
• Middleware cloud-native (Kubernetes, Istio).
• Middleware pour l’IA et le Machine Learning (TensorFlow Serving).
•Perspectives d'avenir :
• Middleware orienté microservices et architectures serverless.
• Intégration avec des technologies émergentes (Blockchain, Edge
Computing).
MODÈLES DE
RÉPARTITION
MODÈLES DE RÉPARTITION
•Définition : Organisation des systèmes distribués où les tâches
sont réparties entre différents nœuds (ordinateurs, serveurs,
services).
•Objectifs principaux :
• Optimiser les performances.
• Améliorer la tolérance aux pannes.
• Faciliter la scalabilité des applications.
MODÈLE CLIENT/SERVEUR
•Concept :
•Un client envoie des requêtes à un serveur, qui répond avec les
résultats.
•Centralisation de la logique métier sur le serveur.
•Exemples : Applications web, bases de données
centralisées.
•Avantages : Simplicité de déploiement, sécurité
centralisée.
•Inconvénients : Goulot d'étranglement sur le serveur,
faible tolérance aux pannes.
MODÈLE COMMUNICATION
PAR MESSAGE
•Concept :
• Communication asynchrone entre systèmes via des files d'attente (queues).
• Les messages sont envoyés sans attendre une réponse immédiate.
•Exemples : RabbitMQ, ActiveMQ, JMS.
•Cas d'utilisation : Systèmes d'e-commerce pour la gestion des
commandes, traitement d'événements.
•Avantages : Découplage des composants, tolérance aux pannes.
•Inconvénients : Complexité de gestion des files d'attente, latence
accrue.
MODÈLE
PUBLISH/SUBSCRIBE
(PUB/SUB)
•Concept :
• Les producteurs publient des messages à un canal auquel les
consommateurs s'abonnent.
• Découplage total entre l'émetteur et le récepteur.
•Exemples : Kafka, MQTT pour l'IoT.
•Avantages : Scalabilité, diffusion en temps réel.
•Inconvénients : Difficulté à garantir la consistance, gestion de la
sécurité.
COMPARAISON DES
MODÈLES
Communication
Critère Client/Serveur Pub/Sub
par Message
Couplage Fort Faible Très faible
Tolérance aux
Moyenne Élevée Élevée
pannes
Scalabilité Limitée Bonne Excellente
PATRONS DE
CONCEPTION
INTRODUCTION AUX
PATRONS DE CONCEPTION
•Définition : Solutions standardisées pour résoudre des problèmes
récurrents dans le design logiciel.
•Objectif : Favoriser la réutilisabilité, faciliter la maintenance et
améliorer la robustesse des systèmes distribués.
PATRON PROXY
•Concept : Intermédiaire qui contrôle l’accès à un autre objet.
•Types de Proxy : Proxy distant, Proxy de protection, Proxy de
cache.
•Exemple : Proxy HTTP pour la mise en cache des pages web.
•Cas d'utilisation : Optimisation des performances, filtrage des
accès.
PATRON FABRIQUE
(FACTORY)
•Concept : Fournit une interface pour créer des objets sans
spécifier leur classe concrète.
•Avantages : Encapsulation du processus d'instanciation, flexibilité
accrue.
•Exemple : Gestion des connexions à une base de données (ex :
ConnectionFactory).
•Cas d'utilisation : Scénarios où les types exacts d'objets à créer ne
sont pas connus à l'avance.
PATRON WRAPPER
(ADAPTATEUR)
•Concept : Convertit l'interface d'une classe pour qu'elle soit
compatible avec une autre.
•Exemple : Adapter une API externe pour qu'elle fonctionne avec un
ancien système.
•Avantages : Facilite l'intégration de systèmes hétérogènes.
•Cas d'utilisation : Intégration de systèmes tiers dans une
architecture existante.
PATRON INTERCEPTEUR
(INTERCEPTOR)
•Concept : Intercepte des appels pour y ajouter des fonctionnalités
(sécurité, logs).
•Exemple : Intercepteur de requêtes HTTP pour vérifier les
autorisations.
•Avantages : Extensibilité, séparation des préoccupations.
•Cas d'utilisation : Filtrage de requêtes dans des applications web.
DISCUSSION
QUESTIONS
•Quels sont les avantages et inconvénients de
chaque modèle de répartition ?
•Comment choisir le bon modèle pour une
application distribuée ?
•Quel patron de conception utiliser pour
améliorer la modularité d’un système ?
ARTICLE "A SURVEY ON
NETWORKED DATA STREAMING
WITH APACHE KAFKA"
