Service Bus Premium-meddelandenivå

Service Bus-meddelanden, inklusive entiteter som köer och ämnen, kombinerar meddelandefunktioner för företag med utförlig publicerings-/prenumerationssemantik i molnskala. Service Bus-meddelanden används som kommunikationsryggrad i flera avancerade molnlösningar.

Premium-nivån av Service Bus-meddelanden är ett svar på vanliga kundönskemål gällande skala, prestanda och tillgänglighet för verksamhetskritiska program. Vi rekommenderar att du använder premiumnivån för produktionsscenarier. Även om funktionsuppsättningarna är nästan identiska är standard- och premiumnivåerna för Service Bus-meddelanden utformade för att hantera olika användningsfall.

En del övergripande skillnader visas i tabellen nedan.

Villkor	Premium	Standard
Genomflöde	Högt genomflöde	Variabelt genomflöde
Prestanda	Förutsägbar prestanda	Variabel svarstid
Prissättning	Fast prissättning	Variabla priser – betala per användning
Skala	Möjlighet att skala arbetsbelastningen uppåt och nedåt	Ej tillämpligt
Meddelandestorlek	Meddelandestorlek upp till 100 MB. Mer information finns i Stöd för stora meddelanden.	Meddelandestorlek upp till 256 kB

Service Bus Premium-meddelanden ger resursisolering på processor- och minnesnivån så att varje kunds arbetsbelastning körs i isolering. Den här resurscontainern kallas för en meddelandefunktionsenhet. Varje Premium-namnområde allokeras minst en meddelandefunktionsenhet. Du kan köpa 1, 2, 4, 8 eller 16 meddelandeenheter för varje Service Bus Premium-namnområde. En enskild arbetsbelastning eller en entitet kan sträcka sig över flera meddelandeenheter och antalet meddelandeenheter kan ändras efter behåll. Resultatet är förutsägbara och repeterbara prestanda för Service Bus-lösningen.

Den här prestandan är inte bara mer förutsägbar och tillgänglig, utan också snabbare. Med premiummeddelanden är högsta prestanda mycket snabbare än med standardnivån.

Tekniska skillnader i Premium-meddelanden

I följande avsnitt beskrivs några skillnader mellan premium- och standardmeddelandenivåer.

Expressenheter

Eftersom Premium-meddelanden körs i en isolerad körningsmiljö stöds inte expressentiteter i premiumnamnområden. En expressentitet innehåller ett meddelande i minnet tillfälligt innan den skrivs till beständig lagring. Om du har kod som körs under standardmeddelanden och vill portera den till premiumnivån kontrollerar du att expressentitetsfunktionen är inaktiverad.

Resursanvändning för Premium-meddelanden

I allmänhet kan alla åtgärder på en entitet orsaka cpu- och minnesanvändning. Här är några av följande åtgärder:

• Hanteringsåtgärder som åtgärder för att skapa, hämta, uppdatera och ta bort (CRUD) i köer, ämnen och prenumerationer.
• Körningsåtgärder (skicka och ta emot meddelanden)
• Övervakningsåtgärder och aviseringar

Den ytterligare processor- och minnesanvändningen prissätts dock inte ytterligare. För premiummeddelandenivån finns det ett enda pris för meddelandeenheten.

Cpu- och minnesanvändningen spåras och visas för dig av följande skäl:

• Ge insyn i systemets interna system
• Förstå kapaciteten för de resurser som köpts.
• Kapacitetsplanering som hjälper dig att bestämma dig för att skala upp/ned.

Hur många meddelandeenheter behövs?

Du anger antalet meddelandeenheter när du etablerar ett Azure Service Bus Premium-namnområde. Dessa meddelandeenheter är dedikerade resurser som allokeras till namnområdet. När partitionering är aktiverat på namnområdet distribueras meddelandeenheterna lika mellan partitionerna.

Antalet meddelandeenheter som allokeras till Service Bus Premium-namnområdet kan justeras dynamiskt för att ta hänsyn till ändringen (öka eller minska) i arbetsbelastningar.

Det finns några faktorer att ta hänsyn till när du bestämmer antalet meddelandeenheter för din arkitektur:

• Börja med 1 eller 2 meddelandeenheter som har allokerats till ditt namnområde eller en meddelandeenhet per partition.
• Studera cpu-användningsstatistiken i resursanvändningsstatistiken för ditt namnområde.
  • Om CPU-användningen är lägre än 20 % kan du kanske skala ned antalet meddelandeenheter som allokerats till ditt namnområde.
  • Om CPU-användningen är över 70 %, kan ditt program dra nytta av att skala upp antalet meddelandeenheter som allokerats till ditt namnområde.

Information om hur du konfigurerar ett Service Bus-namnområde för automatisk skalning (öka eller minska meddelandeenheter) finns i Uppdatera meddelandeenheter automatiskt.

Kommentar

Skalning av de resurser som allokerats till namnområdet kan vara antingen förebyggande eller reaktiv.

• Förebyggande: Om ytterligare arbetsbelastning förväntas (på grund av säsongsvariationer eller trender) kan du fortsätta att allokera fler meddelandeenheter till namnområdet innan arbetsbelastningarna når.

• Reaktiv: Om ytterligare arbetsbelastningar identifieras genom att studera resursanvändningsmåtten kan ytterligare resurser allokeras till namnområdet för att inkludera ökad efterfrågan.

Faktureringsmätare för Service Bus sker varje timme. När du skalar upp betalar du bara för de ytterligare resurserna för de timmar som dessa användes.

Kom igång med Premium-meddelanden

Det är enkelt att komma igång med premiummeddelanden och processen liknar standardmeddelanden. Börja med att skapa ett namnområde i Azure Portal. Se till att du väljer Premium under Prisnivå. Välj Visa fullständig prisinformation för att se mer information om varje nivå.

Du kan också skapa Premium-namnområden med hjälp av Azure Resource Manager-mallar.

Stöd för stora meddelanden

Azure Service Bus premiumnivånamnområden stöder möjligheten att skicka stora meddelandenyttolaster på upp till 100 MB. Den här funktionen är främst inriktad på äldre arbetsbelastningar som använde större meddelandenyttolaster på andra meddelandeköer för företag och som vill migrera sömlöst till Azure Service Bus.

Här följer några saker att tänka på när du skickar stora meddelanden på Azure Service Bus –

• Stöds endast på Azure Service Bus Premium-nivånamnområden.
• Stöds endast när du använder protokollet Advanced Message Queuing Protocol (AMQP). Stöds inte när du använder SBMP- eller HTTP-protokoll, på premiumnivån är den maximala meddelandestorleken för SBMP- och HTTP-protokoll 1 MB.
• Stöds när du använder Java Message Service (JMS) 2.0-klient-SDK och andra språkklient-SDK:er.
• Att skicka stora meddelanden resulterar i minskat dataflöde och ökad svarstid.
• Meddelandenyttolaster på 100 MB stöds, men vi rekommenderar att du håller meddelandets nyttolaster så små som möjligt för att säkerställa tillförlitliga prestanda från Service Bus-namnområdet.
• Den maximala meddelandestorleken framtvingas endast för meddelanden som skickas till kön eller ämnet. Storleksgränsen tillämpas inte för mottagningsåtgärden. Det gör att du kan uppdatera den maximala meddelandestorleken för en viss kö (eller ämne).
• Batchbearbetning stöds inte.

Den 30 september 2026 drar vi tillbaka stödet för SBMP-protokollet för Azure Service Bus, så att du inte längre kan använda det här protokollet efter den 30 september 2026. Migrera till de senaste Azure Service Bus SDK-biblioteken med hjälp av AMQP-protokollet, som erbjuder kritiska säkerhetsuppdateringar och förbättrade funktioner, före det datumet.

Mer information finns i meddelandet om supportavgång.

Aktivera stöd för stora meddelanden för en ny kö (eller ämne)

Om du vill aktivera stöd för stora meddelanden anger du maximal meddelandestorlek när du skapar en ny kö (eller ett nytt ämne) enligt följande bild:

Aktivera stöd för stora meddelanden för en befintlig kö (eller ämne)

Du kan också aktivera stöd för stora meddelanden för befintliga köer (eller ämnen) genom att uppdatera maximal meddelandestorlek i Översikt för den specifika kön (eller ämnet) enligt följande bild.

Nätverkssäkerhet

Följande nätverkssäkerhetsfunktioner är endast tillgängliga på premiumnivån. Mer information finns i Nätverkssäkerhet.

• Tjänsttaggar
• Nätverkstjänstslutpunkter
• Privata slutpunkter

Konfigurera IP-brandväggen med hjälp av Azure Portal är endast tillgängligt för premiumnivånamnrymderna. Du kan dock konfigurera IP-brandväggsregler för andra nivåer med hjälp av Azure Resource Manager-mallar, CLI, PowerShell eller REST API. Mer information finns i Konfigurera IP-brandvägg.

Data i paus och kryptering

Alla data som lagras i lagringsundersystemet krypteras med hjälp av Microsoft-hanterade nycklar. Om du använder din egen nyckel (kallas även kundhanterad nyckel) krypteras data fortfarande med hjälp av den Microsoft-hanterade nyckeln, men dessutom krypteras den Microsoft-hanterade nyckeln med hjälp av den kundhanterade nyckeln. Med den här funktionen kan du skapa, rotera, inaktivera och återkalla åtkomst till kundhanterade nycklar som används för kryptering av Microsoft-hanterade nycklar. Att aktivera funktionen för kundhanterad nyckel är en engångskonfigurationsprocess i ditt namnområde. Mer information finns i Kryptera Azure Service Bus-data i vila.

Partitionering

Det finns vissa skillnader mellan standard- och premiumnivåerna när det gäller partitionering.

• Partitionering är tillgängligt när entitet skapas för alla köer och ämnen i grundläggande SKU:er eller standard-SKU:er. Ett namnområde kan ha både partitionerade och icke-partitionerade entiteter. Partitionering är tillgängligt när namnområdet skapas för premiumnivån, och alla köer och ämnen i namnområdet partitioneras. Alla tidigare migrerade partitionerade entiteter i Premium-namnområden fortsätter att fungera som förväntat.
• När partitionering är aktiverat i Basic- eller Standard-SKU:er skapar Service Bus 16 partitioner. När partitionering är aktiverat på premiumnivån anges antalet partitioner när namnområdet skapas.

Mer information finns i Partitionering i Service Bus.

Geo-haveri och återställning

Azure Service Bus sprider risken för katastrofala fel på enskilda datorer eller till och med kompletta rack över kluster som omfattar flera feldomäner i ett datacenter och implementerar transparenta mekanismer för felidentifiering och redundans så att tjänsten fortsätter att fungera inom de säkra tjänstnivåerna och vanligtvis utan märkbara avbrott när sådana fel inträffar. Ett premiumnamnområde kan ha två eller flera meddelandeenheter och dessa meddelandeenheter är spridda över flera feldomäner i ett datacenter, vilket stöder en helt aktiv Service Bus-klustermodell.

För ett premiumnivånamnområde sprids avbrottsrisken ytterligare över tre fysiskt avgränsade tillgänglighetszoner för anläggningar, och tjänsten har tillräckligt med kapacitetsreserver för att omedelbart hantera den fullständiga, katastrofala förlusten av ett datacenter. Den helt aktiva Azure Service Bus-klustermodellen i en feldomän tillsammans med stöd för tillgänglighetszonen är överlägsen alla lokala meddelandekoordinatorprodukter när det gäller återhämtning mot allvarliga maskinvarufel och till och med katastrofal förlust av hela datacenteranläggningar. Ändå kan det finnas allvarliga situationer med utbredd fysisk förstörelse som inte ens dessa åtgärder kan försvara sig tillräckligt mot.

Geo-haveriberedskapsfunktionen (Geo-DR) i Service Bus är utformad för att göra det enklare att återställa från en katastrof av den här storleken och överge en misslyckad Azure-region för gott utan att behöva ändra dina programkonfigurationer. Att överge en Azure-region omfattar vanligtvis flera tjänster, och den här funktionen syftar främst till att bevara integriteten i den sammansatta programkonfigurationen. Funktionen är globalt tillgänglig för Service Bus Premium-nivån.

Geo-Haveriberedskapsfunktionen säkerställer att hela konfigurationen av ett namnområde (entiteter, konfiguration, egenskaper) kontinuerligt replikeras från ett primärt namnområde till ett sekundärt namnområde som det är kopplat till, och det gör att du kan initiera en redundansväxling som endast en gång flyttas från den primära till den sekundära när som helst. Redundansflyttningen pekar om det valda aliasnamnet för namnområdet till det sekundära namnområdet och bryter sedan parkopplingen. Redundansväxlingen är nästan omedelbar när den har initierats.

Mer information finns i Geo-haveriberedskap för Azure Service Bus.

Geo-replikering

Geo-Replikeringsfunktionen är ett av alternativen för att isolera Azure Service Bus-program mot avbrott och katastrofer, vilket ger replikering av både metadata (entiteter, konfiguration, egenskaper) och data (meddelandedata och meddelandeegenskap/tillståndsändringar), medan geo-DR-funktionen som beskrivs i föregående avsnitt endast replikerar metadata.

Geo-replikeringsfunktionen säkerställer att metadata och data i ett namnområde kontinuerligt replikeras från en primär region till en eller flera sekundära regioner.

• Köer, ämnen, prenumerationer, filter.
• Data som finns i entiteterna.
• Alla tillståndsändringar och egenskapsändringar som körs mot meddelandena i ett namnområde.
• Namnområdeskonfiguration.

Med den här funktionen kan du när som helst befordra valfri sekundär region till primär. När du befordrar en sekundär återpunkt pekar namnet på namnområdet till den valda sekundära regionen och växlar rollerna mellan den primära och sekundära regionen. Kampanjen är nästan omedelbar när den väl har initierats.

Stöd för Java Message Service (JMS)

Premiumnivån stöder JMS 1.1 och JMS 2.0. Mer information finns i Använda JMS 2.0 med Azure Service Bus Premium.

Standardnivån stöder endast JMS 1.1-delmängd som fokuserar på köer. Mer information finns i Använda Java Message Service 1.1 med Azure Service Bus Standard.

Nästa steg

Se följande artikel: Uppdatera meddelandeenheter automatiskt.