Architectures en couches pour applications web Rappel : Architecture en couches

Transcription

1 Rappel : Architecture en couches Une architecture en couches aide à gérer la complexité : 7 Application 6 Presentation 5 Session Application Les couches hautes dépendent des couches basses 4 Transport Transport TCP Les couches basses ne dépendent pas des couches au-dessus 3 Network Internetwork IP Exemple Les couches de protocole du réseau 2 Data Link 1 Physical Link Ethernet Couches OSI Couches TCP/IP Exemples 49 Couches générales La couche présentation Gère les interaction entre l'utilisateur et le logiciel Est une interface HTML (+ JavaScript / AJAX) La couche logique domaine ou logique Fait des calculs, des validations et de la gestion Peut encapsuler la source de, mais normalement ce n'est pas le cas La couche source de Communique avec d'autres systèmes pour recevoir et envoyer des Généralement inclut un système de gestion de bases de pour stocker les persistantes 50

2 Exemple Exemple d'une application LAMP (Linux Apache MySQL PHP) Couche Implémentée en langage PHP PHP est implémenté comme module au sein du serveur web Apache Serveur 1 Apache Serveur 2 Navigateur mod_php MySQL client/server protocol MySQL Couche Également implémentée en PHP, mais séparée de la couche présentation Couche Essentiellement implémentée par la base de MySQL 51 Couches générales Les dépendances sont importantes : les couches et source de ne devraient rient savoir sur la couche présentation En maintenant cette séparation nous pouvons échanger notre interface web pour une nouvelle quand nous voulons, sans changer la logique ou le modèle de En termes de distribution physique des couches : Toutes les couches tournent généralement sur le côté serveur Avec Ajax et technologies associées une partie de la couche présentation peut s'exécuter sur le côte client. dépend de dépend de 52

3 Répartition sur les serveurs Parfois on utilise le terme tier (anglais) au lieu du terme couche Le terme tier implique généralement une séparation physique, tandis qu'une couche est seulement logique Serveur 1 Serveur 2 Répartition sur 2 tiers Serveur 1 Serveur 2 Serveur 3 Répartition sur 3 tiers : Architecture 3 tiers 53 Modules sans état (stateless) Introduction Le protocole est un exemple d'un protocole sans état (stateless) Cette notion s'applique aussi aux modules qui composent une application web Définition Un module d'une application web est sans état (stateless) si le traitement d'une requête venant du client est indépendant des requêtes précédentes. Le module ne doit pas gérer une notion de session ou conversation. Un module qui gère un état est appelé stateful. Avantages Simplicité (scalability) Permet d'utiliser le caching En pratique Beaucoup d'applications simples ne nécessitent pas d'état Toutes les applications qui demandent à l'utilisateur de faire un login le nécessitent Parfois on peut rendre un module stateless en stockant l'état à l'aide du client Dans des cookies Dans des paramètres du URI Dans des champs cachés d'un formulaire Ne fonctionne pas bien pour des grandes quantités de. 54

4 Traitement parallèle (scale-out) Il est très facile de rendre un module qui est stateless évolutif (scalable) Augmentation du nombre de serveurs Traitement en parallèle Distribution de la charge Exemple : Scale-out de la couche présentation Équilibreur de charge statless stateful stateful 55 Équilibreur de charge (load balancer) Un équilibreur de charge (load balancer) pour applications web Agit comme un proxy : Pour le client il parait comme un serveur qui répond aux requêtes En réalité il relaie une requête vers un des serveurs (et les réponses en sens inverse) Les requêtes suivantes sont envoyées à d'autres serveurs à tour de rôle L'équilibreur de charge doit avoir une idée de la charge et de la santé de chaque serveur : monitoring Monitoring des connexions pour estimer la charge Pings réguliers pour détecter les failles La politique de distribution des requêtes (scheduling policy) est généralement configurable. Exemples: Moindre charge Sticky sessions (voir plus loin) Il faut éviter que l'équilibreur de charge luimême devienne un single point of failure. Scale-out de l'équilibreur de charge sur plusieurs serveurs DNS round-robin 56

5 Équilibreur de charge (load balancer) Si le traitement des requêtes par l'application web est stateless l'équilibreur de charge est libre dans sa politique de scheduling Généralement on choisit une politique de moindre charge Vrai aussi pour les application web stateful avec synchronisation (p. ex. par une base de commune, un système de fichiers distribué commun) Les applications stateful sans synchronisation (avec gestion de session) nécessitent la coopération de l'équilibreur de charge pour éviter qu'une paire clientserveur soit déchirée au milieu d'une session Politique sticky sessions Les requêtes d'un même client seront envoyées vers le même serveur Durant un certain temps qui correspond au temps de session Mécanismes utilisés par l'équilibreur de charge Cookies URI rewrite 57 Équilibreur de charge en tant que service AWS offre un équilibreur de charge en tant que service : Elastic Load Balancing (ELB) Un ELB permet de distribuer des requêtes client entre plusieurs instances EC2 Les clients envoient leur requêtes vers le nom de domaine du ELB Le ELB relaie les requêtes vers les instances EC2 Le nombre d'instances peut augmenter et diminuer dynamiquement : élasticité (elasticity) 58