Gebruik een wachtrij die fungeert als een buffer tussen een taak en een service die wordt aangeroepen, om onregelmatige zware belasting te versoepelen waardoor de service kan mislukken of een time-out van de taak kan optreden. Dit kan helpen om de impact van pieken in de vraag op de 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 in feite altijd achterloopt, waarbij het systeem altijd meer aanvragen in de wachtrij zet 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 het mogelijk 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.
Voorbeeld
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, worden beperkt of anderszins mislukken. In het volgende diagram ziet u hoe een gegevensarchief wordt overspoeld 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 verdelen. 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 het archief wordt overbelast. (Anders zal de functie-app hetzelfde probleem opnieuw introduceren 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-berichtenservices. Informatie over het kiezen van een mechanisme voor berichtverzending en wachtrijgebruik n Azure-toepassingen.
Gerelateerde resources
- Schaalbaarheid in een Azure-webtoepassing verbeteren. Deze referentiearchitectuur omvat taakverdeling op basis van wachtrijen als onderdeel van de architectuur.
- Architectuurstijl Web-Queue-Worker. 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 kunnen ook relevant zijn 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.