377 lines
9.7 KiB
Markdown
377 lines
9.7 KiB
Markdown
<style>
|
||
pre { font-size: 0.5em !important; }
|
||
table { font-size: 0.5em !important; }
|
||
</style>
|
||
|
||
# Les architectures distribuées
|
||
## William Petit - S.C.O.P. Cadoles
|
||
|
||
---
|
||
|
||
## Les architectures distribuées (1)
|
||
|
||
### Qu'est ce qu'une application distribuée ?
|
||
|
||
|
||
|
||
> Une application distribuée est une application informatique constituée de **composants indépendants** (i.e. processus distincts et sans partage de mémoire) **communiquant via des messages**.
|
||
|
||
---
|
||
|
||
## Les architectures distribuées (2)
|
||
|
||
### Exemples d'applications distribuées
|
||
|
||
- Sites/applications Web
|
||
- Jeux en ligne multijoueurs
|
||
- Gestionnaire de version de code source (SVN, Git, etc...)
|
||
- Serveurs de courriel
|
||
|
||
---
|
||
<!-- page_number: true -->
|
||
## Les différents modèles d'architectures distribuées
|
||
|
||
### Modèle 2 tiers (ou client/serveur)
|
||
### Modèle 3 tiers
|
||
### Modèle N tiers
|
||
|
||
---
|
||
|
||
## Le modèle 2 tiers (ou "client/serveur")
|
||
|
||
### Définitions
|
||
### Les différentes topologies
|
||
### Communication client/serveur
|
||
### Répartition des traitements
|
||
### Le middleware
|
||
### Exercice : Implémentation d'une calculatrice par TCP/IP
|
||
|
||
---
|
||
## Définitions
|
||
|
||
- **Client** Processus demandant l’exécution d’une opération à
|
||
un autre processus par envoi de message contenant le
|
||
descriptif de l’opération à exécuter et attendant la réponse de
|
||
cette opération par un message en retour.
|
||
- **Serveur** processus accomplissant une opération sur
|
||
demande d’un client, et lui transmettant le résultat.
|
||
- **Requête** message transmis par un client à un serveur
|
||
décrivant l’opération à exécuter pour le compte du client.
|
||
- **Réponse** message transmis par un serveur à un client suite
|
||
à l’exécution d’une opération, contenant le résultat de
|
||
l’opération.
|
||
|
||
---
|
||
|
||
## Les différentes topologies
|
||
|
||
|
||
|
||
---
|
||
|
||
## Communication client/serveur (3)
|
||
|
||
### Protocole de communication
|
||
|
||
Une application distribuée étant fondamentalement un environnement hétérogène (composants indépendants). Il est donc nécessaire de définir un "langage commun" (ou "protocole") pour que les composants puissent communiquer entre eux.
|
||
|
||
La spécification de régles de **sérialisation** et **désérialisation** des structures de données échangées (messages) est souvent à la base de la définition des protocoles d'échange.
|
||
|
||
|
||
[Exemples de formats de sérialisation sur Wikipédia](https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats)
|
||
|
||
---
|
||
|
||
## Communication client/serveur (2)
|
||
|
||
### Modes de communication
|
||
|
||
|
||
|
||
---
|
||
|
||
## Communication client/serveur (3)
|
||
|
||
### Différences entre les deux modes
|
||
|
||
#### Synchrone
|
||
|
||
- Les messages sont émis aussitôt
|
||
- Bloquant
|
||
- Pas de file d'attente de traitement
|
||
|
||
### Asynchrone
|
||
|
||
- Nécessite une file d'attente de traitement
|
||
- Non bloquant
|
||
- Favorise le multitâche/la montée en charge
|
||
|
||
---
|
||
|
||
## Répartition des traitements (1)
|
||
|
||
### Couches de traitement
|
||
|
||
La conception d'une application distribuée nécessite d'établir une répartition de la responsabilité des traitements sur les différents composants. On peut catégoriser ces traitements par "couche":
|
||
|
||
- **Couche de présentation** rendu des interfaces textuelle ou graphique destinée à l'utilisateur de l'application, gestion des interactions, validation des entrées...
|
||
- **Couche métier/logique** traitement appliqués sur les modèles de données de l'application, validation des données...
|
||
- **Couche de données** Persistance et accès aux données de l'application
|
||
|
||
---
|
||
|
||
## Répartition des traitements (2)
|
||
|
||
### Classification des architectures 2 tiers (Gartner Group)
|
||
|
||
|
||
|
||
---
|
||
|
||
## Le middleware (1)
|
||
|
||
Aussi appelé "intergiciel" ou "intersticiel" en français.
|
||
|
||
### Rôle
|
||
|
||
- Ensemble de services logiciels construits **au dessus d’un
|
||
protocole de transport** afin de permettre l’échange de
|
||
requêtes et des réponses associées entre client et serveur **de
|
||
manière transparente**.
|
||
- Les services du middleware sont un ensemble de logiciels
|
||
répartis qui existe entre l’application, l’OS et les services
|
||
réseaux sur un nœud du réseau.
|
||
|
||
---
|
||
|
||
## Le middleware (2)
|
||
|
||
### Fonctions
|
||
|
||
- Procédure d’établissement de connexion
|
||
- Exécution des requêtes
|
||
- Récupération des résultats
|
||
- Procédure de fermeture de connexion
|
||
- Gestion des accès concurrents
|
||
- Sécurité et intégrité
|
||
- Monitoring
|
||
- Terminaison des processus
|
||
- Mise en cache des résultats
|
||
- Mise en cache des requêtes
|
||
|
||
---
|
||
|
||
## Le middleware (3)
|
||
|
||
### Différentes techniques
|
||
|
||
- **Échange de messages**, ou MOM - Message Oriented Middleware. Exemple: AMQP, NATS
|
||
- **Appel de procédures distantes**, ou RPC. Exemple: JSON-RPC2, XML-RPC, SOAP.
|
||
- **Manipulation d'objets** Exemple: REST, DCOMM, CORBA, RMI
|
||
|
||
---
|
||
|
||
## Le middleware (4)
|
||
|
||
### Exemple: RPC
|
||
|
||
|
||
|
||
---
|
||
|
||
## Exercice
|
||
|
||
### Implémentation d'une calculatrice à état distribuée en NodeJS
|
||
|
||
---
|
||
|
||
## L'architecture 3 tiers
|
||
|
||
### Généralités
|
||
### Transactions
|
||
### Sécurité
|
||
|
||
---
|
||
|
||
## Généralités (1)
|
||
|
||
### Principe
|
||
|
||
L'architecture 3 tiers est le modèle d'architecture applicative le plus utilisé aujourd'hui dans la conception d'application. Il propose de découper l'application en 3 couches aux rôles distincts:
|
||
|
||
- Couche **présentation**
|
||
- Couche **logique/métier**
|
||
- Couche **persistence/données**
|
||
|
||
---
|
||
|
||
## Généralités (2)
|
||
|
||
### Exemple: Application LAMP (Linux, Apache, PHP, MySQL)
|
||
|
||
|
||
|
||
---
|
||
|
||
## Transactions (1)
|
||
|
||
### Qu'est ce qu'une transaction ?
|
||
|
||
Une transaction est une série d'opérations appliquées sur un corpus de données respectant les caractéristiques suivantes:
|
||
|
||
- **A**tomicité
|
||
- **C**ohérence
|
||
- **I**solation
|
||
- **D**urable
|
||
|
||
---
|
||
|
||
## Transactions (2)
|
||
|
||
### Atomicité
|
||
|
||
La série d'opérations est indivisible.
|
||
|
||
**Exemple**
|
||
|
||
Soit une transaction comportant 3 opérations arithmétiques sur la variable `ACC`.
|
||
|
||
|Opération|État |Description|
|
||
|:-|:-|:-|
|
||
| -- | `ACC = 0` | État initial |
|
||
| `ACC = ACC + 1` | `ACC = 1` | Application de l'opération A |
|
||
| `ACC = ACC - 5` | `ACC = -4` | Application de l'opération B |
|
||
| `ACC = ACC / 0` | `ACC = 0` | Application de l'opération C. La division par 0 provoque une erreur. Retour à l'état initial. |
|
||
|
||
---
|
||
|
||
## Transactions (3)
|
||
|
||
### Cohérence
|
||
|
||
L'état du corpus de données à la fin de l'exécution de la transaction doit être cohérent (sans pour autant que le résultat de chaque opération pris distinctement soit cohérent).
|
||
|
||
---
|
||
|
||
## Transactions (4)
|
||
|
||
### Isolation
|
||
|
||
Lorsque deux transactions A et B sont exécutées en même temps, les modifications effectuées par A ne sont ni visibles par B, ni modifiables par B tant que la transaction A n'est pas terminée et validée.
|
||
|
||
---
|
||
|
||
## Transactions (5)
|
||
|
||
### Durable
|
||
|
||
Une fois validé, l'état du corpus de données doit être permanent, et aucun incident technique (exemple: crash) ne doit pouvoir engendrer une annulation des opérations effectuées durant la transaction.
|
||
|
||
---
|
||
|
||
## Sécurité (1)
|
||
|
||
### Objectifs
|
||
|
||
- Maintenir l'intégrité des données
|
||
- S'assurer du niveaux d'authentification et d'autorisation
|
||
- Maintenir la disponibilité des services
|
||
- Assurer la traçabilité des échanges
|
||
- Éviter la fuite d'informations
|
||
|
||
---
|
||
|
||
## Sécurité (2)
|
||
|
||
### Modélisation de menace
|
||
|
||
- Identification des **dépendances externes**.
|
||
Exemple: _serveur GNU/Linux, base de données_
|
||
- Identification des **points d'entrées**
|
||
Exemple: _formulaire de contact, port de la base de données_
|
||
- Identification des **assets**
|
||
Exemple: _Comptes utilisateurs de l'application, données personnelles, droits d'accès_
|
||
- Identification des **niveaux de confiance**
|
||
Exemple: _Utilisateur anonyme, administrateur_
|
||
|
||
---
|
||
|
||
## Sécurité (3)
|
||
|
||
### Identification des flux de données
|
||
|
||
|
||
|
||
---
|
||
|
||
## Modèle N tiers
|
||
|
||
### Architecture orientée services (ou SOA)
|
||
### Architecture orientée microservices
|
||
### Exercice
|
||
|
||
---
|
||
|
||
## Architecture orientée services (1)
|
||
|
||
### Notion de "service"
|
||
|
||
Un service est un composant d'une application distribuée répondant aux caractéristiques suivantes:
|
||
|
||
- Il a pour responsabilité **un domaine métier identifié** (ex: gestion du paiement par carte).
|
||
- Il est **autonome**.
|
||
- C'est une **"boite noire"** pour ses utilisateurs.
|
||
- Il peut être lui même un **aggrégat de plusieurs autres sous services**.
|
||
|
||
---
|
||
|
||
## Architecture orientée services (2)
|
||
|
||
### Exemple
|
||
|
||
|
||
|
||
---
|
||
|
||
## Architecture orientée services (3)
|
||
|
||
### Piliers
|
||
|
||
- La **plus-value métier** prévaut sur la technique.
|
||
- L'**interopérabilité** des services doit être considérée comme une des pierres angulaires de la conception.
|
||
- La **flexibilité** de l'architecture doit être privilégiée à l'optimisation.
|
||
|
||
---
|
||
|
||
## Architecture orientée microservices (1)
|
||
|
||
### Différence avec le SOA
|
||
|
||
L'architecture orientée microservices est une variante du modèle plus général de la SOA.
|
||
|
||
Elle peut se résumer à la philosophie Unix **"Faire une seule chose et le faire bien"**.
|
||
|
||
---
|
||
|
||
## Architecture orientée microservices (2)
|
||
|
||
### Piliers
|
||
|
||
- Chaque service remplit **une fonction unique**.
|
||
- La culture de l'**automatisation du processus de développement** devrait être adoptée au maximum par les équipes (mise en place de tests unitaires et fonctionnels, intégration et déploiement continu).
|
||
- L'application devrait **prendre en compte et gérer l'échec** d'un de ses composants.
|
||
- Chaque service est **élastique**, **résilient**, **composable**, **minimaliste** et **complet**.
|
||
|
||
---
|
||
|
||
## Exercice
|
||
|
||
### Prototypage d'une application distribuée basée sur les microservices
|
||
|
||
---
|
||
|
||
# Licence
|
||
|
||
## CC BY-NC-SA 3.0 FR
|
||
|
||
[Creative Commons - Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 3.0 France](https://creativecommons.org/licenses/by-nc-sa/3.0/fr/) |