Systèmes Répartis
Chapitre II :
Architectures des
systèmes répartis
Amine DHRAIEF
1ère année Master Pro Data Science
Introduction
● Les systèmes distribués :
– des logiciels complexes
– dont les composants sont par définition dispersés sur plusieurs machines.
→ Pour maîtriser leur complexité, il est essentiel que ces systèmes soient
correctement organisés et structurés.
● Une structuration évidente → distinguer entre l’architecture
logicielle et matérielle
– Architecture matérielle : le réseau, la topologie, les technologies,…
– Architecture logicielle : comment les différents composants logiciels
doivent être organisés et comment ils doivent interagir.
Systèmes Répartis
2
Introduction
● Les systèmes distribués utilisent une couche
middelware (intergiciel) pour séparer les
applications des plates-formes physiques
sous-jacentes
– l’objectif de la couche middelware est d’assurer
un accès transparent aux ressources (comme si
les ressources étaient locales)
Applications
OS
Applications
Middelware
OS
Systèmes Répartis
3
Introduction
● Les systèmes réparties peuvent avoir différentes
architectures, dites architectures réparties.
● Deux familles d’architectures réparties :
– Centralisés → Client /Serveur, 2-tiers, 3-tiers, …, n-tiers
● Une machine serveur implémente la quasi-totalité des
composants logicielles et des fonctionnalités
– Distribuées → P2P
● Les machines ont des rôles équivalents.
Systèmes Répartis
4
Styles Architecturaux
Systèmes Répartis
5
Architecture Logicielle & Style Architectural ?
● Architecture logicielle : l’organisation logique d’une
système distribué en composants logiciels.
● Style Architectural : formulé en termes de
composants :
– comment les composants sont connectés les uns aux
autres ?
– les données échangées entre les composants .
– et finalement comment ces éléments sont conjointement
configurés dans un système ?
Systèmes Répartis
6
Un composant ?
● Un composant = un élément constitutif d’un
logiciel → une pièce détachée
● Un composant : une unité modulaire + dotée
d'interfaces + remplaçable dans son
environnement.
Systèmes Répartis
7
Changement à chaud d’un composant
● Il est important de pouvoir remplacer un
composant et, en particulier, pendant qu’un
système continue à fonctionner.
– Il n'est pas possible/envisageable d'arrêter un
système pour la maintenance.
– Au mieux, seules certaines parties peuvent être
temporairement hors service.
– Le remplacement d'un composant ne peut être
effectué que si ses interfaces restent intactes.
Systèmes Répartis
8
Connecteur ?
● un connecteur : un mécanisme qui assure la
communication, la coordination ou la
coopération entre les composants
– C’est par les connecteurs que passent les flux de
contrôle & les flux de données entre les
composants,
Systèmes Répartis
9
Connecteurs + Composants = Style Architectural
● En combinants les composants et les connecteurs,
on obtient différentes configurations, qui à leur
tour, sont classés en styles architecturaux :
– Architectures en couches
– Architectures basées sur des objets
– Architectures centrées sur les ressources
– Architectures basées sur des événements
Systèmes Répartis
10
Styles Architecturaux
Architectures en couches
Systèmes Répartis
11
Architecture en Couches
● Les composants sont organisés en couches
● Un composant à la couche Lj envoie une requête
à un composant situé à une couche inférieure Li
(avec i <j) et attend généralement une réponse.
– Dans des cas exceptionnels, un appel est effectué par
un composant de niveau inférieur à un autre situé à un
niveau supérieur.
Systèmes Répartis
12
Architecture en Couches
● (a) architecture en couche ‘pure’ (b) architecture
en couche ‘cross layer’ (c) architecture en
couche avec des appels ascendants
Systèmes Répartis
13
Architecture en Couches
Architecture ‘pure’
● Uniquement des
appels descendants à
la couche strictement
inférieure.
● Modèle utilisé dans
les piles protocolaires
(TCP/IP, OSI,…)
Systèmes Répartis
14
Architecture en Couches
Architecture ‘cross-layer’
● Cas fréquent dû aux contraintes de
l’implémentation :
– Par exemple, une application A qui utilise
une bibliothèque LOS pour l'interface avec un
système d'exploitation.
– Dans le même temps, l'application utilise une
bibliothèque mathématique spécialisée Lmath
qui a été implémentée en utilisant LOS.
– Dans ce cas :
● A est implémenté à couche N- 1,
● Lmath au niveau de la couche N-2 et
● LOS qui leur est commune, à la couche N - 3.
Systèmes Répartis
15
Architecture en Couches
Architecture avec des appels ascendants
● Dans certains cas, une
couche inférieure a besoin
de faire un appel vers sa
couche supérieure à travers
une interface de la couche
supérieure.
Systèmes Répartis
16
Applications distribuées &
architecture en couches
● Une large classe d’applications distribuées permet
l’accès à une base de donnée à une application ou
un utilisateur .
● On a préconisé une distinction entre trois niveaux
logiques, ou couches :
– Le niveau interface (interaction avec un utilisateur ou
une application)
– Le niveau traitement (les fonctionnalités)
– Le niveau data
Systèmes Répartis
17
Advertisement
Applications distribuées &
architecture en couches
● Exemple : moteur de recherche
Systèmes Répartis
18
Styles Architecturaux
Architectures orientées objets et services
Systèmes Répartis
19
Architectures orientées objets et services
● Chaque objet correspond à
un composant.
– Les composants sont
connectés via un mécanisme
d'appel de procédure.
● Dans le cas de systèmes
distribués, un appel de
procédure peut également
être distant (via un réseau)
– c'est-à-dire que l'objet appelant
n'a pas besoin d'être exécuté
sur la même machine que
l'objet appelé.
Systèmes Répartis
20
Architectures orientées objets et services
● Les architectures basées sur les objets permettent
d'encapsuler (i) les données (état d'un objet (state))
(ii) et les opérations qui peuvent être effectué sur
ces données (appelées méthodes de l’objet) dans
une seule entité.
● L'interface offerte par un objet cache les détails
d'implémentation, ce qui signifie essentiellement que
nous pouvons, en principe, considérer un objet
totalement indépendant de son environnement.
Systèmes Répartis
21
Architectures orientées objets et services
● Comme pour les composants, cela signifie également que si
l'interface est clairement définie et laissée intacte, un objet
doit pouvoir être remplacé par un autre ayant exactement la
même interface.
● Cette séparation entre les interfaces et les objets
implémentant ces interfaces nous permet de placer une
interface sur une machine, alors que l'objet lui-même réside
sur une autre machine.
● Cette architecture est généralement appelée objet distribué.
Systèmes Répartis
22
Architectures orientées objets et services
un stub ?
● Un stub est un portion du code qui convertit les paramètres
passés entre le client et le serveur lors d'un appel de procédure
à distance (RPC).
– L'idée principale d'un RPC est de permettre à un ordinateur local (client)
d'appeler à distance des procédures sur un autre ordinateur (serveur).
● Le client et le serveur utilisent des espaces d'adressage
différents, de sorte que les paramètres utilisés dans un appel de
fonction (procédure) doivent être convertis (marshelling), sinon
les valeurs de ces paramètres ne peuvent pas être utilisées.
● Le client et le serveur peuvent également utiliser différentes
représentations de données
– par exemple, big-endian vs little-endian.
Systèmes Répartis
23
Architectures orientées objets et services
un stub ?
● Les bibliothèques de stub doivent être installées du côté
client et du côté serveur.
● Un stub client est responsable de la conversion (marshalling)
des paramètres utilisés dans un appel de fonction et de la
déconversion (unmarshalling) des résultats transmis par le
serveur après exécution de la fonction.
● Un skeleton de serveur, le stub côté serveur, est responsable
de la dé-conversion (unmarshalling) des paramètres transmis
par le client et de la conversion (marshalling) des résultats
après l'exécution de la fonction.
Systèmes Répartis
24
Architectures orientées objets et services
Systèmes Répartis
25
Architectures orientées objets et services
● Les architectures basées sur les objets sont à la base de
l’encapsulation des services dans des unités indépendantes.
● Le service dans son ensemble est réalisé comme une entité
autonome, bien que le service peut éventuellement utiliser
d'autres services.
● En séparant clairement les différents services de telle sorte
qu'ils peuvent opérer de manière indépendante, nous
obtenons une architectures orientées services, généralement
abrégées en SoA.
Systèmes Répartis
26
Architectures orientées objets et services
● Dans une architecture orientée services
(SoA), une application ou un système
distribué est essentiellement construit
comme une composition de nombreux
services différents.
– Tous ces services ne peuvent pas appartenir à la
même organisation administrative.
Systèmes Répartis
27
Architectures orientées objets et services
● Le problème du développement d’un système
distribué est en partie un problème de
composition des services et faire en sorte
ces services fonctionnent en harmonie.
Systèmes Répartis
28
Styles Architecturaux
Architectures centrées sur les ressources
Systèmes Répartis
29
Architectures centrées sur les ressources
RESTful
● Avec l'augmentation du nombre de services
disponibles sur le Web et le développement de
systèmes distribués via la composition des services,
les chercheurs ont commencé à repenser l'architecture
de systèmes distribués principalement basés sur le
Web.
● L'un des problèmes de la composition des services est
que la connexion de divers composants peut facilement
se transformer en un cauchemar d'intégration.
Systèmes Répartis
30
Architectures centrées sur les ressources
RESTful
● Comme alternative, on peut également voir un système
distribué comme une énorme collection de ressources
gérées individuellement par les composants.
● Des ressources peuvent être ajoutées ou supprimées par
des applications (distantes) et peuvent également être
récupérées ou modifiées.
● Cette approche a été largement adoptée pour le Web et est
connue sous le nom de Representational State Transfer
(REST).
Systèmes Répartis
31
Architectures centrées sur les ressources
RESTful
● Il existe quatre caractéristiques principales de ce que l'on
appelle les architectures RESTful :
1) Les ressources sont identifiées par un schéma de nommage
unique
2) Tous les services offrent la même interface, comprenant au
maximum quatre opérations (les verbes HTTP: PUT, GET, DELETE,
POST)
3) Les messages envoyés depuis/à un service sont contiennent
suffisamment d’information pour décrire comment traiter le
message.
4)Après avoir exécuté une opération sur un service, ce composant
oublie tout chose à propos de l'appelant (stateless execution)
Systèmes Répartis
32
Architectures centrées sur les ressources
RESTful
Systèmes Répartis
33
Architectures centrées sur les ressources
RESTful. Exemple Amazon S3
● Amazon S3 : Amazon Simple Storage Service
– Propose des services de stockage à travers des services Web
● Prend en charge uniquement deux ressources:
– Les objets, qui sont essentiellement l'équivalent des fichiers,
– et les buckets, l'équivalent des répertoires.
– Il n'y a pas de concept de placement de buckets dans des buckets.
Advertisement
● Un objet nommé ObjectName contenu dans BucketName est
référencé à l'aide de l'URI (Uniform Resource Identifier) suivant:
http://BucketName.s3.amazonaws.com/ObjectName
Systèmes Répartis
34
Architectures centrées sur les ressources
RESTful. Exemple Amazon S3
● Pour créer un bucket ou un objet, une application
envoie une demande PUT avec l'URI du bucket/objet.
– Il s'agit simplement d'une autre requête HTTP, qui sera
ensuite correctement interprétée par S3.
– Si le bucket ou l'objet existe déjà, un message d'erreur
HTTP est renvoyé.
● De manière similaire, pour savoir quels objets sont
contenus dans un bucket, une application envoie une
requête GET avec l'URI de ce bucket.
– S3 renverra une liste de noms d'objet, toujours sous la
forme d'une réponse HTTP ordinaire.
Systèmes Répartis
35
Architectures centrées sur les ressources
RESTful.
● Un service ne peut pas être rendu plus facile ou
plus difficile à cause de la interface particulière
qu'il offre.
– Un service offre des fonctionnalités, et au mieux la manière
d'accès au service est déterminé par l'interface.
● Amazon S3, qui offre un Interface REST et une
interface plus traditionnelle (appelée SOAP
interface). On va comparer en détail les deux
interfaces.
Systèmes Répartis
36
Architectures centrées sur les ressources
RESTful.
● L'interface Amazon S3 SOAP comprend 16 opérations.
● Par contre, l’interface REST offre très peu d'opérations
(PUT,GET,DELETE,POST)
Systèmes Répartis
37
Styles Architecturaux
Architectures basées sur les événements
Systèmes Répartis
38
Architecture Publish-Subscribe
● Dans les systèmes distribués les processus doivent
rejoindre ou quitter le système le plus facilement possible
– Il est important d'avoir une architecture dans laquelle les
dépendances entre les processus deviennent le moins couplées
que possible.
● Une classe de systèmes distribués a une architecture
dans laquelle il existe une forte séparation entre traitement
et coordination.
– L’idée est de voir un système comme une collection de processus
de fonctionnement autonome.
– Dans ce modèle, la coordination englobe la communication et la
coopération entre les processus.
Systèmes Répartis
39
Architecture Publish-Subscribe
● Une classification possible des différents types
de coordinations entre processus selon les
axes temporels et référentiels :
Systèmes Répartis
40
Architecture Publish-Subscribe
couplage temporel – couplage référentiel
● Le couplage référentiel apparaît généralement sous
la forme d'un référencement explicite en
communication. Par exemple, un processus ne
peut communiquer que s'il connaît le nom ou
identifiant des autres processus avec lesquels il
souhaite échanger des informations.
● Le couplage temporel signifie que les processus
qui communiquent doivent être dans l’état
running
Systèmes Répartis
41
Architecture Publish-Subscribe
mailbox coordination
● Les processus sont découplés temporellement, mais ayant un
couplage référentielle, ce que nous appelons la coordination des
boîtes aux lettres (mailbox coordination).
● Dans ce cas, il n'est pas nécessaire que deux processus qui
communiquent s'exécutent en même temps pour permettre la
communication.
● La communication a lieu en mettant des messages dans une boîte
aux lettres (éventuellement partagée).
● Comme il est nécessaire d'adresser explicitement la boîte aux
lettres qui contiendra les messages à échanger, il existe un
couplage référentiel.
Systèmes Répartis
42
Architecture Publish-Subscribe
● La combinaison de systèmes découplés par référence et
couplés temporellement constitue le groupe de modèles de
coordination basée sur les événements.
● Dans les systèmes découplés de manière référentielle, les
processus ne se connaissent pas explicitement.
● La seule chose qu'un processus puisse faire est de publier
une notification décrivant l'occurrence d'un événement (par
exemple, qu'il souhaite coordonner des activités ou qu'il n'a
produit que des résultats intéressants).
Systèmes Répartis
43
Architecture Publish-Subscribe
● En supposant que les notifications soient de toutes sorte,
les processus peuvent souscrire à un type spécifique de
notification.
● Dans un modèle de coordination basé sur les événements,
une notification publiée sera livrée exactement aux
processus qui y sont abonnés.
● Cependant, il est nécessaire que l'abonné soit opérationnel
au moment de la publication de la notification.
Systèmes Répartis
44
Architecture Publish-Subscribe
● Un modèle de coordination bien connu est la combinaison de
processus découplés de manière référentielle et temporelle,
conduisant à ce que l'on appelle un espace de données partagé
(shared data space).
● L'idée principale est que les processus communiquent entièrement
via des tuples, qui sont des enregistrements de données structurés
constitués d'un certain nombre de champs, très similaires à une ligne
dans une table de base de données.
● Les processus placent des tuples dans l'espace de données partagé.
– Afin de récupérer un tuple, un processus fournit un motif de recherche
correspondant aux tuples.
– Tout tuple correspondant est retourné.
Systèmes Répartis
45
Architecture Publish-Subscribe
● Les espaces de données partagés sont souvent
associés à une coordination basée sur les événements:
– un processus s'abonne à certains tuples en fournissant un
modèle de recherche;
– lorsqu'un processus insère un tuple dans l'espace de
données, les abonnés correspondants sont notifiés.
● Il s’agit d’une architecture de type publish-subscribe
– sa caractéristique principale est que les processus ne font
aucune référence explicite les uns aux autres.
Systèmes Répartis
46
Architecture Publish-Subscribe
Event-based
Shared-data space
Systèmes Répartis
47
Les architectures des système
distribuées
Systèmes Répartis
48
Les architectures des système distribuées
Centralisées : client-serveur
Architectures
Distribuées : P2P
15/10/2018
Systèmes Répartis
49
Les architectures des système
distribuées
Architectures centralisées
Systèmes Répartis
50
Les architectures centralisés
client-serveur
● Les processus sont divisés en
deux groupes (éventuellement
superposés) :
Advertisement
– Un serveur est un processus
implémentant un service
spécifique, par exemple un service
de système de fichiers ou un
service de base de données.
– Un client est un processus qui
demande un service à un serveur
en lui envoyant une demande et en
attendant la réponse du serveur.
15/10/2018
Systèmes Répartis
51
Les architectures centralisés
client-serveur
● La communication entre un client et un serveur peut être mise en œuvre
au moyen d'un protocole simple sans connexion lorsque le réseau
sous-jacent est assez fiable, comme dans de nombreux réseaux
locaux.
● Dans ces cas, lorsqu'un client demande un service, il crée simplement
un message pour le serveur, identifiant le service qu'il souhaite,
ainsi que les données d'entrée nécessaires. Le message est ensuite
envoyé au serveur.
● Le serveur attends une demande entrante, la traite et regroupe les
résultats dans un message de réponse qui sera ensuite envoyé au
client.
15/10/2018
Systèmes Répartis
52
Les architectures centralisés
client-serveur
● L'utilisation d'un protocole sans connexion présente l'avantage
évident d'être efficace.
– Tant que les messages ne sont pas perdus ou corrompus, le protocole
de requête / réponse fonctionne correctement.
● Malheureusement, rendre le protocole résistant aux
défaillances de transmission occasionnelles n’est pas anodin.
– La seule chose que nous puissions faire est de laisser le client
renvoyer la requête quand aucun message de réponse n’intervient.
– Le problème, cependant, est que le client ne peut pas détecter si le
message de la requête initiale a été perdu ou que la transmission de
la réponse a échoué.
15/10/2018
Systèmes Répartis
53
Les architectures centralisés
client-serveur
● Si la réponse a été perdue, le renvoi d'une demande peut
entraîner l'exécution de l'opération deux fois.
– Si l'opération consistait en quelque chose comme «transférer X Dinars de
mon compte bancaire», il aurait été préférable de signaler une erreur à la
place.
– En revanche, si l’opération était «dites-moi combien d’argent me reste», il
serait parfaitement acceptable de renvoyer la demande.
● Lorsqu'une opération peut être répétée plusieurs fois sans
dommage, on dit qu'elle est idempotente.
– Étant donné que certaines demandes sont idempotentes et que d'autres
ne le sont pas, il devrait être clair qu'il n'existe pas de solution unique
pour traiter les messages perdus.
15/10/2018
Systèmes Répartis
54
Les architectures centralisés
client-serveur
● Comme alternative, de nombreux systèmes client-serveur utilisent un
protocole fiable orienté connexion.
– Bien que cette solution ne soit pas tout à fait appropriée dans un réseau local
en raison des performances relativement faibles, elle fonctionne
parfaitement dans les systèmes étendus dans lesquels la communication
est intrinsèquement peu fiable.
– Par exemple, pratiquement tous les protocoles d'application Internet sont
basés sur des connexions TCP / IP fiables. Dans ce cas, chaque fois qu'un
client demande un service, il établit d'abord une connexion au serveur
avant d'envoyer la demande.
– Le serveur utilise généralement cette même connexion pour envoyer le
message de réponse, après quoi la connexion est terminée.
– Le problème peut être que les procédures d’ouverture et de fermeture
d’une connexion sont relativement coûteuses, en particulier lorsque les
messages de demande et de réponse ont de tailles minimes.
15/10/2018
Systèmes Répartis
55
Les architectures centralisés
client-serveur
● Le modèle client-serveur a fait l’objet de nombreux débats et
controverses au fil des ans.
● L'un des principaux problèmes était de savoir comment
distinguer clairement un client et un serveur.
– Sans surprise, il n'y a souvent pas de distinction claire.
– Par exemple, un serveur pour une base de données distribuée peut
continuellement agir en tant que client, car il transfère les demandes
vers différents serveurs de fichiers chargés d’implémenter les tables de
base de données.
– Dans ce cas, le serveur de base de données ne traite que les requêtes.
15/10/2018
Systèmes Répartis
56
Architectures à plusieurs niveaux
● La distinction en trois niveaux logiques, discutés ‘(interface,
traitement, données) suggère un nombre des possibilités de
distribution physique d'une application client-serveur à
travers plusieurs machines.
● L’organisation la plus simple est de n'avoir que deux types
de Machines:
– Une machine cliente contenant uniquement les programmes
implémentant (en partie) le niveau de l'interface utilisateur
– Une machine serveur contenant le reste, c’est-à-dire les
programmes implémentant le traitement et les données
15/10/2018
Systèmes Répartis
57
Architectures à plusieurs niveaux
● Dans cette organisation, tout est géré par le
serveur alors que le client n’est qu’un simple
terminal, éventuellement avec une interface
graphique.
● L'une des méthodes d'organisation des clients et
des serveurs consiste à distribuer les couches
interfaces, traitements, données, sur différentes
machines.
15/10/2018
Systèmes Répartis
58
Architectures à plusieurs niveaux
Architecture deux-tiers
● Dans un premier temps, nous ne distinguons
que deux types de machines:
– machines client et machines serveur, conduisant à
ce que l'on appelle aussi architecture deux-tiers
(physique)
15/10/2018
Systèmes Répartis
59
Architectures à plusieurs niveaux
Architecture deux-tiers
● N'avoir que la partie
dépendante du terminal
de l'interface utilisateur
sur la machine client
● Donner aux
applications le contrôle
à distance sur la
présentation de leurs
données
15/10/2018
Systèmes Répartis
60
Architectures à plusieurs niveaux
Architecture deux-tiers
● Une alternative consiste à placer l’ensemble
du logiciel d’interface utilisateur du côté
client.
● Dans de tels cas, nous divisons
essentiellement l'application en une interface
graphique, qui communique avec le reste de
l'application (résidant sur le serveur) via un
protocole spécifique à l'application.
● Dans ce modèle, le frontend (le logiciel client)
ne fait aucun autre traitement que nécessaire
pour présenter l’interface de l’application.
15/10/2018
Systèmes Répartis
61
Architectures à plusieurs niveaux
Architecture deux-tiers
● Nous pouvons également déplacer une partie
de l’application vers l’avant.
– Un exemple où cela a du sens est celui où
l'application utilise un formulaire qui doit être
entièrement rempli avant de pouvoir être traité.
Advertisement
– Le frontend peut alors vérifier l'exactitude et la
cohérence du formulaire et, le cas échéant,
interagir avec l'utilisateur.
– Un autre exemple d'organisation est celui d'un
traitement de texte dans lequel les fonctions
d'édition de base s'exécutent du côté client où
elles opèrent sur des données mises en cache
localement ou en mémoire, mais où les outils de
support avancés tels que vérifier 'orthographe
et la grammaire du côté serveur.
15/10/2018
Systèmes Répartis
62
Architectures à plusieurs niveaux
Architecture deux-tiers
● Le client est un PC ou un poste de travail,
connecté via un réseau à un système de
fichiers ou à une base de données distribués.
– Essentiellement, la majeure partie de
l'application s'exécute sur l'ordinateur client,
mais toutes les opérations sur les fichiers ou
les entrées de base de données vont au
serveur.
– Par exemple, de nombreuses applications
bancaires s'exécutent sur la machine d'un
utilisateur final où l'utilisateur prépare des
transactions, etc. Une fois terminé,
l’application contacte la base de données sur
le serveur de la banque et télécharge les
transactions pour un traitement ultérieur.
15/10/2018
Systèmes Répartis
63
Architectures à plusieurs niveaux
Architecture deux-tiers
● La figure représente la
situation où le disque local
du client contient une partie
des données.
– Par exemple, lors de la
navigation sur le Web, un client
peut progressivement créer un
énorme cache sur le disque
local des pages Web les plus
récemment inspectées.
15/10/2018
Systèmes Répartis
64
Architectures à plusieurs niveaux
Architecture trois-tiers
● En ne distinguant que les
machines client et
serveur comme nous
l’avions fait jusqu’à
présent, il n’est pas
évident qu’un serveur
doit parfois agir en tant
que client, ce qui
conduit à une
architecture à trois
niveaux (physique).
15/10/2018
Systèmes Répartis
65
Architectures à plusieurs niveaux
Architecture trois-tiers
● Dans cette architecture, traditionnellement, les
programmes faisant partie de la couche de
traitement sont exécutés par un serveur
distinct, mais peuvent en outre être partiellement
répartis sur les machines client et serveur.
– Un exemple typique d'une architecture à trois niveaux
est le traitement des transactions.
– Un processus distinct, appelé moniteur de traitement
des transactions, coordonne toutes les transactions
sur des serveurs de données éventuellement
différents.
15/10/2018
Systèmes Répartis
66
Architectures à plusieurs niveaux
Architecture trois-tiers
● Un autre exemple, mais très différent, est que nous voyons
souvent une architecture à trois niveaux dans l’organisation
des sites Web.
– Dans ce cas, un serveur Web agit en tant que point d’entrée sur un site,
transmettant les demandes à un serveur d’application où le traitement
proprement dit a lieu.
– Ce serveur d’application interagit à son tour avec un serveur de base
de données.
– Par exemple, un serveur d'applications peut être responsable de
l'exécution du code pour inspecter l'inventaire disponible de certaines
marchandises proposé par une librairie électronique.
– Pour ce faire, il peut être nécessaire d'interagir avec une base de
données contenant les données d'inventaire brutes.
15/10/2018
Systèmes Répartis
67
Les architectures des système
distribuées
Architectures distribuées
15/10/2018
Systèmes Répartis
68
Les architectures distribuées
Les systèmes Peer-to-Peer
● Les architectures client-serveur à plusieurs niveaux sont
une conséquence directe de la division des applications
distribuées en une interface utilisateur, des composants de
traitement et des composants de gestion des données.
– Les différents niveaux correspondent directement à
l'organisation logique des applications.
● Dans de nombreux environnements d'entreprise, le
traitement distribué équivaut à organiser une application
client-serveur en tant qu'architecture à plusieurs niveaux.
– Nous appelons ce type de distribution la distribution verticale.
– La caractéristique de la distribution verticale est qu’elle est
obtenue en plaçant des composants logiquement différents sur
des machines différentes.
15/10/2018
Systèmes Répartis
69
Les architectures distribuées
Les systèmes Peer-to-Peer
● Du point de vue de la gestion des systèmes, une
distribution verticale peut aider:
– Les fonctions sont logiquement et physiquement
réparties sur plusieurs machines, chaque machine étant
adaptée à un groupe de fonctions spécifique.
– Cependant, la distribution verticale n'est qu'un moyen
d'organiser les applications client-serveur.
● Dans les architectures modernes, c'est souvent la
distribution des clients et des serveurs qui compte,
que nous appelons la distribution horizontale.
15/10/2018
Systèmes Répartis
70
Les architectures distribuées
Les systèmes Peer-to-Peer
● Dans la distribution horizontale, un client ou un
serveur peut être physiquement divisé en parties
logiquement équivalentes, mais chaque partie
fonctionne sur son propre partage du jeu de
données complet, équilibrant ainsi la charge.
● Les systèmes peer-to-peer est une classe
d’architectures de systèmes modernes prenant en
charge la distribution horizontale.
15/10/2018
Systèmes Répartis
71
Les architectures distribuées
Les systèmes Peer-to-Peer
● Dans une perspective de haut niveau, les processus qui
constituent un système P2P sont tous égaux.
● Cela signifie que les fonctions à exécuter sont
représentées par chaque processus constituant le système
distribué.
● En conséquence, une grande partie de l'interaction entre les
processus est symétrique: chaque processus agira en tant
que client et serveur en même temps (ce qui est également
appelé agir en tant que servant).
15/10/2018
Systèmes Répartis
72
The End !
15/10/2018
Systèmes Répartis
73