Style d’architecture de niveau N

Une architecture multiniveau divise une application en couches logiques et en niveaux physiques.

Le diagramme commence par un client, puis accède à un pare-feu d’applications web (WAF), puis au niveau web. À partir du niveau web, un flux passe au niveau intermédiaire 1 et un autre flux passe à la messagerie, puis au niveau intermédiaire 2. À partir du niveau intermédiaire 1, un flux passe au service distant et un autre flux passe au niveau données. À partir du niveau intermédiaire 2, le flux passe au niveau données. Depuis le niveau de données, les deux flux retournent via le cache, puis vers les niveaux intermédiaires 1 et 2 respectivement.

Les couches séparent les responsabilités et gèrent les dépendances. Chaque couche a une responsabilité spécifique. Une couche supérieure peut utiliser des services dans une couche inférieure, mais une couche inférieure ne peut pas utiliser de services dans une couche supérieure.

Les niveaux sont physiquement séparés et exécutés sur des machines distinctes. De façon contractuelle, le niveau peut avoir des modèles de communication stricts ou détendus. Dans le modèle strict, une demande doit passer par des niveaux adjacents, un par un et ne peut pas ignorer un niveau entre deux. Par exemple, une demande passe du pare-feu d’applications web (WAF) au niveau web, puis au niveau intermédiaire 1, puis continue. En revanche, l’approche assouplie permet aux demandes d’ignorer certains niveaux si nécessaire. L’approche stricte a une latence et une surcharge plus importantes. L’approche détendue a plus de couplages, ce qui rend les changements plus difficiles. Vous pouvez également combiner les deux approches dans le même système.

Un niveau peut appeler directement vers un autre niveau ou utiliser des modèles de messagerie asynchrones via une file d’attente de messages. Vous pouvez héberger chaque couche dans son propre niveau, mais cette approche n’est pas nécessaire. Vous pouvez héberger plusieurs couches sur le même niveau. La séparation physique des niveaux améliore la scalabilité et la résilience, mais ajoute également la latence de la communication réseau supplémentaire.

Une application traditionnelle à trois niveaux dispose d’un niveau de présentation, d’un niveau intermédiaire facultatif et d’une couche base de données. Les applications plus complexes peuvent avoir plus de trois niveaux. Le diagramme précédent montre une application avec deux niveaux intermédiaires qui encapsulent différentes zones de fonctionnalité.

Une application multiniveau peut avoir une architecture de couche fermée ou une architecture de couche ouverte :

• Dans une architecture de couche fermée, une couche peut uniquement appeler la couche suivante immédiatement vers le bas.
• Dans une architecture de couche ouverte, une couche peut appeler n’importe quelle couche en dessous.

Une architecture de couche fermée limite les dépendances entre les couches. Toutefois, cette architecture peut créer un trafic réseau inutile si une couche transmet uniquement les requêtes au niveau de la couche suivante.

Quand utiliser cette architecture

Considérez une architecture de niveau N pour les scénarios suivants :

• Prendre en charge les exigences architecturales qui évoluent toujours.
• Migrez une application locale vers Azure avec des modifications minimales.
• Développez des applications qui s’étendent à la fois sur site et dans les environnements cloud.

Les architectures à plusieurs niveaux sont courantes dans les systèmes locaux traditionnels, ce qui les rend naturels pour la transition des charges de travail existantes vers Azure.

Implémentez efficacement des architectures multiniveau à l’aide de services managés qui fournissent une scalabilité, une fiabilité et une surcharge opérationnelle réduite ou des machines virtuelles. Ces charges de travail bénéficient souvent d’utiliser également des solutions managées pour les composants clés tels que la mise en cache, la messagerie et le stockage des données.

Avantages

• Portable sur le cloud et sur site, et entre les plateformes cloud
• Nécessite moins de courbe d’apprentissage pour la plupart des développeurs
• Coûte relativement peu en ne réarchitecturant pas la solution
• Suit une évolution naturelle du modèle d’application traditionnel
• Prend en charge des environnements mixtes qui incluent Windows et Linux

Défis

• Un niveau intermédiaire peut uniquement effectuer des opérations CRUD (Create, Read, Update, Delete), qui ajoutent une latence et une complexité sans fournir de valeur significative.
• La conception monolithique empêche le déploiement indépendant des fonctionnalités.
• Les grands systèmes peuvent rendre la sécurité réseau difficile à gérer.
• Les demandes utilisateur et les données qui transitent par plusieurs niveaux rendent les tests et la surveillance plus difficiles.

Meilleures pratiques

• Utilisez la mise à l’échelle automatique pour gérer les modifications de charge. Pour plus d’informations, consultez les meilleures pratiques de mise à l’échelle automatique.
• Utilisez de messagerie asynchrone pour dissocier les niveaux.
• Cachez les données qui ne changent pas souvent. Pour plus d’informations, consultez les meilleures pratiques de mise en cache.
• Configurez le niveau de base de données pour la haute disponibilité à l’aide d’une solution telle que des groupes de disponibilité Always On SQL Server.
• Placez un WAF entre le serveur frontal et Internet.
• Placez chaque niveau dans son propre sous-réseau et utilisez des sous-réseaux comme limite de sécurité.
• Limitez l’accès au niveau de données en autorisant uniquement les requêtes d’un niveau intermédiaire.

Architecture multiniveau sur les machines virtuelles

Cette section décrit une architecture multiniveau qui s’exécute sur des machines virtuelles.

Note

Utilisez des machines virtuelles pour héberger une architecture N-teir si vous envisagez de migrer une application existante vers Azure avec une refactorisation minimale. Sinon, envisagez d’utiliser des services managés pour implémenter l’architecture, comme Azure App Service ou Azure Container Apps.

Le flux commence par Internet, qui se connecte à un équilibreur de charge qui route le trafic entrant vers deux appliances virtuelles réseau situées dans le réseau de périmètre. Le trafic passe ensuite par un autre équilibreur de charge pour atteindre plusieurs machines virtuelles dans le niveau web. Un troisième équilibreur de charge transfère le trafic du niveau web au niveau métier, qui inclut plusieurs machines virtuelles. Le niveau Métier se connecte via un quatrième équilibreur de charge au niveau données, qui inclut un serveur SQL Server principal et secondaire. Pour un accès administratif sécurisé, le personnel DevOps utilise le portail Azure pour se connecter à un hôte Azure Bastion situé dans AzureBastionSubnet. Le réseau de périmètre, tous les niveaux et AzureBastionSubnet résident dans un réseau virtuel.

Chaque niveau se compose d'un ensemble de machines virtuelles qui comporte deux machines virtuelles ou plus. Plusieurs machines virtuelles offrent une résilience en cas d’échec d’une machine virtuelle. Les équilibreurs de charge distribuent les requêtes entre les machines virtuelles d’un niveau. Vous pouvez mettre à l’échelle un niveau horizontalement en ajoutant d’autres machines virtuelles au pool.

Chaque niveau est également placé à l’intérieur de son propre sous-réseau, ce qui signifie que leurs adresses IP internes se trouvent dans la même plage d’adresses. Cette approche permet d’appliquer facilement des règles de groupe de sécurité réseau et des tables de routage à des niveaux individuels.

Les niveaux web et métier sont sans état. N’importe quelle machine virtuelle peut gérer n’importe quelle demande pour ce niveau. Le niveau de données doit se composer d’une base de données répliquée. Si possible, utilisez une base de données managée, mais vous pouvez également héberger des bases de données sur des bases de données hébergées par des machines virtuelles. Pour Windows, nous vous recommandons SQL Server avec des groupes de disponibilité Always On pour la haute disponibilité. Pour Linux, choisissez une base de données qui prend en charge la réplication, telle qu’Apache Cassandra.

Les groupes de sécurité réseau limitent l’accès à chaque niveau. Par exemple, le niveau de base de données autorise uniquement l’accès à partir du niveau Entreprise.

Note

Le niveau Business indiqué dans le diagramme de référence fait référence au niveau logique métier. Le niveau de présentation est étiqueté au niveau Web. L’exemple montre une application web, mais vous pouvez également utiliser des architectures multiniveau pour d’autres topologies, comme les applications de bureau. Utilisez des noms clairs et descriptifs pour chaque niveau que votre équipe comprend. Vous pouvez également utiliser ces noms dans vos ressources Azure, par exemple vmss-appname-business-tier.

Autres considérations

• Les architectures à plusieurs niveaux ne sont pas limitées à trois niveaux. Les applications plus complexes ont souvent plus de niveaux. Dans ce cas, envisagez d’utiliser le routage de couche 7 pour router les demandes vers un niveau particulier.

• Les niveaux créent des limites pour l’extensibilité, la fiabilité et la sécurité. Envisagez d’avoir des niveaux distincts pour les services avec des exigences différentes dans ces domaines.

• Utilisez des groupes de machines virtuelles identiques pour la mise à l’échelle automatique.

• Recherchez des emplacements dans l’architecture où vous pouvez utiliser un service managé sans refactorisation significative. En particulier, envisagez la mise en cache, la messagerie, le stockage et les bases de données.

• Placez un réseau de périmètre (également appelé zone DMZ, zone démilitarisée et sous-réseau filtré) devant l’application pour une sécurité plus élevée. Le réseau de périmètre comprend des appliances virtuelles réseau qui implémentent des fonctionnalités de sécurité telles que les pare-feu et l’inspection des paquets. Pour plus d’informations, consultez Implémenter un réseau hybride sécurisé.

• Utilisez deux appliances virtuelles de réseau ou plus dans un groupe de machines virtuelles identiques, avec un équilibreur de charge externe pour répartir les requêtes Internet entre les instances pour assurer une haute disponibilité. Pour plus d'informations, consultez Déployer des NVAs hautement disponibles.

• Bloquez l’accès RDP (Remote Desktop Protocol) direct ou Secure Shell (SSH) aux machines virtuelles qui exécutent du code d’application. Utilisez Plutôt Azure Bastion pour vous connecter en toute sécurité aux machines virtuelles via des adresses IP privées, qui fournissent une connectivité RDP et SSH. Pour plus d’informations, consultez la vue d’ensemble d’Azure Bastion.

• Étendez le réseau virtuel Azure à votre réseau local à l’aide d’un réseau privé virtuel de site à site (VPN) ou d’Azure ExpressRoute. Pour plus d’informations, consultez l’architecture de référence du réseau hybride.

Étape suivante

• Créer une application de niveau N sécurisée dans App Service

Ressource associée

• Messagerie dans un style d’architecture multiniveau sur Azure