Introduction
Les files d’attente de messages et les rubriques de publication-abonnement sont des fonctionnalités du courtier de messages d’entreprise entièrement géré Azure Service Bus (dans un espace de noms). Les avantages suivants sont disponibles lors de l’utilisation de Service Bus pour découpler les applications et les services les uns des autres :
- Répartition des tâches entre les employés rivaux.
- Échange de données et de contrôle au-delà des frontières des services et des applications de manière sécurisée.
- Coordonner un travail transactionnel nécessitant un haut degré de fiabilité.
Présentation du service de bus Azure de Microsoft
Les messages sont utilisés pour déplacer des données entre diverses applications et services. Un message est un conteneur rempli de données contenant des métadonnées. Tout type d’informations peut être utilisé comme données, y compris les données structurées stockées dans des formats populaires tels que JSON, XML, Apache Avro et le texte brut.
Les situations de message typiques incluent :
Messagerie.
Transférez des informations sur la société, telles que des journaux, des mouvements de stock ou des commandes de vente ou d’achat.
Découpler les applications
Les applications et les services doivent être plus évolutifs et fiables. Il n’est pas nécessaire que les producteurs et les consommateurs soient en ligne ou disponibles en même temps. La charge est nivelée de sorte que les pics de trafic ne surchargent pas un service.
L’équilibrage de charge
Permettre à de nombreux consommateurs simultanés de revendiquer en toute sécurité la propriété exclusive de messages individuels lors de la lecture à partir d’une file d’attente.
Sujets et abonnements
L’activation des relations 1:n entre les éditeurs et les abonnés permettra aux abonnés de sélectionner des messages à partir d’un flux de messages publié.
Les transactions vous permettent d’effectuer de nombreuses opérations dans le contexte d’une seule transaction atomique. Par exemple, les opérations suivantes peuvent être effectuées à l’intérieur des paramètres d’une transaction.
- Les messages d’une file d’attente doivent être obtenus.
- Les résultats du traitement doivent être publiés dans une ou plusieurs files d’attente.
- Le message d’entrée doit être déplacé de la file d’attente d’origine.
Ce n’est qu’en cas de succès, y compris le règlement réussi du message d’entrée, que les résultats deviennent apparents pour les consommateurs en aval, permettant une sémantique de traitement unique. Le modèle de transaction compensatoire dans le contexte de solution plus large a une base solide dans ce modèle de transaction.
Séances de messages
Mettez en œuvre une coordination de processus de haut niveau et des transferts multiplexés qui nécessitent un report de messages ou un ordre de messages strict.
Les idées du Service Bus sont comparables à celles d’autres courtiers de messages, tels qu’Apache ActiveMQ. Une distinction importante est que, comme Service Bus est une solution de plate-forme en tant que service (PaaS), vous n’avez pas à vous soucier d’effectuer les tâches suivantes. Azure gère ces courses pour vous.
- Préoccupé par les dysfonctionnements matériels
- Maintien des correctifs des produits ou des systèmes d’exploitation
- Gestion de l’espace disque et ajout de journaux
- Gérer une sauvegarde
- Passer à une machine de sauvegarde
Queues
Les files d’attente sont utilisées à la fois pour envoyer et recevoir des messages. Les messages sont conservés dans des files d’attente jusqu’à ce que l’application réceptrice soit prête à les accepter et à les traiter.
A leur arrivée, les messages dans les files d’attente sont triés et horodatés. Si l’espace de noms est activé pour la zone, le message est toujours conservé durablement dans un stockage à triple redondance après avoir été accepté par le courtier. Jusqu’à ce qu’un client signale un message comme accepté, Service Bus le conserve en mémoire ou dans un autre stockage volatile.
La livraison des messages en mode pull envoie uniquement des messages en réponse aux demandes. Contrairement aux modèles d’interrogation occupée de certaines autres files d’attente cloud, l’opération d’extraction peut prendre beaucoup de temps et n’est terminée que lorsqu’un message est prêt.
Les sujets
Les sujets peuvent également être utilisés pour envoyer et recevoir des messages. Pour la communication point à point, une file d’attente est fréquemment utilisée. Cependant, les rubriques sont utiles dans les applications de publication/abonnement.
Plusieurs abonnements indépendants sont possibles pour les sujets. Ces abonnements sont attachés au sujet et fonctionnent autrement exactement comme des files d’attente du côté récepteur. Chaque message envoyé à un sujet peut être copié et envoyé à un abonné de ce sujet. Les entités nommées sont des abonnements. Bien que les abonnements soient conçus pour durer indéfiniment, ils peuvent être configurés pour expirer puis être supprimés automatiquement. Vous pouvez également créer des abonnements volatils avec Service Bus Premium à l’aide de l’API Java Message Service (JMS), qui n’est active que lorsque la connexion est active.
Sur un abonnement, des règles peuvent être définies. Un filtre pour spécifier les conditions préalables à la copie d’un message dans l’abonnement et une action facultative pour modifier les informations du message sont tous deux inclus dans une règle d’abonnement. Voir Filtres thématiques et actions pour plus de détails. Les situations suivantes nécessitent l’utilisation de cette fonctionnalité :
- Un abonnement ne doit pas être configuré pour recevoir tous les messages publiés sur un sujet.
- Lorsque les messages passent par un abonnement, vous souhaitez les marquer avec des métadonnées supplémentaires.
Espaces de noms
Tous les composants de messagerie sont contenus dans des espaces de noms (files d’attente et rubriques). Un espace de noms peut contenir de nombreuses files d’attente et rubriques ; ainsi, les espaces de noms agissent fréquemment comme des conteneurs pour les applications.
Un espace de noms peut être comparé à un serveur dans la terminologie d’autres courtiers, mais les concepts ne sont pas directement équivalents. Un espace de noms Service Bus est votre propre tranche de capacité d’un grand cluster composé de dizaines de machines virtuelles entièrement actives. Il peut éventuellement s’étendre sur trois zones de disponibilité Azure. Ainsi, vous bénéficiez de tous les avantages de disponibilité et de robustesse de l’exécution du courtier de messages à grande échelle. Et vous n’avez pas à vous soucier des complexités sous-jacentes. Service Bus est une messagerie sans serveur.
Fonctionnalités avancées
De plus, Service Bus inclut des fonctionnalités sophistiquées qui vous permettent de gérer des problèmes de messagerie plus délicats. Ces principales caractéristiques sont expliquées dans les sections ci-dessous :
Séances de messages
Utilisez des sessions pour implémenter une garantie premier entré, premier sorti (FIFO) dans Service Bus. La gestion combinée et organisée de séquences illimitées de messages liés est rendue possible par les sessions de messages.
Transfert automatique
Vous pouvez enchaîner une file d’attente ou un abonnement à une autre file d’attente ou rubrique faisant partie du même espace de noms à l’aide de la fonctionnalité de transfert automatique. Lorsque le transfert automatique est activé, Service Bus déplace automatiquement les messages du premier abonnement (source) ou file d’attente (rubrique) vers la deuxième file d’attente (rubrique) (destination).
Lettres mortes
Les files d’attente de lettres mortes (DLQ) sont prises en charge par Service Bus et sont utilisées pour stocker les messages qui ne peuvent être traités ou remis à aucun destinataire. Après cela, vous pouvez examiner et supprimer des messages du DLQ.
Livraison planifiée
Pour un traitement ultérieur, vous pouvez ajouter des messages à une file d’attente ou à un sujet. Pour planifier une tâche, par exemple, afin qu’elle devienne accessible pour traitement par un système à un moment précis.
Report de messages
Lorsqu’un client de file d’attente ou d’abonnement reçoit un message qu’il souhaite traiter mais qu’il ne peut pas traiter actuellement en raison de conditions uniques dans l’application, l’entité peut reporter la récupération du message à une date ultérieure. Le message est mis de côté mais reste dans la file d’attente ou l’abonnement.
Transactions
Une transaction crée une étendue d’exécution en combinant deux ou plusieurs opérations. Dans le contexte d’une transaction, Service Bus prend en charge les opérations de regroupement sur une seule entité de messagerie (file d’attente, rubrique ou abonnement).
Filtrage et actions
Les abonnés peuvent spécifier les messages d’un sujet qu’ils souhaitent recevoir. Sous la forme d’une ou plusieurs règles d’abonnement nommées, ces messages sont décrits. L’abonnement génère une copie du message sous chaque condition de règle de correspondance, qui peut être annotée différemment pour chaque règle de correspondance.
Suppression automatique en cas d’inactivité
Vous pouvez définir un intervalle d’inactivité avec « suppression automatique en cas d’inactivité », après quoi la file d’attente sera automatiquement effacée. Lorsqu’il y a une activité dans la file d’attente, l’intervalle est réinitialisé. Cinq minutes, c’est le strict minimum.
Détection des doublons
Les détections multiples éliminent l’incertitude dans ces cas en permettant à l’expéditeur de transmettre à nouveau le même message, et la file d’attente ou le sujet supprime toutes les copies en double si une erreur se produit qui laisse le client incertain quant au résultat d’une opération d’envoi.
Signature d’accès partagé (SAS), contrôle d’accès basé sur les rôles et identités gérées
Pour les ressources Azure, Service Bus fournit des protocoles de sécurité tels que les identités managées, le contrôle d’accès basé sur les rôles et les signatures d’accès partagé (SAS).
Récupération géo-catastrophe
La reprise après sinistre géographique permet au traitement des données de se poursuivre dans une autre région Azure ou un autre centre de données lorsque ces régions ou centres de données tombent en panne.
Sécurité
Les protocoles standard HTTP/REST et Advanced Message Queuing Protocol (AMQP) 1.0 sont pris en charge par Service Bus.
Conformité aux normes et protocoles
Advanced Messaging Queuing Protocol (AMQP) 1.0, une norme ISO/IEC ouverte, est le principal protocole filaire pour Service Bus. Les clients peuvent l’utiliser pour créer des programmes qui interagissent avec le Service Bus et les courtiers installés localement comme ActiveMQ ou RabbitMQ. Si vous souhaitez construire une telle abstraction, le guide du protocole AMQP offre des conseils complets.
L’API Java Message Service (JMS) 2.0 pour Java/Jakarta EE est entièrement compatible avec Service Bus Premium. Le sous-ensemble axé sur la file d’attente de JMS 1.1 est également pris en charge par Service Bus Standard. JMS est une abstraction de courtier de messages typique qui fonctionne avec un large éventail de programmes et de frameworks, y compris le framework Spring bien connu. Il vous suffit de reconfigurer la file d’attente et la structure des rubriques, de mettre à jour les dépendances du fournisseur client et de configurer Azure Service Bus pour remplacer les autres courtiers. Voir le guide de migration ActiveMQ pour une illustration.
Bibliothèques clientes
Le SDK Azure propose des bibliothèques client Service Bus entièrement prises en charge.
- Bus de services Azure .NET
- Bibliothèques pour Azure Service Bus en Java
- Fournisseur Java JMS 2.0 pour Azure Service Bus
- Modules pour JavaScript et TypeScript dans Azure Service Bus
- Bibliothèques Microsoft Azure Service Bus
Tout client de protocole compatible AMQP 1.0 peut utiliser le protocole principal d’Azure Service Bus, AMQP 1.0. Il existe des exemples disponibles pour plusieurs clients AMQP open source qui montrent spécifiquement la compatibilité de Service Bus. Pour apprendre à utiliser directement les fonctionnalités de Service Bus avec AMQP 1.0…