Qu'est-ce que Pub/Sub ?

Pub/Sub est un service de messagerie asynchrone qui dissocie les services de production d'événements des services de traitement des événements.

Vous pouvez utiliser Pub/Sub en tant que middleware de messagerie ou outil d'ingestion et de diffusion d'événements pour les pipelines d'analyse en flux continu.

Pub/Sub offre un stockage durable des messages ainsi qu'une distribution des messages en temps réel, avec une haute disponibilité et des performances constantes à grande échelle. Les serveurs Pub/Sub fonctionnent dans toutes les régions Google Cloud réparties dans le monde entier.

Pour commencer tout de suite, essayez le démarrage rapide avec Cloud Console. Pour une introduction plus complète, reportez-vous à la page Créer un système Pub/Sub fonctionnel.

Concepts fondamentaux

  • Sujet : Ressource nommée à laquelle les éditeurs envoient des messages.
  • Abonnement : Ressource nommée représentant le flux de messages d'un sujet spécifique à distribuer dans l'application d'abonnement. Pour plus de détails sur les abonnements et la sémantique de distribution des messages, consultez le Guide pour les abonnés.
  • Message : Combinaison de données et d'attributs (facultatifs) qu'un éditeur envoie dans un sujet et qui est finalement remise aux abonnés.
  • Attribut de message : Paire clé-valeur qu'un éditeur peut définir pour un message. Par exemple, la clé iana.org/language_tag et la valeur en pourraient être ajoutées aux messages pour les marquer comme lisibles par un abonné anglophone.

Relations éditeur-abonné

Une application d'éditeur crée et envoie des messages dans un sujet. Les applications d'abonnés créent un abonnement associé à un sujet pour recevoir des messages de celui-ci. La communication peut être de type un à plusieurs (distribution ramifiée), plusieurs à un (distribution unique) et plusieurs à plusieurs, comme le montre le schéma suivant.

Les éditeurs A et B envoient des messages au même abonné, tandis que l'éditeur C transmet des messages à plusieurs abonnés.

Flux de messages Pub/Sub

Le schéma ci-dessous présente les composants du système Pub/Sub et la manière dont les messages circulent entre eux :

Les principaux composants du système Pub/Sub incluent les messages, les sujets et les abonnements.
  1. Une application d'éditeur crée un sujet dans le service Pub/Sub et envoie des messages à ce sujet. Chaque message contient une charge utile et des attributs facultatifs décrivant le contenu de la charge utile.
  2. Le service garantit que les messages publiés sont conservés pour le compte des abonnements. Un message publié est conservé pour un abonnement jusqu'à ce que tout abonné utilisant les messages de cet abonnement en accuse réception.
  3. Pub/Sub transmet les messages d'un sujet à tous ses abonnements, individuellement.
  4. Un abonné reçoit des messages que Pub/Sub lui transmet en mode push vers le point de terminaison choisi par l'abonné, ou que l'abonné reçoit du service en mode pull.
  5. L'abonné envoie un accusé de réception au service Pub/Sub pour chaque message reçu.
  6. Le service supprime les messages dont la réception est confirmée de la file d'attente des messages de l'abonnement.

Points de terminaison des éditeurs et des abonnés

Les éditeurs peuvent être des applications capables d'envoyer des requêtes HTTPS à pubsub.googleapis.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.

Les requêtes HTTP sont effectuées par des éditeurs tels que des services, des applications ou des appareils IoT, et par des abonnés, tels que des microservices ou des applications de données.

Les abonnés en mode pull peuvent également être des applications capables d'émettre des requêtes HTTPS auprès de googleapis.com.

Actuellement, les abonnés en mode push doivent être des points de terminaison webhook pouvant accepter des requêtes POST via HTTPS.

Cas d'utilisation courants

  • Équilibrage des charges de travail dans les clusters de réseau. Par exemple, une file d'attente importante de tâches peut être efficacement répartie entre plusieurs nœuds, tels que des instances Google Compute Engine.
  • Utilisation de workflows asynchrones. Par exemple, une application de traitement de commandes peut passer une commande dans un sujet, à partir de laquelle elle peut être traitée par un ou plusieurs nœuds.
  • Distribution de notifications d'événements. Par exemple, un service qui accepte les inscriptions d'utilisateurs peut envoyer des notifications chaque fois qu'un nouvel utilisateur s'inscrit, et les services en aval peuvent s'abonner pour recevoir des notifications de l'événement.
  • Actualisation des caches distribués. Par exemple, une application peut publier des événements d'invalidation pour mettre à jour les ID des objets modifiés.
  • Connexion à plusieurs systèmes. Par exemple, une instance Google Compute Engine peut écrire des journaux dans le système de surveillance, dans une base de données pour l'interroger par la suite, etc.
  • Transmission de données par flux depuis divers processus ou appareils. Par exemple, un capteur résidentiel peut diffuser des données par flux sur des serveurs backend hébergés dans le cloud.
  • Amélioration de la fiabilité. Par exemple, un service Compute Engine disponible dans une zone peut fonctionner dans d'autres zones en s'abonnant à un sujet commun pour résoudre des pannes dans une zone ou une région.

Intégrations Pub/Sub

Le schéma suivant montre comment Pub/Sub peut intégrer de nombreux composants de Google Cloud.

Pub/Sub peut intégrer des entrées de Cloud Logging et de Compute Engine à des points de terminaison tels que Dataflow et App Engine.