Dans cet article, nous verrons:
1. Ce qu’est le Message Queuing
4. Quels sont ses avantages et inconvénients
Message Queuing, qu’est-ce que c’est ?
C’est le fait d’utiliser une file d’attente de messages dans votre architecture. Elle permet une communication de service à service de manière asynchrone, c’est-à-dire que le message n’attend pas de réponse immédiate. Les messages sont stockés dans la file d’attente jusqu’à ce qu’ils soient traités ce qui entraine leur suppression. Chaque message n’est traité qu’une fois pour un seul utilisateur à priori. Les files d’attente de messages peuvent être utilisées pour découpler le traitement lourd notamment dans les architectures Microservices.
Comme l’explique Ange Guyader, Team Leader et Expert Microservices
Les files d’attente permettent des traitements asynchrones sans impératif de performances, les messages peuvent être rendus persistants pour ne pas perdre de données en cas de défaillance mais elles aident aussi à l’amélioration des performances grâce à une haute disponibilité, les messages n’étant jamais rejetés
A quoi ça sert ?
Dans l’architecture Cloud en générale et Microservices en particulier, les applications sont découplées en petits composants indépendants plus faciles à développer, à déployer et à gérer. Les files d’attente de messages assurent donc la coordination entre ces applications distribuées. Elles peuvent considérablement simplifier le codage des applications découplées, fluidifier les pics de charge, tout en améliorant les performances, la fiabilité et l’évolutivité.Comment ça marche ?
Une file d’attente de messages fournit une mémoire tampon légère qui stocke temporairement les messages, et des points de terminaison qui permettent de se connecter à la file d’attente pour envoyer et recevoir des messages. Les messages sont généralement petits et peuvent prendre la forme de requêtes, de réponses, de messages d’erreur ou de simples informations en texte clair.
Selon Ange Guyader, Team Leader
L’utilisation des queues de message dans leurs fonctions standards est relativement basique, les données sont simplement poussées d’un point A vers un point B. Chaque ajout de fonctionnalités avancées (exemple : multiplexage, démultiplexage) contribue à complexifier leur implémentation et donc leur usage
Pour envoyer un message, un composant appelé « producteur » ajoute un message à la file d’attente. Le message est stocké jusqu’à ce qu’un autre composant appelé « consommateur » récupère le message et le traite.
De nombreux producteurs et consommateurs peuvent utiliser la file d’attente, mais chaque message n’est traité qu’une seule fois, par un seul consommateur. C’est pourquoi ce modèle de messagerie est souvent qualifié de communication un à un ou point à point. Lorsqu’un message doit être traité par plusieurs clients, les files d’attente de messages peuvent être combinées avec la messagerie pub/sub dans un modèle de conception de déploiement.
Avec ce type d’architecture, un message envoyé par un expéditeur est transmis dans une queue, où il est stocké et conservé jusqu’à ce qu’il soit consommé par le destinataire. Ce dernier va devoir lire la queue pour accéder au message. On applique dans ce cas le principe du ‘First In’ ‘First Out’. Le message consommé sera celui arrivé en premier dans la queue. Cela garantie le fait que l’ordre d’envoi des messages soit respecté.
Pour pouvoir gérer des files d’attente, il faut un serveur de message ‘broker’.
Après avoir consommé le message, le destinataire envoie un accusé de réception au broker qui va alors supprimer le message de la queue. Ainsi, un même message ne peut être lu qu’une seule fois et par un seul destinataire. C’est ce qu’on appelle le principe du ‘Read Once’ ‘Only Once’. Seule exception, si le Système « tombe » entre la consommation du message et l’envoi de l’accusé de réception, alors il y aura de fait persistance et le message pourra être consommé par un autre destinataire.
Sur ce serveur de message, plusieurs éléments devront être paramétrés pour réaliser notre tâche :
- Un producteur (producer/publisher) : qui publiera (publish) les messages
- Une file d’attente (queue) : qui cumulera les messages en attente de leur traitement
- Un consommateur (consumer/subscriber) : qui attendra des messages dans la file à laquelle il sera rattaché puis les traitera (consume)
- Un exchange: là où seront publiés les messages
Le Broker de messages ajoute des fonctionnalités au message Queuing telle que la durabilité (résilience), des potentielles Policies (politiques de messages) concernant par exemple le traitement des messages par lot ou encore les conditions de livraison des messages. Les brokers de messages peuvent aussi fournir d’autre fonctionnalités telles que le Multiplexage/démultiplexage (l’agrégation ou la décomposition de messages de/vers plusieurs messages/ plusieurs destinataires), des couches de sécurité ou encore de la transformation de messages pour traduire les messages entre les formats de sortie et d’entrée.
Comme le précise Ange Guyader
Quels sont ses avantages et inconvénients ?
L’architecture Microservices, de par son fonctionnement, oriente fortement vos applications autour d’événements.
Cette architecture permet non seulement de paralléliser les développements avec un risque minimum mais aussi de les rendre plus modulables, plus propices à l’évolution, au changement.
Les applications décomposées en différentes parties autonomes peuvent être versionnées, déployées et gérées indépendamment les unes des autres mais doivent pouvoir communiquer entre elles d’où l’importance des messages et leur hiérarchisation chronologique.
Les messages étant stockés le temps que le traitement se fasse, l’interruption éventuelle du serveur n’entraîne pas la perte d’un traitement en cours.
De plus, cela permet aussi une meilleure scalabilité réduisant ainsi les problématiques de performance déjà mentionnées.
L’intérêt des brokers de messages est de permettre le découplage et d’aider à intégrer différents composants dans un SI, la transformation permettant de centraliser la « mise aux normes » des messages. L’avantage est aussi de structurer les échanges de données sur un format normalisé évitant ainsi d’interfacer les différentes applications entre elles, les applications émettrices vont « pousser » les messages sur le bus, les applications consommatrices vont quant à elles s’abonner aux messages disponibles qui les intéresse
Selon Ange Guyader
Le plus gros désavantage réside cependant dans un effet secondaire de son principal avantage : le découplage.
Lorsqu’un producteur publie des messages, il suppose de fait qu’un consommateur les traite par la suite sans forcément s’en soucier.
L’impact porte également sur l’expérience utilisateur. Bien qu’on puisse se débarrasser potentiellement de temps de chargements, il faut désormais incorporer dans l’interface la notion de ressource en cours de traitement voire du suivi d’une tâche…
D’ailleurs, un système de monitoring peut être mis en place pour observer la consommation des messages et l’état des services en général, le système ne générant pas d’erreur en cas de service indisponible.Quels sont les outils ?
Il en existe une multitude (ActiveMQ, Kafka, RabbitMQ, Artémis, Redis, Service Bus, …). Certains comme Redis n’ont pas été créés spécifiquement dans ce but mais peuvent être utilisés à cet effet. Les frameworks d’intégration (Apache Camel par exemple) quant à eux intègrent d’autres fonctionnalités telle qu’une sélection de différents connecteurs, FTP, HTTP, SMPT, AMQP (Advanced Message Queuing Protocol). Suivez le guide.
Active MQ
Permet la très haute disponibilité grâce à une configuration Master/Slave de chacun des brokers actifs. Lorsque le broker nominal maître tombe, un des brokers esclave prend aussitôt le relais en toute transparence
Apache Kafka
Très performant notamment si plusieurs consommateurs ont besoin d’avoir accès au même message
Artémis
Si la relation entre producteurs et consommateurs est une relation point-à-point, ne nécessitant pas que plusieurs consommateurs attendent la réception d’un même message
RabbitMQ
Solution très connue et qui s’intègre dans de nombreux langages. Il supporte le protocole AMQP (Advanced Message Queuing Protocol) dont l’objectif est de standardiser les échanges entre serveurs de messages. Ainsi toute interaction avec le serveur se fera au travers de ce protocole.
Service Bus (Enterprise Service Bus)
Ensemble d’outils qui permettent la communication entre différents systèmes en garantissant la sécurité des échanges avec pour vocation d’assurer le transfert des données ainsi que leur persistance. En outre, ils intègrent un système de suivi de messages, des contrôles de gestion de déploiement et de versions de services, des outils de gestion des erreurs et un équilibrage de charge entre services.
On pourra aussi trouver des outils intégrés d’audit, de gestion de routes, etc… d’une grande puissance qui permettent de gérer un grand nombre de composants, comme Biztalk de Microsoft par exemple.
La différence entre les différents types d’outils n’est pas simple à faire d’autant plus que certains mixent les fonctionnalités ascendantes. Il est donc important de bien définir en amont les volumétries, protocoles, sécurités, besoin de résilience pour choisir l’outil correspondant le mieux au besoin. On retrouve aussi des bus dédiés aux applications Cloud tels qu’Azure Service Bus sur le Cloud Azure
Comme l’explique Ange Guyader
Si aucun de ces systèmes n’est nécessaire on peut aussi communiquer directement avec des API ou des WebServices, en privilégiant le REST et en veillant cependant à respecter les standards d’implémentation.
Conclusion
Le message Queuing est une solution qui s’accompagne de concepts qui en font un projet assez conséquent et ambitieux à concevoir et qui demande beaucoup de rigueur. Mais celle-ci reste très intéressante pour améliorer les performances et l’évolution à grande échelle de vos applications ou de votre SI.
