Freigeben über

Was ist Azure Service Bus?

Bei Azure Service Bus handelt es sich um einen vollständig verwalteten Nachrichtenbroker für Unternehmen mit Nachrichtenwarteschlangen und Publish/Subscribe-Themen. Verwenden Sie Service Bus, um Anwendungen und Dienste voneinander zu entkoppeln. Ihnen bieten sich folgende Vorteile:

  • Lastenausgleich funktioniert für konkurrierende Worker
  • Sicheres Weiterleiten und Übertragen von Daten und Kontrolle über Dienst- und Anwendungsgrenzen hinweg
  • Koordiniert Transaktionsarbeit, die ein hohes Maß an Zuverlässigkeit erfordert

Übersicht

Anwendungen und Dienste übertragen Daten untereinander mithilfe von Nachrichten. Eine Nachricht ist ein Container, der Daten enthält und mit Metadaten versehen ist. Die Daten können jede Art von Informationen sein, einschließlich strukturierter Daten, die mit gängigen Formaten wie JSON, XML, Apache Avro oder Nur-Text codiert sind.

Einige gängige Messaging-Szenarien umfassen:

  • 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.

  • Load-Balancing. 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. Führen Sie mehrere Vorgänge aus, alle im Rahmen einer Atomtransaktion. Beispielsweise können die folgenden Vorgänge im Bereich einer Transaktion ausgefü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 Service Bus eine Plattform als Service (PaaS)-Angebot ist, besteht ein wichtiger Unterschied darin, dass Sie sich keine Gedanken über die folgenden Aktionen machen 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

Sie senden und empfangen Nachrichten über Warteschlangen. 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 die Nachricht vom Broker akzeptiert wurde, speichert er sie stets dauerhaft in einem dreifach redundantem Speicher, der über Verfügbarkeitszonen verteilt ist, wenn der Namespace für Zonen aktiviert ist. Service Bus speichert Nachrichten im Arbeitsspeicher oder veränderlichem Speicher, bis der Client sie als akzeptiert meldet.

Nachrichten werden im Pullmodus übermittelt, sodass das System nachrichten nur bei Bedarf übermittelt. Im Gegensatz zum Busy-Polling-Modell einiger anderer Cloudwarteschlangen kann der Pullvorgang lange ausgeführt werden und wird erst abgeschlossen, wenn 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. Diese Abonnements werden an das Thema angefügt. Ansonsten funktionieren sie genau wie Warteschlangen auf der Empfängerseite. 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 dauerhaft, aber Sie können sie so konfigurieren, dass sie ablaufen und dann automatisch gelöscht werden. Über die Java Message Service (JMS)-API können Sie mit Service Bus Premium auch veränderliche Abonnements erstellen, die für die Dauer der Verbindung vorhanden sind.

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, z. B. Warteschlangen und Themen. Ein Namespace kann eine oder mehrere Warteschlangen und Themen enthalten und dient häufig als Anwendungscontainer.

Sie können einen Namespace mit einem Server in der Terminologie anderer Broker vergleichen, aber die Konzepte sind nicht direkt gleichwertig. 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. Sie profitieren von der hohen Verfügbarkeit und Robustheit, die der Betrieb des Nachrichtenbrokers in großem Maßstab bietet. Zudem müssen Sie sich nicht mit den zugrunde liegenden komplexen Zusammenhängen beschäftigen. Service Bus steht für serverloses Messaging.

Erweiterte Features

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. Sie können auch Sitzungen verwenden, um Anforderungsantwortmuster zu implementieren. 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 dem Feature "Autoforwarding " können Sie eine Warteschlange oder ein Abonnement mit einer anderen Warteschlange oder einem anderen Thema verketten, die Teil desselben Namespaces ist. Wenn Sie die automatische Weiterleitung aktivieren, entfernt Service Bus automatisch Nachrichten, die in der ersten Warteschlange oder dem ersten Abonnement (Quelle) platziert werden, und fügt sie in die zweite Warteschlange oder das zweite 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 ein Warteschlangen- oder Abonnementclient eine Nachricht empfängt, die er verarbeiten möchte, die Verarbeitung ist jedoch aufgrund spezieller Umstände innerhalb der Anwendung derzeit nicht möglich, kann die Entität den Abruf der Nachricht zu einem späteren Zeitpunkt zurückstellen. 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

Mithilfe der automatischen Löschung im Leerlauf können Sie ein Leerlaufintervall angeben, nach dem die Warteschlange automatisch gelöscht wird. Das Intervall wird zurückgesetzt, wenn es Datenverkehr in der Warteschlange gibt. Die Mindestdauer beträgt fünf Minuten.

Duplikaterkennung

Wenn ein Fehler auftritt, der dazu führt, dass der Kunde am Ergebnis eines Sendevorgangs zweifelt, beseitigt die Dublettenerkennung in diesen Situationen den Zweifel. Der Absender kann dieselbe Nachricht erneut senden, und die Warteschlange oder das Thema verwirft alle duplizierten Kopien. Weitere Informationen finden Sie unter Duplikaterkennung.

Batchlöschung von Nachrichten

Azure Service Bus unterstützt das Löschen von Nachrichten in Batches. Dieses Feature ist nützlich, wenn Nachrichten in Warteschlangen oder Abonnements abgelaufen sind oder nicht mehr relevant sind und eine Bereinigung erforderlich ist. Weitere Informationen finden Sie unter Batchlöschung.

Sicherheit

Service Bus unterstützt Sicherheitsprotokolle wie Shared Access Signatures (SAS),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.

Geo-Replication

Wenn Azure-Regionen oder Rechenzentren Ausfallzeiten aufweisen, ermöglicht Geo-Replikation die Datenverarbeitung, um weiterhin in einer anderen Region tätig zu sein.

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 konform mit der Java/Jakarta EE Java Message Service (JMS) 2.0 API. 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 und kann von jedem AMQP 1.0-kompatiblen Protokoll-Client aus verwendet 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 Apache Qpid Proton Python
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 ist vollständig in viele Microsoft- und Azure-Dienste integriert, z. B.:

Nächste Schritte

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

  • Last updated on