Partager via

Style d’architecture Web-Queue-Worker

Les principaux composants de cette architecture sont un front-end web qui gère les demandes clientes et un worker qui 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.

Les composants suivants sont généralement incorporés dans cette architecture :

  • 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 web et le worker sont à la fois sans état et l’état de session peut être stocké dans un cache distribué. Le travailleur gère les tâches de longue durée de manière asynchrone. Les messages de la file d'attente peuvent démarrer le worker, ou une tâche planifiée peut l'exécuter 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 appels AJAX, ou une application cliente native peut y accéder directement.

Quand utiliser cette architecture

L’architecture web-Queue-Worker est généralement implémentée à l’aide de services de calcul managés comme Azure App Service ou Azure Kubernetes Service.

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 et facile à suivre

  • Déploiement et gestion avec un effort minimal

  • Séparation claire des responsabilités

  • Découplage de l'interface utilisateur et du processus de travail par le biais d'une messagerie asynchrone

  • Mise à l’échelle indépendante de l'interface utilisateur et des processus

Défis

  • Sans conception minutieuse, le front-end et le worker peuvent devenir de grands composants monolithiques difficiles à gérer et à mettre à jour.

  • Si le serveur frontal et le worker partagent des schémas de données ou des modules de code, il peut y avoir des dépendances masquées.

  • Le serveur frontal web peut échouer après avoir conservé la base de données, mais avant d’envoyer des messages à la file d’attente, ce qui provoque des problèmes de cohérence, car le worker ne fait pas sa partie de la logique. Pour atténuer ce problème, vous pouvez utiliser des techniques telles que le modèle de boîte de sortie transactionnelle, qui nécessitent le routage des messages sortants pour revenir d'abord dans une file d’attente distincte. La bibliothèque de session transactionnelle NServiceBus prend en charge cette technique.

Meilleures pratiques

Le Web-Queue-Worker sur l'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

  • L'interface est implémentée en tant qu'application web App Service, et le worker est implémenté en tant qu'application Azure Functions. L’application web et l’application Functions sont associées à un plan App Service qui fournit les instances de machine virtuelle.

  • Vous pouvez utiliser soit Azure Service Bus soit Azure Storage queues pour la file d’attente de messages. Le diagramme précédent utilise une file d’attente de stockage.

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

  • Azure Content Delivery Network est utilisé pour mettre en cache du contenu statique comme des images, CSS ou HTML.

  • Pour le stockage, choisissez les technologies qui conviennent le mieux aux besoins de votre application. Cette approche, appelée persistance polyglotte, utilise plusieurs technologies de stockage dans le même système pour répondre à différentes exigences. Pour illustrer cette idée, le diagramme montre Azure SQL Database et Azure Cosmos DB.

Pour plus d’informations, consultez l’application web redondante interzone hautement disponible de référence et Créez des applications métier basées sur des messages avec NServiceBus et Service Bus.

Autres considérations

  • Toutes les transactions ne sont pas obligées de passer par la file d'attente et le processus de traitement pour le stockage. Le serveur frontal web peut effectuer des opérations de lecture et d’écriture simples directement. Les workers sont conçus pour des tâches gourmandes en ressources ou des flux de travail de longue durée. Dans certains cas, vous n’avez peut-être pas besoin d’un travailleur du tout.

  • Utilisez la fonctionnalité de mise à l’échelle automatique intégrée de votre plateforme de calcul pour effectuer un scale-out du nombre d’instances. Si la charge sur l’application 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’ils puissent être mis à l’échelle indépendamment.

  • Utilisez des plans App Service distincts pour la production et les tests.

  • 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 intermédiaire, puis de basculer vers la nouvelle version. Il vous permet également de revenir à la version précédente en cas de problème pendant la mise à jour.

  • Last updated on