0Pricing
Azure Fundamentals · Lektion

Azure Service Bus für entkoppelte Nachrichtenübermittlung

Erstellen Sie einen Service-Bus-Namespace mit Warteschlangen und Themen, senden und empfangen Sie Nachrichten aus einer Anwendung und konfigurieren Sie Dead-Letter-Warteschlangen für die Behandlung fehlgeschlagener Nachrichten.

Azure Service Bus für entkoppelte Nachrichtenübermittlung ist eine kostenlose Azure Fundamentals-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Azure Fundamentals-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Azure Fundamentals-Kurs umfasst insgesamt 4 Lektionen.

Warum Nachrichtenübermittlung zur Entkopplung verwenden?

In eng gekoppelten Architekturen rufen Dienste einander synchron auf – wenn der nachgelagerte Dienst langsam oder nicht verfügbar ist, wird auch der aufrufende Dienst blockiert oder fällt aus. Nachrichtenwarteschlangen schaffen einen asynchronen Puffer zwischen Produzenten und Konsumenten, sodass ein langsamer nachgelagerter Dienst keine Fehlerkaskade zu den vorgelagerten Diensten auslöst. Azure Service Bus ist der Messagingdienst von Microsoft für geschäftskritische Anwendungen und bietet Warteschlangen (Punkt-zu-Punkt) sowie Themen (Publish-Subscribe) mit garantierter Zustellung, Nachrichtenreihenfolge und Dead-Lettering-Funktionen.

Service Bus-Namespaces und -Tarife

Ein Service Bus-Namespace ist der übergeordnete Container für alle Messagingentitäten (Warteschlangen und Themen) und stellt den FQDN-Endpunkt bereit (z. B. myns.servicebus.windows.net). Namespaces sind in drei Tarifen verfügbar: Basic (nur Warteschlangen, keine Themen, maximale Nachrichtengröße 256 KB), Standard (Warteschlangen und Themen, maximal 256 KB) und Premium (Warteschlangen und Themen, Nachrichten bis zu 100 MB, dedizierte Kapazität, VNet-Integration, geografische Notfallwiederherstellung). Für Produktionsworkloads, die eine durch ein SLA abgesicherte Leistung benötigen, ist Premium erforderlich.

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

Warteschlangen: Punkt-zu-Punkt-Nachrichtenübermittlung

Eine Service Bus-Warteschlange speichert Nachrichten in FIFO-Reihenfolge und stellt jede Nachricht genau an einen Konsumenten zu. Konsumenten empfangen Nachrichten über einen Peek-Lock-Mechanismus: Während der Verarbeitung wird die Nachricht vorübergehend für andere Konsumenten ausgeblendet. Bei erfolgreicher Verarbeitung ruft der Konsument CompleteMessage() auf, um die Nachricht aus der Warteschlange zu entfernen. Wenn die Verarbeitung fehlschlägt, ruft der Konsument AbandonMessage() auf, und die Nachricht wird für einen weiteren Versuch wieder sichtbar. Nach einer konfigurierbaren Anzahl von Zustellversuchen werden nicht verarbeitbare Nachrichten in die Dead-Letter-Warteschlange (DLQ) verschoben.

# 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

Themen und Abonnements

Themen implementieren das Publish-Subscribe-Muster: Ein Produzent sendet eine Nachricht an ein Thema, und beliebig viele Abonnements dieses Themas erhalten jeweils eine Kopie der Nachricht. Abonnements können über Filter (SQL- oder Korrelationsausdrücke) so konfiguriert werden, dass sie nur eine Teilmenge der Nachrichten empfangen – beispielsweise ein Abonnement HighPriority, das nur Nachrichten empfängt, bei denen die Eigenschaft Priority dem Wert High entspricht. So kann ein einzelnes Thema Nachrichten an viele nachgelagerte Dienste verteilen, die jeweils an einer anderen Teilmenge von Ereignissen interessiert sind.

# 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'"'"''

Nachrichten senden und empfangen

Das Azure Service Bus SDK stellt zum Senden und Empfangen einen ServiceBusClient bereit. Zum Senden erstellen Sie einen ServiceBusSender und rufen SendMessageAsync() auf. Zum Empfangen erstellen Sie einen ServiceBusReceiver und rufen ReceiveMessageAsync() auf (Pull-basiert), oder Sie verwenden einen ServiceBusProcessor mit einem Ereignishandler für eine kontinuierliche Push-basierte Verarbeitung. Durch die Verwendung von DefaultAzureCredential mit dem Service Bus SDK werden Verbindungszeichenfolgen überflüssig, sodass das kennwortlose Muster beibehalten wird.

# 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')

Dead-Letter-Warteschlange

Die Dead-Letter-Warteschlange (DLQ) ist eine Unterwarteschlange, in der automatisch Nachrichten abgelegt werden, die nicht zugestellt werden können. Nachrichten werden in die Dead-Letter-Warteschlange verschoben, wenn sie die maximale Zustellungsanzahl überschreiten, ablaufen (die TTL verstrichen ist) oder die Auswertung eines Themenabonnementfilters fehlschlägt. Die Überwachung der DLQ ist unverzichtbar – eine wachsende DLQ weist auf einen systematischen Verarbeitungsfehler hin. DLQ-Nachrichten behalten ihren ursprünglichen Inhalt sowie die von Service Bus hinzugefügten Eigenschaften Grund für Dead-Lettering und Beschreibung, die bei der Ermittlung der Ursache helfen.

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

Nachrichtensitzungen für die Reihenfolge

Sitzungen ermöglichen eine strikt geordnete Verarbeitung von Nachrichten, die zu derselben logischen Gruppe gehören. Jede Nachricht wird mit einer SessionId versehen (z. B. einer Kunden- oder Bestell-ID), und ein sitzungsfähiger Konsument empfängt alle Nachrichten einer bestimmten Sitzung exklusiv in FIFO-Reihenfolge. Sitzungen sind für Workflows unverzichtbar, deren Schritte in einer bestimmten Reihenfolge ausgeführt werden müssen – etwa bei der Verarbeitung aller Ereignisse für eine bestimmte Bestellung: Created → PaymentReceived → Shipped → Delivered. Sitzungen werden beim Erstellen der Warteschlange oder des Abonnements aktiviert.

Service Bus im Vergleich zu Event Grid und Event Hubs

Diese drei Azure-Messagingdienste werden häufig verwechselt: Service Bus dient der zuverlässigen, transaktionalen Messagingübermittlung in Unternehmen mit Reihenfolge, Sitzungen und DLQ – geeignet für Auftragsverarbeitung, Finanztransaktionen und Workfloworchestrierung. Event Grid dient dem reaktiven Ereignisrouting (ein Blob wurde hochgeladen, eine VM wurde gelöscht) mit Verteilung an mehrere Handler, jedoch ohne Reihenfolge oder Replay. Event Hubs dient dem Event Streaming mit hohem Durchsatz (Millionen von Ereignissen pro Sekunde) und Replay-Funktion – geeignet für IoT-Telemetrie und Protokollaufnahme. Treffen Sie Ihre Wahl anhand der Anforderungen an Reihenfolge, Durchsatz und Dauerhaftigkeit.

Geografische Notfallwiederherstellung

Service Bus Geo-Disaster Recovery (Geo-DR) repliziert die Namespace-Metadaten (Warteschlangen, Themen, Abonnements und Zugriffsrichtlinien) in eine sekundäre Region. Die gekoppelten Regionen verwenden einen gemeinsamen Alias-Hostnamen. Wenn die primäre Region ausfällt, initiieren Sie ein Failover, und der Alias wird in die sekundäre Region aufgelöst. Beachten Sie, dass Nachrichtendaten (Nachrichten während der Verarbeitung) im Tarif Standard nicht repliziert werden – nur Geo-DR im Tarif Premium repliziert Nachrichten. Verwenden Sie für geschäftskritische Messaginganwendungen Premium mit Geo-DR, um die Anforderungen an RTO und RPO zu erfüllen.

Skalierung und partitionierte Entitäten

Aktivieren Sie für Szenarien mit hohem Durchsatz beim Erstellen von Warteschlangen und Themen die Partitionierung. Partitionierte Entitäten verwenden intern mehrere Nachrichtenbroker und Speicherfragmente und vervielfachen dadurch die Durchsatzkapazität. Im Tarif Standard haben partitionierte Entitäten eine Gesamtgröße von bis zu 80 GB. Jede Nachricht wird anhand ihrer Eigenschaft PartitionKey an eine Partition weitergeleitet (standardmäßig anhand der Sitzungs-ID, wenn Sitzungen aktiviert sind). Die Partitionierung ist eine einmalige Entscheidung beim Erstellen – eine vorhandene Warteschlange kann nicht nachträglich partitioniert werden. Verwenden Sie den Premium-Tarif für den höchsten garantierten Durchsatz ohne die Komplexität der Partitionierung.

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

Überwachen der Service Bus-Integrität

Wichtige Service Bus-Metriken, die Sie in Azure Monitor überwachen sollten: Active Messages (Warteschlangentiefe – eine zunehmende Tiefe weist auf einen Rückstand bei den Konsumenten hin), Dead-lettered Messages (Verarbeitungsfehler), Server Errors und User Errors (Probleme mit Authentifizierung und Drosselung) sowie Incoming Requests (Gesamtdurchsatz). Konfigurieren Sie Metrikwarnungen, damit Betriebsteams benachrichtigt werden, wenn die Dead-Letter-Warteschlange einen Schwellenwert überschreitet oder aktive Nachrichten über einen längeren Zeitraum nicht verarbeitet werden.

Kurzer Test

Testen Sie Ihr Verständnis der Konzepte aus dieser Lektion zu Microsoft Azure Fundamentals (AZ-900).

Zusammenfassung der Lektion

In dieser Lektion haben Sie Folgendes gelernt: Service Bus-Warteschlangen ermöglichen Punkt-zu-Punkt-Nachrichtenübermittlung mit Peek-Lock-Zustellung und einer Dead-Letter-Warteschlange für fehlgeschlagene Nachrichten. Themen und Abonnements verteilen Nachrichten anhand von Filterregeln an mehrere Konsumenten, und Sitzungen ermöglichen die geordnete Verarbeitung von Nachrichten, die zur selben logischen Gruppe gehören. Als Nächstes sehen wir uns Azure Container Apps für die Bereitstellung moderner Microservices an.

Häufig gestellte Fragen

Ist die Lektion „Azure Service Bus für entkoppelte Nachrichtenübermittlung“ kostenlos?

Ja — der vollständige Text von „Azure Service Bus für entkoppelte Nachrichtenübermittlung“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Azure Fundamentals-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Azure Fundamentals-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Azure Service Bus für entkoppelte Nachrichtenübermittlung“?

Erstellen Sie einen Service-Bus-Namespace mit Warteschlangen und Themen, senden und empfangen Sie Nachrichten aus einer Anwendung und konfigurieren Sie Dead-Letter-Warteschlangen für die Behandlung f… Du übst Azure Fundamentals mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Azure Fundamentals zu starten?

Keine Vorkenntnisse erforderlich. Azure Fundamentals auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.

Wie lange dauert die Lektion „Azure Service Bus für entkoppelte Nachrichtenübermittlung“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Azure Fundamentals-Lektion Code schreiben und ausführen?

Ja. Jede Azure Fundamentals-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. Verwaltete Identität für kennwortlose Authentifizierung
  2. Azure Service Bus für entkoppelte Nachrichtenübermittlung
  3. Azure Container Apps
  4. End-to-End-Entwicklerworkflow
← Zurück zu Azure Fundamentals