Les principaux composants de cette architecture sont un serveur web frontal qui traite les requêtes des clients et un Worker qui s’occupe des tâches gourmandes en ressources, des flux de travail à exécution longue ou des programmes de traitement par lots. Le serveur web frontal communique avec le Worker via une file d’attente de messages.
Les autres composants généralement intégrés dans cette architecture sont :
- Une ou plusieurs bases de données.
- Un cache pour stocker des valeurs à partir de la base de données pour des lectures rapides.
- Un réseau de distribution de contenu (CDN) pour traiter du contenu statique.
- Des services à distance, tels qu’un service de messagerie ou SMS. Souvent, ces fonctionnalités sont fournies par des tiers.
- Un fournisseur d’identité pour l’authentification.
Le serveur web et le Worker sont sans état. L’état de session peut être stocké dans un cache distribué. N’importe quel travail à exécution longue est traité de façon asynchrone par le Worker. Le Worker peut être déclenché par des messages dans la file d’attente ou s’exécuter selon une planification pour le traitement par lots. Le Worker est un composant facultatif. S’il n’y a aucune opération à exécution longue, le Worker peut être omis.
Le serveur frontal peut être une API web. Du côté client, l’API web peut être utilisée par une application de page unique qui effectue les appels AJAX ou par une application cliente native.
Quand utiliser cette architecture
L’architecture Web-File d’attente-Worker est généralement implémentée à l’aide des services de calcul gérés d’Azure App Service ou d’Azure Cloud Services.
Envisagez ce style d’architecture pour :
- Des applications avec un domaine relativement simple.
- Des applications ayant des flux de travail à exécution longue ou des opérations par lots.
- Lorsque vous souhaitez utiliser des services gérés plutôt que l’infrastructure as a service (IaaS).
Avantages
- Architecture relativement simple, facile à comprendre.
- Gestion et déploiement faciles.
- Séparation nette des problèmes.
- Le serveur frontal est dissocié du Worker à l’aide d’une messagerie asynchrone.
- Le serveur frontal et le Worker peuvent être mis à l’échelle indépendamment.
Défis
- Sans une conception minutieuse, le serveur frontal et le Worker peuvent devenir des composants monolithiques volumineux, difficiles à gérer et à mettre à jour.
- Des dépendances masquées peuvent être présentes si le serveur frontal et le Worker partagent des schémas de données ou des modules de code.
- Un dysfonctionnement du front-end web peut se produire après avoir correctement persisté la base de données, mais avant d’émettre les messages dans la file d’attente. Cela peut entraîner des problèmes de cohérence possibles, car le worker n’effectue pas sa partie de la logique. Les techniques telles que le modèle de boîte d’envoi transactionnelle peuvent être utilisées pour atténuer ce problème, mais elles nécessitent de modifier le routage des messages sortants pour commencer par « boucler » via une file d’attente distincte. Une bibliothèque qui prend en charge cette technique est la session transactionnelle NServiceBus.
Meilleures pratiques
- Exposez une API bien conçue au client. Consultez Bonnes pratiques en matière de conception d'API.
- Effectuez une mise à l’échelle automatique pour gérer les évolutions au niveau de la charge. Consultez Bonnes pratiques en matière de mise à l'échelle automatique.
- Mettez en cache les données semi-statiques. Consultez Bonnes pratiques en matière de mise en cache.
- Utilisez un réseau de distribution de contenu (CDN) pour héberger le contenu statique. Consultez Bonnes pratiques en matière de réseau de distribution de contenu (CDN).
- Utilisez la persistance polyglotte lorsque cela est approprié. Consultez [Utiliser le meilleur magasin de données pour le travail][polyglotte].
- Partitionnez des données pour améliorer l’extensibilité, réduire la contention et optimiser les performances. Consultez Bonnes pratiques en matière de partitionnement des données.
Web-File d’attente-Worker sur Azure App Service
Cette section décrit une architecture Web-File d’attente-Worker recommandée qui utilise Azure App Service.
Téléchargez un fichier Visio de cette architecture.
Workflow
Le serveur front-end est implémenté en tant qu’application web Azure App Service et le Worker est implémenté en tant qu’application Azure Functions. L'application web et l'application de fonction sont associées à un plan App Service qui fournit les instances de machine virtuelle.
Vous pouvez utiliser les files d’attente Azure Service Bus ou de stockage Azure pour la file d’attente de messages. (Le schéma montre une file d’attente de stockage Azure.)
Azure Cache pour Redis stocke l’état de session et d’autres données qui nécessitent un accès à faible latence.
Azure CDN est utilisé pour mettre en cache le contenu statique comme les images, CSS ou HTML.
Pour le stockage, choisissez les technologies de stockage qui répondent le mieux aux besoins de l’application. Vous pouvez utiliser plusieurs technologies de stockage (persistance polyglotte). Pour illustrer cette idée, le schéma montre Azure SQL Database et Azure Cosmos DB.
Pour plus d’informations, consultez l’architecture de référence des applications web App Service et la manière de créer des applications métier pilotées par message avec NServiceBus et Azure Service Bus.
Autres considérations
Toutes les transactions n’ont pas à passer par la file d’attente et le Worker avant d’arriver au stockage. Le serveur web frontal peut directement effectuer des opérations de lecture/d’écriture simples. Les Workers sont conçus pour les tâches gourmandes en ressources ou les flux de travail à exécution longue. Dans certains cas, aucun Worker ne vous sera nécessaire.
Utilisez la fonctionnalité de mise à l’échelle intégrée d’App Service pour effectuer un scale-out du nombre des instances de machine virtuelle. Si la charge sur l’application suit les modèles prévisibles, utilisez la mise à l’échelle automatique basée sur la planification. Si la charge est imprévisible, utilisez des règles de mise à l’échelle automatique basée sur des métriques.
Envisagez de placer l'application web et l'application de fonction dans des plans App Service distincts. Elles pourront ainsi être mises à l’échelle de manière indépendante.
Utilisez des plans App Service distincts pour la production et le test. Sinon, si vous utilisez le même plan pour la production et le test, cela signifie que l’exécution des tests a lieu sur vos machines virtuelles de production.
Utilisez des emplacements de déploiement pour gérer les déploiements. Cette méthode vous permet de déployer une version mise à jour sur un emplacement de préproduction, puis de basculer sur la nouvelle version. Cela vous permet également de revenir à la version précédente en cas de problème avec la mise à jour.
Ressources associées
- Conception d’API web RESTful
- Mise à l’échelle automatique
- Recommandations en matière de cache
- Recommandations pour l’utilisation des réseaux de distribution de contenu (CDN)
- Recommandations en matière de partitionnement des données
- Application web scalable
- Modèle de nivellement de charge basé sur une file d’attente