Qu’est-ce qu’une architecture multiniveau ?
Une architecture multiniveau (ou « à n niveaux ») divise une application en plusieurs couches logiques et niveaux physiques. Le n indique en combien de niveaux physiques l’application est divisée, ce qui correspond généralement au nombre de couches. Nous pouvons avoir une architecture à deux niveaux (client/serveur), ou même une architecture à cinq niveaux, même s’il est courant et souvent préférable de maintenir le nombre de niveaux inférieur ou égal à quatre.
Examinons ce qui constitue les couches et les niveaux.
Présentation des couches
Les couches séparent logiquement le code d’application qui compose une application. À chaque couche correspond une responsabilité spécifique, comme la gestion des demandes des utilisateurs, l’exécution de la logique métier ou la gestion du stockage de données.
En divisant une application en ces couches logiques, nous traitons chaque couche de manière indépendante. Cette division rend les composants de l’application modulaires et nous permet d’assurer plus facilement la maintenance de l’application. Nous pouvons optimiser l’application pour chaque responsabilité. La couche qui traite les requêtes web se concentre sur sa tâche principale : le traitement des requêtes web. Elle n’est pas concernée par le stockage de données ou l’exécution de la logique métier. À l’inverse, la couche d’accès aux données se concentre sur l’optimisation de la communication avec le magasin de données et ignore les détails sur la façon dont elle présente les données à l’utilisateur. Ce concept consistant à limiter les objectifs à des fonctionnalités particulières est appelé séparation des problématiques.
Voici un diagramme qui illustre les couches dans une architecture multiniveau courante. Chaque couche gère un aspect de l’application. La couche métier gère la communication entre la couche d’interface utilisateur et la couche d’accès aux données.
Présentation des niveaux
Les niveaux représentent la séparation physique des parties de votre application sur des ressources de calcul distinctes. En général, chaque niveau physique exécute une couche logique de l’application.
La séparation de l’architecture en niveaux physiques présente plusieurs avantages :
- Les composants de l’application peuvent être mis à l’échelle séparément en ajoutant des ressources à chaque niveau.
- L’application peut gagner en résilience par l’ajout de l’équilibrage de charge pour détecter les ressources en échec et rediriger les demandes vers des systèmes sains.
- La sécurité de l’application peut être renforcée en limitant les communications réseau entre les niveaux et en autorisant seulement l’accès nécessaire.
L’architecture exige que la communication entre les niveaux s’effectue de haut en bas. Chaque niveau peut communiquer avec le niveau inférieur suivant, mais il n’est généralement pas autorisé à ignorer des niveaux. Cette conception améliore la sécurité en limitant la surface exposée d’un niveau.
L’architecture à trois niveaux
Parmi toutes les architectures multiniveaux, une architecture à trois niveaux est la plus courante. Les responsabilités et les noms de chaque couche et de chaque niveau varient selon l’application et l’activité, mais une application à trois niveaux classique a un niveau Présentation, un niveau Application (ou niveau intermédiaire) et un niveau Données. Cette architecture est le style multiniveau le plus courant. Pour le reste de ce module, nous allons faire référence à un modèle à trois niveaux, où chaque niveau exécute une seule couche de l’application, et nous les désignerons indifféremment sous le nom de « niveaux ».
Niveau Présentation
Le niveau Présentation facilite généralement les demandes de l’utilisateur. Ces demandes peuvent provenir d’utilisateurs accédant à une page web ou d’un accès public à votre application par le biais d’une API exposée. À ce niveau, l’accent est mis sur l’expérience utilisateur. Pour cela, vous devez par exemple fournir des éléments comme une interface intuitive et garantir une communication sécurisée entre l’utilisateur final et votre application.
Dans ce niveau, vous ne vous préoccupez pas des données proprement dites, excepté la façon dont elles sont présentées à l’utilisateur. En général, il n’y a aucun traitement des données ni accès aux données dans ce niveau. Ces opérations relèvent des niveaux inférieurs.
Niveau Application
Le niveau Application (également souvent appelé « niveau intermédiaire ») se concentre généralement sur le traitement de la logique métier de l’application. Il peut s’agir du traitement d’une commande client, du suivi d’une expédition ou de la mise à jour d’un inventaire en fonction de documents reçus. Ce niveau est également chargé des activités CRUD (« Create, Read, Update, Delete » : créer, lire, mettre à jour, supprimer) sur le niveau Données. Cet emplacement est également idéal pour effectuer des appels à des services dépendants, comme des API externes.
Ce niveau ne se préoccupe pas de la façon dont les informations sont présentées à l’utilisateur, ni de la façon dont les données sont stockées et extraites. Tout l’intérêt est porté à la logique métier nécessaire pour répondre à la demande que l’application a reçue.
Niveau Données
Dans ce niveau, le focus est placé sur le stockage de données. Il incombe à ce niveau de stocker les données se trouvant dans des tables, des fichiers ou tout autre support. Ce niveau fournit une interface (par exemple, T-SQL) pour accéder aux données. Dans une architecture à trois niveaux, le niveau Données permet au niveau Application d’accéder aux données.
Ce niveau ne porte pas sur la façon dont les données sont présentées à l’utilisateur ni sur la logique appliquée à ces données. Ce niveau peut inclure l’utilisation de procédures stockées, mais la majeure partie de la logique appliquée aux données doit être traitée à un niveau supérieur.
Quand utiliser des architectures multiniveaux
Maintenant que nous avons expliqué ce qu’est une architecture multiniveau, examinons les cas d’usage de ce style d’architecture. Une architecture multiniveau est à envisager pour :
- les applications web de petite à moyenne taille ;
- la migration d’une application locale vers Azure avec une refactorisation minimale ;
- l’utilisation des compétences, des fonctionnalités et de l’expérience des développeurs locaux.
Les applications web sont un bon cas d’utilisation des architectures de ce style. En raison de la complexité réduite de ce style d’architecture et la séparation souvent naturelle entre les responsabilités dans les applications web, les architectures multiniveaux peuvent fonctionner correctement. Il peut s’agir d’applications publiques ou bien d’applications métier utilisées en interne par une organisation. Pour les applications plus petites ou moins complexes, une architecture à deux niveaux (client/serveur) peut suffire, avec les niveaux Présentation et Application combinés au lieu d’être dissociés.
Les architectures multiniveaux sont courantes dans les applications locales classiques. De ce fait, elles conviennent parfaitement quand il s’agit de migrer des charges de travail existantes vers Azure. Les applications dans ce style sont souvent migrées vers Azure avec une refactorisation ou des modifications minimales, ce qui simplifie la migration initiale. Une fois sur Azure, vous pouvez tirer parti des services PaaS (platform as a service) pour encore améliorer votre application.
Comme il s’agit d’un style d’architecture courant, les ingénieurs ont souvent une plus grande expérience et connaissance de celui-ci. En choisissant cette architecture, vous pouvez recourir à des compétences existantes pour déployer des applications et ainsi éviter d’apprendre de nouveaux modèles d’architecture.