Gebruik een wachtrij die fungeert als een buffer tussen een taak en een service die wordt aangeroepen om onregelmatige zware belastingen die ertoe kunnen leiden dat de service mislukt of dat er een time-out optreedt voor de taak. Dit kan helpen om de impact van pieken in de vraag op beschikbaarheid en reactiesnelheid voor zowel de taak als de service te minimaliseren.
Context en probleem
Veel oplossingen in de cloud hebben betrekking op actieve taken die services aanroepen. Als in deze omgeving een service te maken heeft met onregelmatige zware belastingen, kan dit leiden tot problemen met de prestaties of betrouwbaarheid.
Een service kan deel uitmaken van dezelfde oplossing als de taken die de service gebruiken of kan een service van derden zijn die toegang biedt tot veelgebruikte resources, zoals een cache of een opslagservice. Als dezelfde service wordt gebruikt door een aantal taken die gelijktijdig worden uitgevoerd, kan het lastig zijn om op elk moment het volume van de aanvragen van de service te voorspellen.
Een service kan pieken in de vraag ondervinden die ertoe leiden dat de service wordt overbelast en niet op tijd kan reageren op aanvragen. Als een service wordt overspoeld door een groot aantal gelijktijdige aanvragen, kan dit er ook toe leiden dat de service tekortschiet als deze de conflicten die deze aanvragen veroorzaken, niet kan afhandelen.
Oplossing
Herstructureer de oplossing en plaats een wachtrij tussen de taak en de service. De taak en de service worden asynchroon uitgevoerd. De taak plaatst een bericht met de gegevens die de service vereist in een wachtrij. De wachtrij fungeert als buffer en slaat het bericht op totdat dit wordt opgehaald door de service. De service haalt de berichten uit de wachtrij op en verwerkt deze. Aanvragen van een aantal taken, die met een zeer variabele snelheid kunnen worden gegenereerd, kunnen via dezelfde berichtenwachtrij worden doorgegeven aan de service. In deze afbeelding ziet u hoe een wachtrij wordt gebruikt om de belasting van een service te spreiden.
De wachtrij koppelt de taken los van de service en de service kan de berichten in zijn eigen tempo afhandelen, ongeacht het volume van de aanvragen van gelijktijdige taken. Daarnaast treedt er geen vertraging in een taak op als de service niet beschikbaar is op het moment dat een bericht in de wachtrij wordt geplaatst.
Dit patroon biedt de volgende voordelen:
Het kan helpen zorgen voor een maximale beschikbaarheid omdat vertragingen in services geen onmiddellijke en directe invloed hebben op de toepassing, die berichten in de wachtrij kan blijven plaatsen, zelfs als de service niet beschikbaar is of momenteel geen berichten verwerkt.
Het kan helpen zorgen voor een maximale schaalbaarheid omdat zowel het aantal wachtrijen als het aantal services kan worden gevarieerd om aan vraag te voldoen.
Het kan helpen de kosten te beperken omdat het aantal geïmplementeerde service-exemplaren alleen toereikend hoeft te zijn voor de gemiddelde belasting in plaats van voor de piekbelasting.
Sommige services implementeren aanvraagbeperking als de vraag een drempel bereikt waarboven het systeem tekort kan schieten. Deze beperking kan de beschikbare functionaliteit verminderen. U kunt load leveling implementeren met deze services om ervoor te zorgen dat deze drempelwaarde niet wordt bereikt.
Problemen en overwegingen
Beschouw de volgende punten als u besluit hoe u dit patroon wilt implementeren:
- U moet een toepassingslogica implementeren die de snelheid bepaalt waarop services berichten afhandelen om te voorkomen dat de doelresource wordt overspoeld. Vermijd dat pieken in de aanvraag worden doorgestuurd naar de volgende fase van het systeem. Test het systeem met belasting om er zeker van te zijn dat het de vereiste herverdeling biedt en pas het aantal wachtrijen en het aantal service-exemplaren dat berichten afhandelt aan om dit te bereiken.
- Berichtenwachtrijen zijn een eenrichtingscommunicatiemechanisme. Als een taak een antwoord van een service verwacht, is het wellicht noodzakelijk een mechanisme te implementeren dat de service kan gebruiken kunt om een antwoord te verzenden. Zie Asynchronous Messaging Primer (Inleiding in asynchrone berichtverzending) voor meer informatie.
- Wees voorzichtig als u automatisch schalen toepast op services die luisteren naar aanvragen in de wachtrij. Dit kan leiden tot meer conflicten voor alle resources die deze services delen en de effectiviteit van het gebruik van de wachtrij om de belasting te spreiden verminderen.
- Afhankelijk van de belasting van de service, kunt u een situatie tegenkomen waarin u effectief altijd achterloopt, waarbij het systeem altijd in de wachtrij staat voor meer aanvragen dan u verwerkt. Er moet rekening worden gehouden met de variabiliteit van binnenkomend verkeer naar uw toepassing
- Het patroon kan informatie verliezen, afhankelijk van de persistentie van de wachtrij. Als uw wachtrij vastloopt of informatie wegvalt (vanwege systeemlimieten) is er een mogelijkheid dat u geen gegarandeerde levering hebt. Er moet rekening worden gehouden met het gedrag van uw wachtrij- en systeemlimieten op basis van de behoeften van uw oplossing.
Wanneer dit patroon gebruiken
Dit patroon is bruikbaar voor elke toepassing die gebruikmaakt van services die vatbaar zijn voor overbelasting.
Dit patroon is niet bruikbaar als de toepassing een reactie van de service verwacht met een minimale latentie.
Workloadontwerp
Een architect moet evalueren hoe het patroon load leveling op basis van wachtrijen kan worden gebruikt in het ontwerp van hun workload om de doelstellingen en principes te verhelpen die worden behandeld in de pijlers van het Azure Well-Architected Framework. Voorbeeld:
| Pijler | Hoe dit patroon ondersteuning biedt voor pijlerdoelen |
|---|---|
| Beslissingen over betrouwbaarheidsontwerp helpen uw workload bestand te worden tegen storingen en ervoor te zorgen dat deze herstelt naar een volledig functionerende status nadat er een fout is opgetreden. | De aanpak die in dit patroon wordt beschreven, kan tolerantie bieden tegen plotselinge pieken in de vraag door de ontvangst van taken los te koppelen van hun verwerking. Het kan ook storingen in wachtrijverwerking isoleren, zodat ze geen invloed hebben op de opname. - RE:06 Schalen - RE:07 Achtergrondtaken |
| Kostenoptimalisatie is gericht op het ondersteunen en verbeteren van het rendement van uw workload op investering. | Omdat de belastingverwerking is losgekoppeld van de aanvraag of taakinname, kunt u deze methode gebruiken om de noodzaak te verminderen om resources te veel inrichten om piekbelasting te verwerken. - CO:12 Schaalkosten |
| Prestatie-efficiëntie helpt uw workload efficiënt te voldoen aan de vereisten door optimalisaties in schalen, gegevens, code. | Deze benadering maakt opzettelijk ontwerp mogelijk voor doorvoerprestaties, omdat de opname van aanvragen niet hoeft te correleren met de snelheid waarin ze worden verwerkt. - PE:05 Schalen en partitioneren |
Net als bij elke ontwerpbeslissing moet u rekening houden met eventuele compromissen ten opzichte van de doelstellingen van de andere pijlers die met dit patroon kunnen worden geïntroduceerd.
Opmerking
Een web-app schrijft gegevens naar een extern gegevensarchief. Als een groot aantal exemplaren van de web-app gelijktijdig wordt uitgevoerd, kan het gegevensarchief mogelijk niet snel genoeg reageren op aanvragen, waardoor er een time-out optreedt voor aanvragen, wordt vertraagd of anderszins mislukt. In het volgende diagram ziet u dat een gegevensarchief wordt overweldigd door een groot aantal gelijktijdige aanvragen van exemplaren van een toepassing.
U kunt dit oplossen door een wachtrij te gebruiken om de belasting tussen de toepassingsexemplaren en het gegevensarchief te e leveleren. Een Azure Functions-app leest de berichten uit de wachtrij en voert de lees-/schrijfaanvragen uit naar het gegevensarchief. De toepassingslogica in de functie-app kan de snelheid bepalen waarmee aanvragen worden doorgegeven aan het gegevensarchief, om te voorkomen dat de store wordt overweldigd. (Anders introduceert de functie-app hetzelfde probleem opnieuw aan de back-end.)
Volgende stappen
De volgende richtlijnen zijn mogelijk ook relevant bij de implementatie van dit patroon:
Asynchronous Messaging Primer (Inleiding in asynchrone berichtpatronen). Berichtenwachtrijen zijn inherent asynchroon. De toepassingslogica in een taak moet mogelijk opnieuw worden ontworpen als deze wordt aangepast van directe communicatie met een service naar het gebruik van een berichtenwachtrij. Het kan ook nodig zijn een service zo te herstructureren dat deze aanvragen van een berichtenwachtrij accepteert. In plaats daarvan kan mogelijk ook een proxyservice worden geïmplementeerd, zoals in het voorbeeld wordt beschreven.
Kies tussen Azure Messaging-services. Informatie over het kiezen van een mechanisme voor berichtverzending en wachtrijgebruik n Azure-toepassingen.
Verwante resources
- Architectuurstijl webwachtrij-werkrol. De web-front-end en de werkrol zijn beide staatloos. Sessiestatus kan worden opgeslagen in een gedistribueerde cache. Langlopende bewerkingen worden asynchroon door de werkrol uitgevoerd. De werkrol kan worden geactiveerd door berichten in de wachtrij of aan de hand van een schema voor batchverwerking worden uitgevoerd.
De volgende patronen zijn mogelijk ook relevant bij het implementeren van dit patroon:
Patroon Concurrerende consumenten. Het is wellicht mogelijk meerdere exemplaren van een service uit te voeren, die elk fungeren als een berichtgebruiker uit de wachtrij voor load leveling. U kunt deze benadering gebruiken om de snelheid aan te passen waarmee berichten worden ontvangen van en doorgestuurd naar een service.
Patroon voor beperking. Een eenvoudige manier om aanvraagbeperking te implementeren met een service, is op wachtrij gebaseerde load leveling te gebruiken en alle aanvragen naar een service om te leiden via een berichtenwachtrij. De service kan aanvragen verwerken met een snelheid die ervoor zorgt dat de resources die de service vereist, niet worden uitgeput en die het aantal mogelijke conflicten verlaagt.