0Pricing
Azure Fundamentals · Leçon

Azure Service Bus pour une messagerie découplée

Créez un espace de noms Service Bus avec des files d’attente et des rubriques, envoyez et recevez des messages depuis une application, puis configurez des files d’attente de lettres mortes pour traiter les messages en échec.

Azure Service Bus pour une messagerie découplée est une leçon Azure Fundamentals gratuite sur CoddyKit. Ceci est la leçon 2 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Azure Fundamentals, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Azure Fundamentals comprend 4 leçons au total.

Pourquoi découpler avec la messagerie ?

Dans les architectures fortement couplées, les services s’appellent de manière synchrone : si le service en aval est lent ou indisponible, l’appelant est lui aussi bloqué ou échoue. Les files d’attente de messages introduisent un tampon asynchrone entre les producteurs et les consommateurs, de sorte qu’un service en aval lent ne provoque pas une cascade d’échecs en amont. Azure Service Bus est un service de messagerie d’entreprise offrant des files d’attente (point à point) et des rubriques (publication-abonnement), avec des fonctionnalités de remise garantie, de conservation de l’ordre et de mise en file d’attente des messages non distribuables.

Espaces de noms et niveaux de Service Bus

Un espace de noms Service Bus est le conteneur de niveau supérieur pour toutes les entités de messagerie (files d’attente et rubriques) et fournit le point de terminaison FQDN (par exemple, myns.servicebus.windows.net). Les espaces de noms sont proposés selon trois niveaux : Basique (files d’attente uniquement, sans rubriques, taille maximale des messages de 256 Ko), Standard (files d’attente et rubriques, 256 Ko maximum) et Premium (files d’attente et rubriques, messages jusqu’à 100 Mo, capacité dédiée, intégration au réseau virtuel et récupération après sinistre géographique). Le niveau Premium est requis pour les charges de production nécessitant des performances couvertes par un SLA.

# Create a Service Bus namespace (Standard tier)
az servicebus namespace create \
  --resource-group myRG \
  --name myservicebusns \
  --location eastus \
  --sku Standard

Files d’attente : messagerie point à point

Une queue Service Bus stocke les messages dans l’ordre FIFO et remet chaque message à un seul consommateur. Les consommateurs reçoivent les messages à l’aide d’un mécanisme de consultation-verrouillage : le message est temporairement masqué pour les autres consommateurs pendant son traitement. Si le consommateur termine correctement le traitement, il appelle CompleteMessage() pour supprimer le message de la queue. Si le traitement échoue, le consommateur appelle AbandonMessage() et le message redevient visible pour une nouvelle tentative. Après un nombre configurable de tentatives de remise, les messages impossibles à traiter sont déplacés vers la file d’attente des messages non distribuables (DLQ).

# Create a Service Bus queue with DLQ enabled
az servicebus queue create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --name orders \
  --max-delivery-count 5 \
  --default-message-time-to-live P7D \
  --dead-lettering-on-message-expiration true

Rubriques et abonnements

Les rubriques implémentent le modèle publication-abonnement : un producteur envoie un message à une rubrique, et chacun des abonnements associés à cette rubrique reçoit une copie du message. Les abonnements peuvent avoir des filtres (expressions SQL ou de corrélation) afin de ne recevoir qu’un sous-ensemble des messages — par exemple, un abonnement HighPriority qui ne reçoit que les messages dont la propriété Priority est égale à High. Cela permet à une seule rubrique de distribuer les messages à de nombreux services en aval, chacun s’intéressant à un sous-ensemble différent des événements.

# Create a topic and two subscriptions with filters
az servicebus topic create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --name order-events

az servicebus topic subscription create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --topic-name order-events \
  --name high-priority-sub

az servicebus topic subscription rule create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --topic-name order-events \
  --subscription-name high-priority-sub \
  --name PriorityFilter \
  --filter-sql-expression 'Priority = '"'"'High'"'"''

Envoi et réception de messages

Le SDK Azure Service Bus fournit un ServiceBusClient pour envoyer et recevoir des messages. Pour envoyer un message, créez un ServiceBusSender et appelez SendMessageAsync(). Pour recevoir un message, créez un ServiceBusReceiver et appelez ReceiveMessageAsync() (réception par interrogation), ou utilisez un ServiceBusProcessor avec un gestionnaire d’événements pour un traitement continu fondé sur la poussée. L’utilisation de DefaultAzureCredential avec le SDK Service Bus élimine le besoin de chaînes de connexion et préserve le modèle sans mot de passe.

# Python: Send a message to a Service Bus queue
from azure.servicebus import ServiceBusClient, ServiceBusMessage
from azure.identity import DefaultAzureCredential

credential = DefaultAzureCredential()
client = ServiceBusClient(
  fully_qualified_namespace='myservicebusns.servicebus.windows.net',
  credential=credential
)
with client.get_queue_sender(queue_name='orders') as sender:
    msg = ServiceBusMessage('{ 'orderId': '12345', 'amount': 99.99 }')
    sender.send_messages(msg)
    print('Message sent')

File d’attente des messages non distribuables

La file d’attente des messages non distribuables (DLQ) est une sous-file d’attente qui reçoit automatiquement les messages qui ne peuvent pas être remis. Les messages sont transférés vers la file des messages non distribuables lorsqu’ils dépassent le nombre maximal de remises, lorsqu’ils expirent (TTL écoulé) ou lorsqu’ils échouent à l’évaluation d’un filtre d’abonnement à une rubrique. La surveillance de la DLQ est essentielle : une DLQ qui augmente indique un échec systématique du traitement. Les messages de la DLQ conservent leur contenu d’origine ainsi que les propriétés motif de mise en file d’attente des messages non distribuables et description, ajoutées par Service Bus pour aider à diagnostiquer la cause racine.

# Read messages from the dead-letter queue
az servicebus queue show \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --name 'orders/$DeadLetterQueue' \
  --query 'countDetails.deadLetterMessageCount'

Sessions de messages pour conserver l’ordre

Les sessions permettent de conserver strictement l’ordre des messages appartenant au même groupe logique. Chaque message est associé à un SessionId (par exemple, un identifiant client ou un identifiant de commande), et un consommateur prenant en charge les sessions reçoit exclusivement tous les messages d’une session donnée dans l’ordre FIFO. Les sessions sont essentielles pour les flux de travail dont les étapes doivent être exécutées dans l’ordre — par exemple, le traitement de tous les événements d’une commande spécifique : Créée → PaymentReceived → Expédiée → Livrée. Les sessions sont activées lors de la création de la queue ou de l’abonnement.

Service Bus, Event Grid ou Event Hubs

Ces trois services de messagerie Azure sont souvent confondus : Service Bus est destiné à la messagerie d’entreprise fiable et transactionnelle, avec conservation de l’ordre, sessions et DLQ — il convient au traitement des commandes, aux transactions financières et à l’orchestration des flux de travail. Event Grid sert au routage réactif d’événements (un objet blob a été chargé, une VM a été supprimée), avec distribution à plusieurs gestionnaires, mais sans conservation de l’ordre ni possibilité de relecture. Event Hubs est destiné à la diffusion d’événements à haut débit (des millions d’événements par seconde), avec possibilité de relecture — il convient à la télémétrie IoT et à l’ingestion de journaux. Faites votre choix en fonction des exigences de conservation de l’ordre, de débit et de durabilité.

Récupération après sinistre géographique

La récupération après sinistre géographique (Geo-DR) de Service Bus réplique les métadonnées de l’espace de noms (files d’attente, rubriques, abonnements et stratégies d’accès) vers une région secondaire. Les régions appairées partagent un nom d’hôte d’alias ; si la région principale tombe en panne, vous lancez un basculement et l’alias est résolu vers la région secondaire. Notez que les données des messages (messages en cours de traitement) ne sont pas répliquées dans le niveau Standard : seul le niveau Premium réplique les messages avec Geo-DR. Pour une messagerie stratégique, utilisez Premium avec Geo-DR afin de respecter les exigences de RTO et de RPO.

Mise à l’échelle et entités partitionnées

Pour les scénarios à haut débit, activez le partitionnement des files d’attente et des rubriques lors de leur création. Les entités partitionnées utilisent en interne plusieurs courtiers de messages et fragments de stockage, ce qui multiplie la capacité de débit. Dans le niveau Standard, les entités partitionnées peuvent atteindre une taille totale de 80 Go. Chaque message est acheminé vers une partition en fonction de sa propriété PartitionKey (l’identifiant de session est utilisé par défaut si les sessions sont activées). Le partitionnement est une décision unique prise lors de la création : vous ne pouvez pas partitionner une queue existante. Utilisez le niveau Premium pour bénéficier du débit garanti le plus élevé sans la complexité du partitionnement.

# Create a partitioned queue (Standard tier)
az servicebus queue create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --name orders-partitioned \
  --enable-partitioning true

Surveillance de l’état de Service Bus

Principales métriques Service Bus à surveiller dans la supervision Azure : Active Messages (profondeur de la queue — une profondeur croissante indique un retard des consommateurs), Dead-lettered Messages (échecs de traitement), Server Errors et User Errors (problèmes d’authentification et de limitation du débit), ainsi que Incoming Requests (débit global). Configurez des alertes de métriques afin que les équipes d’exploitation soient averties lorsque la file d’attente des messages non distribuables dépasse un seuil ou lorsque les messages actifs ne sont pas consommés pendant une période prolongée.

Vérification rapide

Vérifiez votre compréhension des concepts de Fondamentaux de Microsoft Azure (AZ-900) présentés dans cette leçon.

Récapitulatif de la leçon

Dans cette leçon, vous avez appris que les files d’attente Service Bus fournissent une messagerie point à point avec remise par consultation-verrouillage et une file d’attente des messages non distribuables pour les messages en échec, que les rubriques et abonnements distribuent les messages à plusieurs consommateurs au moyen de règles de filtrage, et que les sessions permettent de traiter dans l’ordre les messages appartenant au même groupe logique. Ensuite, nous découvrirons les applications conteneurisées Azure pour déployer des microservices modernes.

Questions Fréquemment Posées

La leçon « Azure Service Bus pour une messagerie découplée » est-elle gratuite ?

Oui — le texte complet de « Azure Service Bus pour une messagerie découplée » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Azure Fundamentals, passe à CoddyKit PRO. Le cours Azure Fundamentals comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Azure Service Bus pour une messagerie découplée » ?

Créez un espace de noms Service Bus avec des files d’attente et des rubriques, envoyez et recevez des messages depuis une application, puis configurez des files d’attente de lettres mortes pour trait… Tu pratiques Azure Fundamentals avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Azure Fundamentals ?

Aucune expérience préalable n'est requise. Azure Fundamentals sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 2 sur 4.

Combien de temps prend la leçon « Azure Service Bus pour une messagerie découplée » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Azure Fundamentals ?

Oui. Chaque leçon Azure Fundamentals inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Identité managée pour une authentification sans mot de passe
  2. Azure Service Bus pour une messagerie découplée
  3. Azure Container Apps
  4. Flux de travail de développement de bout en bout
← Retour à Azure Fundamentals