1-Tier 2-Tier 3-Tier N-Tier... besoin d'explications

1-Tier 2-Tier 3-Tier N-Tier... besoin d'explications - SQL/NoSQL - Programmation

Marsh Posté le 03-05-2006 à 21:47:23    

Bonsoir,
 
Je n'arrive pas à faire la distinction entre les différentes architectures i-tier.
Pouriez-vous m'aider sur ce sujet?
 
1-tier me semble-t-il est centré sur les db.
 
2-tier et 3-tier jvois pas la nuance
 
et alors N-tier jcrois que c'est plein de clients, pleins de bases, beaucoup de DBMS etc.
 
merci pour votre aide

Reply

Marsh Posté le 03-05-2006 à 21:47:23   

Reply

Marsh Posté le 03-05-2006 à 23:35:12    

Dorian BAC+4 a écrit :

Bonsoir,
 
Je n'arrive pas à faire la distinction entre les différentes architectures i-tier.
Pouriez-vous m'aider sur ce sujet?
 
1-tier me semble-t-il est centré sur les db.
 
2-tier et 3-tier jvois pas la nuance
 
et alors N-tier jcrois que c'est plein de clients, pleins de bases, beaucoup de DBMS etc.
 
merci pour votre aide


 
L'architecture 3 tiers s'articule autour de 3 éléments
- le client
- le serveur internet (style Apache)
- un module permettant de générer dynamiquement du HTML (style PHP)
L'ensemble formant un tout global. le client envoie ses demandes au serveur, celui-ci envoie le code php au module PHP, le module PHP calcule la réponse et la renvoie sous forme de HTML au serveur qui l'affiche chez le client.
 
Le pb, c'est que le module PHP n'est pas forcément assez puissant pour tout calculer. S'il doit gérer des données en grand nombre et se croisant, faire des gros calculs ou autre, il va vite se retrouver à l'ouest.
 
L'architecture "n-tiers" est une évolution. On rajoute derrière le module PHP différents tiers (différents serveurs)
- un serveur s'occupera de la BDD
- un serveur fera les gros calculs mathématiques
- un serveur s'occupera de X
- un serveur s'occupera de Y
etc
Dès que le module PHP doit faire un truc particulièrement compliqué, il renvoie son pb sur le serveur qui s'occupe du truc. Le serveur fait le truc à sa façon (évidemment plus rapidement que PHP) puis lui renvoie la réponse que le module PHP renvoie au serveur Apache qui la renvoie sur le client.


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

Marsh Posté le 04-05-2006 à 09:25:45    

Pour compléter l'explication précédente, en architecture 3-tiers :  
- Une partie application, par exemple un client.
- Une partie logique qui gère les connexions des clients et la couche métier, par exemple un serveur Web.
- Une partie de stockage de données, comme une base de données.
 
Le client communique avec le serveur Web qui communique avec la base de données. Tu peux avoir plusieurs serveurs Web dans cette architecture ce qui te permettra de faire de la répartition de charge de tes clients.
 
Dans une architecture 2-tiers, le client communique directement avec le serveur Web qui contient également la base de données. La répartition de charge et la tolérance de panne devient plus contraignante.
 
Tu peut retrouver aussi l'architecture 3-tiers au sein d'une application :
- Une couche présentation, avec ton interface IHM.
- Une couche métier, qui contiendra la logique de ton application, les algorithmes, etc...
- Une couche acces aux données qui fera le lien entre la couche métier et la base de données. Cette couche contiendra les méthodes d'accès à la base de données.
 
Tout ceci permet de segmenter l'application, pour faciliter entre autre l'administration, la maintenance et l'évolutivité de ton application. Si demain tu veux passer d'une base Mysql à une base Oracle, tu n'as logiquement qu'a modifier ta couche acces aux donnés, sans toucher aux algorithmes métiers ;) !

Reply

Marsh Posté le 04-05-2006 à 09:35:54    

J'ai effectué quelques recherches ces derniers mois et voilà ce que j'en retient pour ma part.
 
Le gros interêt des architectures 3 tiers ou n-tiers c'est de centraliser la maintenance sur le serveur et non sur les x clients.  
 
Pour celà on utilise au niveau des clients soit :
- un terminal (pas d'OS sur les machines, juste une session ouverte directement sur le serveur à travers le réseau).
- un client léger (un PC avec l'OS de son choix et un navigateur web généralement équipé d'une JVM).
 
Les applications tournent sur les serveurs et les utilisateurs se connectent soit via une session graphique (terminal) soit via leur navigateur (client léger).
 
Avant (client - serveur)  
"Je dois patcher mes 300 clients avec la V2 de la gestion de production.
J'utilise un batch à la connexion de chaque utilisateur ou alors je me coltine les install à la main dans la soirée.  
Dans le premier cas, je plombe les perfs de mon réseau le temps que tous le monde pompe son patch à l'allumage de sa machine.  
Dans le second cas, je ne dors pas de la nuit et le matin j'ai toujours pas fini."
 
Après (3 tiers ou n-tiers)
"Je dois patcher mon serveur d'appli avec la V2 gestion de production.
Je programme une tâche planifiée (ou crontab) sur le serveur pour dans la nuit. Je peux rentrer chez moi. Demain matin la charge réseau sera normale."
 
Maintenant le terme "architecture n-tiers", n'a pas la même signification pour tout le monde. Une architecture 3 tiers peut ressembler à ça :
 
client <---> serveur d'application <---> base de données
 
Mais si on doit équilibrer la charge ou installer des serveurs de secours, on arrive vite sur du n-tiers.
 
Par exmple :
 
client <---> serveur d'application <---> Base de donnée 1
        <---> serveur web            <---> Base de donnée 1 (serveur de secours)
 
etc ...
 
Maintenant, rien ne t'empêche de faire du n-tiers avec du client lourd mais l'interêt m'échappe si c'est pour retrouver les problèmes du client-serveur.


Message édité par jeoff le 04-05-2006 à 09:37:57
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed