Storage Queues and Service Bus Queues - Compared and Contrasted (Storage-wachtrijen en Service Bus-wachtrijen: overeenkomsten en verschillen)
In dit artikel worden de verschillen en overeenkomsten tussen de twee typen wachtrijen geanalyseerd die worden aangeboden door Microsoft Azure: Opslagwachtrijen en Service Bus-wachtrijen. Door deze informatie te gebruiken, kunt u een beter geïnformeerde beslissing nemen over welke oplossing het beste aan uw behoeften voldoet.
Inleiding
ondersteuning voor Azure twee soorten wachtrijmechanismen: Opslagwachtrijen en Service Bus-wachtrijen.
Opslagwachtrijen maken deel uit van de Azure Storage-infrastructuur . Hiermee kunt u grote aantallen berichten opslaan. U hebt overal ter wereld toegang tot berichten via geverifieerde oproepen met HTTP of HTTPS. Een wachtrijbericht kan maximaal 64 KB groot zijn. Een wachtrij kan miljoenen berichten bevatten, tot aan de totale capaciteitslimiet van een opslagaccount. Wachtrijen worden vaak gebruikt om een voorraad werk te maken dat asynchroon moet worden verwerkt. Zie Wat zijn Azure Storage-wachtrijen voor meer informatie.
Service Bus-wachtrijen maken deel uit van een bredere Azure Messaging-infrastructuur die ondersteuning biedt voor wachtrijen, publiceren/abonneren en geavanceerdere integratiepatronen. Ze zijn ontworpen om toepassingen of toepassingsonderdelen te integreren die meerdere communicatieprotocollen, gegevenscontracten, vertrouwensdomeinen of netwerkomgevingen kunnen omvatten. Zie de Service Bus-wachtrijen, onderwerpen en abonnementen voor meer informatie over Service Bus-wachtrijen/onderwerpen/abonnementen.
Overwegingen voor technologieselectie
Opslagwachtrijen en Service Bus-wachtrijen hebben een iets andere functieset. U kunt een of beide kiezen, afhankelijk van de behoeften van uw specifieke oplossing.
Bij het bepalen welke wachtrijtechnologie past bij het doel van een bepaalde oplossing, moeten oplossingsarchitecten en ontwikkelaars rekening houden met deze aanbevelingen.
Overweeg opslagwachtrijen te gebruiken
Als oplossingsarchitect/ontwikkelaar moet u overwegen opslagwachtrijen te gebruiken wanneer:
- Uw toepassing moet meer dan 80 gigabyte aan berichten opslaan in een wachtrij.
- Uw toepassing wil de voortgang bijhouden voor het verwerken van een bericht in de wachtrij. Het is handig als de werknemer een bericht vastloopt. Een andere werknemer kan die informatie vervolgens gebruiken om door te gaan vanaf waar de vorige werknemer was gebleven.
- U hebt logboeken aan de serverzijde nodig van alle transacties die worden uitgevoerd voor uw wachtrijen.
Overweeg om Service Bus-wachtrijen te gebruiken
Als oplossingsarchitect/ontwikkelaar moet u overwegen om Service Bus-wachtrijen te gebruiken wanneer:
- Uw oplossing moet berichten ontvangen zonder de wachtrij te hoeven peilen. Met Service Bus kunt u dit bereiken met behulp van een langdurige polling-ontvangstbewerking met behulp van de TCP-protocollen die Service Bus ondersteunt.
- Uw oplossing vereist dat de wachtrij een gegarandeerde eerste-in-first-out (FIFO) bestelde levering biedt.
- Uw oplossing moet ondersteuning bieden voor automatische detectie van dubbele waarden.
- U wilt dat uw toepassing berichten verwerkt als parallelle langlopende streams (berichten zijn gekoppeld aan een stream met behulp van de eigenschap sessie-id in het bericht). In dit model concurreren elk knooppunt in de verbruikende toepassing voor streams, in plaats van berichten. Wanneer een stream wordt gegeven aan een verbruikend knooppunt, kan het knooppunt de status van de stroomstatus van de toepassing onderzoeken met behulp van transacties.
- Uw oplossing vereist transactioneel gedrag en atomiciteit bij het verzenden of ontvangen van meerdere berichten uit een wachtrij.
- Uw toepassing verwerkt berichten die groter zijn dan 64 kB, maar nadert waarschijnlijk niet de limiet van 256 kB of 1 MB, afhankelijk van de gekozen servicelaag (hoewel Service Bus-wachtrijen berichten tot 100 MB kunnen verwerken).
- U moet een op rollen gebaseerd toegangsmodel bieden voor de wachtrijen en verschillende rechten/machtigingen voor afzenders en ontvangers. Zie de volgende artikelen voor meer informatie:
- De grootte van uw wachtrij wordt niet groter dan 80 GB.
- U wilt het op standaarden gebaseerde berichtenprotocol AMQP 1.0 gebruiken. Zie Overzicht van Service Bus AMQP voor meer informatie over AMQP.
- U ziet een uiteindelijke migratie van punt-naar-punt-naar-punt-communicatie op basis van wachtrijen naar een berichtenpatroon voor publiceren/abonneren. Met dit patroon kunnen extra ontvangers (abonnees) worden geïntegreerd. Elke ontvanger ontvangt onafhankelijke kopieën van sommige of alle berichten die naar de wachtrij worden verzonden.
- Uw berichtenoplossing moet de leveringsgarantie 'At-Most-Once' en 'At-Least-Once' ondersteunen zonder dat u de extra infrastructuuronderdelen hoeft te bouwen.
- Uw oplossing moet batches berichten publiceren en gebruiken.
Opslagwachtrijen en Service Bus-wachtrijen vergelijken
De tabellen in de volgende secties bieden een logische groepering van wachtrijfuncties. Hiermee kunt u in één oogopslag de mogelijkheden vergelijken die beschikbaar zijn in zowel Azure Storage-wachtrijen als Service Bus-wachtrijen.
Basismogelijkheden
In deze sectie worden enkele van de fundamentele wachtrijmogelijkheden van Storage-wachtrijen en Service Bus-wachtrijen vergeleken.
| Vergelijkingscriteria | Opslagwachtrijen | Service Bus-wachtrijen |
|---|---|---|
| Bestelgarantie | Nee Zie de eerste opmerking in de sectie Aanvullende informatie voor meer informatie. |
Ja - First-In-First-Out (FIFO) (met behulp van berichtsessies) |
| Leveringsgarantie | Ten minste één keer | At-Least-Once (met peekLock-ontvangstmodus. Dit is de standaardinstelling) At-Most-Once (met receiveAndDelete-ontvangstmodus) Meer informatie over verschillende ontvangstmodi |
| Ondersteuning voor atomische bewerkingen | Nr. | Ja |
| Ontvangstgedrag | Niet-blokkerend (wordt onmiddellijk voltooid als er geen nieuw bericht wordt gevonden) |
Blokkeren met of zonder time-out (biedt lange polling of de "Komeettechniek") Niet-blokkerend (alleen met .NET beheerde API) |
| PUSH-API | Nr. | Ja Onze SDK's voor .NET, Java, JavaScript en Go bieden push-api's. |
| Ontvangstmodus | Korte weergave en lease | Korte weergave en vergrendeling Ontvangen en verwijderen |
| Exclusieve toegangsmodus | Lease gebaseerd | Op basis van vergrendeling |
| Duur lease/vergrendelen | 30 seconden (standaard) 7 dagen (maximum) (u kunt een berichtlease verlengen of vrijgeven met behulp van de UpdateMessage-API .) |
30 seconden (standaard) U kunt de berichtvergrendeling elke keer handmatig verlengen of de functie voor automatische vergrendelingsvernieuwing gebruiken, waarbij de client de verlenging van vergrendelingen voor u beheert. |
| Precisie lease/vergrendelen | Berichtniveau Elk bericht kan een andere time-outwaarde hebben, die u vervolgens zo nodig kunt bijwerken tijdens het verwerken van het bericht met behulp van de UpdateMessage-API . |
Wachtrijniveau (elke wachtrij heeft een vergrendelingsprecisie toegepast op alle berichten, maar de vergrendeling kan worden vernieuwd zoals beschreven in de vorige rij) |
| Batchgewijs ontvangen | Ja (expliciet het aantal berichten opgeven bij het ophalen van berichten, maximaal 32 berichten) |
Ja (impliciet een eigenschap voor ophalen vooraf inschakelen of expliciet met behulp van transacties) |
| Verzonden batchgewijs verzenden | Nr. | Ja (door transacties of batchverwerking aan de clientzijde te gebruiken) |
Aanvullende informatie
- Berichten in opslagwachtrijen zijn meestal first-in-first-out, maar soms zijn ze niet in orde. Wanneer de time-outduur voor zichtbaarheid van een bericht bijvoorbeeld verloopt omdat een clienttoepassing is vastgelopen tijdens het verwerken van een bericht. Wanneer de time-out voor zichtbaarheid verloopt, wordt het bericht weer zichtbaar in de wachtrij, zodat een andere werkrol het kan verwijderen. Op dat moment kan het zojuist zichtbare bericht in de wachtrij worden geplaatst om opnieuw te worden weergegeven.
- Voor het gegarandeerde FIFO-patroon in Service Bus-wachtrijen is het gebruik van berichtensessies vereist. Als de toepassing vastloopt tijdens het verwerken van een bericht dat is ontvangen in de modus Weergeven en vergrendelen , wordt de volgende keer dat een wachtrijontvanger een berichtensessie accepteert, gestart met het mislukte bericht nadat de vergrendelingsduur van de sessie is verlopen.
- Opslagwachtrijen zijn ontworpen ter ondersteuning van standaardwachtrijscenario's, zoals de volgende:
- Toepassingsonderdelen loskoppelen om de schaalbaarheid en tolerantie voor fouten te vergroten
- Herverdeling van belasting
- Proceswerkstromen bouwen.
- Inconsistenties met betrekking tot de verwerking van berichten in de context van Service Bus-sessies kunnen worden vermeden door de sessiestatus te gebruiken om de status van de toepassing op te slaan ten opzichte van de voortgang van de verwerking van de berichtenreeks van de sessie, en door transacties te gebruiken rond het vereffenen van ontvangen berichten en het bijwerken van de sessiestatus. Dit soort consistentiefunctie wordt soms exact eenmaal gelabeld als verwerking in de producten van andere leveranciers. Eventuele transactiefouten zorgen er uiteraard voor dat berichten opnieuw worden verzonden en daarom is de term niet precies voldoende.
- Opslagwachtrijen bieden een uniform en consistent programmeermodel voor wachtrijen, tabellen en BLOBs, zowel voor ontwikkelaars als voor operationele teams.
- Service Bus-wachtrijen bieden ondersteuning voor lokale transacties in de context van één wachtrij.
- De modus Ontvangen en verwijderen die door Service Bus wordt ondersteund, biedt de mogelijkheid om het aantal berichtenbewerkingen (en de bijbehorende kosten) te verminderen in ruil voor lagere leveringsgarantie.
- Opslagwachtrijen bieden leases met de mogelijkheid om de leases voor berichten uit te breiden. Met deze functie kunnen de werkprocessen korte leases voor berichten onderhouden. Dus als een werkrol vastloopt, kan het bericht snel opnieuw worden verwerkt door een andere werknemer. Bovendien kan een werknemer de lease op een bericht uitbreiden als deze langer moet worden verwerkt dan de huidige leasetijd.
- Opslagwachtrijen bieden een time-out voor zichtbaarheid die u kunt instellen op het controleren of verwijderen van een bericht. U kunt ook een bericht bijwerken met verschillende leasewaarden tijdens runtime en verschillende waarden bijwerken tussen berichten in dezelfde wachtrij. Time-outs voor Service Bus-vergrendeling worden gedefinieerd in de metagegevens van de wachtrij. U kunt de berichtvergrendeling echter handmatig verlengen voor de vooraf gedefinieerde duur van de vergrendeling of de functie voor automatische vergrendelingsvernieuwing gebruiken, waarbij de client de verlenging van vergrendelingen voor u beheert.
- De maximale time-out voor een blokkerende ontvangstbewerking in Service Bus-wachtrijen is 24 dagen. Op REST gebaseerde time-outs hebben echter een maximumwaarde van 55 seconden.
- Batchverwerking aan de clientzijde die door Service Bus wordt geleverd, stelt een wachtrijclient in staat om meerdere berichten in één verzendbewerking te batcheren. Batchverwerking is alleen beschikbaar voor asynchrone verzendbewerkingen.
- Functies zoals het plafond van 200 TB aan opslagwachtrijen (meer wanneer u accounts virtualiseert) en onbeperkte wachtrijen maken het een ideaal platform voor SaaS-providers.
- Opslagwachtrijen bieden een flexibel en goed presterend mechanisme voor gedelegeerd toegangsbeheer.
Geavanceerde mogelijkheden
In deze sectie worden geavanceerde mogelijkheden vergeleken die worden geboden door Opslagwachtrijen en Service Bus-wachtrijen.
| Vergelijkingscriteria | Opslagwachtrijen | Service Bus-wachtrijen |
|---|---|---|
| Geplande bezorging | Ja | Ja |
| Automatische dode lettering | Nr. | Ja |
| Time-to-live-waarde van wachtrij verhogen | Ja (via in-place update van time-out voor zichtbaarheid) |
Ja (geleverd via een toegewezen API-functie) |
| Ondersteuning voor gifberichten | Ja | Ja |
| In-place update | Ja | Ja |
| Transactielogboek aan serverzijde | Ja | Nr. |
| Metrische gegevens voor opslag | Ja Minute Metrics biedt realtime metrische gegevens voor beschikbaarheid, TPS, aantal API-aanroepen, foutaantallen en meer. Ze worden allemaal in realtime samengevoegd per minuut en binnen een paar minuten gerapporteerd van wat er zojuist in de productie is gebeurd. Zie Over Opslaganalyse metrische gegevens voor meer informatie. |
Ja Zie metrische gegevens van berichten voor informatie over metrische gegevens die worden ondersteund door Azure Service Bus. |
| Statusbeheer | Nee | Ja (Actief, Uitgeschakeld, SendDisabled, ReceiveDisabled. Zie Wachtrijstatus voor meer informatie over deze statussen. |
| Bericht automatisch doorsturen | Nr. | Ja |
| Wachtrijfunctie leegmaken | Ja | Ja |
| Berichtgroepen | Nr. | Ja (met behulp van berichtensessies) |
| Toepassingsstatus per berichtgroep | Nr. | Ja |
| Duplicaatdetectie | Nr. | Ja (configureerbaar aan de kant van de afzender) |
| Door berichtengroepen bladeren | Nr. | Ja |
| Berichtsessies ophalen op id | Nr. | Ja |
Aanvullende informatie
- Met beide wachtrijtechnologieën kan een bericht op een later tijdstip worden gepland voor levering.
- Met automatisch doorsturen van wachtrijen kunnen duizenden wachtrijen hun berichten automatisch doorsturen naar één wachtrij, waaruit de ontvangende toepassing het bericht verbruikt. U kunt dit mechanisme gebruiken om beveiliging, controlestroom en opslag tussen elke berichtuitgever te isoleren.
- Opslagwachtrijen bieden ondersteuning voor het bijwerken van berichtinhoud. U kunt deze functionaliteit gebruiken voor het behouden van statusinformatie en incrementele voortgangsupdates in het bericht, zodat het kan worden verwerkt vanaf het laatst bekende controlepunt, in plaats van helemaal opnieuw te beginnen. Met Service Bus-wachtrijen kunt u hetzelfde scenario inschakelen met behulp van berichtsessies. Zie de status van de berichtsessie voor meer informatie.
- Service Bus-wachtrijen bieden ondersteuning voor onbestelbare brieven. Het kan handig zijn voor het isoleren van berichten die voldoen aan de volgende criteria:
- Berichten kunnen niet worden verwerkt door de ontvangende toepassing
- Berichten kunnen hun bestemming niet bereiken vanwege een verlopen TTL-eigenschap (Time to Live). De TTL-waarde geeft aan hoe lang een bericht in de wachtrij blijft. Met Service Bus wordt het bericht verplaatst naar een speciale wachtrij met de naam $DeadLetterQueue wanneer de TTL-periode verloopt.
- Als u 'gif'-berichten in Storage-wachtrijen wilt vinden, onderzoekt de toepassing de eigenschap DequeueCount van het bericht wanneer u een bericht uit de wachtrij verwijdert. Als DequeueCount groter is dan een bepaalde drempelwaarde, verplaatst de toepassing het bericht naar een door de toepassing gedefinieerde wachtrij met 'dode letters'.
- Met opslagwachtrijen kunt u een gedetailleerd logboek ophalen van alle transacties die worden uitgevoerd op basis van de wachtrij en geaggregeerde metrische gegevens. Beide opties zijn handig voor foutopsporing en inzicht in hoe uw toepassing opslagwachtrijen gebruikt. Ze zijn ook handig voor het afstemmen van de prestaties van uw toepassing en het verlagen van de kosten voor het gebruik van wachtrijen.
- Met berichtensessies die worden ondersteund door Service Bus, kunnen berichten die deel uitmaken van een logische groep, worden gekoppeld aan een ontvanger. Er wordt een sessieachtige affiniteit tussen berichten en hun respectieve ontvangers gemaakt. U kunt deze geavanceerde functionaliteit in Service Bus inschakelen door de eigenschap sessie-id in te stellen op een bericht. Ontvangers kunnen vervolgens luisteren naar een specifieke sessie-id en berichten ontvangen die de opgegeven sessie-id delen.
- De functie voor duplicatiedetectie van Service Bus-wachtrijen verwijdert automatisch dubbele berichten die naar een wachtrij of onderwerp worden verzonden, op basis van de waarde van de eigenschap bericht-id.
Capaciteit en quota
In deze sectie worden opslagwachtrijen en Service Bus-wachtrijen vergeleken vanuit het perspectief van capaciteit en quota die van toepassing kunnen zijn.
| Vergelijkingscriteria | Opslagwachtrijen | Service Bus-wachtrijen |
|---|---|---|
| Maximale wachtrijgrootte | 500 TB (beperkt tot één opslagaccountcapaciteit) |
1 GB tot 80 GB (Premium SKU of Standard SKU met partitionering) |
| Maximale berichtgrootte | 64 kB (48 KB bij het gebruik van Base 64-codering) ondersteuning voor Azure grote berichten door wachtrijen en blobs te combineren. Op dat moment kunt u maximaal 200 GB voor één item in de wachtrij plaatsen. |
256 KB, 1 MB of 100 MB (inclusief koptekst en hoofdtekst, maximale koptekstgrootte: 64 kB). Is afhankelijk van de servicelaag. |
| Maximum aantal bericht-TTL's | Oneindig (api-versie 2017-07-27 of hoger) | TimeSpan.MaxValue |
| Maximum aantal wachtrijen | Onbeperkt | 10.000 (Standard SKU) 1000 / Berichteneenheid (Premium SKU) (per servicenaamruimte) |
| Maximum aantal gelijktijdige clients | Onbeperkt | 5.000 |
Aanvullende informatie
- Service Bus dwingt limieten voor wachtrijgrootten af. De maximale wachtrijgrootte wordt opgegeven bij het maken van een wachtrij. Dit kan tussen 1 GB en 80 GB zijn. Als de grootte van de wachtrij deze limiet bereikt, worden extra binnenkomende berichten geweigerd en ontvangt de beller een uitzondering. Zie Service Bus-quota's voor meer informatie over quota in Service Bus.
- In de Standard Messaging-laag kunt u Service Bus-wachtrijen en onderwerpen maken in 1 (standaard), 2, 3, 4 of 5 GB. Wanneer u partitionering inschakelt in de Standard-laag, maakt Service Bus 16 kopieën (16 partities) van de entiteit, elk van dezelfde grootte die is opgegeven. Als u als zodanig een wachtrij maakt die 5 GB groot is, met 16 partities wordt de maximale wachtrijgrootte (5 * 16) = 80 GB. U kunt de maximale grootte van uw gepartitioneerde wachtrij of onderwerp bekijken in Azure Portal.
- Als de inhoud van het bericht niet xml-veilig is, moet de inhoud met Storage-wachtrijen worden gecodeerd met Base64 . Als u het bericht base64 coderen, kan de nettolading van de gebruiker maximaal 48 kB zijn in plaats van 64 kB.
- Met Service Bus-wachtrijen bestaat elk bericht dat in een wachtrij is opgeslagen uit twee delen: een koptekst en een hoofdtekst. De totale grootte van het bericht mag niet groter zijn dan de maximale berichtgrootte die wordt ondersteund door de servicelaag.
- Wanneer clients communiceren met Service Bus-wachtrijen via het TCP-protocol, is het maximum aantal gelijktijdige verbindingen met één Service Bus-wachtrij beperkt tot 100. Dit nummer wordt gedeeld tussen afzenders en ontvangers. Als dit quotum is bereikt, worden aanvragen voor extra verbindingen geweigerd en wordt er een uitzondering ontvangen door de aanroepende code. Deze limiet wordt niet opgelegd aan clients die verbinding maken met de wachtrijen met behulp van rest-API.
- Als u meer dan 10.000 wachtrijen wilt schalen met Service Bus Standard SKU of 1000 wachtrijen/berichteneenheid met Service Bus Premium SKU, kunt u ook extra naamruimten maken met behulp van Azure Portal.
Beheer en bewerkingen
In deze sectie worden de beheerfuncties van Opslagwachtrijen en Service Bus-wachtrijen vergeleken.
| Vergelijkingscriteria | Opslagwachtrijen | Service Bus-wachtrijen |
|---|---|---|
| Beheerprotocol | REST via HTTP/HTTPS | REST via HTTPS |
| Runtime-protocol | REST via HTTP/HTTPS | REST via HTTPS AMQP 1.0 Standard (TCP met TLS) |
| .NET API | Ja (.NET Storage Client API) |
Ja (.NET Service Bus API) |
| Systeemeigen C++ | Ja | Ja |
| Java-API | Ja | Ja |
| PHP-API | Ja | Ja |
| Node.js-API | Ja | Ja |
| Ondersteuning voor willekeurige metagegevens | Ja | Nr. |
| Regels voor naamgeving van wachtrijen | Maximaal 63 tekens lang (Letters in een wachtrijnaam moeten kleine letters zijn.) |
Maximaal 260 tekens lang (Wachtrijpaden en -namen zijn niet hoofdlettergevoelig.) |
| Functie Wachtrijlengte ophalen | Ja (Geschatte waarde als berichten buiten de TTL verlopen zonder te worden verwijderd.) |
Ja (Exacte, point-in-time-waarde.) |
| De functie Peek | Ja | Ja |
Aanvullende informatie
- Opslagwachtrijen bieden ondersteuning voor willekeurige kenmerken die kunnen worden toegepast op de beschrijving van de wachtrij, in de vorm van naam-/waardeparen.
- Beide wachtrijtechnologieën bieden de mogelijkheid om een bericht te bekijken zonder het te hoeven vergrendelen, wat handig kan zijn bij het implementeren van een hulpprogramma wachtrijverkenner/browser.
- De Service Bus .NET Brokered Messaging-API's maken gebruik van full-duplex TCP-verbindingen voor verbeterde prestaties in vergelijking met REST via HTTP en ondersteunen het AMQP 1.0-standaardprotocol.
- Namen van opslagwachtrijen kunnen 3 tot 63 tekens lang zijn, kunnen kleine letters, cijfers en afbreekstreepjes bevatten. Zie Naamgevingswachtrijen en metagegevens voor meer informatie.
- Namen van Service Bus-wachtrijen kunnen maximaal 260 tekens lang zijn en hebben minder beperkende naamgevingsregels. Service Bus-wachtrijnamen kunnen letters, cijfers, punten, afbreekstreepjes en onderstrepingstekens bevatten.
Verificatie en autorisatie
In deze sectie worden de verificatie- en autorisatiefuncties besproken die worden ondersteund door Opslagwachtrijen en Service Bus-wachtrijen.
| Vergelijkingscriteria | Opslagwachtrijen | Service Bus-wachtrijen |
|---|---|---|
| Verificatie | Symmetrische sleutel en op rollen gebaseerd toegangsbeheer (RBAC) | Symmetrische sleutel en op rollen gebaseerd toegangsbeheer (RBAC) |
| Federatie van id-provider | Ja | Ja |
Aanvullende informatie
- Elke aanvraag voor een van de wachtrijtechnologieën moet worden geverifieerd. Openbare wachtrijen met anonieme toegang worden niet ondersteund.
- Met sas-verificatie (Shared Access Signature) kunt u een regel voor gedeelde toegangsautorisatie maken in een wachtrij waarmee gebruikers alleen-schrijven, alleen-lezen of volledige toegang kunnen krijgen. Zie Azure Storage - SAS-verificatie en Azure Service Bus - SAS-verificatie voor meer informatie.
- Beide wachtrijen ondersteunen het autoriseren van toegang met behulp van Microsoft Entra-id. Het autoriseren van gebruikers of toepassingen met behulp van OAuth 2.0-token dat wordt geretourneerd door Microsoft Entra ID biedt superieure beveiliging en gebruiksgemak ten opzichte van handtekeningen voor gedeelde toegang (SAS). Met Microsoft Entra ID hoeft u de tokens niet op te slaan in uw code en potentiële beveiligingsproblemen te riskeren. Zie Azure Storage - Microsoft Entra-verificatie en Azure Service Bus - Microsoft Entra-verificatie voor meer informatie.
Conclusie
Door meer inzicht te krijgen in de twee technologieën, kunt u een beter geïnformeerde beslissing nemen over welke wachtrijtechnologie moet worden gebruikt en wanneer. De beslissing over het gebruik van Opslagwachtrijen of Service Bus-wachtrijen hangt duidelijk af van veel factoren. Deze factoren zijn sterk afhankelijk van de individuele behoeften van uw toepassing en de bijbehorende architectuur.
U kunt liever Opslagwachtrijen kiezen om redenen zoals de volgende wachtrijen:
- Als uw toepassing al gebruikmaakt van de kernmogelijkheden van Microsoft Azure
- Als u basiscommunicatie en berichten tussen services nodig hebt
- Wachtrijen nodig die groter kunnen zijn dan 80 GB
Service Bus-wachtrijen bieden veel geavanceerde functies, zoals de volgende. Ze kunnen dus een voorkeurskeuze zijn als u een hybride toepassing bouwt of als voor uw toepassing anders deze functies zijn vereist.
- Sessies
- Transacties
- Duplicatendetectie
- Automatische dead-lettering
- Duurzame mogelijkheden voor publiceren en abonneren
Volgende stappen
De volgende artikelen bevatten meer richtlijnen en informatie over het gebruik van Opslagwachtrijen of Service Bus-wachtrijen.