Häufig gestellte Fragen (FAQ) zu Azure Service Bus

Azure Service Bus ist eine asynchrone Cloudplattform für Messaging, mit der Sie Daten zwischen entkoppelten Systemen senden können. Microsoft stellt dieses Feature als Dienst bereit, sodass Sie keine eigene Hardware hosten müssen, um es verwenden zu können.

Ein Namespace ist ein Bereichscontainer für die Adressierung von Service Bus-Ressourcen innerhalb Ihrer Anwendung. Die Namespace-Erstellung ist für die Verwendung von Service Bus erforderlich und ist einer der ersten Schritte.

Eine Service Bus-Warteschlange ist eine Entität, in der Nachrichten gespeichert werden. Warteschlangen sind nützlich, wenn Sie über mehrere Anwendungen oder mehrere Teile einer verteilten Anwendung verfügen, die miteinander kommunizieren müssen. Die Warteschlange ähnelt einem Verteilzentrum, in dem mehrere Produkte (Nachrichten) eingehen und von diesem Standort aus dann weiterverschickt werden.

Eine Thema kann als Warteschlange visualisiert werden, und bei Verwendung mehrerer Abonnements ergibt sich ein umfassenderes Messagingmodell. Im Wesentlichen handelt es sich um ein Tool für die 1:n-Kommunikation. Bei diesem Modell vom Typ „Veröffentlichen/Abonnieren“ (Pub/Sub) kann für eine Anwendung, die eine Nachricht an ein Thema mit mehreren Abonnements sendet, erreicht werden, dass die Nachricht von mehreren Anwendungen empfangen wird.

Eine herkömmliche Warteschlange oder ein Thema werden von einem einzelnen Nachrichtenbroker verarbeitet und in einem Nachrichtenspeicher gespeichert. Eine partitionierte Warteschlange bzw. ein Thema wird mit mehreren Nachrichtenbrokern verarbeitet und in mehreren Nachrichtenspeichern gespeichert. Dies bedeutet, dass der Gesamtdurchsatz einer partitionierten Warteschlange oder eines Themas nicht mehr durch die Leistung eines einzelnen Nachrichtenbrokers oder Nachrichtenspeichers beschränkt wird. Außerdem führt ein vorübergehender Ausfall eines Nachrichtenspeichers nicht dazu, dass eine partitionierte Warteschlange oder ein Thema nicht mehr verfügbar ist.

Bei der Verwendung von partitionierten Entitäten ist keine Sortierung gewährleistet. Wenn eine Partition nicht verfügbar ist, ist es trotzdem möglich, Nachrichten zu senden und von anderen Partitionen zu empfangen.

Im Tarif „Standard“ von Azure Service Bus wird Azure SQL-Datenbank für die Back-End-Speicherebene genutzt. Für alle Regionen mit Ausnahme von „Brasilien, Süden“ und „Asien, Südosten“ wird die Datenbanksicherung in einer anderen Region gehostet (normalerweise in der anderen Region des Azure-Regionspaars). Für die Regionen „Brasilien, Süden“ und „Asien, Südosten“ werden Datenbanksicherungen in derselben Region gespeichert, um die Anforderungen an die Datenresidenz für diese Regionen zu erfüllen.

Im Premium-Tarif von Azure Service Bus werden die Metadaten und Daten in den Regionen gespeichert, die Sie auswählen. Wenn die georedundante Notfallwiederherstellung für einen Azure Service Bus-Namespace im Tarif „Premium“ eingerichtet wird, werden die Metadaten in die von Ihnen ausgewählte sekundäre Region kopiert.

Sie können die folgenden Protokolle mit Azure Service Bus verwenden, um Nachrichten zu senden und zu empfangen:

• Advanced Message Queuing Protocol 1.0 (AMQP)
• Hypertext Transfer Protocol 1.1 mit TLS (HTTPS)

In der folgenden Tabelle finden Sie die ausgehenden TCP-Ports, die Sie öffnen müssen, um diese Protokolle für die Kommunikation mit Azure Service Bus verwenden zu können:

Der HTTPS-Port ist in der Regel für die ausgehende Kommunikation auch dann erforderlich, wenn AMQP über Port 5671 verwendet wird, da mehrere Verwaltungsvorgänge, die von den Client-SDKs ausgeführt werden, und der Abruf von Token aus Microsoft Entra ID (falls verwendet) über HTTPS erfolgen.

Die offiziellen Azure-SDKs verwenden im Allgemeinen das AMQP-Protokoll zum Senden von Nachrichten an und Empfangen von Nachrichten von Service Bus.

Die Option AMQP-over-WebSockets-Protokoll wird über TCP-Port 443 wie die HTTP-/REST-API ausgeführt, ist aber ansonsten funktionell identisch mit einfachem AMQP. Diese Option weist eine höhere anfängliche Verbindungslatenz auf, weil zusätzliche Handshakeroundtrips auftreten und der Mehraufwand als Kompromisse bei der gemeinsamen Verwendung des HTTPS-Ports geringfügig größer ist. Wenn dieser Modus ausgewählt ist, ist TCP-Port 443 für die Kommunikation ausreichend. Mit den folgenden Optionen können Sie den AMQP-WebSockets-Modus auswählen.

Am 30. September 2026 werden die Azure Service Bus SDK-Bibliotheken „WindowsAzure.ServiceBus“, „Microsoft.Azure.ServiceBus“ und „com.microsoft.azure.servicebus“ eingestellt, da sie nicht den Azure SDK-Richtlinien entsprechen. Außerdem wird die Unterstützung des SBMP-Protokolls beendet, sodass Sie dieses Protokoll nach dem 30. September 2026 nicht mehr verwenden können. Migrieren Sie vor diesem Datum zu den neuesten Azure SDK-Bibliotheken, die wichtige Sicherheitsupdates und verbesserte Funktionen bieten.

Obwohl die älteren Bibliotheken noch über den 30. September 2026 hinaus verwendet werden können, erhalten sie keinen offiziellen Support und keine Updates mehr von Microsoft. Weitere Informationen finden Sie in der Ankündigung der Supporteinstellung.

Ja. Es gibt Unterstützung. Weitere Informationen finden Sie in folgenden Artikeln:

• Verwenden der Java Message Service 2.0-API mit Azure Service Bus Premium
• JMS-Entwicklerhandbuch

Um die richtigen IP-Adressen zu ermitteln, die Sie auf die Positivliste für Ihre Verbindungen setzen sollten, führen Sie die folgenden Schritte aus:

1. Führen Sie den folgenden Befehl an einer Eingabeaufforderung aus:

   nslookup <YourNamespaceName>.servicebus.windows.net
   

2. Notieren Sie sich die IP-Adresse, die in Non-authoritative answer zurückgegeben werden.

Wenn Sie Zonenredundanz für Ihren Namespace verwenden, müssen Sie einige zusätzliche Schritte ausführen:

1. Führen Sie zunächst nslookup für den Namespace aus.

   nslookup <yournamespace>.servicebus.windows.net
   

2. Notieren Sie sich den Namen im Abschnitt non-authoritative answer (nicht autorisierende Antwort), der in einem der folgenden Formate vorliegt:

   <name>-s1.cloudapp.net
   <name>-s2.cloudapp.net
   <name>-s3.cloudapp.net
   

3. Führen Sie den Befehl „nslookup“ für jeden Namen mit den Suffixen s1, s2 und s3 aus, um die IP-Adressen aller drei Instanzen zu erhalten, die in drei Verfügbarkeitszonen ausgeführt werden.

   Hinweis

   Die vom nslookup-Befehl zurückgegebene IP-Adresse ist keine statische IP-Adresse. Sie bleibt konstant, bis die zugrunde liegende Bereitstellung gelöscht oder in einen anderen Cluster verschoben wird. Die Verwendung von IN-Adressen wird jedoch nicht empfohlen oder unterstützt, und Sie müssen Änderungen an den IP-Adressen nachverfolgen.

Die IP-Adressen von Clients, die Nachrichten an einen Namespace senden oder von diesem empfangen, werden von uns nicht protokolliert. Generieren Sie die Schlüssel neu, damit die Authentifizierung aller vorhandenen Clients nicht mehr funktioniert, und überprüfen Sie die Einstellungen der rollenbasierten Zugriffssteuerung in Azure (Azure RBAC), um sicherzustellen, dass nur zulässige Benutzer oder Anwendungen Zugriff auf den Namespace haben.

Wenn Sie einen Premium-Namespace verwenden, schränken Sie den Zugriff auf den Namespace mithilfe von IP-Filtern, Dienstendpunkten für virtuelle Netzwerke und privaten Endpunkten ein.

Siehe Bewährte Methoden für Leistungsoptimierungen mithilfe von Service Bus – In diesem Artikel wird beschrieben, wie Sie die Leistung beim Austauschen von Nachrichten optimieren können.

Die folgenden Eigenschaften einer Warteschlange und eines Themas sind unveränderlich. Berücksichtigen Sie diese Einschränkung beim Erstellen Ihrer Entitäten, da diese Eigenschaften nicht geändert werden können, ohne eine neue Ersatzentität zu erstellen.

• Partitionierung
• Sitzungen
• Duplikaterkennung
• Express-Entität

Preise

In diesem Abschnitt werden einige häufig gestellte Fragen zur Service Bus-Preisstruktur beantwortet.

Im Artikel Service Bus – Preise und Abrechnung werden die Abrechnungseinheiten in Service Bus erläutert. Detailliertere Informationen zu den Service Bus-Preisoptionen finden Sie unter Service Bus – Preise.

Sie können auch Häufig gestellte Fragen zum Azure-Support aufrufen, wenn Sie nach allgemeinen Azure-Preisinformationen suchen.

Vollständige Informationen zu Service Bus-Preisen finden Sie unter Service Bus-Preise. Neben den aufgeführten Preisen werden Ihnen die damit verbundenen aus dem Rechenzentrum ausgehenden Datenübertragungen berechnet, mit denen Ihre Anwendung bereitgestellt wird.

Jede Datenübertragung innerhalb der jeweiligen Azure-Region ist ebenso wie jede eingehende Datenübertragung kostenfrei. Für die Datenübertragung außerhalb einer Region gelten Gebühren für ausgehenden Datenverkehr, die hier aufgeführt sind.

Nein. Für Service Bus fallen keine Speicherkosten an. Es gibt allerdings ein Kontingent, das die Höchstmenge von Daten begrenzt, die pro Warteschlange/Thema beibehalten werden kann. Weitere Informationen finden Sie im nächsten Abschnitt.

Vor Kurzem wurden die Abrechnungskomponenten für Azure Service Bus aktualisiert. Aufgrund dieser Änderung werden bei einem Service Bus Standard-Namespace möglicherweise Zeilenelemente für die Ressource /subscriptions/<azure_subscription_id>/resourceGroups/$system/providers/Microsoft.ServiceBus/namespaces/$system unter Ressourcengruppe $system angezeigt.

Diese Gebühren stellen die Grundgebühr für jedes Azure-Abonnement dar, das einen Service Bus Standard-Namespace bereitgestellt hat.

Beachten Sie, dass es sich hierbei nicht um neue Gebühren handelt, d. h., sie bestanden auch im vorherigen Abrechnungsmodell. Die einzige Änderung besteht darin, dass sie jetzt unter „$system“ aufgeführt sind. Dies erfolgt aufgrund von Einschränkungen im neuen Abrechnungssystem, bei denen die Gebühren auf Abonnementebene, die nicht an eine bestimmte Ressource gebunden sind, unter der Ressourcen-ID „$system“ gruppiert werden.

Kontingente

Eine Liste mit Service Bus-Grenzwerten und -Kontingenten finden Sie unter Übersicht über Service Bus-Kontingente.

Service Bus-Messagingdienste (Warteschlangen und Themen/Abonnements) ermöglichen Anwendungen, Nachrichten mit einer Größe bis zu 256 KB (Standard-Tarif) oder 100 MB (Premium-Tarif) zu senden. Wenn die Größe der Nachrichten die zulässige Größe überschreitet, verwenden Sie das in diesem Blogbeitrag beschriebene Anspruchsüberprüfungsmuster.

Wenn Sie einen Namespace aus einem Abonnement löschen, warten Sie vier Stunden, bevor Sie ihn mit dem gleichen Namen in einem anderen Abonnement erstellen. Sie erhalten andernfalls unter Umständen die folgende Fehlermeldung: Namespace already exists.

Eine Liste der möglichen Service Bus-Ausnahmen finden Sie in der Übersicht über Ausnahmen.

SAS (Shared Access Signatures) sind ein Authentifizierungsmechanismus, der auf sicheren Hashes (SHA-256) oder URIs basiert. Informationen dazu, wie Sie Ihre eigenen Signaturen in Node.js, PHP, Java, Python und C# generieren, finden Sie im Artikel Shared Access Signatures.

Sie können einen Namespace entweder über das Azure-Portal oder unter Verwendung von PowerShell-Befehlen von einem Azure-Abonnement in ein anderes verschieben. Der Namespace muss bereits aktiv sein, um diesen Vorgang durchführen zu können. Der Benutzer, der die Befehle ausführt, muss sowohl im Quellabonnement als auch im Zielabonnement Administrator sein.

Wenn Sie Service Bus-Namespaces mithilfe des Azure-Portals auf ein anderes Abonnement übertragen möchten, folgen Sie den hier aufgeführten Anweisungen.

Mit der folgenden PowerShell-Befehlssequenz wird ein Namespace aus einem Azure-Abonnement in ein anderes verschoben. Um diesen Vorgang auszuführen, muss der Namespace bereits aktiv sein und der Benutzer, der die PowerShell-Befehle ausführt, muss sowohl im Quell- als auch im Zielabonnement Administratorrechte besitzen.

# Create a new resource group in target subscription
Select-AzSubscription -SubscriptionId 'ffffffff-ffff-ffff-ffff-ffffffffffff'
New-AzResourceGroup -Name 'targetRG' -Location 'East US'

# Move namespace from source subscription to target subscription
Select-AzSubscription -SubscriptionId 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa'
$res = Find-AzResource -ResourceNameContains mynamespace -ResourceType 'Microsoft.ServiceBus/namespaces'
Move-AzResource -DestinationResourceGroupName 'targetRG' -DestinationSubscriptionId 'ffffffff-ffff-ffff-ffff-ffffffffffff' -ResourceId $res.ResourceId

Ist es möglich, TLS 1.0 oder 1.1 für Service Bus-Namespaces zu deaktivieren?

Ja, Sie können TLS 1.0 oder 1.1 für Service Bus-Namespaces deaktivieren, indem Sie die TLS-Mindestversion festlegen. Weitere Informationen finden Sie unter Erzwingen der erforderliche Mindestversion der Transport Layer Security (TLS) für Anforderungen an einen Service Bus-Namespace.

Nächste Schritte

Weitere Informationen zu Service Bus finden Sie in den folgenden Artikeln:

• Einführung in Azure Service Bus Premium (Blogbeitrag)
• Introducing Azure Service Bus Premium (Channel9) (Einführung in Azure Service Bus Premium (Channel9))
• Übersicht über Service Bus
• Erste Schritte mit Service Bus-Warteschlangen