Processeur back-end pour lire la file d’attente de stockage

Voici tout ce dont vous avez besoin pour extraire en toute sécurité les messages d’une file d’attente de stockage Azure dans le cadre de la création d’une application asynchrone fiable, évolutive et extensible.

Dans mes derniers articles, j’ai parcouru création d’une file d’attente de stockage Azure et a montré comment ajouter des messages à cette file d’attente à partir d’un Interface ASP.NET Core ou TypeScript/JavaScript. Cet article explique comment créer le processeur backend qui lira les messages de cette file d’attente et les traitera.

Une option consiste à utiliser une Azure Function App ou une Logic App avec un déclencheur lié à la file d’attente de stockage pour exécuter une fonction dans Function App lorsqu’un message est ajouté à la file d’attente. Cependant, la meilleure partie de l’utilisation des Function Apps est la facilité avec laquelle ils sont configurés et gérés, principalement parce que vous abandonnez beaucoup de contrôle sur la façon dont vous traiterez un message et sur la façon dont vous gérerez le service. Vous pouvez récupérer une partie de ce contrôle en déployant votre Function App sur un App Service.

Cela dit, pour cet article, je vais créer mon processeur backend en tant que Worker Service dans un App Service. Ce choix me donne accès à plus de fonctionnalités de traitement des messages qu’avec une Function App (par exemple, consulter un message plutôt que de le lire) et à toutes les fonctionnalités d’un App Service pour gérer mon backend.

Création et sécurisation du service App

Fondamentalement, vous créez votre App Service exactement comme vous créeriez un App Service pour un Service Web principal. Pour votre App Service de développement, vous souhaiterez peut-être activer Authentification de base pour prendre en charge la configuration de votre App Service.

Après avoir créé le service, accédez au Paramètres | Configuration choix de menus. Dans la page des paramètres qui s’affiche à droite, recherchez le Toujours activé option et réglez-la sur Sur (cela augmentera vos coûts mais garantira également que votre application ne s’arrête pas parce que vous êtes resté longtemps sans voir de message). Vous devez également, pour votre App Service de développement, activer la journalisation à partir du Surveillance | Journaux App Service menu sur le côté gauche de votre App Service.

Vous voudrez également vous assurer que seuls vos processeurs back-end approuvés peuvent lire votre file d’attente. Étant donné que je crée mon processeur back-end en tant qu’application côté serveur, mon outil préféré (et la recommandation de Microsoft) consiste à utiliser un Identité managée Azure. Lorsque vous créez votre identité gérée, notez son identifiant client : vous en aurez besoin plus tard.

Toujours dans le portail, surfez jusqu’à votre File d’attente de stockagecliquez sur son Contrôle d’accès (IAM) choix de menu dans le menu en bas à gauche, et utilisez le Ajouter une attribution de rôle sur la page résultante pour donner à votre identité gérée le Contributeur au stockage de file d’attente rôle pour votre file d’attente.

Enfin, surfez jusqu’au Service d’application sur lequel vous allez déployer votre processeur backend. De la Service d’applicationc’est Paramètres | Identité choix dans le menu en bas à gauche, utilisez le Utilisateur attribué pour attribuer votre identité gérée au service.

Vous êtes maintenant prêt à créer votre processeur backend.

Création du processeur

Bien entendu, vous devez d’abord créer votre projet dans Visual Studio ou Visual Studio Code. Dans Visual Studio, vous souhaitez utiliser le modèle Worker Service ; dans Visual Studio Code, vous souhaitez utiliser cette commande pour créer votre projet.

J’ai nommé mon projet WarehouseMgmtProductsProcessor. Vous souhaiterez échanger le nom de votre propre projet :

dotnet new worker -n  WarehouseMgmtProductsProcessor

Une fois votre projet créé, vous devrez ajouter le package NuGet Azure.Storage.Queues à votre projet (si vous utilisez l’onglet Gérer les packages NuGet de Visual Studio, recherchez « files d’attente de stockage Azure »). Vous devrez également ajouter le Microsoft.Identity.Web package afin que votre processeur backend puisse obtenir l’autorisation d’accéder à la file d’attente.

Une fois votre projet créé, ouvrez le fichier Worker.cs qui est automatiquement ajouté à votre projet. La boucle à l’intérieur du ExecuteAsync La méthode s’exécutera automatiquement lorsque vous démarrerez ou arrêterez l’App Service sur lequel vous déployez votre backend. Il vous suffit d’ajouter le code pour rechercher un message et le traiter.

Accéder à la file d’attente

Avant de pouvoir lire dans la file d’attente, vous devez créer un QueueClient objet, en transmettant l’URL de votre file d’attente (enveloppée dans un Uri objet) et un objet d’identification qui autorise l’accès à la file d’attente.

Si vous utilisez une identité gérée pour fournir une autorisation (et vous devriez le faire), vous pouvez utiliser le ManagedIdentityCredential opposez-vous à autoriser votre client, comme je le fais dans le code suivant. Vous devrez réussir votre ManagedIdentityCredential l’identifiant client de l’identité gérée que vous avez créée.

Code typique dans le Worker constructeur de classe pour créer le QueueClient et le mettre dans un champ local ressemblerait à ceci :

private QueueClient qc;
public Worker(ILogger<Worker> logger)
{
    qc = new QueueClient(
   new Uri("https://warehousemgmtphv.queue.core.windows.net/updateproductinventory"),
   new ManagedIdentityCredential("ee8…-…-…-…-…be7"));

Lire dans la file d’attente

Avec le QueueClient objet créé, vous pouvez ensuite utiliser son ReadMessagesAsync méthode pour lire, par défaut, le message suivant de la file d’attente et le renvoyer enveloppé dans un Response objet : en supposant qu’un message existe dans la file d’attente. S’il n’y a aucun message dans la file d’attente, alors ReadMessagesAsync renvoie un objet Response dont la propriété Value est définie sur null.

S’il y a un message dans la file d’attente, vous pouvez récupérer la valeur du message (presque certainement la représentation JSON d’un objet) à partir du Value la propriété Body propriété. Le message sera invisible pour tout autre processeur pendant 30 secondes (en supposant qu’il y ait un autre processeur).

Il est de votre responsabilité de supprimer le message de la file d’attente soit lorsque vous avez terminé le traitement, soit lorsque vous rencontrez une erreur lors du traitement du message (si vous avez une erreur, vous devriez probablement écrire le message dans un espace « lettre morte » pour le revoir plus tard). Si vous ne trouvez pas de message, votre code doit attendre un délai raisonnable avant de réessayer.

Ce code suppose que la file d’attente contient la représentation JSON d’une classe que j’ai appelée QueueDTO:

while (!stoppingToken.IsCancellationRequested)
 {           
   Response<QueueMessage> msg = await qc.ReceiveMessageAsync();
   if (msg.Value != null)
        {
            try
            {
                QueueDTO? qDto = JsonSerializer.Deserialize<QueueDTO>(msg.Value.Body);
                
            }
            catch (Exception ex)
            {
                _logger.LogError(ex.Message, ex.InnerException);
            }
            finally
            {
                await qc.DeleteMessageAsync(msg.Value.MessageId, msg.Value.PopReceipt);
	 
            }
   }
   else
   {
      await Task.Delay(5000, stoppingToken);
   }

Vous pouvez passer un TimeSpan objet comme deuxième paramètre du ReceiveMessageAsync méthode pour modifier la durée pendant laquelle le message reste invisible pour les autres processeurs après avoir été reçu.

Si votre file d’attente va se vider pendant des périodes de temps significatives, vous souhaiterez peut-être implémenter un modèle d’attente plus sophistiqué que le « Toujours 5 secondes » que j’ai utilisé dans mon exemple de code (par exemple, si vous effectuez trois lectures sans message, prolongez la période d’attente à 30 secondes, à 20 lectures, prolongez l’attente à 60 secondes et ainsi de suite). Si vous savez quand votre candidature ne le fera pas être en cours d’exécution, vous pouvez créer une application logique récurrente pour démarrer et arrêter votre service.

Vous pouvez également avoir le ReceiveMessageAsync récupérez plusieurs messages en transmettant une valeur maximale de messages à la méthode (jusqu’à un maximum de 32 messages). Cependant, si vous souhaitez recevoir plusieurs messages, je pense qu’il est plus simple d’utiliser le ReceiveMessagesAsync méthode car elle renvoie un tableau de QueueMessage objets.

Ce code, par exemple, utilise ReceiveMessagesAsync pour récupérer jusqu’à 10 messages à la fois, puis traite chaque message avant de lire le lot suivant :

Response<QueueMessage[]> msgs = await qc.ReceiveMessagesAsync(10);
if (msg.Value != null)
{
    foreach (QueueMessage qmsg in msgs.Value)
    {
        try
           {    
               QueueDTO? qDto = JsonSerializer.Deserialize<QueueDTO>(qmsg.Body);
	…
          }
         catch { … }
         finally { … }        
    }
}                

Étant donné que chaque réception est en fait une requête HTTP distincte adressée à la file d’attente, récupérer plusieurs messages est probablement une bonne idée.

Après avoir déployé votre backend sur un App Service, vous pourrez l’arrêter et le démarrer à partir du portail Azure. Sous le capot, le portail transmet un jeton d’annulation à votre travailleur, provoquant la fin de la boucle dans laquelle vous avez placé votre code.

Vous pouvez également transmettre ce jeton à votre ReceiveMessageAsync méthode pour y mettre fin et arrêter votre Worker un peu plus rapidement. Vous ne devez cependant pas transmettre le jeton à votre DeleteMessageAsync méthode. À moins que vos messages ne soient idempotents (c’est-à-dire que traiter deux fois le même message ne posera pas de problème), vous souhaitez que les messages lus et traités soient supprimés.

Déployer et tester votre application

Vous pouvez déployer votre backend Worker sur votre App Service en tant que service déclenché ou continu (ces deux options s’affichent sous des emplacements différents dans votre App Service : vous pouvez déployer sur les deux).

Un Worker continu sera démarré automatiquement après le déploiement tandis qu’un Worker déclenché doit être démarré manuellement. À des fins de test et de débogage, vous devez déployer en tant que service déclenché, ce qui vous permettra, par exemple, de charger des données de test dans votre file d’attente avant de démarrer votre backend. En production, vous souhaiterez peut-être passer au continu.

Studio visuel

Pour déployer à partir de Visual Studio, à partir du Construire menu, sélectionnez Publier la sélection pour ouvrir un onglet Publier pour votre projet. Cliquez sur le Ajouter un profil de publication lien pour démarrer un assistant de création de votre profil.

Vous le constaterez après avoir sélectionné Azuré en tant que cible, vous avez le choix de choisir les WebJobs appropriés (soit Azure WebJobs (Windows) ou Azure WebJobs (Linux)) plutôt que les choix App Services auxquels vous êtes peut-être habitué. Choisissez simplement la catégorie qui correspond à la plate-forme que vous avez utilisée pour votre App Service (par exemple, Azure WebJobs (Windows) si vous avez créé un App Service basé sur Windows) et vous serez redirigé vers une liste d’App Services. Sélectionnez l’App Service sur lequel vous souhaitez déployer votre backend et terminez la création de votre profil.

Lorsque votre profil de publication complété s’affiche, cliquez sur son lien « Afficher tous les paramètres » pour afficher le Paramètres du profil dialogue. Sur cette boîte de dialogue, vous verrez un Type de tâche Web liste déroulante qui vous permettra de choisir entre déployer votre application dans l’emplacement Continu ou Déclenché du service. Pour les tests et le développement, le mieux est de sélectionner Déclenché.

Une fois votre profil configuré, fermez la boîte de dialogue Paramètres du profil en cliquant sur le bouton Sauvegarder et, de retour dans votre profil, cliquez sur le bouton Publier pour déployer votre backend sur son App Service.

Si vous souhaitez publier la version de production de votre backend en continu, plutôt que déclenchée, votre meilleur choix est de créer un deuxième profil de publication (appelez-le quelque chose d’intelligent, comme « Publier sur Prod ») et de définir son type de tâche Web sur Continu.

Code de Visual Studio

Pour déployer votre application à partir de Visual Studio Code, vous devez d’abord créer un package de publication à l’aide de publication dotnet. Une fois ce package de publication créé (et en supposant que vous avez ajouté les extensions Azure à votre copie de Visual Studio Code), vous pouvez ouvrir le package de publication de Visual Studio Code. Extensions Azure panneau, cliquez avec le bouton droit sur l’App Service sur lequel vous souhaitez déployer et sélectionnez Déployer maintenant. Cela ouvrira une boîte de dialogue de navigateur de fichiers dans Visual Studio Code : parcourez le dossier bin du projet jusqu’à ce que vous trouviez le dossier de publication et sélectionnez ce dossier.

Il vous sera ensuite demandé de resélectionner votre App Service et, après cela, votre backend sera déployé (il vous sera également demandé si vous souhaitez toujours déployer votre projet sur cet App Service. Choisissez l’option : cela vous fera gagner du temps plus tard).

Par défaut, votre backend sera déployé sur votre App Service Déclenché slot qui correspond à ce que vous souhaitez pour les tests et le développement. Pour basculer votre déploiement en continu, ouvrez les propriétés/PublishProfiles/ de votre projet.<project name>-Fichier WebDeploy.pubxml et, dans ce fichier, définissez le <WebJobType> élément en Continu.

Tester votre back-end

Pour tester votre backend, dans le portail Azure, accédez à votre App Service et, dans le menu en bas à gauche, sélectionnez l’option Paramètres | Emplois Web choix de menu pour afficher les emplacements déclenchés/continus où vous avez déployé des applications. Pour exécuter un backend dans l’emplacement Déclenché, cliquez sur le bouton icône d’exécution dans le Courir colonne près de l’extrémité droite de l’emplacement.

En supposant que vous avez activé la journalisation pour votre App Service, vous pouvez afficher tous les messages de journal générés par votre application en cliquant sur l’icône icône du presse-papiers dans le Journaux colonne de la fente.

Vous pouvez arrêter votre backend en cliquant sur le bouton Rafraîchir dans le menu en haut de la liste des emplacements, puis en cliquant sur le bouton icône d’arrêt dans le Courir colonne.

Prochaines étapes

En plus de recevoir et de supprimer des messages, vous pouvez également mettre à jour un message, en modifiant soit son corps, soit la durée pendant laquelle le message sera invisible après sa réception, puis laisser le message dans la file d’attente. Le PeekMessage la méthode est une alternative à la ReceiveMessageAsync méthode. PeekMessage vous permet de récupérer un message sans le rendant invisible à tout autre processeur.

Ces options peuvent être utiles si vous disposez de plusieurs processeurs, chacun effectuant un traitement différent pour les messages dans la file d’attente. Puisque chacun des processeurs doit voir chaque message, vous pouvez utiliser PeekMessage pour lire un message et, après avoir traité le message, mettre à jour le message au lieu de le supprimer. Dans ce modèle, les messages resteraient dans la file d’attente jusqu’à ce que chaque processeur les ait traités (vous aurez besoin d’un processeur pour parcourir régulièrement la file d’attente, trouver tous les messages dont tout le traitement a été effectué et supprimer ces messages).

Si cela semble compliqué/compliqué, il pourrait être plus facile de demander à votre interface d’écrire le message dans plusieurs files d’attente, chaque file d’attente ayant son propre processeur dédié. Vous pouvez également commencer à envisager de passer à un Azure Service Bus qui prend en charge plusieurs processeurs de manière native. Je parlerai des services bus dans mon prochain article.