Skip to content
Learni
Voir tous les tutoriels
Cloud Infrastructure

Comment maîtriser Cloud Pub/Sub sur GCP en 2026

18 minEXPERT
Google CloudPub/SubArchitecture Événementielle
Read in English

Introduction

Google Cloud Pub/Sub est le service de messagerie asynchrone de référence pour les architectures événementielles modernes. Il permet de découpler les producteurs et consommateurs à grande échelle tout en garantissant la livraison des messages. En 2026, les exigences de résilience, d'ordering et de latence exigent une maîtrise approfondie des fonctionnalités avancées comme les dead-letter queues, le exactly-once delivery et les schémas Avro. Ce tutoriel vous guide pas à pas vers une implémentation production-ready.

Prérequis

  • Compte Google Cloud avec facturation activée
  • SDK Google Cloud CLI installé et authentifié
  • Connaissances solides en TypeScript et Node.js 20+
  • Compréhension des patterns événementiels et des SLA

Configuration du projet et authentification

setup.sh
#!/bin/bash
PROJECT_ID="mon-projet-pubsub-2026"
gcloud config set project $PROJECT_ID
gcloud services enable pubsub.googleapis.com
npm install @google-cloud/pubsub typescript @types/node

Cette commande active l'API Pub/Sub et installe le client officiel. Assurez-vous que le compte de service dispose des rôles Pub/Sub Publisher et Subscriber.

Création du topic avec rétention avancée

create-topic.ts
import { PubSub } from '@google-cloud/pubsub';

const pubsub = new PubSub();

async function createAdvancedTopic() {
  const topicName = 'orders-topic';
  const [topic] = await pubsub.createTopic({
    name: topicName,
    messageRetentionDuration: { seconds: 86400 * 7 },
    messageStoragePolicy: { allowedPersistenceRegions: ['europe-west1'] }
  });
  console.log(`Topic créé : ${topic.name}`);
}
createAdvancedTopic();

Nous définissons une rétention de 7 jours et une politique de stockage régionale pour respecter les exigences de souveraineté des données.

Publication de messages avec ordering

publish-ordered.ts
import { PubSub } from '@google-cloud/pubsub';

const pubsub = new PubSub();

async function publishOrderedMessages() {
  const topic = pubsub.topic('orders-topic', { enableMessageOrdering: true });
  const messages = [
    { data: Buffer.from(JSON.stringify({orderId: '123', status: 'created'})), orderingKey: '123' },
    { data: Buffer.from(JSON.stringify({orderId: '123', status: 'paid'})), orderingKey: '123' }
  ];
  for (const msg of messages) {
    await topic.publishMessage(msg);
  }
}
publishOrderedMessages();

L'orderingKey garantit l'ordre de livraison par clé. Activez enableMessageOrdering sur le topic pour activer cette fonctionnalité critique en production.

Création d'une subscription avec dead-letter queue

create-subscription.ts
import { PubSub } from '@google-cloud/pubsub';

const pubsub = new PubSub();

async function createSubscriptionWithDLQ() {
  const topic = pubsub.topic('orders-topic');
  const dlqTopic = pubsub.topic('orders-dlq');
  await dlqTopic.create();
  const [subscription] = await topic.createSubscription('orders-processing', {
    deadLetterPolicy: {
      deadLetterTopic: dlqTopic.name,
      maxDeliveryAttempts: 5
    },
    ackDeadlineSeconds: 60
  });
  console.log(`Subscription créée : ${subscription.name}`);
}
createSubscriptionWithDLQ();

La dead-letter queue isole automatiquement les messages non traités après 5 tentatives, évitant la perte de données tout en permettant un traitement manuel ultérieur.

Consommation avec exactly-once et retry

consume-messages.ts
import { PubSub } from '@google-cloud/pubsub';

const pubsub = new PubSub();

async function consumeWithExactlyOnce() {
  const subscription = pubsub.subscription('orders-processing');
  subscription.on('message', async (message) => {
    try {
      const data = JSON.parse(message.data.toString());
      await processOrder(data);
      message.ack();
    } catch (error) {
      console.error('Erreur traitement:', error);
      message.nack();
    }
  });
}
async function processOrder(order: any) {
  // Logique métier critique
  console.log('Traitement commande:', order.orderId);
}
consumeWithExactlyOnce();

Le nack() permet un retry contrôlé. Combinez avec la DLQ pour une résilience maximale. Évitez les traitements longs dans le handler.

Bonnes pratiques

  • Toujours activer l'ordering lorsque la séquence des événements est critique
  • Configurer des dead-letter queues avec un nombre limité de tentatives
  • Utiliser des schémas Avro ou Protobuf pour garantir la compatibilité des messages
  • Monitorer les métriques de backlog et de latence via Cloud Monitoring
  • Limiter la taille des messages à 10 Mo et privilégier le batch publishing

Erreurs courantes à éviter

  • Oublier d'activer enableMessageOrdering sur le topic avant d'utiliser des ordering keys
  • Ne pas configurer de dead-letter queue, ce qui provoque des boucles infinies de retry
  • Ignorer les erreurs de désérialisation des messages sans nack approprié
  • Utiliser des subscriptions pull sans gestion de flux, entraînant des timeouts

Pour aller plus loin

Approfondissez vos compétences avec nos formations avancées Google Cloud. Découvrez également les patterns d'event-driven architecture et l'intégration avec Cloud Run et Dataflow.