Qu'est-ce que Pub/Sub ?

Pub/Sub permet aux services de communiquer de manière asynchrone, avec des latences environ 100 millisecondes.

Pub/Sub est utilisé pour les pipelines d'analyse de flux et d'intégration de données afin d'ingérer et de distribuer des données. Ce format est aussi efficace que les middlewares de messagerie pour l'intégration de services ou les files d'attente pour charger des tâches en parallèle.

Pub/Sub vous permet de créer des systèmes de producteurs et de consommateurs d'événements, appelés éditeurs et abonnés. Les éditeurs communiquent de manière asynchrone avec les abonnés en diffusant des événements plutôt que par des appels de procédure à distance (RPC) synchrones.

Les éditeurs envoient des événements au service Pub/Sub, sans savoir comment ni quand ces événements doivent être traités. Pub/Sub diffuse ensuite des événements à tous les services qui doivent y réagir. Par rapport aux systèmes qui communiquent via des RPC, où les éditeurs doivent attendre que les abonnés reçoivent les données, cette intégration asynchrone augmente la flexibilité et l'efficacité du système global.

Pour commencer à utiliser Pub/Sub, consultez le guide de démarrage rapide sur l'utilisation de Cloud Console. Pour une introduction plus complète, reportez-vous à la page Créer un système de messagerie Pub/Sub.

Cas d'utilisation courants

  • Ingestion de l'interaction des utilisateurs et événements serveur Pour utiliser les événements d'interaction utilisateur provenant d'applications utilisateur ou d'événements serveur de votre système, vous pouvez les transférer vers Pub/Sub, puis utiliser un outil de traitement par flux (tel que Dataflow) qui les transmet à BigQuery, Bigtable, Cloud Storage et d'autres bases de données. Pub/Sub vous permet de réunir simultanément les événements de nombreux clients.

  • Distribution d'événements en temps réel. Les événements, bruts ou traités, peuvent être mis à la disposition de plusieurs applications au sein de votre équipe et de votre organisation pour un traitement en temps réel. Elles sont compatibles avec les modèles de conception d'applications dédiés aux événements d'entreprise et basés sur des événements. Pub/Sub vous permet d'intégrer de nombreux systèmes Google qui exportent des événements vers Pub/Sub.

  • Réplication des données entre des bases de données. Pub/Sub est couramment utilisé pour distribuer des événements de modification à partir de bases de données. Ces événements peuvent servir à créer une vue de l'état et de l'historique d'état de la base de données dans BigQuery et d'autres systèmes de stockage de données.

  • Traitement en parallèle et workflows. Vous pouvez répartir efficacement un grand nombre de tâches entre plusieurs nœuds de calcul, comme compresser des fichiers texte, envoyer des notifications par e-mail, évaluer des modèles d'IA ou reformater des images. Pour cela, associez des messages Pub/Sub à Cloud Functions.

  • Bus d'événement d'entreprise. Vous pouvez créer un bus de partage de données en temps réel à l'échelle de votre entreprise, en distribuant des événements commerciaux, des mises à jour de bases de données et des événements d'analyse à l'échelle de votre organisation.

  • Diffusion de données depuis des applications, des services ou des appareils IoT. Par exemple, une application SaaS peut publier un flux en temps réel d'événements, ou un capteur résidentiel peut diffuser des données dans Pub/Sub pour les utiliser dans d'autres produits Google Cloud via un Dataflow.

  • 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.

  • Équilibrage de charge pour plus de fiabilité. Par exemple, les instances d'un service peuvent être déployées sur Compute Engine dans plusieurs zones, mais soumises à un sujet commun. Lorsque le service échoue dans une zone, les autres peuvent récupérer la charge automatiquement.

Types de services Pub/Sub

Pub/Sub se compose de deux services :

  • Service Pub/Sub. Ce service de messagerie est le choix par défaut pour la plupart des utilisateurs et applications. Elle offre la plus grande fiabilité et le plus grand ensemble d'intégrations, ainsi qu'une gestion de la capacité automatique. Pub/Sub garantit la réplication synchrone de toutes les données au moins deux zones et une réplication optimale dans une troisième zone supplémentaire.

  • Service Pub/Sub Lite. Un service de messagerie distinct, mais similaire, conçu à moindre coût Il offre une fiabilité inférieure à celle de Pub/Sub. Il propose un stockage de sujets zonal ou régional. Les sujets Lite zonaux sont stockés dans une seule zone. Les sujets Lite régionaux répliquent les données dans une deuxième zone de manière asynchrone. Par ailleurs, Pub/Sub Lite nécessite de pré-provisionner et de gérer la capacité de stockage ainsi que le débit. Pub/Sub Lite n'est disponible que pour les applications où un coût extrêmement faible justifie un travail opérationnel supplémentaire et réduire la fiabilité.

Pour plus d'informations sur les différences entre Pub/Sub et Pub/Sub Lite, consultez la page Choisir Pub/Sub ou Pub/Sub Lite.

Comparer Pub/Sub à d'autres technologies de messagerie

Pub/Sub combine l'évolutivité horizontale d'Apache Kafka et de Pulsar avec les fonctionnalités du middleware de messagerie traditionnel, comme Apache ActiveMQ et RabbitMQ, telles que les files d'attente de lettre morte et le filtrage.

Une autre fonctionnalité que Pub/Sub adopte à partir du middleware de messagerie est le parallélisme par message (plutôt que basé sur une partition). Pub/Sub "loue" des messages individuels aux clients abonnés, puis vérifie si un message donné a bien été traité.

En revanche, d'autres systèmes de messagerie horizontalement évolutifs utilisent des partitions pour le scaling horizontal. Cela oblige les abonnés à traiter les messages dans chaque partition dans l'ordre et limite le nombre de clients simultanés au nombre de partitions. Le traitement par message maximise le parallélisme des applications d'abonnés et permet de garantir l'indépendance de l'éditeur/l'abonné.

Communication de service à service et communication de service à client

Pub/Sub est destiné à la communication de service à service plutôt qu'à la communication avec des utilisateurs finaux ou des clients IoT. D'autres modèles sont mieux adaptés aux autres produits :

Vous pouvez utiliser une combinaison de ces services pour créer des clients -> services -> modèles de base de données. Par exemple, consultez le tutoriel Diffuser des messages Pub/Sub via WebSockets.

Intégrations

Pub/Sub offre de nombreuses intégrations à d'autres produits Google Cloud pour créer un système de messagerie complet :

  • Traitement des flux et intégration des données : Compatible avec Dataflow, y compris avec les modèles et SQL de Dataflow, qui permettent le traitement et l'intégration de données dans BigQuery et des lacs de données dans Cloud Storage Les modèles Dataflow permettant de déplacer des données de Pub/Sub vers Cloud Storage, BigQuery et d'autres produits sont disponibles dans les interfaces utilisateur de Pub/Sub et Dataflow de Cloud Console. L'intégration avec Apache Spark, en particulier lorsqu'elle est gérée avec Dataproc, est également disponible. La composition visuelle des pipelines d'intégration et de traitement exécutés sur Spark et Dataproc peut être réalisée avec Datafusion.
  • Surveillance, alertes et journalisation : Compatible avec les produits Monitoring et Logging.
  • Authentification et IAM. Pub/Sub s'appuie sur une authentification OAuth standard utilisée par d'autres produits Google Cloud et accepte un contrôle IAM précis, qui permet de contrôler les accès à des ressources individuelles.
  • API. Pub/Sub utilise les technologies API et de l'API de service REST standards, ainsi que les bibliothèques clientes pour plusieurs langages.
  • Déclencheurs, notifications et webhooks : Pub/Sub propose la distribution push de messages en tant que requêtes HTTP POST vers des webhooks. Ainsi, vous pouvez facilement mettre en œuvre l'automatisation des workflows à l'aide de Cloud Functions ou d'autres produits sans serveur.
  • Orchestration. Pub/Sub peut être intégré de manière déclarative dans des workflows sans serveur. Le big data et l'orchestration analytique sont souvent effectués via Cloud Composer, qui est compatible avec les déclencheurs Pub/Sub.

Concepts fondamentaux

  • Sujet. Ressource nommée à laquelle les éditeurs envoient des messages.
  • Abonnement. Ressource nommée représentant le flux de messages à partir d'un sujet spécifique, à distribuer à 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 à un sujet et 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.
  • Éditeur : Application qui crée des messages et les envoie à un ou plusieurs sujets.
  • Abonné. Application avec abonnement à un ou des sujets pour recevoir des messages de celui-ci.
  • Accusé de réception (ou de reconnaissance). Signal envoyé par un abonné à Pub/Sub après avoir reçu un message. Les messages dont la réception a été accusée sont supprimés de la file d'attente des messages de l'abonnement.
  • Tirez et tirez Les deux modes de distribution des messages. 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.

Les relations éditeur-abonné peuvent être de type un à plusieurs (distribution ramifiée), plusieurs à un (distribution unique) et plusieurs à plusieurs, comme le montre le schéma suivant :

Relations éditeur-abonné

Le diagramme suivant illustre la façon dont un message passe d'un éditeur à un abonné. Notez que pour la distribution push, l'accusé de réception est implicite dans la réponse à la requête push, tandis que pour la distribution pull, il nécessite un RPC distinct.

Cycle de vie des messages

Étapes suivantes