Service Bus Premium Messaging-laag

Service Bus Messaging, dat entiteiten zoals wachtrijen en onderwerpen omvat, combineert functies voor bedrijfsberichten met krachtige semantiek voor publiceren/abonneren in de cloud. Service Bus Messaging wordt gebruikt als de communicatie-backbone voor veel geavanceerde cloudoplossingen.

De Premium-laag van de Service Bus Messaging-service zorgt voor de afhandeling van algemene klantaanvragen met betrekking tot de schaal, prestaties en beschikbaarheid van essentiële toepassingen. Voor productiescenario's wordt de laag Premium aanbevolen. Hoewel de functiesets bijna identiek zijn, zijn deze twee lagen van de Service Bus Messaging-service ontworpen voor verschillende gebruiksscenario’s.

In de volgende tabel worden enkele belangrijke verschillen uitgelicht.

Criteria Premium Standaard
Overal Hoge doorvoersnelheid Variabele doorvoersnelheid
Prestaties Voorspelbare prestaties Variabele latentie
Prijzen Vaste prijzen Variabel omslagstelsel voor betalen per gebruik
Schaal wijzigen 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.

Deze prestaties zijn niet alleen voorspelbaarder en beschikbaar, maar ook sneller. Met de Premium-laag zijn de piekprestaties veel sneller dan met de Standard-laag.

Technische verschillen Premium Messaging

In de volgende secties wordt een aantal verschillen besproken tussen Premium en Standard Messaging.

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 Standard Messaging en deze wilt overzetten naar de Premium-laag, moet u ervoor zorgen dat de functie voor express-entiteiten is uitgeschakeld.

Premium Messaging-resourcegebruik

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

  • Beheerbewerkingen zoals CRUD-bewerkingen (Maken, Ophalen, Bijwerken en Verwijderen) 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:

  • Transparantie bieden 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 toegewezen resources die zijn toegewezen aan de naamruimte. 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 zijn elk uur. In het geval van omhoog schalen betaalt u alleen voor de extra resources voor de uren dat deze zijn gebruikt.

Aan de slag met Premium Messaging

U kunt snel aan de slag met Premium Messaging. Het proces is vergelijkbaar met dat van Standard Messaging. 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 grotere nettoladingen van berichten hebben gebruikt op andere enterprise messaging-brokers en die naadloos willen migreren naar Azure Service Bus.

Hier volgen enkele overwegingen bij het verzenden van grote berichten in Azure Service Bus -

  • Alleen ondersteund in Naamruimten in de Premium-laag van Azure Service Bus.
  • Alleen ondersteund bij het gebruik van het AMQP-protocol. Niet ondersteund bij het gebruik van SBMP- of HTTP-protocollen, in de Premium-laag, is de maximale berichtgrootte voor deze 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, is het raadzaam om de nettoladingen van berichten zo klein mogelijk te houden 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.
  • Service Bus Explorer biedt geen ondersteuning voor het verzenden of ontvangen van grote berichten.

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 AMQP-protocol, dat essentiële beveiligingsupdates en verbeterde mogelijkheden biedt, vóór die datum.

Zie de aankondiging van de buitengebruikstelling van de ondersteuning voor meer informatie.

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 van het inschakelen van ondersteuning voor grote berichten voor een bestaande wachtrij.

Ondersteuning voor grote berichten inschakelen voor een bestaande wachtrij (of onderwerp)

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

Schermopname van de pagina Wachtrij maken met ondersteuning voor grote berichten ingeschakeld.

Netwerkbeveiliging

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 gegevens in rust

Azure Service Bus Premium biedt versleuteling van data-at-rest met Azure Storage Service Encryption (Azure SSE). Service Bus Premium maakt gebruik van Azure Storage om de gegevens op te slaan. Alle gegevens die zijn opgeslagen met Azure Storage, worden versleuteld met behulp van door Microsoft beheerde sleutels. Als u uw eigen sleutel gebruikt (ook wel door de klant beheerde sleutel (CMD) of door de klant beheerde sleutel genoemd), worden de gegevens nog steeds versleuteld met behulp van de door Microsoft beheerde sleutel, maar daarnaast wordt de door Microsoft beheerde sleutel versleuteld met behulp van de door de klant beheerde sleutel. Met deze functie kunt u de toegang tot door de klant beheerde sleutels maken, draaien, uitschakelen en intrekken die worden gebruikt voor het versleutelen van door Microsoft beheerde sleutels. Het inschakelen van de CMK-functie is een eenmalig installatieproces voor uw naamruimte. Zie Azure Service Bus-data-at-rest versleutelen voor meer informatie.

Partitionering

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.

Geo-noodgeval en herstel

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 worden verspreid over meerdere foutdomeinen binnen een datacenter, die ondersteuning bieden voor een volledig actief Service Bus-clustermodel.

Voor een naamruimte in de Premium-laag wordt het risico op storingen verder verdeeld over drie fysiek gescheiden beschikbaarheidszones voor faciliteiten en heeft de service voldoende capaciteitsreserves om direct om te gaan 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.

De Service Bus Geo-disaster recovery-functie is ontworpen om het gemakkelijker te maken om te herstellen van een noodgeval van deze omvang en om een mislukte Azure-regio voorgoed te verlaten zonder dat u uw toepassingsconfiguraties hoeft te wijzigen. Het afbreken van een Azure-regio omvat doorgaans verschillende services en deze functie is voornamelijk bedoeld om de integriteit van de samengestelde toepassingsconfiguratie te behouden. De functie is wereldwijd beschikbaar voor de Service Bus Premium-laag.

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

Ondersteuning voor Java Message Service (JMS)

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.

Volgende stappen

Zie het volgende artikel: Berichteneenheden automatisch bijwerken.