Architecture client-serveur, 2 tiers, 3 tiers et n-tiers

L'architecture client-serveur répartit une application entre des clients, qui envoient des requêtes, et des serveurs, qui les traitent et répondent. Selon le nombre de niveaux de machines (ou de programmes) qui se partagent le travail, on parle d'architecture 2 tiers (le client parle directement à la base), 3 tiers (un serveur d'application s'intercale entre le client et la base) ou n-tiers (plus de trois niveaux). Ce chapitre décrit ces architectures, les compare avec l'exemple de ResaSalles, et lève la confusion entre tiers et couches.

Le modèle client-serveur

Dans le modèle client-serveur, un programme serveur écoute sur un port réseau et attend des requêtes ; un programme client se connecte, envoie une requête et reçoit une réponse. Les deux parlent un protocole commun.

Un même programme peut être serveur pour les uns et client pour les autres : l'API Node.js de ResaSalles est serveur pour les navigateurs, et client du serveur MySQL. C'est ce qui permet d'empiler les niveaux.

Architecture 1 tiers

Tout est sur la même machine, dans le même programme ou presque : l'interface, les règles et les données. C'est le cas d'une application de bureau qui enregistre ses données dans un fichier local ou une base embarquée (SQLite, un fichier Access, un tableur avec macros).

C'est simple à installer, mais les données ne sont pas partagées : chaque poste a sa propre copie. Pour ResaSalles, ce serait inutilisable : deux salariés ne verraient pas les réservations l'un de l'autre.

Architecture 2 tiers

Le client contient l'interface et les règles de gestion ; il se connecte directement au serveur de base de données. C'est l'architecture de l'application WinForms du chapitre 5 : chaque poste exécute ResaSalles.exe, qui ouvre une connexion MySQL sur le port 3306.

Le 2 tiers reste courant pour de petites applications internes, sur un réseau maîtrisé. Il pose un vrai problème de sécurité : un utilisateur qui récupère la chaîne de connexion peut interroger la base avec n'importe quel outil, en contournant toutes les règles de l'application. On limite le risque avec un compte MySQL aux droits réduits, voire des procédures stockées comme seul point d'accès ; on le supprime en passant au 3 tiers.

Architecture 3 tiers

Un serveur d'application s'intercale entre le client et la base. Le client ne contient que l'interface ; les règles de gestion et l'accès aux données sont sur le serveur d'application ; la base n'accepte que les connexions du serveur d'application.

Pour ResaSalles en version web : le navigateur (tiers présentation) envoie des requêtes HTTPS à l'API Node.js (tiers application, ou tiers métier), qui interroge MySQL (tiers données). Les identifiants de la base ne quittent jamais le serveur d'application, et le pare-feu peut fermer le port 3306 à tout le monde sauf à ce serveur.

Architecture n-tiers

Dès qu'on ajoute des niveaux, on parle d'architecture n-tiers (ou multi-tiers). Dans une application réelle, on trouve souvent :

• un proxy inverse (reverse proxy, Nginx, HAProxy, Traefik) qui reçoit les connexions HTTPS, gère le certificat et répartit les requêtes entre plusieurs instances de l'API (répartition de charge) ;
• plusieurs instances du serveur d'application ;
• un cache (Redis) pour les données lues souvent ;
• des services externes : envoi d'e-mails, paiement, authentification unique (SSO) de l'entreprise, stockage de fichiers ;
• un serveur de base de données principal et un réplica en lecture.

Chaque niveau peut évoluer, être remplacé ou multiplié indépendamment des autres. En contrepartie, il faut tout superviser, sécuriser chaque flux et documenter l'ensemble, ce que fait le chapitre 12.

Tiers et couches : ne plus confondre

Les deux notions se combinent : l'API ResaSalles est un tiers (le serveur d'application) qui contient trois couches (présentation HTTP, service, accès aux données). L'application WinForms 2 tiers contient elle aussi des couches (vue, contrôleur, DAO), toutes exécutées sur le poste client.

Client léger, client lourd, client riche

Le client d'une architecture client-serveur se décline en plusieurs familles.

Ces familles ne s'excluent pas : une même API peut servir un client riche, un client lourd et une application mobile en même temps. C'est l'architecture du chapitre 10.

Les situations d'exécution de l'E6

L'environnement technologique de l'épreuve E6 SLAM exige que tes réalisations couvrent, dans leurs architectures, des appels à des services applicatifs distants et au moins trois de ces quatre situations : du code exécuté sur un poste fixe (client lourd), dans un navigateur, sur un terminal mobile, sur un serveur. Pour les compter, regarde où s'exécute réellement le code que tu as écrit :

Le détail de ces exigences est dans le cours Épreuve E6 SLAM.

Exercices

Exercice 1 sur 4 Compter les tiers Réussi À revoir

Pour chaque architecture, donne le nombre de tiers et nomme-les.

1. Une application WinForms qui lit et écrit dans un fichier SQLite sur le poste.
2. Une application WinForms qui se connecte au serveur MySQL de l'entreprise.
3. Un site PHP en MVC hébergé sur un serveur Debian, avec MySQL sur le même serveur, consulté depuis un navigateur.
4. Un front React servi par Nginx, qui appelle une API Express, qui interroge MySQL et appelle l'API d'un prestataire d'envoi de SMS.

Voir la réponseMasquer la réponse de l'exercice 1

1. Un tiers : tout s'exécute sur le poste, dans le même programme (SQLite est une bibliothèque, pas un serveur).
2. Deux tiers : le client lourd (présentation et règles) et le serveur MySQL (données).
3. Trois tiers : le navigateur (présentation), PHP sur le serveur web (traitement), MySQL (données). MySQL est sur la même machine que PHP mais c'est un programme distinct, joint par une connexion (réseau local ou socket) : on compte les programmes, pas les boîtiers. Certains auteurs, qui comptent les machines, diraient deux niveaux côté infrastructure ; justifie toujours ta façon de compter.
4. N-tiers : le navigateur qui exécute React, le serveur Nginx, l'API Express, MySQL et le service SMS externe.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 4 Tiers ou couches ? Réussi À revoir

Pour chaque phrase, dis si elle parle de tiers ou de couches, et corrige-la si elle mélange les deux.

1. « Le service de réservation est dans la couche métier de l'API. »
2. « Mon application a trois tiers : les vues, les contrôleurs et les modèles. »
3. « Le serveur MySQL n'accepte que les connexions du tiers application. »
4. « La couche données est sur un autre serveur que la couche présentation. »

Voir la réponseMasquer la réponse de l'exercice 2

1. Couches, correct.
2. Mélange : vues, contrôleurs et modèles sont des couches (ou des rôles MVC). Correction : « Mon application a trois couches… » ; les tiers se comptent en programmes qui communiquent par le réseau.
3. Tiers, correct : c'est une règle de flux réseau entre deux machines.
4. Mélange : on parle de serveurs, donc de tiers. Correction : « Le tiers données (le SGBD) est sur un autre serveur que le tiers application ».

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 4 Les flux à autoriser Réussi À revoir

ResaSalles passe en 3 tiers : les postes du réseau 192.168.10.0/24 accèdent à l'API Node.js sur le serveur 192.168.20.10, qui écoute en HTTPS ; la base MySQL est sur 192.168.30.5. Écris la liste des flux à autoriser sur le pare-feu (source, destination, port), et dis quel flux de l'ancienne version 2 tiers on peut maintenant fermer.

Voir la réponseMasquer la réponse de l'exercice 3

Source	Destination	Port	Rôle
192.168.10.0/24 (postes)	192.168.20.10 (API)	TCP 443	Les clients appellent l'API en HTTPS
192.168.20.10 (API)	192.168.30.5 (MySQL)	TCP 3306	Seule l'API se connecte à la base

Le flux de l'ancienne version, postes vers MySQL sur le port 3306, doit être fermé : plus aucun poste ne doit pouvoir joindre la base directement. Tout le reste est refusé par défaut. L'administration (SSH vers les serveurs) s'ajoute depuis le seul réseau d'administration.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 4 sur 4 Quel client ? Réussi À revoir

Brévent Industrie a trois besoins. Propose pour chacun un type de client (léger, riche, lourd, mobile) et justifie.

1. Les salariés réservent une salle depuis leur poste, une ou deux fois par semaine.
2. L'accueil imprime chaque matin les badges des visiteurs attendus en salle de réunion, sur une imprimante à étiquettes branchée en USB.
3. Les techniciens de maintenance signalent un problème dans une salle (vidéoprojecteur en panne) en prenant une photo.

Voir la réponseMasquer la réponse de l'exercice 4

1. Client léger ou riche (application web) : rien à installer sur 120 postes, mise à jour instantanée. Un client riche React donne une interface plus fluide (planning qui se met à jour sans recharger).
2. Client lourd : l'accès direct à une imprimante USB spécifique est bien plus simple depuis une application installée. Il appelle la même API que le web pour lire la liste des visiteurs.
3. Application mobile : l'appareil photo et la mobilité sont le cœur du besoin. Elle envoie la photo et le signalement à l'API.

Tu avais trouvé ?

Oui, j'avais bonPas encore