Qu'est-ce que Cloud Pub/Sub ?

Cloud Pub/Sub apporte au cloud la flexibilité et la fiabilité des middlewares orientés message d'entreprise. Parallèlement, Cloud Pub/Sub est un système évolutif et durable d'ingestion et de diffusion d'événements, qui sert de base aux pipelines d'analyse de flux modernes. En fournissant une messagerie asynchrone de type plusieurs à plusieurs, qui dissocie les expéditeurs et les destinataires, ce service permet une communication sécurisée et hautement disponible entre des applications développées indépendamment. Cloud Pub/Sub offre une messagerie durable à faible latence qui aide les développeurs à intégrer rapidement les systèmes hébergés sur Google Cloud Platform et en externe.

Êtes-vous un développeur de messagerie expérimenté et souhaitez-vous commencer immédiatement ? Lisez le Guide de démarrage rapide. Pour une introduction plus complète, reportez-vous à la rubrique Créer un système Cloud Pub/Sub fonctionnel. Reportez-vous également à la documentation sur Cloud Pub/Sub et à la documentation sur les bibliothèques clientes, deux ressources couramment consultées par les nouveaux utilisateurs.

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.

Flux de messages Cloud Pub/Sub

Voici un aperçu des composants du système Pub/Sub et de la manière dont les messages circulent entre eux :

  1. Une application d'éditeur crée un sujet dans le service Cloud 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. Cloud Pub/Sub transmet les messages d'un sujet à tous ses abonnements, individuellement. Un abonnement reçoit des messages de deux façons. Soit Cloud Pub/Sub les distribue dans le point de terminaison choisi par l'abonné (pushing) soit l'abonné les récupère à partir du service (pulling).
  4. L'abonné reçoit les messages en attente de son abonnement et en accuse réception auprès du service Cloud Pub/Sub.
  5. Lorsque l'abonné a confirmé la réception du message, celui-ci est supprimé 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 à 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 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 Cloud Pub/Sub

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation sur Cloud Pub/Sub