Cette page vous aide à comprendre Pub/Sub, pourquoi les entreprises ont besoin de Pub/Sub et les avantages de Pub/Sub par rapport aux technologies similaires. Découvrez également les concepts Pub/Sub de base, y compris les termes sujet, diffuseur et abonné.
Pub/Sub est un service de messagerie asynchrone et évolutif qui dissocie les services de production de messages des services qui traitent ces messages.
Pub/Sub permet aux services de communiquer de manière asynchrone avec des latences 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 également efficace en tant que middleware de messagerie pour l'intégration des services ou comme file d'attente pour charger en parallèle des tâches.
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 seront traités. Pub/Sub fournit ensuite des événements à tous les services qui y réagissent. Dans les systèmes qui communiquent via des RPC, les éditeurs doivent attendre que les abonnés reçoivent les données. L'intégration asynchrone dans Pub/Sub augmente toutefois la flexibilité et la robustesse du système dans son ensemble.
Pour commencer à utiliser Pub/Sub, consultez le guide de démarrage rapide sur l'utilisation de 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 d'événements d'interaction utilisateur et d'événements de serveur. Pour utiliser des événements d'interaction utilisateur en provenance d'applications pour utilisateurs finaux, ou bien des événements de serveur provenant de votre système, vous pouvez les transférer vers Pub/Sub. Vous pouvez ensuite utiliser un outil de traitement par flux, tel que Dataflow, qui envoie les événements aux bases de données. BigQuery, Bigtable et Cloud Storage sont des exemples de telles bases de données. Pub/Sub vous permet de regrouper des événements de nombreux clients simultanément.
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. Pub/Sub est compatible avec un "bus d'événement d'entreprise" et les modèles de conception d'applications basés sur les é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 les événements de modification à partir de 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 un historique des états dans BigQuery et d'autres systèmes de stockage de données.
Traitement en parallèle et workflows. Vous pouvez distribuer efficacement de nombreuses tâches entre plusieurs nœuds de calcul en utilisant des messages Pub/Sub pour vous connecter à des fonctions Cloud Run. Il peut s'agir, par exemple, de compresser des fichiers texte, d'envoyer des notifications par e-mail, d'évaluer des modèles d'IA et de reformater des images.
Bus d'événement d'entreprise. Vous pouvez créer un bus de partage de données en temps réel à l'échelle de l'entreprise, en répartissant les événements commerciaux, les mises à jour de base de données et les événements d'analyse dans votre organisation.
Diffusion de données en streaming depuis des applications, des services ou des appareils IoT. Par exemple, une application SaaS peut publier un flux d'événements en temps réel. Un capteur résidentiel peut également 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 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 s'abonner à un sujet commun. Lorsque le service échoue dans une zone, les autres utilisateurs peuvent récupérer automatiquement la charge.
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 des applications. Il offre la plus haute fiabilité et le plus grand ensemble d'intégrations, ainsi qu'une gestion automatique de la capacité. Pub/Sub garantit la réplication synchrone de toutes les données dans au moins deux zones et la réplication au mieux de ses capacités dans une troisième zone supplémentaire.
Service Pub/Sub Lite Service de messagerie distinct, mais similaire, conçu à faible 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 ne sont stockés que dans une seule zone. Les sujets Lite régionaux répliquent les données de manière asynchrone vers une deuxième zone. De plus, Pub/Sub Lite nécessite de préprovisionner et de gérer la capacité de stockage et le débit. Pub/Sub Lite est réservé aux applications dont le coût faible justifie un travail opérationnel supplémentaire et une fiabilité réduite.
Pour en savoir plus 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. Les files d'attente de messages non distribués et le filtrage sont des exemples de telles fonctionnalités.
Une autre fonctionnalité que Pub/Sub adopte à partir du middleware de messagerie est le parallélisme par message, plutôt que la messagerie basée 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é.
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 :
- Client-serveur Pour envoyer des messages entre une application mobile/Web et un service, utilisez des produits qui incluent Firebase Realtime Database et Firebase Cloud Messaging.
- Appels de service asynchrones Utilisez Cloud Tasks.
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 les modèles Dataflow et SQL, qui permettent le traitement et l'intégration des données dans BigQuery et des lacs de données sur 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 dans la console Google Cloud. 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 Data Fusion.
- Surveillance, alerte 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 est compatible avec IAM précis, ce qui permet contrôle des accès pour des ressources individuelles.
- API Pub/Sub utilise les technologies d'API de service gRPC et REST standards ainsi que des bibliothèques clientes pour plusieurs langages.
- Déclencheurs, notifications et webhooks Pub/Sub propose la distribution en mode push des messages sous forme de requêtes HTTP POST aux webhooks. Vous pouvez 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 aux workflows sans serveur en plusieurs étapes. Le big data et l'orchestration analytique sont souvent effectués via Cloud Composer, qui est compatible avec les déclencheurs Pub/Sub. Vous pouvez également intégrer Pub/Sub à l'intégration d'applications (aperçu), une solution iPaaS (Integration Platform as a Service). L'intégration d'applications fournit un déclencheur Pub/Sub pour déclencher ou démarrer des intégrations.
- Integration Connectors(Preview) Ces connecteurs vous permettent de vous connecter à diverses sources de données. Grâce aux connecteurs, les services Google Cloud et les applications d'entreprise tierces sont exposés à vos intégrations via une interface standard transparente. Pour Pub/Sub, vous pouvez créer une connexion Pub/Sub à utiliser dans vos intégrations.
Concepts fondamentaux
- Thème 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 valeuren
pourraient être ajoutées aux messages pour les marquer comme lisibles par un abonné anglophone. - Éditeur Application qui crée et envoie des messages dans un ou plusieurs sujets.
- Abonné Application avec un abonnement à un ou plusieurs sujets pour recevoir des messages de celui-ci.
- Acquittement (ou "ack"). Signal envoyé par un abonné à Pub/Sub après avoir reçu un message. Les messages dont la réception a été confirmée sont supprimés de la file d'attente des messages de l'abonnement.
- Push et pull. Les deux méthodes 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 :
Le diagramme suivant illustre la façon dont un message passe d'un éditeur à un abonné. Pour la distribution push, l'acquittement est implicite dans la réponse à la requête push, tandis que pour la distribution pull, il nécessite un RPC distinct.
Étapes suivantes
- Commencez avec le guide de démarrage rapide de Pub/Sub ou le guide de démarrage rapide de Pub/Sub Lite.
- Consultez la présentation de l'architecture de Pub/Sub.
- Découvrez comment créer un système de messagerie Pub/Sub.
- Découvrez les tarifs de Pub/Sub.
- Découvrez les quotas et les limites de Pub/Sub et de Pub/Sub Lite.
- Consultez les notes de version de Pub/Sub.
- Découvrez l'ingénierie des données avec les services Google Cloud sur Qwiklabs.