Google Cloud Pub/Sub est un service de messagerie conçu pour faciliter l'échange de messages entre systèmes ou composants indépendants au sein d'une application distribuée. Il permet le découplage de ces composants, leur permettant de communiquer de manière asynchrone sans dépendances directes. Nous allons explorer ce que c'est, comment cela fonctionne, et pourquoi c'est une innovation majeure pour les architectures event-driven.
Topic : Une ressource nommée à laquelle les messages sont envoyés par les éditeurs (Publishers).
Subscription : Une ressource nommée représentant le flux de messages provenant d'un topic spécifique, à être livré à l'application abonnée.
Message : La combinaison de données et d'attributs (facultatifs) qu'un éditeur envoie à un topic et qui est finalement livré aux abonnés.
Publisher : Une application qui crée et envoie des messages à un ou plusieurs topics.
Subscriber : Une application avec un abonnement à un ou plusieurs topics pour recevoir des messages de ceux-ci.
Le diagramme suivant illustre comment un message passe d'un éditeur à un abonné.
Un publisher (éditeur) envoie un message contenant une charge utile (les données réelles) et des attributs facultatifs à un topic spécifique.
Les subscribers souscrits traitent le message et agissent en fonction de son contenu, ce qui peut inclure le traitement des données, le déclenchement d'actions ou la mise à jour de systèmes.
Après avoir traité le message avec succès, le subscriber envoie une confirmation à Pub/Sub. Cette confirmation atteste que le message a été reçu et traité.
Une fois que Pub/Sub reçoit la confirmation du subscriber, il accorde la réception réussie du message. Le message est alors retiré de la subscription, évitant ainsi les livraisons en double.
Les publishers peuvent être n'importe quelle application capable de faire des requêtes HTTPS à pubsub.google.apis.com : une application App Engine, un service web hébergé sur Google Compute Engine ou tout autre réseau tiers, une application installée sur un ordinateur ou un appareil mobile, ou même un navigateur.
Le subscriber est l'application qui reçoit et traite le message. L'abonnement connecte le topic à un subscriber. Un topic peut avoir plusieurs abonnements, mais un abonnement donné appartient à un seul topic.
Dans une subscription de type "pull", le subscriber demande activement des messages à Pub/Sub à son propre rythme. Voici comment cela fonctionne :
Le subscriber envoie des requêtes au service Pub/Sub, demandant des messages d'une subscription spécifique.
Pub/Sub répond avec un ou plusieurs messages si disponibles. Les messages sont récupérés par lots.
Le subscriber traite les messages reçus et exécute les actions requises.
Une fois que le subscriber a traité un message avec succès, il envoie une confirmation à Pub/Sub.
Si un message n'est pas confirmé dans un certain délai, Pub/Sub suppose qu'il n'a pas été traité avec succès et peut tenter une nouvelle livraison.
Les subscriptions de type "push" offrent une approche plus automatisée, où Pub/Sub se charge de la livraison des messages aux subscribers. Voici le processus :
Le subscriber fournit un endpoint URL (HTTP/HTTPS) où il souhaite recevoir les messages.
Lorsqu'un message est publié à un topic, Pub/Sub le transmet immédiatement au endpoint enregistré de tous les subscribers push.
Le endpoint du subscriber traite le message reçu, ce qui peut inclure la manipulation des données, le déclenchement d'actions ou la mise à jour de systèmes.
Comme pour les subscriptions pull, le subscriber envoie une confirmation à Pub/Sub après avoir traité le message avec succès.
Si le endpoint du subscriber renvoie un statut d'erreur ou ne répond pas, Pub/Sub tente une nouvelle livraison plusieurs fois avec un délai croissant.
Contrôle vs. Automatisation : Les subscriptions pull donnent plus de contrôle aux subscribers sur le moment et la manière de récupérer les messages, tandis que les subscriptions push automatisent la livraison des messages aux endpoints enregistrés.
Latence : Les subscriptions push ont généralement une latence plus faible car les messages sont livrés immédiatement à leur arrivée. Dans les subscriptions pull, la latence dépend de la fréquence de polling du subscriber.
Évolutivité : Les subscriptions push conviennent lorsque les subscribers peuvent gérer les requêtes HTTP entrantes. Les subscriptions pull conviennent mieux aux scénarios où le subscriber veut contrôler le taux de récupération des messages.
Configuration Webhook : Les subscriptions push nécessitent que les subscribers configurent et maintiennent un endpoint HTTP/HTTPS (webhook) pour recevoir les messages. Les subscriptions pull ne nécessitent que le subscriber interroge les messages.
Architectures Event-Driven : Pub/Sub est idéal pour construire des systèmes event-driven où divers composants doivent réagir aux événements en temps réel.
Ingestion et Streaming de Données : Il est utilisé pour ingérer et traiter de grands volumes de données en streaming provenant de sources comme les appareils IoT, les journaux et les capteurs.
Microservices Découplés : Pub/Sub permet aux microservices de communiquer sans dépendances directes, améliorant ainsi l'évolutivité et la maintenabilité.
Analytique en Temps Réel : C'est un composant clé pour le traitement et l'analyse des données en temps réel.
Google Cloud Pub/Sub se présente comme un outil puissant pour permettre la communication asynchrone au sein d'applications distribuées. En découplant les composants, en assurant une livraison fiable des messages et en offrant une évolutivité efficace, il permet aux entreprises de construire des systèmes robustes, réactifs et résilients.
Nous espérons que vous avez maintenant une meilleure idée de ce qu'est Pub/Sub et comment il fonctionne.