Qu'est-ce que Pub/Sub et Pub/Sub Lite ?

Cette page vous aide à comprendre Pub/Sub, pourquoi les entreprises ont besoin de Pub/Sub et les avantages de Pub/Sub par rapport à des technologies similaires. Apprenez-en davantage sur les fonctionnalités Les concepts Pub/Sub qui incluent les termes "sujet", "éditeur" et "abonné".

Pub/Sub est un service de messagerie asynchrone et évolutif qui dissocie services produisant des messages à partir des services qui traitent ces messages.

Pub/Sub permet aux services de communiquer de manière asynchrone, de l'ordre de 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. Il est tout aussi efficace en tant intergiciel de messagerie pour l'intégration de services ou en file 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 tenir compte comment ou quand ces événements doivent être traités. puis à Pub/Sub envoie les événements à tous les services qui y réagissent. Dans les systèmes communiquant via les RPC, les éditeurs doivent attendre que les abonnés reçoivent les données. Toutefois, l'intégration asynchrone dans Pub/Sub améliore la flexibilité et la robustesse du système global.

Pour commencer à utiliser Pub/Sub, consultez le Guide de démarrage rapide avec la console Google Cloud Pour une introduction plus complète, reportez-vous à la page Créer un système de messagerie Pub/Sub.

Cas d'utilisation courants

  • Ingestion des interactions des utilisateurs et des événements de serveur. Pour utiliser le profil utilisateur d'interaction provenant d'applications d'utilisateurs finaux ou d'événements de serveur sur votre système, vous pouvez et les transférer à Pub/Sub. Vous pouvez ensuite utiliser un modèle tel que Dataflow, qui envoie les événements aux bases de données. Parmi ces bases de données, citons BigQuery, Bigtable et Cloud Storage. Pub/Sub vous permet de rassembler des événements clients simultanément.

  • Distribution d'événements en temps réel. Des événements, bruts ou traités, peuvent être disponibles pour de multiples applications au sein de votre équipe et de votre organisation le temps de traitement. Pub/Sub accepte un "bus d'événements d'entreprise" et de conception d'applications basées sur des événements. Pub/Sub vous permet s'intègrent à 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 les événements de modification à partir des bases de données. Ces événements peuvent être utilisés pour créer une vue de l'état de la base de données et de l'historique des états dans BigQuery et d'autres systèmes de stockage de données.

  • Traitement en parallèle et workflows. Vous pouvez répartir efficacement de nombreuses entre plusieurs nœuds de calcul à l'aide de messages Pub/Sub pour vous connecter à Cloud Functions. Il peut s'agir, par exemple, de compresser du texte des fichiers, l'envoi de notifications par e-mail, l'évaluation des modèles d'IA et le reformatage images.

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

  • Flux de données provenant d'applications, de services ou d'appareils IoT. Par exemple, un L'application SaaS peut publier un flux d'événements en temps réel. ou un capteur domestique Diffuser des données vers Pub/Sub pour les utiliser dans d'autres produits Google Cloud via un pipeline Dataflow.

  • Actualisation des caches distribués. Par exemple, une application peut publier d'invalidation pour mettre à jour les identifiants des objets qui ont été modifiés.

  • Équilibrage de charge pour plus de fiabilité. Par exemple, les instances d'un service peuvent être déployés sur Compute Engine dans plusieurs zones, mais qui s'abonnent à un sujet commun. En cas de défaillance du service dans n'importe quelle zone, les autres peuvent prendre en charge la charge. automatiquement.

Types de services Pub/Sub

Pub/Sub se compose de deux services :

  • Service Pub/Sub. Ce service de messagerie est le service par défaut pour la plupart des utilisateurs et applications. Il offre le niveau de fiabilité le plus élevé le plus grand ensemble d'intégrations disponibles, ainsi qu'une gestion automatique de la capacité. Pub/Sub garantit une réplication synchrone de toutes les données deux zones et la réplication dans la mesure du possible vers une troisième zone supplémentaire.

  • Service Pub/Sub Lite. Un message distinct, mais similaire conçu pour réduire les coûts. Il offre une fiabilité inférieure Pub/Sub. Elle offre un stockage zonal ou régional des sujets. Les sujets Lite zonaux sont stockés dans un seul dans la zone. Les sujets Lite régionaux répliquent les données sur une seconde de manière asynchrone. De plus, Pub/Sub Lite nécessite de pré-provisionner et de gérer le stockage et la capacité de débit. N'envisagez Pub/Sub Lite que pour les applications Un faible coût justifie un travail opérationnel supplémentaire et réduit et la fiabilité.

Pour en savoir plus sur les différences entre Pub/Sub et Pub/Sub Lite, consultez Choisir Pub/Sub ou Pub/Sub Lite

Comparer Pub/Sub à d'autres technologies de messagerie

Pub/Sub combine l'évolutivité horizontale Apache Kafka et Pulsar avec disponibles dans les middleware de messagerie traditionnels comme Apache ActiveMQ RabbitMQ. Les files d'attente de lettres mortes et le filtrage en sont des exemples.

Une autre fonctionnalité adoptée par Pub/Sub à partir du middleware de messagerie est parallélisme par message, plutôt qu'une messagerie basée sur les partitions. Pub/Sub : "bail" des messages individuels aux clients abonnés, permet de savoir 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. Traitement par message maximise le parallélisme des applications d'abonnés et aide à garantir l'indépendance de l'éditeur et de l'abonné.

Comparer la communication de service à service et 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 par flux et intégration des données. Compatible avec Dataflow, y compris les modèles Dataflow et SQL, qui permettent de traiter et l'intégration des données à BigQuery et aux lacs de données sur Cloud Storage. Dataflow des modèles pour transférer des données de Pub/Sub Cloud Storage, BigQuery et d'autres produits sont disponibles les interfaces utilisateur Pub/Sub et Dataflow console Google Cloud. L'intégration avec Apache Spark, en particulier lorsqu'elle est gérée avec Dataproc, est également disponible. Composition visuelle de l'intégration et des pipelines de traitement exécutés sur Spark et Dataproc. Data Fusion :
  • Surveillance, alertes et journalisation. Compatible avec Monitoring et les produits de journalisation.
  • Authentification et IAM. Pub/Sub s'appuie sur un protocole OAuth standard utilisée par d'autres produits Google Cloud et prend en charge des stratégies IAM précises, en activant le contrôle des accès aux ressources individuelles.
  • API. Pub/Sub utilise les API de service gRPC et REST standards technologies ainsi que des bibliothèques clientes pour plusieurs langages.
  • Déclencheurs, notifications et webhooks. Pub/Sub propose une distribution push la distribution de messages sous forme de requêtes HTTP POST aux webhooks. Vous pouvez implémenter l'automatisation des workflows à l'aide de Cloud Functions. ou d'autres produits sans serveur.
  • Orchestration. Pub/Sub peut être intégré à un environnement sans serveur en plusieurs étapes Workflows de manière déclarative. le big data et l'orchestration d'analyses, souvent avec Cloud Composer, qui est compatible avec les déclencheurs Pub/Sub. Vous pouvez aussi intégrer Pub/Sub Application Integration (Preview), qui est un Solution iPaaS (Integration-Platform as a Service) Application L'intégration offre Déclencheur Pub/Sub pour déclencher ou démarrer des intégrations.
  • Connecteurs d'intégration(preview) Ces connecteurs vous permettent de vous connecter à différentes sources de données. Avec les connecteurs, les services Google Cloud et les applications d'entreprise tierces sont exposés à vos intégrations via une interface standard et transparente. Pour Pub/Sub, vous pouvez créer une connexion Pub/Sub. à utiliser dans vos intégrations.

Concepts fondamentaux

  • Sujet. Ressource nommée à laquelle les éditeurs envoient des messages.
  • Abonnement. Une ressource nommée représentant le flux de messages provenant un sujet unique et spécifique, à transmettre à 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. La combinaison de données et d'attributs (facultatifs) qu'une que l'éditeur envoie dans un sujet et est finalement distribué aux abonnés.
  • Attribut de message. Une paire clé-valeur qu'un éditeur peut définir pour . 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 et envoie des messages à un ou plusieurs sujets.
  • Abonné. Une application avec un abonnement à un ou plusieurs sujets pour recevoir des messages de celle-ci.
  • Remerciements (ou "ack") Un signal envoyé par un abonné à Pub/Sub après a bien reçu un message. Les messages confirmés sont supprimés de la file d'attente des messages de l'abonnement.
  • Push and pull. Les deux modes de distribution des messages Un abonné reçoit soit par Pub/Sub, soit en les envoyant à l'abonné point de terminaison choisi, ou par l'abonné qui les extraient du service.

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é. Pour la distribution push, l'accusé de réception est implicite dans la réponse à la requête push, alors que pour la distribution pull, elle nécessite un RPC distinct.

Cycle de vie des messages

Étapes suivantes