Choisir une remise de messages avec files d’attente

Effectué

Supposons que vous planifiez l’architecture de votre application de partage de musique. Vous voulez vous assurer que les fichiers de musique sont chargés sur l’API web de manière fiable à partir de l’application mobile. Vous souhaitez ensuite indiquer directement dans l’application les informations relatives aux nouveaux morceaux lorsqu’un artiste ajoute de la musique à sa collection. Ce scénario constitue une utilisation parfaite d’un système basé sur des messages. Azure propose deux solutions à ce problème :

  • Stockage File d’attente Azure
  • Azure Service Bus

Qu’est-ce que Stockage File d’attente Azure ?

Stockage File d’attente est un service qui utilise Stockage Azure pour stocker de nombreux messages accessibles de façon sécurisée à partir de n’importe où dans le monde à l’aide d’une simple interface basée sur REST. Les files d’attente peuvent contenir des millions de messages, la limite étant la capacité du compte de stockage auquel elles sont rattachées.

Présentation des files d’attente Azure Service Bus

Service Bus est un système de répartiteur de messages destiné aux applications d’entreprise. Souvent, ces applications utilisent plusieurs protocoles de communication, ont des contrats de données différents et des exigences de sécurité plus élevées et peuvent inclure des services cloud et locaux. Service Bus repose sur une infrastructure de messagerie dédiée conçue exactement pour ces scénarios.

Ces deux services sont basés sur l’idée d’une file d’attente, qui conserve les messages envoyés jusqu’à ce que la cible soit prête à les recevoir.

Présentation des rubriques Azure Service Bus

Les rubriques Service Bus Azure sont comme des files d’attente, mais elles peuvent avoir plusieurs abonnés. Lorsqu’un message est envoyé à une rubrique au lieu d’une file d’attente, plusieurs composants peuvent être déclenchés pour faire leur travail. Imaginez qu’un utilisateur écoute une chanson dans une application de partage de musique. L’application mobile peut envoyer un message à la rubrique « Écoutée ». Cette rubrique aura un abonnement à « UpdateUserListenHistory » et un autre abonnement à « UpdateArtistsFanList ». Chacune de ces fonctions est gérée par un autre composant qui reçoit sa propre copie du message.

En interne, les rubriques utilisent des files d’attente. Lorsque vous publiez une rubrique, le message est copié et déposé dans la file d’attente pour chaque abonnement. La file d’attente signifie que la copie du message reste là pour être traitée par chaque branche de l’abonnement même si le composant de traitement de cet abonnement est trop occupé pour suivre le rythme.

Avantages des files d’attente

Les infrastructures de file d’attente peuvent prendre en charge de nombreuses fonctionnalités avancées qui les rendent utiles à différents égards :

Accroissement de la fiabilité

Les files d’attente sont utilisées par les applications distribuées en tant qu’emplacements de stockage temporaire pour la remise des messages en attente à un composant de destination. Le composant source peut ajouter un message à la file d’attente, que les composants de destination peuvent récupérer au début de la file d’attente en vue de le traiter. Les files d’attente augmentent la fiabilité de l’échange de messages, car, en cas de forte demande, les messages peuvent attendre qu’un composant de destination soit prêt à les traiter.

Garanties de remise des messages

Les systèmes de mise en file d’attente garantissent généralement la remise des messages en file d’attente à un composant de destination. Toutefois, ces garanties peuvent prendre différentes approches :

  • Au minimum une remise : cette approche garantit la remise de chaque message à au moins un des composants qui récupèrent les messages de la file d’attente. Notez cependant que dans certaines circonstances, il peut arriver qu’un même message soit délivré plusieurs fois. Par exemple, si deux instances d’une application web extraient des messages d’une file d’attente, chaque message n’aboutit habituellement qu’à une seule de ces instances. Toutefois, si une instance met beaucoup de temps à traiter le message, à l’expiration d’un délai d’attente déterminé, le message peut être également envoyé à l’autre instance. Vous devez concevoir le code de votre application web en ayant cela à l’esprit.

  • Une livraison au maximum : dans cette approche, la livraison de chaque message n’est pas garantie et il y a un petit risque qu’elle ne se produise pas. Cependant, à la différence de l’option Au minimum une remise, il est totalement impossible que le message soit remis deux fois. Cette approche est parfois appelée détection automatique des doublons.

  • Premier entré, premier sorti (FIFO) : dans la plupart des systèmes de messagerie, les messages quittent la file d’attente dans l’ordre dans lequel ils y ont été ajoutés. Il convient cependant d’examiner si cette remise est garantie. Si votre application distribuée nécessite que les messages soient traités dans cet ordre précis, vous devez choisir un système de file d’attente incluant une garantie FIFO.

Prise en charge transactionnelle

Certains groupes de messages étroitement liés peuvent occasionner des problèmes en cas d’échec de livraison d’un message du groupe.

Imaginez, par exemple, une application d’e-commerce. Quand l’utilisateur sélectionne le bouton Acheter, une série de messages peut être générée et envoyée à différentes destinations de traitement :

  • Un message avec les détails de la commande est envoyé à un centre de traitement des commandes.
  • Un message avec le montant total et les détails du paiement est envoyé à un processeur de carte de crédit
  • Un message avec les informations de réception est envoyé à une base de données afin que soit générée une facture pour le client.

Dans ce cas, nous voulons que tous les messages soient traités, ou aucun. Nous finirons par mettre la clé sous la porte si les messages des cartes de crédit ne sont pas délivrés et que toutes les commandes sont traitées sans paiement ! Vous pouvez éviter des problèmes de ce type en regroupant les deux messages au sein d’une transaction. Les transactions de messages réussissent ou échouent en tant qu’unité unique, tout comme dans le monde des bases de données. En cas d’échec de la remise du message contenant les informations de la carte de crédit, la remise de celui des détails de la commande échoue également.

Quel service dois-je choisir ?

Ayant compris que la stratégie de communication pour cette architecture doit être un message, vous devez choisir entre l’utilisation de files d’attente de Stockage Azure et d’Azure Service Bus. Vous pouvez utiliser les deux technologies pour stocker et livrer des messages entre vos composants. Chaque technologie a un ensemble de fonctionnalités légèrement différent, ce qui signifie que vous pouvez choisir l’une ou l’autre, ou utiliser les deux, selon le problème à résoudre.

Cas dans lesquels les files d’attente Service Bus sont préconisées

  • Vous avez besoin d’une garantie Au maximum une remise.
  • Vous avez besoin d’une garantie FIFO.
  • Vous avez besoin de regrouper les messages dans des transactions.
  • Vous souhaitez recevoir les messages sans interroger la file d’attente.
  • Vous devez fournir un modèle d’accès en fonction du rôle aux files d’attente.
  • Vous devez gérer des messages dont la taille est comprise entre 64 Ko et 100 Mo. La taille maximale des messages prise en charge est de 256 Ko pour le niveau standard et de 100 Mo pour le niveau premium.
  • La taille de la file d’attente ne pourra pas dépasser 1 To. La taille maximale de file d’attente est de 80 Ko pour le niveau standard et de 1 To pour le niveau premium.
  • Vous souhaitez publier et consommer des lots de messages.

Cas dans lesquels les rubriques Service Bus sont préconisées

  • Besoin de toutes les fonctionnalités fournies par les files d’attente Service Bus, en plus d’implémenter un modèle pub-sub où les messages peuvent être acheminés vers l’un de plusieurs abonnements, chacun avec ses propres récepteurs indépendants

Le Stockage File d’attente n’est pas aussi riche en fonctionnalités, mais peut représenter un choix plus simple si elles ne vous sont pas nécessaires. En outre, il constitue la meilleure solution si votre application a l’une des exigences suivantes.

Cas dans lesquels le Stockage File d’attente est préconisé

  • Vous avez besoin d’une piste d’audit de tous les messages qui passent par la file d’attente.
  • Vous pensez que la taille de la file d’attente va dépasser 1 To.
  • Vous souhaitez suivre la progression du traitement d’un message dans la file d’attente.

Une file d’attente est un simple emplacement de stockage temporaire pour les messages échangés entre les composants d’une application distribuée. Utilisez une file d’attente pour organiser les messages et gérer correctement des pics de demande imprévisibles.

Utilisez des files d’attente de stockage quand vous souhaitez un système de file d’attente simple et facile à coder. Pour des besoins plus avancés, utilisez des files d’attente Service Bus. Si vous avez plusieurs destinations pour un seul message, mais que vous avez besoin d’un comportement de type file d’attente, utilisez des rubriques Service Bus.