Style d’architecture Web-Queue-Worker

Cette architecture comporte deux composants principaux. Un serveur frontal web gère les demandes des clients, et un worker effectue des tâches gourmandes en ressources, des workflows de longue durée ou des travaux par lots. Le frontend web communique avec le worker via une file d’attente de messages.

Diagramme logique montrant l’architecture web-Queue-Worker.

Cette architecture utilise généralement les composants suivants :

  • Une ou plusieurs bases de données

  • Cache permettant de stocker des valeurs à partir de la base de données pour les lectures rapides

  • Un réseau de distribution de contenu pour servir du contenu statique

  • Services distants, tels que l’e-mail ou le service SMS (Short Message Service), que les fournisseurs de services non-Microsoft fournissent généralement

  • Fournisseur d’identité pour l’authentification

Le serveur frontal web et le worker sont tous deux sans état. Vous pouvez stocker l’état de session dans un cache distribué. Le travailleur gère les tâches de longue durée de manière asynchrone. Vous pouvez déclencher le worker à l’aide de messages de file d’attente ou l’exécuter selon un calendrier défini pour un traitement par lots. Le worker est facultatif si l’application n’a pas d’opérations de longue durée.

Le serveur frontal peut inclure une API web. Une application monopage peut consommer l’API web en effectuant des requêtes HTTP asynchrones, ou une application cliente native peut l’utiliser directement.

Quand utiliser cette architecture

Pour implémenter l’architecture web-Queue-Worker, vous utilisez généralement des services de calcul managés comme Azure App Service, Azure Kubernetes Service (AKS) ou Azure Container Apps.

Tenez compte de cette architecture pour les cas d’usage suivants :

  • Applications qui ont un domaine relativement simple

  • Applications qui ont des flux de travail ou des opérations par lots longues

  • Scénarios où vous préférez les services managés par rapport à l’infrastructure en tant que service (IaaS)

Avantages

  • Architecture simple facile à comprendre

  • Déploiement et gestion simples

  • Séparation claire des responsabilités entre le front end et l'exécutant

  • Messagerie asynchrone qui dissocie l’interface utilisateur du module d’exécution

  • Possibilité de mettre à l’échelle le front-end et le worker indépendamment

Défis

  • Sans conception minutieuse, le front-end et le worker peuvent croître en composants monolithiques volumineux qui deviennent difficiles à gérer et à mettre à jour.

  • Les schémas de données partagés ou les modules de code entre le serveur frontal et le worker peuvent créer des dépendances masquées.

  • Le front-end web peut échouer une fois qu’il écrit dans la base de données, mais avant d’envoyer un message à la file d’attente. Cet échec entraîne des problèmes de cohérence car le worker ne traite jamais sa partie de la logique. Pour résoudre ce problème, utilisez des techniques telles que le modèle de boîte de réception transactionnelle, qui route d’abord les messages sortants via une file d’attente distincte. La bibliothèque de session transactionnelle NServiceBus prend en charge cette approche.

Meilleures pratiques

Web-File d’attente-Worker sur App Service

Cette section décrit une architecture webQueue-Worker recommandée qui utilise App Service.

Diagramme montrant l’architecture web-Queue-Worker.

Téléchargez un fichier Visio de cette architecture.

Flux de travail

  • Une application web App Service sert de serveur frontal et une application Azure Functions sert de worker. Les deux composants s’exécutent sur un plan App Service.

  • Le diagramme illustre une implémentation qui utilise Stockage File d'attente Azure. Vous pouvez également utiliser Azure Service Bus pour la file d’attente de messages, en fonction de vos besoins en matière de messagerie.

  • Azure Managed Redis stocke l’état de session et d’autres données nécessitant un accès à faible latence.

  • Une fois la mise en cache activée, Azure Front Door Standard ou Premium met en cache du contenu statique comme les images, CSS et HTML à partir de Stockage Blob Azure.

  • Pour le stockage, choisissez les technologies qui conviennent le mieux aux besoins de votre application. Cette approche, appelée persistance polyglotte, combine plusieurs technologies de stockage dans un système pour répondre à différentes exigences. Le diagramme précédent illustre cette approche à l’aide d’Azure SQL Database et d’Azure Cosmos DB.

Pour plus d’informations, consultez l’Application web redondante interzone de base hautement disponible et Créer des Applications métier pilotées par les messages avec NServiceBus et Service Bus.

Autres considérations

  • Toutes les transactions ne doivent pas passer par la file d’attente et le worker avant d’arriver au stockage. Le serveur frontal web peut gérer des opérations de lecture et d’écriture simples directement. Réservez des travailleurs pour des tâches gourmandes en ressources ou des workflows de longue durée. Si votre application n’a pas de telles tâches, vous n’avez peut-être pas besoin d’un worker.

  • Utilisez la fonctionnalité de mise à l’échelle automatique intégrée de votre plateforme de calcul pour effectuer un scale-out des instances. Si la charge suit des modèles prévisibles, utilisez la mise à l’échelle automatique basée sur la planification. Si la charge est imprévisible, utilisez la mise à l’échelle automatique basée sur les métriques.

  • Envisagez de placer l’application web et l’application Functions dans des plans App Service distincts afin qu’elles puissent être mises à l’échelle indépendamment.

  • Utilisez des plans App Service distincts pour les environnements de production et de test.

  • Utilisez des emplacements de déploiement pour gérer les déploiements pour les plans App Service. Déployez une version mise à jour sur un emplacement intermédiaire, puis échangez vers la nouvelle version. Si des problèmes se produisent, revenez à la version précédente.

  • Dernière mise à jour :