Azure Service Bus - Veelgestelde vragen (faq)

Azure Service Bus is een asynchroon berichtencloudplatform waarmee u gegevens tussen losgekoppelde systemen kunt verzenden. Microsoft biedt deze functie als een service, wat betekent dat u uw eigen hardware niet hoeft te hosten om deze te gebruiken.

Een naamruimte biedt een bereikcontainer voor het adresseren van Service Bus-resources in uw toepassing. Het maken van een naamruimte is nodig om Service Bus te gebruiken en is een van de eerste stappen om aan de slag te gaan.

Een Service Bus-wachtrij is een entiteit waarin berichten worden opgeslagen. Wachtrijen zijn handig wanneer u meerdere toepassingen of meerdere delen van een gedistribueerde toepassing hebt die met elkaar moeten communiceren. De wachtrij is vergelijkbaar met een distributiecentrum waarin meerdere producten (berichten) worden ontvangen en vervolgens vanaf die locatie worden verzonden.

Een onderwerp kan worden gevisualiseerd als een wachtrij en wanneer u meerdere abonnementen gebruikt, wordt het een uitgebreider berichtenmodel; in wezen een een-op-veel-communicatietool. Met dit publicatie-/abonnementsmodel (of pub/sub) kan een toepassing een bericht verzenden naar een onderwerp met meerdere abonnementen om dat bericht door meerdere toepassingen te laten ontvangen.

Een conventionele wachtrij of onderwerp wordt verwerkt door één berichtenbroker en opgeslagen in één berichtenarchief. Een gepartitioneerde wachtrij of onderwerp wordt verwerkt door meerdere berichtbrokers en opgeslagen in meerdere berichtenarchieven. Deze functie betekent dat de algehele doorvoer van een gepartitioneerde wachtrij of onderwerp niet langer wordt beperkt door de prestaties van één berichtenbroker of berichtenarchief. Een tijdelijke onderbreking van een berichtenarchief geeft ook geen gepartitioneerde wachtrij of onderwerp niet beschikbaar.

Ordenen wordt niet gegarandeerd bij het gebruik van gepartitioneerde entiteiten. Als een partitie niet beschikbaar is, kunt u nog steeds berichten van de andere partities verzenden en ontvangen.

Azure Service Bus Standard-laag maakt gebruik van Azure SQL Database voor de back-endopslaglaag. Voor alle regio's behalve Brazilië - zuid en Azië - zuidoost wordt de databaseback-up gehost in een andere regio (meestal de gekoppelde Azure-regio). Voor de regio's Brazilië - zuid en Azië - zuidoost worden back-ups van databases opgeslagen in dezelfde regio om te voldoen aan vereisten voor gegevenslocatie voor deze regio's.

In de Premium-laag van Azure Service Bus worden metagegevens en gegevens opgeslagen in regio's die u selecteert. Wanneer geo-noodherstel is ingesteld voor een Azure Service Bus Premium-naamruimte, worden de metagegevens gekopieerd naar de secundaire regio die u selecteert.

U kunt de volgende protocollen met Azure Service Bus gebruiken om berichten te verzenden en te ontvangen:

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

Zie de volgende tabel voor de uitgaande TCP-poorten die u moet openen om deze protocollen te gebruiken om te communiceren met Azure Service Bus:

De HTTPS-poort is over het algemeen vereist voor uitgaande communicatie ook wanneer AMQP wordt gebruikt via poort 5671, omdat verschillende beheerbewerkingen die worden uitgevoerd door de client-SDK's en het verkrijgen van tokens van Microsoft Entra-id (wanneer gebruikt) via HTTPS worden uitgevoerd.

De officiële Azure SDK's gebruiken over het algemeen het AMQP-protocol voor het verzenden en ontvangen van berichten van Service Bus.

De protocoloptie AMQP-over-WebSockets wordt uitgevoerd via poort TCP 443, net als de HTTP/REST API, maar is anders functioneel identiek met gewone AMQP. Deze optie heeft een hogere initiële verbindingslatentie vanwege extra handshake-roundtrips en iets meer overhead als compromis voor het delen van de HTTPS-poort. Als deze modus is geselecteerd, is TCP-poort 443 voldoende voor communicatie. Met de volgende opties kunt u de AMQP WebSockets-modus selecteren.

Op 30 september 2026 gaan we de Azure Service Bus SDK-bibliotheken WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus en com.microsoft.azure.servicebus buiten gebruik stellen, die niet voldoen aan de Azure SDK-richtlijnen. We beëindigen ook de ondersteuning van het SBMP-protocol, zodat u dit protocol na 30 september 2026 niet meer kunt gebruiken. Migreer naar de nieuwste Azure SDK-bibliotheken, die vóór die datum essentiële beveiligingsupdates en verbeterde mogelijkheden bieden.

Hoewel de oudere bibliotheken nog steeds meer dan 30 september 2026 kunnen worden gebruikt, ontvangen ze geen officiële ondersteuning en updates meer van Microsoft. Zie de aankondiging van de buitengebruikstelling van de ondersteuning voor meer informatie.

Ja. Dat doet het wel. Zie de volgende artikelen:

• JMS 2.0-API gebruiken met Azure Service Bus Premium
• Ontwikkelaarshandleiding voor JMS

Voer de volgende stappen uit om de juiste IP-adressen te vinden die u wilt toevoegen aan de acceptatielijst voor uw verbindingen:

1. Voer de volgende opdracht uit vanaf een opdrachtprompt:

   nslookup <YourNamespaceName>.servicebus.windows.net
   

2. Noteer het IP-adres dat is geretourneerd in Non-authoritative answer.

Als u de zoneredundantie voor uw naamruimte gebruikt, moet u een paar extra stappen uitvoeren:

1. Eerst voert u nslookup uit op de naamruimte.

   nslookup <yournamespace>.servicebus.windows.net
   

2. Noteer de naam in de sectie niet-bindende antwoorden , die zich in een van de volgende notaties bevindt:

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

3. Voer nslookup uit voor elk exemplaar met achtervoegsels s1, s2 en s3 om de IP-adressen op te halen van alle drie exemplaren die worden uitgevoerd in drie beschikbaarheidszones,

   Notitie

   Het IP-adres dat door de nslookup opdracht wordt geretourneerd, is geen statisch IP-adres. Het blijft constant totdat de onderliggende implementatie wordt verwijderd of verplaatst naar een ander cluster, maar het gebruik van IN-adressen wordt niet aanbevolen of ondersteund en u moet wijzigingen in de IP-adressen bijhouden.

We registreren niet de IP-adressen van clients die berichten verzenden of ontvangen van/naar uw naamruimte. Genereer sleutels opnieuw, zodat alle bestaande clients de instellingen voor op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) niet kunnen verifiëren en controleren om ervoor te zorgen dat alleen toegestane gebruikers of toepassingen toegang hebben tot de naamruimte.

Als u een Premium-naamruimte gebruikt, gebruikt u IP-filtering, service-eindpunten voor virtuele netwerken en privé-eindpunten om de toegang tot de naamruimte te beperken.

Zie aanbevolen procedures voor prestatieverbeteringen met Service Bus . In dit artikel wordt beschreven hoe u de prestaties optimaliseert bij het uitwisselen van berichten.

De volgende eigenschappen van een wachtrij en onderwerp zijn onveranderbaar. Houd rekening met deze beperking wanneer u uw entiteiten maakt, omdat deze eigenschappen niet kunnen worden gewijzigd zonder een nieuwe vervangingsentiteit te maken.

• Partitionering
• Sessies
• Duplicaatdetectie
• Express-entiteit

Prijzen

In deze sectie vindt u antwoorden op enkele veelgestelde vragen over de Service Bus-prijsstructuur.

In het artikel over prijzen en facturering van Service Bus worden de factureringsmeters in Service Bus uitgelegd. Zie Service Bus-prijsinformatie voor specifieke informatie over Service Bus-prijsopties.

U kunt ook de veelgestelde vragen over Azure-ondersteuning voor algemene azure-prijzen bezoeken.

Zie Service Bus-prijsinformatie voor volledige informatie over prijzen van Service Bus. Naast de vermelde prijzen worden er kosten in rekening gebracht voor gekoppelde gegevensoverdrachten voor uitgaand verkeer buiten het datacenter waarin uw toepassing is ingericht.

Elke gegevensoverdracht binnen een bepaalde Azure-regio wordt kosteloos aangeboden, evenals eventuele binnenkomende gegevensoverdracht. Gegevensoverdracht buiten een regio is onderhevig aan uitgaande kosten, die hier te vinden zijn.

Nee Service Bus brengt geen kosten in rekening voor opslag. Er is echter een quotum dat de maximale hoeveelheid gegevens beperkt die per wachtrij/onderwerp kan worden bewaard. Zie de volgende veelgestelde vragen.

Azure Service Bus heeft onlangs de factureringsonderdelen bijgewerkt. Als u vanwege deze wijziging een Service Bus Standard-naamruimte hebt, ziet u mogelijk regelitems voor de resource /subscriptions/<azure_subscription_id>/resourceGroups/$system/providers/Microsoft.ServiceBus/namespaces/$system onder de resourcegroep $system.

Deze kosten vertegenwoordigen de basiskosten per Azure-abonnement dat een Service Bus Standard-naamruimte heeft ingericht.

Het is belangrijk te weten dat deze kosten niet nieuw zijn, dat wil weten dat ze ook in het vorige factureringsmodel bestaan. De enige wijziging is dat ze nu worden vermeld onder $system. Dit wordt gedaan vanwege beperkingen in het nieuwe factureringssysteem dat kosten op abonnementsniveau groeperen, niet gekoppeld aan een specifieke resource, onder de $system resource-id.

Targets

Zie het overzicht van Service Bus-quota voor een lijst met Service Bus-limieten en -quota.

Met Service Bus-berichtenservices (wachtrijen en onderwerpen/abonnementen) kunnen toepassingen berichten met een grootte van maximaal 256 kB (standard-laag) of 100 MB (Premium-laag) verzenden. Als u te maken hebt met berichten met een grotere grootte dan de toegestane grootte, gebruikt u het claimcontrolepatroon dat in dit blogbericht wordt beschreven.

Wanneer u een naamruimte uit een abonnement verwijdert, wacht u 4 uur voordat u deze opnieuw maakt met dezelfde naam in een ander abonnement. Anders krijgt u mogelijk het volgende foutbericht: Namespace already exists.

Zie Het overzicht uitzonderingen voor een lijst met mogelijke Service Bus-uitzonderingen.

Shared Access Signatures zijn een verificatiemechanisme op basis van sha-256-beveiligde hashes of URI's. Zie het artikel Shared Access Signatures voor informatie over het genereren van uw eigen handtekeningen in Node.js, PHP, Java, Python en C#.

U kunt een naamruimte van het ene Azure-abonnement naar het andere verplaatsen met behulp van de Azure-portal of PowerShell-opdrachten. Als u de bewerking wilt uitvoeren, moet de naamruimte al actief zijn. De gebruiker die de opdrachten uitvoert, moet een beheerder zijn voor zowel de bron- als doelabonnementen.

Als u Azure Portal wilt gebruiken om Service Bus-naamruimten te migreren naar een ander abonnement, volgt u de instructies hier.

Met de volgende reeks PowerShell-opdrachten wordt een naamruimte van het ene Azure-abonnement naar het andere verplaatst. Als u deze bewerking wilt uitvoeren, moet de naamruimte al actief zijn en moet de gebruiker die de PowerShell-opdrachten uitvoert een beheerder zijn voor zowel de bron- als doelabonnementen.

# 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

Is het mogelijk om TLS 1.0 of 1.1 uit te schakelen op Service Bus-naamruimten?

Ja, u kunt TLS 1.0 of 1.1 uitschakelen op Service Bus-naamruimten door de minimale TLS-versie in te stellen. Zie Een minimaal vereiste versie van Tls (Transport Layer Security) afdwingen voor aanvragen naar een Service Bus-naamruimte voor meer informatie.

Volgende stappen

Zie de volgende artikelen voor meer informatie over Service Bus:

• Inleiding tot Azure Service Bus Premium (blogbericht)
• Inleiding tot Azure Service Bus Premium (Channel9)
• Overzicht van Service Bus
• Aan de slag met Service Bus-wachtrijen