Partage via

Qu’est-ce qu’Azure Service Bus ?

  • Article

Azure Service Bus est un répartiteur de messages d’entreprise complètement managé, avec des files d’attente de messages et des rubriques de publication/abonnement. Service Bus est utilisé pour découpler les applications et les services les uns des autres pour offrir les avantages suivants :

  • Travail d’équilibrage de charge entre les workers concurrents
  • Routage et transfert de façon sécurisée des données et du contrôle au-delà des limites des services et des applications
  • Coordination du travail transactionnel qui nécessite un degré élevé de fiabilité

Vue d’ensemble

Les données sont transférées entre différents services et applications à l’aide de messages. Un message est un conteneur décoré de métadonnées, qui contient des données. Les données peuvent être n’importe quel type d’informations, y compris des données structurées, codées aux formats courants comme ceux-ci : JSON, XML, Apache Avro, Texte brut.

Les scénarios de messagerie courants sont :

  • Messagerie. transfert de données d’entreprise, telles que les ventes ou les bons de commande, les journaux ou les mouvements de stock.

  • Découplage d’applications : amélioration de la fiabilité et de l’extensibilité de vos applications et services. Il n’est pas nécessaire que les producteurs et les consommateurs soient en ligne ou immédiatement disponibles en même temps. La charge est nivelée de telle sorte que les pics de trafic ne surtaxent pas un service.

  • Équilibrage de charge. Possibilité pour plusieurs consommateurs concurrents de lire dans une file d’attente en même temps, chacun obtenant de façon sécurisée la propriété exclusive sur des messages spécifiques.

  • Rubriques et abonnements : Activation des relations 1:n entre les éditeurs et les abonnés, ce qui permet aux abonnés de sélectionner des messages particuliers dans un flux de messages publiés.

  • Transactions. Possibilité d’effectuer plusieurs opérations, toutes dans l’étendue d’une transaction atomique. Par exemple, les opérations suivantes peuvent être effectuées dans l’étendue d’une transaction.

    1. Obtenir un message depuis une file d’attente.
    2. Publier les résultats du traitement dans une ou plusieurs files d’attente différentes.
    3. Déplacer le message d’entrée à partir de la file d’attente d’origine.

    Pour les consommateurs en aval, les résultats ne sont visibles qu’en cas de réussite, ce qui comprend le règlement du message d’entrée autorisant la sémantique de traitement une fois seulement. Ce modèle de transaction constitue une base solide pour le modèle des transactions de compensation dans le contexte de solution supérieur.

  • Sessions de messagerie : Implémentez une coordination à grande échelle des flux de travail et des transferts multiplexés qui nécessitent un classement strict des messages ou le report des messages.

Si vous êtes familiarisé avec d’autres répartiteurs de messages, comme Apache ActiveMQ, les concepts de Service Bus sont similaires à ceux que vous connaissez. Service Bus étant une offre PaaS (Platform-as-a-service), la grande différence se situe dans les actions suivantes, dont vous n’avez pas à vous soucier. Azure s’occupe de ces tâches pour vous.

  • Inquiétude par rapport aux défaillances matérielles
  • Mise à jour des systèmes d’exploitation ou des produits
  • Placement des journaux et gestion de l’espace disque
  • Gestion des sauvegardes
  • Basculement vers une machine de réserve

Concepts

Cette section décrit les concepts de base de Service Bus.

Files d’attente

Les messages sont envoyés vers et reçus depuis les files d’attente. Les files d’attente stockent les messages jusqu’à ce que l’application réceptrice soit disponible pour recevoir et traiter ces messages.

Diagramme montrant une file d’attente Service Bus avec un expéditeur et un récepteur envoyant et recevant des messages.

Les messages dans les files d’attente sont classés et horodatés à l’arrivée. Une fois que le répartiteur a accepté le message, celui-ci est toujours conservé de manière durable dans un stockage à triple redondance, réparti entre les zones de disponibilité si l’espace de noms est compatible avec les zones. Le Service Bus conserve les messages en mémoire ou dans un stockage volatile jusqu’à ce que le client les signalent comme étant acceptés.

Les messages sont remis en mode tirage (pull) , qui remet uniquement les messages lorsqu’ils sont demandés. Contrairement au modèle busy-polling de certaines autres files d’attente cloud, l’opération de tirage peut être longue et ne se terminer qu’une fois un message disponible.

Notes

Pour comparer les files d’attente Service Bus et les files d’attente de stockage, consultez Files d’attente de stockage et files d’attente Service Bus : comparaison et différences.

Rubriques

Vous pouvez également utiliser des rubriques pour envoyer et recevoir des messages. Si une file d’attente est souvent utilisée pour la communication point à point, les rubriques sont utiles dans les scénarios de publication/abonnement.

Diagramme montrant une rubrique Service Bus avec un expéditeur et plusieurs récepteurs.

Les rubriques peuvent avoir plusieurs abonnements indépendants, qui s’attachent à la rubrique et fonctionnent exactement comme des files d’attente côté destinataire. Un abonné à une rubrique peut recevoir une copie de chaque message envoyé à cette rubrique. Les abonnements sont des entités nommées. Les abonnements sont durables par défaut, mais ils peuvent être configurés pour expirer, puis être automatiquement supprimés. Par le biais de l’API Java Message Service (JMS), Service Bus Premium vous permet également de créer des abonnements volatiles qui existent le temps de la connexion.

Vous pouvez définir des règles sur un abonnement. Une règle d’abonnement est dotée d’un filtre permettant de définir une condition afin que le message soit copié dans l’abonnement, et d’une action facultative qui peut modifier les métadonnées du message. Si vous souhaitez en savoir plus, veuillez consulter l’article Actions et filtres de rubrique. Cette fonctionnalité est utile dans les scénarios suivants :

  • Lorsqu’il n’est pas souhaitable qu’un abonnement reçoive tous les messages envoyés à une rubrique.
  • Quand il est nécessaire de marquer les messages avec des métadonnées supplémentaires lors du passage par un abonnement.

Notes

Pour plus d’informations sur les files d’attente et les rubriques, consultez Files d’attente, rubriques et abonnements Service Bus.

Espaces de noms

Un espace de noms est un conteneur pour tous les composants de messagerie (files d'attente et rubriques). Un espace de noms peut avoir une ou plusieurs files d’attente et rubriques, et sert souvent de conteneur d’application.

Un espace de noms peut être comparé à un serveur dans la terminologie d’autres répartiteurs, mais les concepts ne sont pas directement équivalents. Un espace de noms Service Bus représente votre portion de capacité propre d’un grand cluster constitué de dizaines de machines virtuelles actives. Il s’étend éventuellement sur trois zones de disponibilité Azure. Vous bénéficiez ainsi de tous les avantages de la disponibilité et de la robustesse qui sont liés à l’exécution du répartiteur de messages à très grande échelle. Qui plus est, vous n’avez pas à vous soucier des complexités sous-jacentes. Service Bus est une messagerie serverless.

Fonctionnalités avancées

Service Bus a également des fonctionnalités avancées qui vous permettent de résoudre des problèmes de messagerie plus complexes. Les sections suivantes décrivent ces fonctionnalités principales :

Sessions de message

Pour créer une garantie FIFO (premier entré, premier sorti) dans le traitement des messages des files d’attente ou des abonnements Service Bus, utilisez des sessions. Vous pouvez également utiliser les sessions pour implémenter des modèles requête-réponse. Le modèle requête-réponse permet à l’application de l’expéditeur d’envoyer une requête et fournit au destinataire le moyen de renvoyer correctement une réponse vers l’application de l’expéditeur. Pour plus d’informations, consultez les sessions de messages.

Transfert automatique

La fonctionnalité de Transfert automatique vous permet de lier une file d’attente ou un abonnement à une autre file d’attente ou rubrique qui fait partie du même espace de noms. Lorsque le transfert automatique est activé, Service Bus supprime automatiquement les messages placés dans la première file d’attente ou le premier abonnement (source) pour les placer dans la deuxième file d’attente ou rubrique (destination). Pour en savoir plus, consultez Chaînage des entités Service Bus avec transfert automatique

Lettres mortes

Les files d’attente et les abonnements aux rubriques Service Bus fournissent une sous-file d’attente secondaire, appelée file d’attente de lettres mortes. La file d’attente de lettres mortes conserve les messages qui ne peuvent pas être remis aux destinataires ou les messages qui ne peuvent pas être traités. Vous pouvez supprimer des messages depuis la DLQ et les inspecter. Il est possible qu’une application puisse, à l’aide d’un opérateur, corriger des problèmes et renvoyer le message, journaliser le fait qu’une erreur se soit produite et effectuer un action corrective. Pour en savoir plus, consultez Vue d’ensemble des files d’attente de lettres mortes Service Bus.

Remise planifiée

Cette fonctionnalité vous permet d’envoyer des messages à une file d’attente ou à une rubrique pour différer leur traitement. Par exemple, vous pouvez planifier la disponibilité d’un travail pour qu’il soit traité par un système à un moment précis. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Messages planifiés.

Report de message

Lorsqu’un client de file d’attente ou d’abonnement reçoit un message qu’il souhaite traiter, mais pour lequel le traitement n’est pas possible actuellement en raison de circonstances particulières dans l’application, l’entité peut reporter la récupération du message à plus tard. Le message est conservé dans la file d’attente ou l’abonnement, mais il est mis de côté. Si vous souhaitez en savoir plus, veuillez consulter l’article Report de message.

Transactions

Une transaction regroupe plusieurs opérations dans une étendue d’exécution. Service Bus prend en charge les opérations de regroupement par rapport à une entité de messagerie unique (file d’attente, rubrique, abonnement) dans l’étendue d’une transaction. Si vous souhaitez en savoir plus, veuillez consulter l’article Vue d’ensemble du traitement des transactions Service Bus.

Actions et filtres

Les abonnés peuvent définir les messages qu’ils veulent recevoir d’une rubrique. Ces messages sont spécifiés sous la forme d’une ou de plusieurs règles d’abonnement nommées. Chaque règle comprend une condition de filtre qui sélectionne des messages spécifiques et éventuellement une action qui annote le message sélectionné. Pour chaque condition de règle de correspondance, l’abonnement crée une copie du message, qui peut être annotée différemment selon la règle de correspondance utilisée. Si vous souhaitez en savoir plus, veuillez consulter l’article Actions et filtres de rubrique.

Suppression automatique inactive

La suppression automatique inactive vous permet de spécifier un intervalle d’inactivité après lequel la file d’attente est automatiquement supprimée. L’intervalle est réinitialisé lorsqu’un trafic existe dans la file d’attente. La durée minimale est de 5 minutes.

Détection des doublons

Si une erreur se produit et suscite un doute chez le client concernant le résultat d’une opération d’envoi, la détection des doublons lève ce type d’incertitude en permettant à l’expéditeur de renvoyer le même message, et à la file d’attente ou la rubrique d’ignorer les copies en double. Pour en savoir plus, consultez Détection des doublons.

Suppression par lot des messages

Azure Service Bus prend en charge la suppression de messages par lots. Cela est utile dans les scénarios dans lesquels les messages dans les files d’attente ou les abonnements sont arrivés à expiration, ou ne sont plus pertinents et nécessitent un nettoyage. Pour plus d’informations, consultez la section Suppression par lots.

Sécurité

Service Bus prend en charge les protocoles de sécurité tels que les Signatures d’accès partagé (SAS), le Contrôle d’accès en fonction du rôle (RBAC) (RBAC) et les Identités managées pour les ressources Azure.

Service Bus prend en charge les protocoles standard Advance Message Queueing Protocol (AMQP) 1.0 et HTTP/REST.

Géorécupération d’urgence

Lorsque les régions ou centres de données Azure subissent un temps d’arrêt, la géo-récupération d’urgence permet au traitement des données de continuer à fonctionner dans un autre centre de données ou région.

Notes

Pour plus d’informations sur ces fonctionnalités, consultez Fonctionnalités avancées d’Azure Service Bus.

Conformité avec les normes et les protocoles

Le protocole filaire principal de Service Bus est AMQP (Advanced Messaging Queueing Protocol) 1.0, une norme ISO/IEC ouverte. Il permet aux clients d’écrire des applications qui fonctionnent sur Service Bus et sur des répartiteurs locaux, tels que ActiveMQ ou RabbitMQ. Le Guide du protocole AMQP fournit des informations détaillées au cas où vous souhaiteriez élaborer une telle abstraction.

Service Bus Premium est entièrement compatible avec l’API Java Message Service (JMS) 2.0 de Java/Jakarta EE. De plus, Service Bus standard prend en charge le sous-ensemble JMS 1.1 axé sur les files d’attente. JMS est une abstraction courante pour les répartiteurs de messages, elle s’intègre à de nombreuses applications et frameworks, y compris le populaire framework Spring. Pour passer d’un autre répartiteur à Azure Service Bus, il vous suffit de recréer la topologie des files d’attente et des rubriques, puis de modifier les dépendances et la configuration du fournisseur client. Pour consulter un exemple, reportez-vous au Guide de migration d’ActiveMQ.

Bibliothèques clientes

Les bibliothèques de client Service Bus entièrement prises en charge sont disponibles par le biais du kit SDK Azure.

Le protocole principal d’Azure Service Bus est AMQP 1.0 ; il est utilisable depuis n’importe quel client de protocole compatible AMQP 1.0. Quelques clients AMQP open source offrent des exemples illustrant de manière explicite l’interopérabilité de Service Bus. Consultez le Guide du protocole AMQP 1.0 pour comprendre comment utiliser les fonctionnalités Service Bus directement avec les clients AMQP 1.0.

Langage Bibliothèque
Java Apache Qpid Proton-J
C/C++ Azure uAMQP C, Apache Qpid Proton-C
Python Azure uAMQP pour Python, Apache Qpid Proton Python)
PHP Azure uAMQP pour PHP
Ruby Apache Qpid Proton Ruby
Go Azure Go AMQP, Apache Qpid Proton Go
C#/F#/VB AMQP .NET Lite, Apache NMS AMQP
JavaScript/Node Rhea

Intégration

Service Bus s’intègre entièrement à de nombreux services Microsoft et Azure, par exemple :

Étapes suivantes

Pour commencer à utiliser la messagerie Service Bus, consultez les articles suivants :