Was ist Azure Service Bus?

  • Artikel

Bei Azure Service Bus handelt es sich um einen vollständig verwalteten Nachrichtenbroker für Unternehmen mit Nachrichtenwarteschlangen und Publish/Subscribe-Themen. Service Bus wird verwendet, um Anwendungen und Dienste voneinander zu entkoppeln und so die folgenden Vorteile zu erzielen:

  • Übergreifender Lastenausgleich für konkurrierende Worker
  • Sicherheit beim Routing und der Übertragung von Daten sowie Kontrolle über Dienst- und Anwendungsgrenzen hinweg
  • Koordinierung von Transaktionsausgaben mit hohen Anforderungen an die Zuverlässigkeit

Übersicht

Die Datenübertragung zwischen verschiedenen Anwendungen und Diensten erfolgt mithilfe von Nachrichten. Eine Nachricht ist ein Container, der über Metadaten verfügt und Daten enthält. Bei den Daten kann es sich um eine beliebige Art von Informationen handeln, z. B. strukturierte Daten in den folgenden gängigen Formaten: JSON, XML, Apache Avro, Nur-Text.

Im Anschluss finden Sie einige gängige Messagingszenarien:

  • Messaging: Übertragung von Geschäftsdaten (beispielsweise Verkäufe/Bestellungen, Journale oder Bestandsbewegungen)

  • Entkoppelung von Anwendungen: Höhere Zuverlässigkeit und bessere Skalierbarkeit von Anwendungen und Diensten. Producer und Consumer müssen nicht gleichzeitig online bzw. immer verfügbar sein. Die Last wird verteilt, damit ein Dienst nicht aufgrund von Datenverkehrsspitzen überlastet wird.

  • Lastenausgleich: Ermöglicht es, dass mehrere konkurrierende Consumer gleichzeitig Daten aus einer Warteschlange auslesen und die Consumer dann jeweils auf sichere Weise die exklusive Eigentümerschaft für bestimmte Nachrichten erhalten.

  • Themen und Abonnements: Ermöglichen 1:n-Beziehungen zwischen Herausgebern und Abonnenten, damit Abonnenten bestimmte Nachrichten aus einem Datenstrom mit veröffentlichten Nachrichten auswählen können.

  • Transaktionen: Ermöglichen Ihnen die Durchführung mehrerer Vorgänge im Rahmen einer atomischen Transaktion. Beispielsweise können die folgenden Vorgänge im Rahmen einer Transaktion durchgeführt werden.

    1. Abrufen einer Nachricht aus einer Warteschlange
    2. Posten von Ergebnissen in einer oder mehreren anderen Warteschlangen
    3. Verschieben der Eingabenachricht aus der ursprünglichen Warteschlange

    Die Ergebnisse werden für nachgeschaltete Consumer erst im Erfolgsfall sichtbar, z. B. der erfolgreiche Abgleich der Eingabenachricht. Dies ermöglicht die Verwendung einer Semantik mit einmaliger Verarbeitung. Dieses Transaktionsmodell ist eine stabile Grundlage für das Muster für Kompensierende Transaktionen im weiteren Lösungskontext.

  • Nachrichtensitzungen: Hiermit wird eine umfassende Koordinierung von Workflows und Multiplex-Übertragungen implementiert, für die eine strikte Nachrichtensortierung oder -verzögerung erforderlich ist.

Wenn Sie bereits mit anderen Nachrichtenbrokern wie Apache ActiveMQ vertraut sind, werden Ihnen die Service Bus-Konzepte bekannt vorkommen, weil sie ähnlich sind. Da es sich bei Service Bus um ein PaaS-Angebot (Platform-as-a-Service) handelt, besteht ein wichtiger Unterschied darin, dass Sie sich nicht um die folgenden Aktionen kümmern müssen. Azure übernimmt die Durchführung dieser Aufgaben für Sie.

  • Achten auf Hardwarefehler
  • Sicherstellen der Patches für die Betriebssysteme oder die Produkte
  • Anordnen von Protokollen und Verwalten des Speicherplatzes
  • Verarbeiten von Sicherungsvorgängen
  • Ausführen von Failovern auf einen Reservecomputer

Konzepte

In diesem Abschnitt werden die grundlegenden Konzepte von Service Bus erläutert.

Warteschlangen

Nachrichten werden an Warteschlangen gesendet und daraus empfangen. Warteschlangen dienen zum Speichern von Nachrichten, bis die empfangende Anwendung empfangs- und verarbeitungsbereit ist.

Abbildung einer Service Bus-Warteschlange mit einem Absender und einem Empfänger, die Nachrichten senden und empfangen

Nachrichten in Warteschlangen werden bei ihrem Eingang sortiert und mit einem Zeitstempel versehen. Nachdem der Broker die Nachricht akzeptiert hat, wird sie immer dauerhaft im dreifach redundanten Speicher vorgehalten – verteilt auf die Verfügbarkeitszonen, falls die Nutzung in Zonen für den Namespace aktiviert ist. Von Service Bus werden Nachrichten im Arbeitsspeicher oder flüchtigen Speicher belassen, bis sie vom Client als akzeptiert gemeldet wurden.

Nachrichten werden im Pull-Modus (also nur auf Anforderung) zugestellt. Im Gegensatz zum Busy-Polling-Modell einiger anderer Cloudwarteschlangen ist der Pullvorgang langlebig und wird erst abgeschlossen, nachdem eine Nachricht verfügbar ist.

Hinweis

Einen Vergleich von Service Bus-Warteschlangen mit Storage-Warteschlangen finden Sie unter Storage-Warteschlangen und Service Bus-Warteschlangen – Vergleich und Gegenüberstellung.

Themen

Nachrichten können auch unter Verwendung von Themen gesendet und empfangen werden. Themen sind in Veröffentlichungs-/Abonnementszenarien hilfreich. Bei der Punkt-zu-Punkt-Kommunikation werden dagegen häufig Warteschlangen verwendet.

Abbildung eines Service Bus-Themas mit einem Absender und mehreren Empfängern

Themen können über mehrere, unabhängige Abonnements verfügen, die an das Thema angefügt sind und ansonsten genauso wie Warteschlangen auf der Empfängerseite funktionieren. Ein Abonnent eines Themas kann eine Kopie jeder Nachricht erhalten, die an das Thema gesendet wird. Bei Abonnements handelt es sich um benannte Entitäten. Abonnements sind standardmäßig dauerhafter Natur, aber sie können auch so konfiguriert werden, dass sie ablaufen und dann automatisch gelöscht werden. Über die JMS-API (Java Message Service) ermöglicht Service Bus Premium Ihnen auch die Erstellung von flüchtigen Abonnements, die nur für die Dauer der Verbindung bestehen.

Sie können Regeln für ein Abonnement definieren. Eine Abonnementregel verfügt über einen Filter, um für die Nachricht eine Bedingung für das Kopieren in das Abonnement zu definieren, und über eine optionale Aktion, mit der die Metadaten der Nachricht geändert werden können. Weitere Informationen finden Sie unter Themenfilter und -aktionen. Dieses Feature ist in den folgenden Szenarien nützlich:

  • Sie möchten nicht, dass ein Abonnement alle Nachrichten empfängt, die an ein Thema gesendet werden.
  • Sie möchten Nachrichten mit zusätzlichen Metadaten kennzeichnen, wenn sie ein Abonnement durchlaufen.

Hinweis

Weitere Informationen zu Warteschlangen und Themen finden Sie unter Service Bus-Warteschlangen, -Themen und -Abonnements.

Namespaces

Ein Namespace ist ein Container für alle Messagingkomponenten (Warteschlangen und Themen). Ein Namespace kann eine oder mehrere Warteschlangen und Themen enthalten und dient häufig als Anwendungscontainer.

Ein Namespace ist damit vergleichbar, was in der Terminologie anderer Broker als Server bezeichnet wird, aber die Konzepte sind nicht völlig äquivalent. Ein Service Bus-Namespace ist Ihr eigenes Kapazitätssegment eines großen Clusters, der aus Dutzenden von aktiven virtuellen Computern besteht. Optional kann er über drei Azure-Verfügbarkeitszonen reichen. So profitieren Sie von allen Vorteilen in Bezug auf die Verfügbarkeit und Stabilität, die sich aus der umfassenden Ausführung des Nachrichtenbrokers ergeben. Zudem müssen Sie sich nicht mit den zugrunde liegenden komplexen Zusammenhängen beschäftigen. Service Bus steht für serverloses Messaging.

Erweiterte Funktionen

Service Bus verfügt auch über erweiterte Features für komplexere Messagingszenarien. Die wichtigsten dieser Features werden in den folgenden Abschnitten beschrieben:

Nachrichtensitzungen

Verwenden Sie Sitzungen, um eine FIFO-Garantie (First-in, First-out) bei der Verarbeitung von Nachrichten in Service Bus-Warteschlangen oder -Abonnements umzusetzen. Sitzungen können auch zum Implementieren von Anforderung/Antwort-Mustern verwendet werden. Das Anforderung/Antwort-Muster ermöglicht es der sendenden Anwendung, eine Anforderung zu senden, und bietet dem Empfänger die Möglichkeit, eine Antwort ordnungsgemäß an die Absenderanwendung zurückzusenden. Weitere Informationen finden Sie unter Nachrichtensitzungen.

Automatische Weiterleitung

Mit der Funktion Automatische Weiterleitung können Sie eine Warteschlange oder ein Abonnement mit einer weiteren Warteschlange oder einem Thema aus dem selben Namespace verketten. Wenn die automatische Weiterleitung aktiviert ist, entfernt Service Bus die Nachrichten automatisch, die in der ersten Warteschlange oder dem Abonnement (Quelle) platziert wurden, und fügt sie in die zweite Warteschlange oder das Thema (Ziel) ein. Weitere Informationen finden Sie unter Verketten von Service Bus-Entitäten mit automatischer Weiterleitung.

Unzustellbare Nachrichten

Service Bus-Warteschlangen und -Themenabonnements verfügen über eine sekundäre Unterwarteschlange, die als „Warteschlange für unzustellbare Nachrichten“ (DLQ, Dead-letter queue) bezeichnet wird. In der Warteschlange für unzustellbare Nachrichten werden Nachrichten gespeichert, die an keinen Empfänger übermittelt oder nicht verarbeitet werden können. Nachrichten aus der DLQ können entfernt und untersucht werden. Eine Anwendung kann mithilfe eines Operators Probleme beheben und die Nachricht erneut senden, den Fehler protokollieren und eine Korrekturmaßnahme durchführe. Weitere Informationen finden Sie unter Übersicht über Service Bus-Warteschlangen für unzustellbare Nachrichten.

Zeitgesteuerte Zustellung

Sie können Nachrichten zur verzögerten Verarbeitung an eine Warteschlange oder an ein Thema senden. Sie können einen Auftrag beispielsweise so planen, dass er zu einem bestimmten Zeitpunkt für die Verarbeitung durch ein System verfügbar wird. Weitere Informationen finden Sie unter Geplante Nachrichten.

Nachrichtenverzögerung

Wenn eine Warteschlangen- oder ein Abonnementclient eine Nachricht erhält, die verarbeitet werden soll, aber die Verarbeitung aufgrund von besonderen Umständen innerhalb der Anwendung zu diesem Zeitpunkt nicht möglich ist, kann die Entität das Abrufen der Nachricht auf später verschieben. Die Nachricht bleibt in der Warteschlange oder im Abonnement, wird jedoch zurückgestellt. Weitere Informationen finden Sie unter Nachrichtenverzögerung.

Transaktionen

Eine Transaktion gruppiert zwei oder mehr Vorgänge in einem Ausführungsbereich. Service Bus unterstützt Gruppierungsvorgänge für eine einzelne Nachrichtenentität (Warteschlange, Thema, Abonnement) innerhalb eines Transaktionsbereichs. Weitere Informationen finden Sie unter Übersicht über die Service Bus-Transaktionsverarbeitung.

Filter und Aktionen

Abonnenten können definieren, welche Nachrichten von einem Thema empfangen werden sollen. Diese Nachrichten werden in Form von benannten Abonnementregeln angegeben. Jede Regel besteht aus einer Filterbedingung, mit der bestimmte Nachrichten ausgewählt werden, und enthält optional eine Aktion, mit der die ausgewählte Nachricht kommentiert wird. Für jede übereinstimmende Regelbedingung erzeugt das Abonnement eine Kopie der Nachricht, die für jede übereinstimmende Regel anders kommentiert werden kann. Weitere Informationen finden Sie unter Themenfilter und -aktionen.

Automatisches Löschen nach Leerlauf

Automatisches Löschen nach Leerlauf ermöglicht das Angeben eines Leerlaufintervalls, nach dem die Warteschlange automatisch gelöscht wird. Das Intervall wird zurückgesetzt, wenn in der Warteschlange Datenverkehr vorhanden ist. Die Mindestdauer ist fünf Minuten.

Duplikaterkennung

Sollte ein Fehler dazu führen, dass der Client das Ergebnis eines Sendevorgangs nicht mit Bestimmtheit ermitteln kann, sorgt die Duplikaterkennung für Klarheit: Der Absender kann die gleiche Nachricht erneut senden, und die Warteschlange oder das Thema verwirft mögliche Duplikate. Weitere Informationen finden Sie unter Duplikaterkennung.

Sicherheit

Service Bus unterstützt Sicherheitsprotokolle wie Shared Access Signatures (SAS), die rollenbasierte Zugriffssteuerung (Role Based Access Control, RBAC) und verwaltete Identitäten für Azure-Ressourcen.

Service Bus unterstützt die Standardprotokolle AMQP 1.0 (Advance Message Queueing Protocol) und HTTP/REST.

Georedundante Notfallwiederherstellung

Sollte eine Azure-Region oder ein Azure-Datencenter ausfallen, kann die Datenverarbeitung dank georedundanter Notfallwiederherstellung in einer anderen Region oder in einem anderen Datencenter fortgesetzt werden.

Hinweis

Weitere Informationen zu diesen Features finden Sie unter Azure Service Bus: Erweiterte Features.

Sicherstellen der Konformität mit Standards und Protokollen

Das primäre Verbindungsprotokoll für Service Bus ist Advanced Messaging Queueing Protocol (AMQP) 1.0 (offener ISO/IEC-Standard). Es ermöglicht Kunden das Schreiben von Anwendungen für die Verwendung mit Service Bus und lokalen Brokern wie ActiveMQ oder RabbitMQ. Der Protokollleitfaden zu AMQP enthält ausführliche Informationen, die Ihnen weiterhelfen, falls Sie eine Abstraktion dieser Art erstellen möchten.

Service Bus Premium ist vollständig mit der Java Message Service (JMS) 2.0-API für Java/Jakarta EE konform. Darüber hinaus wird von Service Bus Standard auch die JMS 1.1-Unterversion für Warteschlangen unterstützt. JMS ist eine gängige Abstraktion für Nachrichtenbroker und kann mit vielen Anwendungen und Frameworks integriert werden, z. B. das häufig verwendete Spring-Framework. Für den Wechsel von anderen Brokern zu Azure Service Bus müssen Sie lediglich die Topologie mit den Warteschlangen und Themen neu erstellen und die Abhängigkeiten und die Konfiguration für den Clientanbieter ändern. Ein Beispiel finden Sie im Migrationsleitfaden für ActiveMQ.

Clientbibliotheken

Vollständig unterstützte Service Bus-Clientbibliotheken sind über das Azure SDK verfügbar.

Das primäre Protokoll von Azure Service Bus ist AMQP 1.0. Es kann über jeden AMQP 1.0-konformen Protokollclient genutzt werden. Einige Open-Source-AMQP-Clients verfügen über Beispiele, mit denen die Service Bus-Interoperabilität explizit demonstriert wird. Im AMQP 1.0-Protokollleitfaden erfahren Sie, wie Sie die Features von Service Bus direkt mit AMQP 1.0-Clients verwenden.

Sprache Bibliothek
Java Apache Qpid Proton-J
C/C++ Azure uAMQP C, Apache Qpid Proton-C
Python Azure uAMQP für Python, Apache Qpid Proton Python
PHP Azure uAMQP für PHP
Ruby Apache Qpid Proton Ruby
Go Azure Go AMQP, Apache Qpid Proton Go
C#/F#/VB AMQP .NET Lite, Apache NMS AMQP
JavaScript/Node Rhea

Integration

Service Bus kann vollständig mit vielen Microsoft- und Azure-Diensten integriert werden, z. B.:

Nächste Schritte

Informationen zu den ersten Schritten mit Service Bus-Messaging finden Sie in folgenden Artikeln: