BlazingMQ est une plateforme développée par le groupe Bloomberg Managed Services (BMS). Il est décrit comme un logiciel intermédiaire générique orienté message qui permet de créer des applications décentralisées communiquant à l'aide de files d'attente de messages. « BlazingMQ fournit des files d'attente durables, tolérantes aux pannes, très performantes et très disponibles, ainsi que des fonctionnalités telles que diverses stratégies d'acheminement des messages (par exemple, files d'attente de travail, priorité, fan-out, diffusion, etc.) », indique la documentation de l'outil. Le groupe BMS a publié BlazingMQ après des années d'utilisation en interne.
« BlazingMQ est un système de file d'attente de messages distribués qui offre une solution rapide, fiable, riche en fonctionnalités pour aider les développeurs à déplacer des données. Si vous regardez le monde des logiciels d'entreprise, presque toutes les applications transfèrent des données d'un point A à un point B, et les développeurs de ces applications sont toujours à la recherche d'un middleware de messagerie efficace et flexible qui fonctionne tout simplement. Avec BlazingMQ, notre objectif est de faciliter les décisions des développeurs et de leur fournir une solution de messagerie convaincante, a déclaré Ankur Saxena, membre du groupe BMS.
BlazingMQ n'est pas une solution nouvelle. Le groupe indique qu'il est utilisé en production au sein de Bloomberg depuis environ huit ans. Au cours de cette période, il est passé d'une solution de messagerie rudimentaire à un nœud à une solution qui couvre plusieurs clusters et prend en charge plusieurs flux de travail critiques pour l'entreprise. Le démarrage de BlazingMQ est dit facile. Il est livré avec une image Docker et des instructions étape par étape pour voir les fonctionnalités de BlazingMQ en action d'une manière simple. L'équipe encourage tout le monde à l'essayer. Voici quelques-unes des caractéristiques les plus importantes de BlazingMQ :
- durabilité et haute disponibilité : il fournit des files d'attente durables, hautement disponibles et efficaces, qui permettent une communication asynchrone et faiblement couplée entre les applications. Les files d'attente peuvent être répliquées dans les centres de données, ce qui garantit la continuité des activités en cas de scénarios de reprise après sinistre ;
- abstraction du transport : BlazingMQ fait abstraction du transport et du réseau, et les applications productrices et consommatrices n'ont pas besoin de se préoccuper du transport sous-jacent ou de la situation géographique des uns et des autres ;
- stratégies d'acheminement des messages : il permet aux applications de mettre en œuvre divers modèles d'architecture d'entreprise grâce à son riche ensemble de stratégies d'acheminement des messages - file d'attente, priorité, fan-out, diffusion, demande/réponse, etc. ;
- un riche ensemble de fonctionnalités : en plus de ce qui précède, il est doté de fonctionnalités supplémentaires telles que la compression, la détection des pilules empoisonnées, une architecture enfichable, une cohérence configurable, un riche ensemble d'API en C++, Python et Java SDK, etc. ;
- hautes performances : BlazingMQ offre une faible latence et un débit élevé à l'échelle de l'entreprise. Les applications peuvent compter sur BlazingMQ pour être très performantes ;
- fiabilité : BlazingMQ offre un haut niveau de fiabilité et tente de protéger les applications contre les perturbations transitoires du réseau ou du matériel. Un cluster BlazingMQ peut disparaître du réseau pendant quelques minutes (configurables), pendant lesquelles les applications productrices peuvent continuer à lui soumettre du travail sans remarquer d'erreurs ;
- mesures étendues : BlazingMQ fournit un ensemble complet de mesures de surveillance pour aider les utilisateurs à déterminer et à comprendre le comportement de leurs applications et des clusters BlazingMQ.
L'infrastructure de BlazingMQ se compose de courtiers de messages et de clients (applications productrices et consommatrices) fonctionnant dans un environnement distribué. Les clients ne se parlent pas directement entre eux, ils se connectent uniquement aux courtiers BlazingMQ. Des bibliothèques clients sont disponibles en C++, Java et Python. Une file d'attente est un flux logique de données sur lequel les applications productrices et consommatrices échangent des messages. Les files d'attente permettent aux producteurs et aux consommateurs de s'isoler temporellement et spatialement les uns des autres, garantissant ainsi leur découplage.
Les files d'attente sont conservées sur disque et répliquées sur les machines du cluster BlazingMQ. Elles sont regroupées en domaines : un domaine fournit un espace de noms pour les applications et encapsule la configuration commune associée aux files d'attente, comme le mode de routage, le quota de stockage de la file d'attente, le TTL du message et d'autres paramètres. BlazingMQ supporte optionnellement la notion de niveaux - une file d'attente peut avoir plusieurs instances isolées à travers différents niveaux, tels que dev, alpha, beta, uat, qa, prod, etc. Le groupe BMS présente BlazingMQ comme une alternative à RabbitMQ et Apache Kafka.
Mais il indique également qu'il n'existe pas de réponse simple à la question "quel système de messagerie dois-je utiliser ?" en raison de la complexité des facteurs en jeu. « Ceux qui cherchent une réponse directe à cette question seront probablement déçus. Nous évitons délibérément de recommander un système spécifique, car chaque système est unique et meilleur que les autres à certains égards tout en présentant des lacunes dans d'autres points. Nous encourageons les utilisateurs potentiels à effectuer leurs propres recherches et comparaisons de ces systèmes, en gardant à l'esprit leurs cas d'utilisation actuels et potentiels », note l'équipe.
Par exemple, en matière de dépendance, BlazingMQ ne dépend d'aucun autre framework logiciel. RabbitMQ quant à lui fonctionne sur la machine virtuelle Erlang. Les deux systèmes sont autosuffisants et peuvent héberger leurs données, ainsi que les métadonnées, par eux-mêmes. Ce n'est pas le cas d'Apache Kafka, qui nécessite Apache ZooKeeper pour le stockage des métadonnées. Cependant, Kafka est en train de se débarrasser de sa dépendance à l'égard de ZooKeeper et stockera bientôt ses données et métadonnées au sein du cluster Kafka lui-même. En outre, il faut également noter que Kafka fonctionne sur la machine virtuelle Java.
BlazingMQ, RabbitMQ et Kafka offrent une garantie de livraison des messages "au moins une fois", ce qui nécessite une persistance (stockage) et, inévitablement, une réplication. Outre le stockage, un autre aspect important du cycle de vie des messages produits est le routage des données (c'est-à-dire la logique de distribution des messages entre les consommateurs). Kafka se distingue de BlazingMQ et RabbitMQ (Streams mis à part) en découplant le stockage du routage des données. Les lectures dans Kafka ne sont pas destructives (c'est-à-dire que la durée de vie d'un message ne dépend pas de la livraison ou du traitement du message).
Les messages sont supprimés conformément à la politique de nettoyage configurée (par exemple, en fonction du temps, de la taille, du compactage). Ce choix de conception permet aux consommateurs Kafka de lire le "passé" (retour en arrière ou relecture). Cela nécessite également que chaque consommateur Kafka connaisse le décalage à partir duquel il doit lire les données. En revanche, BlazingMQ et RabbitMQ ne conservent les messages que jusqu'à ce qu'ils soient consommés. Les consommateurs de ces systèmes ne peuvent pas revenir en arrière pour accéder aux messages qui ont été traités précédemment.
Source : BlazingMQ (1, 2)
Et vous ?
Que pensez-vous de BlazingMQ ?
Voir aussi
L'IA générative et l'ESG vont remodeler le marché des logiciels de Big Data et d'Analytics dans les années à venir, selon IDC Europe
Big Data : la plateforme de développement pour l'analyse in-memory Apache Arrow 1.0.0 est disponible et s'accompagne de nombreuses améliorations
Apache Spark : la version 3.0 du framework open source de traitement big data disponible, avec une amélioration des API Python, une meilleure compatibilité ANSI SQL et est deux fois plus rapide