Azure Service Bus Premium Messaging-laag

Azure Service Bus is een volledig beheerde berichtenbroker voor ondernemingen. De Premium-laag van Service Bus biedt toegewezen resource-isolatie op CPU- en geheugenniveau, zodat elke berichtenworkload onafhankelijk van andere tenants wordt uitgevoerd. Zie Wat is Azure Service Bus? voor meer informatie over Service Bus.

Wanneer uw toepassingen voorspelbare doorvoer, consistente latentie of ondersteuning voor grote berichten tot 100 MB vereisen, biedt de Premium-laag de prestatiegaranties die u nodig hebt voor productie- en bedrijfskritieke scenario's.

In dit artikel worden de technische verschillen tussen de Premium- en Standard-lagen uitgelegd, hoe berichteneenheden en resourcegebruik werken en hoe u aan de slag gaat met een Premium-naamruimte. In de volgende tabel worden enkele belangrijke verschillen gemarkeerd.

Criterium Premiumkwaliteit Standaard
Doorvoer Hoge doorvoersnelheid Variabele doorvoersnelheid
Prestaties Voorspelbare prestaties Variabele latentie
Prijzen Vaste prijzen Variabele prijsstelling voor betalen naar gebruik
Schaal Mogelijkheid om de workload omhoog en omlaag te schalen N.v.t.
Berichtgrootte Berichtgrootte tot 100 MB. Zie Ondersteuning voor grote berichten voor meer informatie. Berichtformaat tot maximaal 256 kB

Service Bus Premium Messaging biedt isolatie van resources op het niveau van de CPU en het geheugen, zodat elke workload van een klant geïsoleerd wordt uitgevoerd. Deze resourcecontainer wordt een Messaging-eenheid genoemd. Aan elke Premium-naamruimte wordt ten minste één Messaging-eenheid toegewezen. U kunt 1, 2, 4, 8 of 16 berichteneenheden aanschaffen voor elke Service Bus Premium-naamruimte. Eén workload of entiteit kan meerdere berichteneenheden omvatten en het aantal berichteneenheden kan op elk moment worden gewijzigd. Dit resulteert in voorspelbare en herhaalbare prestaties voor uw Service Bus-oplossing.

Premium Messaging biedt ook snellere piekprestaties in vergelijking met de standard-laag.

Technische verschillen in Premium Messaging

In de volgende secties worden enkele verschillen tussen Premium- en Standard Messaging-lagen besproken.

Express-entiteiten

Omdat Premium Messaging wordt uitgevoerd in een geïsoleerde runtimeomgeving, worden express-entiteiten niet ondersteund in Premium-naamruimten. Een express-entiteit bevat tijdelijk een bericht in het geheugen voordat deze naar permanente opslag wordt geschreven. Als u code hebt die wordt uitgevoerd onder standaardberichten en deze wilt overzetten naar de Premium-laag, moet u ervoor zorgen dat de functie voor express-entiteiten is uitgeschakeld.

Resourcegebruik voor Premium Messaging

Over het algemeen kan elke bewerking op een entiteit cpu- en geheugengebruik veroorzaken. Hier volgen enkele van deze bewerkingen:

  • Beheerbewerkingen zoals CRUD-bewerkingen (Create, Retrieve, Update en Delete) voor wachtrijen, onderwerpen en abonnementen.
  • Runtimebewerkingen (berichten verzenden en ontvangen).
  • Bewakingsbewerkingen en waarschuwingen.

Het extra CPU- en geheugengebruik is echter niet geprijsd. Voor de Premium Messaging-laag is er één prijs voor de berichteneenheid.

Het CPU- en geheugengebruik worden om de volgende redenen bijgehouden en weergegeven:

  • Zorg voor transparantie in de interne systeeminstellingen.
  • Inzicht in de capaciteit van aangeschafte resources.
  • Capaciteitsplanning waarmee u kunt besluiten omhoog/omlaag te schalen.

Hoeveel berichteneenheden zijn er nodig?

U geeft het aantal berichteneenheden op bij het inrichten van een Azure Service Bus Premium-naamruimte. Deze berichteneenheden zijn toegewijde resources die aan de naamruimte zijn toegewezen. Wanneer partitionering is ingeschakeld voor de naamruimte, worden de berichteneenheden gelijkmatig verdeeld over de partities.

Het aantal berichteneenheden dat is toegewezen aan de Service Bus Premium-naamruimte, kan dynamisch worden aangepast om rekening te houden met de wijziging (toename of afname) van workloads.

Er zijn enkele factoren die u moet overwegen bij het bepalen van het aantal berichteneenheden voor uw architectuur:

  • Begin met 1 of 2 berichteneenheden die zijn toegewezen aan uw naamruimte of 1 berichteenheid per partitie.
  • Bekijk de metrische gegevens over het CPU-gebruik binnen de metrische gegevens over resourcegebruik voor uw naamruimte.
    • Als het CPU-gebruik lager is dan 20%, kunt u mogelijk het aantal berichteneenheden dat aan uw naamruimte is toegewezen omlaag schalen .
    • Als het CPU-gebruik hoger is dan 70%, profiteert uw toepassing van het omhoog schalen van het aantal berichteneenheden dat aan uw naamruimte is toegewezen.

Zie Berichteneenheden automatisch bijwerken voor informatie over het configureren van een Service Bus-naamruimte om automatisch te schalen (berichteneenheden vergroten of verkleinen).

Notitie

Het schalen van de resources die aan de naamruimte zijn toegewezen, kan preemptive of reactief zijn.

  • Preemptive: Als er extra werkbelasting wordt verwacht (vanwege seizoensgebondenheid of trends), kunt u doorgaan met het toewijzen van meer berichteneenheden aan de naamruimte voordat de workloads worden bereikt.

  • Reactief: als er extra workloads worden geïdentificeerd door de metrische gegevens over resourcegebruik te bestuderen, kunnen extra resources worden toegewezen aan de naamruimte om een toenemende vraag op te nemen.

De factureringsmeters voor Service Bus werken per uur. Wanneer u omhoog schaalt, betaalt u alleen voor de extra resources voor de uren dat deze zijn gebruikt.

Aan de slag met Premium Messaging

Aan de slag met Premium Messaging is eenvoudig en het proces is vergelijkbaar met die van standaardberichten. Maak eerst een naamruimte in Azure Portal. Zorg ervoor dat bij Prijscategorie de optie Premium is geselecteerd. Selecteer Volledige prijsinformatie weergeven voor meer informatie over elke laag.

Schermopname van de selectie van de Premium-laag bij het maken van een naamruimte.

U kunt ook Premium-naamruimtes maken met behulp van Azure Resource Manager-sjablonen.

Ondersteuning voor grote berichten

Azure Service Bus-naamruimten van de Premium-laag ondersteunen de mogelijkheid om grote berichtnettoladingen tot 100 MB te verzenden. Deze functie is voornamelijk gericht op verouderde workloads die gebruikmaken van grotere nettoladingen voor berichten in andere enterprise messaging-brokers en die naadloos willen migreren naar Azure Service Bus.

Hier volgen enkele overwegingen bij het verzenden van grote berichten op Azure Service Bus:

  • Alleen ondersteund in Naamruimten in de Premium-laag van Azure Service Bus.
  • Alleen ondersteund bij het gebruik van het AMQP-protocol (Advanced Message Queuing Protocol). Niet ondersteund bij het gebruik van SBMP- of HTTP-protocollen, in de Premium-laag, is de maximale berichtgrootte voor SBMP- en HTTP-protocollen 1 MB.
  • Ondersteund bij het gebruik van JMS 2.0-client-SDK (Java Message Service) en andere client-SDK's voor talen.
  • Het verzenden van grote berichten resulteert in een verminderde doorvoer en een verhoogde latentie.
  • Hoewel nettoladingen van 100 MB berichten worden ondersteund, houdt u de nettoladingen van het bericht zo klein mogelijk om betrouwbare prestaties van de Service Bus naamruimte te garanderen.
  • De maximale berichtgrootte wordt alleen afgedwongen voor berichten die naar de wachtrij of het onderwerp worden verzonden. De groottelimiet wordt niet afgedwongen voor de ontvangstbewerking. Hiermee kunt u de maximale berichtgrootte voor een bepaalde wachtrij (of onderwerp) bijwerken.
  • Batchverwerking wordt niet ondersteund.

Important

Op 30 september 2026 wordt de ondersteuning van het SBMP-protocol voor Azure Service Bus buiten gebruik gesteld, zodat u dit protocol na 30 september 2026 niet meer kunt gebruiken. Migreer naar de nieuwste Azure Service Bus SDK-bibliotheken met behulp van het Advanced Message Queuing Protocol (AMQP), dat essentiële beveiligingsupdates en verbeterde mogelijkheden biedt, vóór die datum.

Zie voor meer informatie de aankondiging van het buitengebruik stellen van de ondersteuning.

Ondersteuning voor grote berichten inschakelen voor een nieuwe wachtrij of onderwerp

Als u ondersteuning voor grote berichten wilt inschakelen, stelt u de maximale berichtgrootte in bij het maken van een nieuwe wachtrij of onderwerp, zoals wordt weergegeven in de volgende afbeelding:

Schermopname die laat zien hoe u ondersteuning voor grote berichten inschakelt bij het maken van een nieuwe wachtrij.

Ondersteuning voor grote berichten inschakelen voor een bestaande wachtrij of een bestaand onderwerp

U kunt ook ondersteuning inschakelen voor grote berichten voor bestaande wachtrijen of onderwerpen door de maximale berichtgrootte bij te werken in het overzicht voor die specifieke wachtrij of onderwerp, zoals wordt weergegeven in de volgende afbeelding.

Schermopname van de pagina Overzicht voor een bestaande wachtrij met de instelling Maximale berichtgrootte.

Netwerkbeveiliging in Service Bus Premium

De volgende netwerkbeveiligingsfuncties zijn alleen beschikbaar in de Premium-laag. Zie Netwerkbeveiliging voor meer informatie.

Ip-firewall configureren met behulp van Azure Portal is alleen beschikbaar voor de naamruimten van de Premium-laag. U kunt echter IP-firewallregels configureren voor andere lagen met behulp van Azure Resource Manager-sjablonen, CLI, PowerShell of REST API. Zie IP-firewall configureren voor meer informatie.

Versleuteling van data in rust in Service Bus

Alle Service Bus gegevens worden in rust versleuteld met behulp van door Microsoft beheerde sleutels in zowel de Standard- als de Premium-laag. De Premium-laag ondersteunt ook door de klant beheerde sleutels (CMK), waarmee een tweede versleutelingslaag wordt toegevoegd boven op de Microsoft beheerde sleutel. Met CMK kunt u de toegang tot de sleutels die worden gebruikt voor het versleutelen van uw gegevens maken, draaien, uitschakelen en intrekken. Door de klant beheerde sleutels inschakelen is een eenmalig installatieproces in uw naamruimte. Zie Azure Service Bus-data-at-rest versleutelen voor meer informatie.

Partitioneren in Service Bus

Er zijn enkele verschillen tussen de standard- en premium-lagen als het gaat om partitionering.

  • Partitionering is beschikbaar bij het maken van entiteiten voor alle wachtrijen en onderwerpen in basis- of standaard-SKU's. Een naamruimte kan zowel gepartitioneerde als niet-gepartitioneerde entiteiten bevatten. Partitionering is beschikbaar bij het maken van naamruimten voor de Premium-laag en alle wachtrijen en onderwerpen in die naamruimte worden gepartitioneerd. Alle eerder gemigreerde gepartitioneerde entiteiten in Premium-naamruimten blijven werken zoals verwacht.
  • Wanneer partitionering is ingeschakeld in de Basic- of Standard-SKU's, maakt Service Bus 16 partities. Wanneer partitionering is ingeschakeld in de Premium-laag, wordt het aantal partities opgegeven tijdens het maken van de naamruimte.

Zie Partitionering in Service Bus voor meer informatie.

Hoge beschikbaarheid in Service Bus

Azure Service Bus verspreidt het risico op onherstelbare fouten van afzonderlijke machines of zelfs complete racks tussen clusters die meerdere foutdomeinen binnen een datacenter omvatten en implementeert transparante foutdetectie- en failovermechanismen, zodat de service blijft werken binnen de verzekerde serviceniveaus en doorgaans zonder merkbare onderbrekingen wanneer dergelijke fouten optreden. Een Premium-naamruimte kan twee of meer berichteneenheden hebben, en deze berichteneenheden zijn verspreid over meerdere storingsdomeinen binnen een datacenter, ter ondersteuning van een volledig actief Service Bus-clustermodel.

Voor een Service Bus naamruimte wordt het risico op storingen verder verspreid over drie fysiek gescheiden faciliteiten beschikbaarheidszones en heeft de service voldoende capaciteitsreserves om direct te kunnen omgaan met het volledige, catastrofale verlies van een datacenter. Het volledig actieve Azure Service Bus-clustermodel binnen een foutdomein, samen met de ondersteuning van de beschikbaarheidszone, is beter dan elk on-premises message broker-product in termen van tolerantie tegen ernstige hardwarefouten en zelfs onherstelbaar verlies van volledige datacenterfaciliteiten. Toch kunnen er ernstige situaties zijn met wijdverspreide fysieke vernietiging die zelfs die maatregelen niet voldoende kunnen verdedigen.

Bovendien is de functie Geo-Replication een van de opties om Azure Service Bus-toepassingen te beschermen tegen storingen en rampen, waarmee replicatie van zowel metagegevens (entiteiten, configuratie, eigenschappen) als gegevens (berichtgegevens en wijzigingen in berichteigenschappen of de status) wordt geboden. De functie Geo-replicatie zorgt ervoor dat de metagegevens en gegevens van een naamruimte continu worden gerepliceerd van een primaire regio naar een of meer secundaire regio's.

  • Wachtrijen, onderwerpen, abonnementen, filters.
  • Gegevens die zich in de entiteiten hebben gevestigd.
  • Alle statuswijzigingen en eigenschapswijzigingen worden uitgevoerd voor de berichten in een naamruimte.
  • Naamruimteconfiguratie.

Met deze functie kunt u op elk gewenst moment elke secundaire regio naar primaire regio promoveren. Door een secundaire regio te promoten, wordt de naam voor de naamruimte naar de geselecteerde secundaire regio hergericht, en worden de rollen tussen de primaire en de secundaire regio omgewisseld. De promotie is bijna onmiddellijk gestart.

Zie Azure Service Bus Geo-disaster recovery (Geo-herstel na noodgeval in Azure Service Bus) voor meer informatie.

ondersteuning voor Java Message Service (JMS) in Service Bus

De Premium-laag ondersteunt JMS 1.1 en JMS 2.0. Zie JMS 2.0 gebruiken met Azure Service Bus Premium voor meer informatie.

De standard-laag ondersteunt alleen JMS 1.1-subset die is gericht op wachtrijen. Zie Java Message Service 1.1 gebruiken met Azure Service Bus Standard voor meer informatie.