Qu’est-ce que RabbitMQ ?
Dans n’importe quelle application native cloud, les microservices doivent communiquer afin d’obtenir toutes les informations dont ils ont besoin pour répondre aux utilisateurs. Vous devez vérifier que cette messagerie est robuste même en cas de problèmes réseau ou d’échecs entre les composants. RabbitMQ est un outil que vous pouvez utiliser pour augmenter la fiabilité de la messagerie.
Chez votre détaillant de vêtements d’extérieur, vous progressez rapidement avec vos microservices. Toutefois, dans les tests d’application, certains appels d’un microservice à un autre semblent être perdus. Vous voulez vérifier que ce problème ne se produit pas dans votre environnement de production où la réputation de votre entreprise est en jeu.
Dans cette unité, vous voyez comment RabbitMQ peut créer une plateforme de communication flexible et résiliente pour les microservices.
Pourquoi utiliser un répartiteur de messages dans une application native cloud ?
Les applications natives cloud se composent de microservices indépendants, souvent créés par des équipes distinctes, et utilisant différentes technologies et langages. Chaque équipe a ses propres sprints de développement et planifications de mise à niveau, et peut déployer des correctifs et des nouvelles fonctionnalités en continu. Toutefois, quand un utilisateur envoie une demande, le microservice qui la reçoit doit presque toujours appeler d’autres microservices et services sous-jacents, et recevoir des réponses de leur part, pour formuler la réponse complète.
De toute évidence, le format et le schéma de ces demandes et réponses interservices doivent être convenus entre les équipes de développement et changent rarement. Ils sont généralement implémentés en tant qu’API REST. Vous devez implémenter de préférence les nouvelles fonctionnalités de chaque interface sans modifier les méthodes et paramètres existants. Toutefois, si vous choisissez de faire en sorte que les microservices communiquent directement, plusieurs problèmes peuvent survenir :
- Quand un microservice de destination est hors connexion ou occupé, que se passe-t-il pour les messages qui lui sont envoyés ? Quelles sont les conséquences de la perte de messages ?
- Comment envoyer le même message à plusieurs destinations ?
- Si un microservice s’exécute sur plusieurs conteneurs, auquel devez-vous envoyer les messages ?
Un répartiteur de messages est un intergiciel qui résout ces problèmes. Les services envoient des messages au répartiteur de messages au lieu de choisir directement une destination. Le répartiteur les stocke dans des files d’attente dans l’ordre d’arrivée. Les services de destination s’abonnent à ces files d’attente et récupèrent les messages, un par un, pour les traiter.
Si le service de destination n’est pas disponible, le microservice d’envoi peut toujours placer les messages dans la file d’attente. Quand la destination redémarre, elle continue de récupérer des messages de la file d’attente, à partir du même point. Aucun message n’est perdu, même si l’expéditeur doit attendre plus longtemps.
Comme plusieurs destinations peuvent s’abonner à une file d’attente, un même message peut être reçu par plusieurs microservices. Par ailleurs, quand plusieurs conteneurs hébergent des instances d’un même microservice, la première instance disponible récupère le message. Le répartiteur distribue automatiquement les messages aux instances pour répartir la charge.
Qu’est-ce que RabbitMQ ?
RabbitMQ est un des répartiteurs de messages les plus populaires et ses nombreuses fonctionnalités en font un candidat idéal pour gérer les communications dans une application native cloud. Il inclut :
- Le serveur RabbitMQ, qui héberge les files d’attente. Le serveur prend en charge le clustering et le basculement pour la haute disponibilité, et peut s’exécuter dans des conteneurs.
- Implémentations du protocole AMQP (Advanced Message Queuing Protocol), du protocole STOMP (Text Oriented Message Protocol) simple et du transport MQTT (Message Queue Telemetry Transport).
- Bibliothèques de client AMQP que vous pouvez utiliser dans .NET, Java et Erlang.
Concepts RabbitMQ
Dans la terminologie RabbitMQ, vos microservices, qui envoient et reçoivent des messages, sont des clients. Les clients qui envoient des messages sont appelés producteurs de messages. Les clients qui reçoivent des messages sont des consommateurs de messages. Le service RabbitMQ est le répartiteur de messages.
Comment envoyer des messages
RabbitMQ est polyvalent et capable d’implémenter de nombreux modèles différents de mise en file d’attente. Examinons quelques modèles connus.
Si vous avez un seul producteur et un seul consommateur, vous utilisez une seule file d’attente et tous les messages atteignent la même destination. Même dans cette configuration simple, vous créez un système de messagerie robuste qui gère les pannes de manière fluide :
Envoi de messages à des consommateurs concurrents
Dans le modèle de consommateurs concurrents, un producteur envoie des messages à une seule file d’attente de travail. Au moins deux consommateurs récupèrent les messages de la file d’attente. Les consommateurs sont en concurrence pour récupérer les messages, car chaque message peut être récupéré seulement par un seul consommateur.
Ce modèle est utile dans les applications natives cloud quand vous avez un microservice de consommation hébergé sur plusieurs conteneurs pour améliorer la capacité. Comme chaque message atteint une seule instance du consommateur, il est traité une seule fois. Le travail n’est pas dupliqué.
Publication et abonnement
Si vous voulez envoyer un seul message d’un producteur à plusieurs consommateurs, utilisez le modèle publication/abonnement. Le producteur envoie des messages à un échangeur. Chaque consommateur s’abonne aux messages de cet échangeur. Quand ils s’abonnent, RabbitMQ crée une file d’attente de travail pour cet abonnement. Chaque message est copié dans chaque file d’attente de cet échangeur et reçu par chaque consommateur abonné. Les consommateurs ne sont pas en concurrence pour chaque message. À la place, ils reçoivent tous une copie de chaque message.
Le modèle publication/abonnement utilise un échangeur de répartition, qui copie chaque message dans chaque file d’attente de travail.
Ce modèle est utile si vous voulez que chaque message soit traité par plusieurs microservices. Par exemple, quand un client valide un panier, vous pouvez envoyer un message concernant la quantité de chaque produit qu’il a acheté. Ce message doit atteindre à la fois le microservice d’expédition, pour demander à l’entrepôt de préparer le colis, et le microservice de stock, pour décrémenter la quantité de stock et éventuellement déclencher des commandes aux fournisseurs.
Routage des messages et rubriques
Parfois, vous pouvez avoir besoin de distribuer un message à plusieurs consommateurs, mais, pour chaque consommateur, vous appliquez un filtre. Ce modèle est appelé routeur de messages. Comme dans le modèle publication/abonnement, les consommateurs s’abonnent à l’échangeur pour créer plusieurs files d’attente de travail. Toutefois, au lieu d’un échangeur de répartition, le modèle utilise un échangeur direct. Avec cet échangeur, chaque abonnement a une clé de liaison. Seuls les messages dont la clé de routage correspond à la clé de liaison sont envoyés à cet abonnement. Les autres sont masqués.
Ce modèle est utile quand certains consommateurs doivent traiter seulement une partie du flux de messages. Par exemple, supposons que vous avez un microservice qui envoie des messages en cas d’erreurs. Toutes les erreurs doivent être envoyées au microservice de journalisation. Les erreurs critiques doivent être envoyées au microservice d’administration qui doit alerter les ingénieurs pour qu’ils résolvent le problème.
L’échangeur direct route les messages en fonction d’un seul critère. Pour rendre les choses encore plus flexibles, vous pouvez utiliser un échangeur de rubrique. Pour chaque message, vous pouvez utiliser une clé de routage avec plusieurs termes séparés par des points. Dans la clé de liaison, vous pouvez utiliser les caractères génériques *, pour remplacer exactement un mot, ou # pour remplacer zéro ou plusieurs mots.
Remarque
Les alternatives à RabbitMQ sont Apache Kafka et Azure Service Bus. Ces deux répartiteurs de messages sont pris en charge par des composants dédiés dans .NET Aspire. Vous découvrez Azure Service Bus dans un module ultérieur de ce parcours d’apprentissage.