Azure Service Bus – Vanliga frågor och svar

Azure Service Bus är en asynkron molnplattform för meddelanden som gör att du kan skicka data mellan frikopplade system. Microsoft erbjuder den här funktionen som en tjänst, vilket innebär att du inte behöver vara värd för din egen maskinvara för att använda den.

Ett namnområde tillhandahåller en omfångscontainer för adressering av Service Bus-resurser i ditt program. Att skapa ett namnområde är nödvändigt för att använda Service Bus och är ett av de första stegen för att komma igång.

En Service Bus-kö är en entitet där meddelanden lagras. Köer är användbara när du har flera program eller flera delar av ett distribuerat program som behöver kommunicera med varandra. Kön liknar ett distributionscenter eftersom flera produkter (meddelanden) tas emot och sedan skickas från den platsen.

Ett ämne kan visualiseras som en kö och när du använder flera prenumerationer blir det en mer omfattande meddelandemodell. en-till-många-kommunikationsverktyg. Den här publicerings-/prenumerationsmodellen (eller pub/sub) gör det möjligt för ett program som skickar ett meddelande till ett ämne med flera prenumerationer att få meddelandet mottaget av flera program.

En konventionell kö eller ett ämne hanteras av en enda meddelandekö och lagras i ett meddelandearkiv. En partitionerad kö eller ett ämne hanteras av flera meddelandeköer och lagras i flera meddelandearkiv. Den här funktionen innebär att det övergripande dataflödet för en partitionerad kö eller ett ämne inte längre begränsas av prestanda för en enda meddelandekö eller ett meddelandearkiv. Ett tillfälligt avbrott i ett meddelandearkiv gör inte heller en partitionerad kö eller ett ämne otillgängligt.

Ordningen säkerställs inte när partitionerade entiteter används. Om en partition inte är tillgänglig kan du fortfarande skicka och ta emot meddelanden från de andra partitionerna.

Azure Service Bus-standardnivån använder Azure SQL Database för sitt lagringslager på serverdelen. För alla regioner utom Brasilien, södra och Sydostasien finns databassäkerhetskopian i en annan region (vanligtvis den Länkade Azure-regionen). För regionerna Brasilien, södra och Sydostasien lagras databassäkerhetskopior i samma region för att uppfylla kraven på datahemvist för dessa regioner.

Azure Service Bus Premium-nivån lagrar metadata och data i regioner som du väljer. När geo-haveriberedskap har konfigurerats för ett Azure Service Bus Premium-namnområde kopieras metadata över till den sekundära region som du väljer.

Du kan använda följande protokoll med Azure Service Bus för att skicka och ta emot meddelanden:

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

Se följande tabell för de utgående TCP-portar som du behöver öppna för att använda dessa protokoll för att kommunicera med Azure Service Bus:

HTTPS-porten krävs vanligtvis för utgående kommunikation även när AMQP används via port 5671, eftersom flera hanteringsåtgärder som utförs av klient-SDK:er och förvärv av token från Microsoft Entra-ID (när det används) körs över HTTPS.

De officiella Azure SDK:erna använder vanligtvis AMQP-protokollet för att skicka och ta emot meddelanden från Service Bus.

Protokollalternativet AMQP-over-WebSockets körs via port TCP 443 precis som HTTP/REST-API:et, men är annars funktionellt identiskt med vanlig AMQP. Det här alternativet har högre inledande anslutningsfördröjning på grund av extra handskakningsturer och något mer omkostnader som kompromiss för att dela HTTPS-porten. Om det här läget är valt räcker det med TCP-port 443 för kommunikation. Med följande alternativ kan du välja LÄGET AMQP WebSockets.

Den 30 september 2026 drar vi tillbaka Azure Service Bus SDK-biblioteken WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus och com.microsoft.azure.servicebus, som inte följer Riktlinjerna för Azure SDK. Vi kommer också att avsluta stödet för SBMP-protokollet, så du kommer inte längre att kunna använda det här protokollet efter den 30 september 2026. Migrera till de senaste Azure SDK-biblioteken, som erbjuder kritiska säkerhetsuppdateringar och förbättrade funktioner, före det datumet.

Även om de äldre biblioteken fortfarande kan användas efter den 30 september 2026 får de inte längre officiell support och uppdateringar från Microsoft. Mer information finns i meddelandet om supportavgång.

Ja. Det gör det. Mer information finns i följande artiklar:

• Använda JMS 2.0 API med Azure Service Bus Premium
• JMS-utvecklarguide

Följ dessa steg för att hitta rätt IP-adresser att lägga till i listan över tillåtna anslutningar:

1. Kör följande kommando från en kommandotolk:

   nslookup <YourNamespaceName>.servicebus.windows.net
   

2. Anteckna IP-adressen som returnerades i Non-authoritative answer.

Om du använder zonredundansen för ditt namnområde måste du göra några extra steg:

1. Först kör du nslookup på namnområdet.

   nslookup <yournamespace>.servicebus.windows.net
   

2. Anteckna namnet i avsnittet icke-auktoritativt svar , som är i något av följande format:

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

3. Kör nslookup för var och en med suffixen s1, s2 och s3 för att hämta IP-adresserna för alla tre instanser som körs i tre tillgänglighetszoner.

   Kommentar

   IP-adressen som returneras av nslookup kommandot är inte en statisk IP-adress. Den förblir konstant tills den underliggande distributionen tas bort eller flyttas till ett annat kluster, men användning av IN-adresser rekommenderas inte eller stöds inte, och du måste hålla reda på ändringar i IP-adresserna.

Vi loggar inte IP-adresserna för klienter som skickar eller tar emot meddelanden till/från ditt namnområde. Återskapa nycklar så att alla befintliga klienter inte kan autentisera och granska Azures rollbaserade åtkomstkontrollinställningar (Azure RBAC)) för att säkerställa att endast tillåtna användare eller program har åtkomst till namnområdet.

Om du använder ett premiumnamnområde använder du IP-filtrering, tjänstslutpunkter för virtuellt nätverk och privata slutpunkter för att begränsa åtkomsten till namnområdet.

Se Metodtips för prestandaförbättringar med Hjälp av Service Bus – den här artikeln beskriver hur du optimerar prestanda vid utbyte av meddelanden.

Följande egenskaper för en kö och ett ämne är oföränderliga. Tänk på den här begränsningen när du skapar dina entiteter, eftersom dessa egenskaper inte kan ändras utan att skapa en ny ersättningsentitet.

• Partitionering
• Sessioner
• Dubblettidentifiering
• Expressentitet

Prissättning

Det här avsnittet besvarar några vanliga frågor om Service Bus-prisstrukturen.

Pris - och faktureringsartikeln för Service Bus förklarar faktureringsmätaren i Service Bus. Specifik information om prisalternativ för Service Bus finns i Prisinformation för Service Bus.

Du kan också besöka vanliga frågor och svar om Azure-support för allmän azure-prisinformation.

Fullständig information om Service Bus-priser finns i Prisinformation för Service Bus. Utöver de angivna priserna debiteras du för associerade dataöverföringar för utgående trafik utanför det datacenter där ditt program etableras.

All dataöverföring inom en viss Azure-region tillhandahålls utan kostnad, samt eventuell inkommande dataöverföring. Dataöverföring utanför en region är föremål för utgående avgifter, som du hittar här.

Nej. Service Bus debiteras inte för lagring. Det finns dock en kvot som begränsar den maximala mängden data som kan sparas per kö/ämne. Se nästa vanliga frågor och svar.

Azure Service Bus har nyligen uppgraderat faktureringskomponenterna. Om du har ett Service Bus Standard-namnområde kan du se radobjekt för resursen /subscriptions/<azure_subscription_id>/resourceGroups/$system/providers/Microsoft.ServiceBus/namespaces/$system under resursgruppen $systempå grund av den här ändringen.

Dessa avgifter representerar den basavgift per Azure-prenumeration som har etablerat ett Service Bus Standard-namnområde.

Det är viktigt att observera att dessa avgifter inte är nya, dvs. de fanns även i den tidigare faktureringsmodellen. Den enda ändringen är att de nu visas under $system. Det görs på grund av begränsningar i det nya faktureringssystemet som grupperar avgifter på prenumerationsnivå, som inte är knutna till en specifik resurs, under resurs-ID $system :t.

Säljbudgetar

En lista över Service Bus-gränser och -kvoter finns i översikten över Service Bus-kvoter.

Med Service Bus-meddelandetjänster (köer och ämnen/prenumerationer) kan programmet skicka meddelanden med en storlek på upp till 256 KB (standardnivå) eller 100 MB (premiumnivå). Om du hanterar meddelanden med större storlek än den tillåtna storleken använder du mönstret för anspråkskontroll som beskrivs i det här blogginlägget.

När du tar bort ett namnområde från en prenumeration väntar du i 4 timmar innan du återskapar det med samma namn i en annan prenumeration. Annars kan du få följande felmeddelande: Namespace already exists.

En lista över möjliga Service Bus-undantag finns i Undantagsöversikt.

Signaturer för delad åtkomst är en autentiseringsmekanism som baseras på SHA-256-säkra hashar eller URI:er. Information om hur du genererar egna signaturer i Node.js, PHP, Java, Python och C# finns i artikeln Signaturer för delad åtkomst.

Du kan flytta ett namnområde från en Azure-prenumeration till en annan med hjälp av antingen Azure-portalen eller PowerShell-kommandon. Om du vill köra åtgärden måste namnområdet redan vara aktivt. Användaren som kör kommandona måste vara administratör för både käll- och målprenumerationerna.

Följ anvisningarna här om du vill använda Azure-portalen för att migrera Service Bus-namnområden till en annan prenumeration.

Följande sekvens med PowerShell-kommandon flyttar ett namnområde från en Azure-prenumeration till en annan. Om du vill köra den här åtgärden måste namnområdet redan vara aktivt och användaren som kör PowerShell-kommandona måste vara administratör för både käll- och målprenumerationerna.

# 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

Går det att inaktivera TLS 1.0 eller 1.1 på Service Bus-namnområden?

Ja, du kan inaktivera TLS 1.0 eller 1.1 på Service Bus-namnområden genom att ange den lägsta TLS-versionen. Mer information finns i Framtvinga en lägsta version av TLS (Transport Layer Security) för begäranden till ett Service Bus-namnområde.

Nästa steg

Mer information om Service Bus finns i följande artiklar:

• Introduktion till Azure Service Bus Premium (blogginlägg)
• Introduktion till Azure Service Bus Premium (Channel9)
• Översikt över Service Bus
• Komma igång med Service Bus-köer