Qu’est-ce qu’un broker de messages ?

Les brokers de messages proposent deux modèles basiques de distribution des messages ou styles de messagerie :

Messagerie de point à point : il s’agit du modèle de distribution utilisé dans les files d’attente de messages avec une relation individuelle entre l’expéditeur et le destinataire du message. Chaque message de la file d’attente est envoyé à un seul destinataire et n’est consommé qu’une seule fois. La messagerie de point à point est nécessaire lorsqu’un message ne doit être traité qu’une seule fois. Parmi les exemples de cas d’utilisation de ce style de messagerie, citons le traitement des bulletins de paie et des transactions financières. Dans ces systèmes, les expéditeurs et les destinataires ont besoin de la garantie que chaque paiement ne sera envoyé qu’une seule fois.

Messagerie de publication/d’abonnement : dans ce modèle de distribution de messages, souvent appelé « pub/sub », le producteur de chaque message le publie dans un sujet, et plusieurs consommateurs de messages s’abonnent aux sujets dont ils souhaitent recevoir les messages. Tous les messages publiés sur un sujet sont distribués à toutes les applications qui y sont abonnées. Il s’agit d’une méthode de distribution de type « diffusion », dans laquelle il existe une relation un-à-plusieurs entre l’éditeur du message et ses consommateurs. Si, par exemple, une compagnie aérienne doit diffuser des mises à jour sur les heures d’atterrissage ou les retards de ses vols, de nombreuses parties peuvent utiliser ces informations : les équipes au sol chargées de la maintenance et du ravitaillement des avions, les bagagistes, les hôtesses de l’air et les pilotes qui préparent le prochain voyage de l’avion, ainsi que les opérateurs d’écrans d’affichage à destination du public. Un style de messagerie publication/abonnement est approprié dans ce scénario.

Les applications cloud natives sont conçues pour exploiter les avantages inhérents au cloud computing, notamment la flexibilité, l’évolutivité et la rapidité du déploiement. Ces applications sont constituées de petits composants discrets et réutilisables appelés microservices. Chaque microservice est déployé et peut fonctionner indépendamment des autres. Cela signifie que chacun d’entre eux peut être mis à jour, mis à l’échelle ou redémarré sans affecter les autres services du système. Souvent regroupés dans des conteneurs, les microservices fonctionnent ensemble pour constituer une application complète, mais chacun possède sa propre pile (qui comprend une base de données et un modèle de données qui peuvent être différents des autres).

Les microservices doivent disposer d’un moyen de communiquer entre eux pour fonctionner de concert. Les brokers de messages sont un mécanisme qu’ils utilisent pour créer ce réseau de communications partagés.

Dans les environnements de cloud hybride, les brokers de messages sont souvent utilisés pour gérer les communications entre les systèmes sur site et les composants du cloud. L’utilisation d’un broker de messages permet de mieux contrôler les communications entre les services et garantit que les données sont envoyées de manière sécurisée, fiable et efficace entre les composants d’une application. Les brokers de messages peuvent jouer un rôle similaire dans l’intégration d’environnements multicloud, car ils permettent la communication entre les workloads et les environnements d’exécution qui résident sur différentes plateformes. Ils sont également parfaitement adaptés à l’informatique sans serveur, dans laquelle les services individuels hébergés dans le cloud sont exécutés à la demande, par requête.

Les API REST sont couramment utilisées pour les communications entre microservices. Le terme REST (« Representational State Transfer ») définit un ensemble de principes et de contraintes que les développeurs peuvent suivre lors de la création de services web. Tous les services qui y adhèrent pourront communiquer à l’aide d’un ensemble uniforme d’opérateurs et de demandes sans état partagés. L’interface de programmation des applications (API) désigne le code sous-jacent qui, s’il est conforme aux règles du REST, permet aux services de communiquer entre eux.

Les API REST utilisent le protocole HTTP (« Hypertext Transfer Protocol ») pour communiquer. Le HTTP étant le protocole de transport standard de l’Internet public, les API REST sont largement connues, fréquemment utilisées et largement interopérables. Le HTTP est un protocole de demande/réponse. Il est donc préférable de l’utiliser dans les situations qui nécessitent une demande/réponse synchrone. Cela signifie que les services qui font des requêtes par l’intermédiaire des API REST doivent être conçus pour obtenir une réponse immédiate. Si le client qui reçoit la réponse est hors service, le service d’envoi sera bloqué en attendant la réponse. La logique de basculement et de gestion des erreurs doit être intégrée aux deux services.

Les brokers de messages permettent des communications asynchrones entre les services, de sorte que le service expéditeur n’a pas besoin d’attendre la réponse du service destinataire. Cela améliore la tolérance aux pannes et la résilience dans les systèmes dans lesquels ils sont utilisés. En outre, l’utilisation de brokers de messages facilite la montée en charge des systèmes, car un modèle de messagerie publication/abonnement peut facilement prendre en charge un nombre changeant de services. Les brokers de messages suivent également les états des consommateurs.

Alors que les brokers de messages peuvent prendre en charge deux modèles de messagerie ou plus, y compris les files d’attente de messages et le mode publication/abonnement, les plateformes de transmission d’événements en continu ne proposent que des modèles de distribution de type publication/abonnement. Conçues pour être utilisées avec de gros volumes de messages, les plateformes de transmission d’événements en continu peuvent facilement monter en charge. Elles sont capables de classer des flux d’enregistrements dans des catégories et de les stocker pendant une durée prédéterminée. Toutefois, contrairement aux brokers de messages, les plateformes de transmission d’événements en continu ne peuvent pas garantir la livraison des messages ni savoir quels consommateurs ont reçu les messages.

Les plateformes de transmission d’événements en continu offrent plus d’évolutivité que les brokers de messages, mais moins de fonctionnalités qui garantissent la tolérance aux pannes (comme la réexpédition des messages), ainsi que des capacités de routage et de mise en file d’attente des messages plus limitées.

En savoir plus sur l’architecture orientée événements.

Un enterprise service bus (ESB) est un modèle architectural parfois utilisé dans les architectures orientées services (« service-oriented architectures » ou SOA) implantées dans les entreprises. Dans un ESB, une plateforme logicielle centralisée combine des protocoles de communication et des formats de données dans un « langage commun » que tous les services et toutes les applications de l’architecture peuvent partager. Un ESB peut, par exemple, traduire les requêtes qu’il reçoit d’un protocole (tel que le XML) vers un autre (tel que le JSON). Les ESB transforment les charges utiles de leurs messages à l’aide d’un processus automatisé. La plateforme logicielle centralisée gère également d’autres logiques d’orchestration, comme la connectivité, le routage et le traitement des demandes.

Les infrastructures ESB sont toutefois complexes et peuvent être difficiles à intégrer et coûteuses à maintenir. Il est difficile de solutionner leurs problèmes lorsque ceux-ci surviennent dans les environnements de production, elles ne montent pas facilement en charge et les mises à jour sont fastidieuses.

Les brokers de messages sont une alternative « légère » aux ESB. Ils fournissent une fonctionnalité similaire (un mécanisme de communication interservice) de manière plus simple et à moindre coût. Ils sont bien adaptés aux architectures de microservices qui se sont répandues avec la démocratisation des ESB.

L’implantation de brokers de messages peut répondre à une grande variété de besoins métier dans de nombreux secteurs et au sein de divers environnements informatiques d’entreprise. Les brokers sont utiles à tout moment et partout où une communication interapplication fiable et une livraison de messages garantie sont requises.

Les brokers de messages sont souvent utilisés de la manière suivante :

• Transactions financières et traitement des paiements : il est essentiel de s’assurer que les paiements ne sont envoyés qu’une seule fois. L’utilisation d’un broker de messages pour gérer les données de ces transactions permet de garantir que les informations de paiement ne seront ni perdues ni dupliquées accidentellement, fournit une preuve de réception et permet aux systèmes de communiquer de manière fiable, même lorsque les réseaux intermédiaires sont en panne.
  
  
• Traitement et expédition des commandes e-commerce : si vous exercez vos activités en ligne, la solidité de la réputation de votre marque dépend de la fiabilité de votre site web et de votre plateforme d’e-commerce. Avec leur capacité à améliorer la tolérance aux pannes et à garantir que les messages sont consommés une fois seulement, les brokers de messages s’imposent naturellement pour le traitement des commandes en ligne.
  
  
• Protection des données hautement sensibles au repos et en transit : si votre secteur est hautement réglementé ou si votre entreprise est confrontée à des risques de sécurité importants, choisissez une solution de messagerie dotée de capacités de chiffrement de bout en bout.