Introduction à l'architecture à trois niveaux
L'architecture à trois niveaux est l'architecture d'interaction la plus courante sur Internet. Il est apparu lorsque la partie serveur à deux niveaux a été divisée en deux parties : une couche logique et une couche de données .
Cela ressemblait à ceci :
La couche client est la partie de "l'application distribuée" qui est responsable de l'interaction de l'utilisateur. Cette couche ne doit pas contenir de logique métier et ne doit pas stocker de données critiques. En outre, il ne doit pas interagir directement avec la couche de base de données, mais uniquement via la couche de logique métier.
Cependant, il y a encore une certaine logique ici. Premièrement, c'est l'interaction avec l'utilisateur via l'interface, la validation des données saisies par lui, le travail avec des fichiers locaux. Cela inclut également tout ce qui concerne l'autorisation de l'utilisateur et le cryptage des données lors de l'utilisation du serveur.
Deuxièmement, c'est une simple logique commerciale. Par exemple, si une boutique en ligne a envoyé une liste de produits, nous pouvons les trier et les filtrer côté client. Et le stockage de données primitif est également présent : mise en cache, cookies d'utilisateurs connectés, etc.
La couche de logique métier est située au deuxième niveau, la majeure partie de la logique métier y est concentrée. En dehors de celui-ci, seuls les fragments exportés vers le client, ainsi que les éléments logiques immergés dans la base de données (procédures stockées et déclencheurs) restent.
Une partie très importante du serveur de logique métier contient non seulement cette même logique, mais résout également des problèmes de mise à l'échelle : le code est divisé en parties et distribué sur différents serveurs. Certains services très demandés peuvent fonctionner sur des dizaines de serveurs. La charge entre eux est gérée par l'équilibreur de charge.
Les applications serveur sont généralement conçues de manière à ce qu'une autre copie du serveur puisse être facilement lancée et commencer à fonctionner en coopération avec d'autres copies de celui-ci. Autrement dit, même dans le processus d'écriture du code serveur, vous n'aurez jamais la garantie que votre classe statique est lancée dans une seule instance.
La couche de données fournit le stockage des données et est placée à un niveau séparé, mis en œuvre, en règle générale, au moyen de systèmes de gestion de base de données (SGBD), la connexion à ce composant n'est fournie qu'à partir du niveau du serveur d'application.
Raisons de séparer la couche de données
La séparation de la couche de données en une troisième couche à part entière s'est produite pour de nombreuses raisons, mais la principale est l'augmentation de la charge sur le serveur.
Premièrement, les bases de données ont commencé à nécessiter beaucoup de mémoire et de temps processeur pour le traitement des données. Par conséquent, ils ont commencé à être placés partout sur des serveurs séparés.
Avec une charge accrue, le backend pouvait facilement être dupliqué et dix copies d'un serveur pouvaient être créées, mais il était impossible de dupliquer la base de données - la base de données restait toujours un composant unique et indivisible du système.
Deuxièmement, les bases de données sont devenues intelligentes - elles ont leur propre logique métier. Ils ont commencé à prendre en charge les procédures stockées, les déclencheurs, leurs propres langages tels que PLSQL. Et même des programmeurs sont apparus qui ont commencé à écrire du code qui s'exécute à l'intérieur du SGBD.
Toute la logique qui n'était pas liée aux données était extraite du backend et lancée en parallèle sur des dizaines de serveurs. Tout ce qui était lié de manière critique aux données restait à l'intérieur du SGBD, et là déjà, les problèmes de charge accrue devaient être résolus en utilisant nos propres méthodes :
- Un cluster de bases de données est un groupe de serveurs de bases de données qui stockent les mêmes données et les synchronisent à l'aide d'un protocole spécifique.
- Sharding - les données sont divisées en blocs logiques et réparties sur différents serveurs de base de données. Il est très difficile de maintenir les modifications de la base de données avec cette approche.
- L'approche NoSQL consiste à stocker des données dans des bases de données conçues pour stocker d'énormes quantités de données. Ce ne sont souvent même pas des bases de données, mais des stockages de fichiers spécifiques. Fonctionnalité très médiocre par rapport aux bases de données relationnelles.
- Mise en cache des données. Au lieu d'un simple cache au niveau de la base de données, un SGBD de mise en cache complet est apparu, qui stockait le résultat uniquement en mémoire.
Il est clair que des personnes distinctes et / ou des équipes entières étaient nécessaires pour gérer ce zoo de technologies de serveur, ce qui a conduit à la suppression de la couche de données dans une couche distincte.
Important! Toutes les technologies de pointe naissent dans les profondeurs des grandes entreprises informatiques, lorsque les anciennes approches ne font plus face aux nouveaux défis. Faire des bases de données une couche séparée n'a été inventé par aucun programmeur, mais par un groupe d'ingénieurs quelque part dans les profondeurs d'Oracle ou d'IBM.
Intéressant! Lorsque Zuckerberg a commencé à écrire Facebook, il travaillait simplement sur PHP + MySQL. Quand il y avait des millions d'utilisateurs, ils ont écrit un traducteur spécial qui traduisait tout le code PHP en C ++ et le compilait en code machine natif.
De plus, MySQL n'est pas capable de stocker les données de milliards d'utilisateurs, donc Facebook a développé le concept de bases de données NoSQL et a écrit un puissant SGBD NoSQL côté serveur - Cassandra. Au fait, il est entièrement écrit en Java.
Ambiguïté de l'emplacement de la logique d'application
Et bien qu'une architecture à trois niveaux distribue presque sans ambiguïté les rôles entre ses parties, il n'est pas toujours possible de déterminer correctement où dans le système une nouvelle partie de la logique métier (nouveau code) doit être ajoutée.
Un exemple d'une telle ambiguïté est illustré dans l'image ci-dessous :
La partie serveur est remplie d'un fond gris, la partie client est remplie de blanc. Un bon exemple de cette dernière approche (à l'extrême droite) est celui des applications mobiles modernes. Le côté client (sur le téléphone) contient la vue (affichage), la logique et les données. Et seulement parfois ces données sont synchronisées avec le serveur.
Un exemple de l'option la plus à gauche est un serveur PHP typique, qui a toute la logique sur le serveur, et il donne au client du code HTML déjà statique. Quelque part entre ces deux extrêmes, votre projet se situera.
Au début du travail, après vous être familiarisé avec le projet, vous devrez consulter les programmeurs qui y travaillent, sur les endroits où il est préférable pour vous de mettre en œuvre la logique de la tâche suivante.
Sentez-vous à l'aise de le faire. Premièrement, ils ne montent pas dans le monastère de quelqu'un d'autre avec leur charte. Deuxièmement, il sera plus facile pour tout le monde (et vous aussi) de trouver le code dont vous avez besoin à l'endroit où vous vous attendez à le trouver.