Mönster för köbaserad belastningsutjämning

Använd en kö som fungerar som en buffert mellan en uppgift och den tjänst som den anropar. Den här metoden jämnar ut tillfälliga tunga belastningar som kan leda till att tjänsten misslyckas eller att aktiviteten överskrider tidsgränsen. Det hjälper till att minimera effekten av efterfrågetoppar på tillgänglighet och svarstider för uppgiften och tjänsten.

Kontext och problem

Många lösningar i molnet kör uppgifter som anropar tjänster. I den här miljön kan tillfälliga tunga belastningar orsaka prestanda- eller tillförlitlighetsproblem för en tjänst.

En tjänst kan ingå i samma lösning som de uppgifter som använder den, eller så kan det vara en partnertjänst som ger åtkomst till resurser som används ofta. Exempel på dessa typer av tjänster är en cache eller en lagringstjänst. När flera uppgifter körs samtidigt och använder samma tjänst är det svårt att förutsäga mängden begäranden när som helst.

En tjänst kan uppleva belastningar på efterfrågan som överbelastar den och gör att tjänsten inte kan svara på begäranden snabbt. Att överbelasta en tjänst med många samtidiga begäranden kan också få tjänsten att sluta fungera om den inte kan hantera de resurskonflikter som dessa begäranden orsakar.

Lösning

Placera en kö mellan uppgiften och tjänsten. Aktiviteten och tjänsten körs asynkront. Uppgiften skickar ett meddelande som innehåller de uppgifter som tjänsten behöver till kön. Kön fungerar som en buffert och lagrar meddelandet tills tjänsten hämtar det. Tjänsten hämtar meddelanden från kön och bearbetar dem. Begäranden från flera uppgifter, som kan genereras med mycket varierande hastighet, kan skickas till tjänsten via samma meddelandekö. Följande diagram visar hur en kö kan utjämna belastningen på en tjänst.

Kön frikopplar uppgifterna från tjänsten så att tjänsten kan hantera meddelandena i sin egen takt även när parallella uppgifter genererar en stor mängd förfrågningar. Dessutom fördröjs inte uppgifter om tjänsten inte är tillgänglig när meddelanden skickas till kön.

Det här mönstret ger följande fördelar:

• Det hjälper till att maximera tillgängligheten eftersom tjänstförseningar inte omedelbart och direkt påverkar programmet. Programmet kan fortsätta att skicka meddelanden till kön även om tjänsten inte är tillgänglig eller för närvarande inte bearbetar meddelanden.

• Det hjälper till att maximera skalbarheten eftersom antalet köer och antalet tjänster kan variera för att möta efterfrågan.

• Det hjälper dig att kontrollera kostnaderna eftersom du bara behöver tillräckligt med tjänstinstanser för att uppfylla kraven för en genomsnittlig belastning i stället för den högsta belastningen.

Problem och överväganden

Tänk på följande när du bestämmer hur du ska implementera det här mönstret:

• Implementera programlogik som styr hur snabbt tjänsterna hanterar meddelanden för att undvika att överbelasta målresursen. Undvik att vidarebefordra toppar i efterfrågan till nästa steg i systemet. Testa systemet under belastning för att säkerställa att det ger den nödvändiga utjämningen. Justera antalet köer och antalet tjänstinstanser som hanterar meddelanden för att uppnå den nivå som krävs.

• Meddelandeköer är en metod för envägskommunikation. Om en uppgift förväntar sig ett svar från en tjänst kan du behöva implementera en mekanism som tjänsten kan använda för att skicka ett svar. Mer information finns i Asynkrona meddelandealternativ i Azure.

• Automatisk skalning utan att begränsa konsumenternas aggregerade nedströmsfrekvens flyttar bara överlagringen till underordnade beroenden. Den här överbelastningen kan öka konkurrens om resurser som dessa tjänster delar och minska köens förmåga att jämna ut belastningen.

• Om din genomsnittliga producentfrekvens överskrider konsumentfrekvensen fortsätter kön att växa och svarstiden ökar. Övervaka ködjupet och skala upp antalet konsumenter inom säkra gränser, eller begränsa belastningen vid producenten.

• Det här mönstret beror på köhållbarheten för att förhindra meddelandeförlust. Om meddelandeförmedlaren inte lagrar meddelanden permanent i beständig lagring kan en krasch eller kapacitetsgräns leda till att data i kön går förlorade innan konsumenterna hinner bearbeta dem. Välj en kötjänst som bevarar meddelanden till disken eller replikerad lagring och förstå dess storlekskvoter och kvarhållningsgränser. För arbetsbelastningar som kräver att meddelanden överlever regionala avbrott bör du utvärdera alternativ för geografisk haveriberedskap.

• De flesta kötjänster levererar meddelanden med semantik minst en gång, vilket innebär att konsumenter kan ta emot samma meddelande mer än en gång. Utforma konsumentlogik så att den är idempotent så att bearbetning av samma meddelande flera gånger ger samma resultat och undviker problem som duplicerade poster eller upprepade avgifter.

• Vissa meddelanden kan inte bearbetas eftersom de innehåller felaktiga data, refererar till resurser som saknas eller utlöser beständiga fel. I stället för att låta dessa meddelanden fortsätta cirkulera på obestämd tid och blockera kön, dirigera dem till en dead letter-kö. Övervaka djupet på kön för obeställbara meddelanden så att driftteam kan utreda fel, åtgärda det underliggande problemet och skicka om meddelanden när det är lämpligt.

• Att införa en kö mellan en producent och konsument bevarar inte den ursprungliga sändningsordningen under alla förhållanden, särskilt när flera konsumenter bearbetar meddelanden parallellt. Om din arbetsbelastning kräver strikt ordning använder du funktioner som meddelandesessioner i Azure Service Bus. Om strikt ordning inte krävs kan du utforma konsumenter för att hantera meddelanden i valfri ordning, vilket förenklar skalningen.

När du ska använda det här mönstret

Använd det här mönstret i sådana här scenarier:

• Arbetsbelastningen upplever tillfälliga toppar som kan överbelasta underordnade tjänster.

• Du måste frikoppla intaget av begäranden från bearbetningsdataflödet för att förbättra motståndskraften och kostnadskontrollen.

Det här mönstret kanske inte är lämpligt när:

• Anroparen kräver ett synkront svar med låg svarstid.

• Arbetsbelastningen är förutsägbart låg och stabil, så att införa ytterligare komplexitet i form av köhantering ger liten nytta.

Design av arbetsbelastning

Utvärdera hur man använder mönstret köbaserad belastningsutjämning i utformningen av en arbetsbelastning för att hantera målen och principerna som behandlas i pelarna i Azure Well-Architected Framework. Följande tabell innehåller vägledning om hur det här mönstret stöder målen för varje pelare.

Om detta mönster inför kompromisser inom en pelare bör du överväga dem mot målen för de andra pelarna.

Example

En webbapp skriver data till ett externt datalager. Om flera instanser av webbappen körs samtidigt kanske datalagret inte kan svara tillräckligt snabbt på begäranden, vilket gör att begäranden överskrider tidsgränsen, begränsas eller på annat sätt misslyckas. Följande diagram visar ett datalager som överbelastas av samtidiga begäranden från instanser av ett program.

Lös problemet genom att använda en kö för att utjämna belastningen mellan programinstanserna och datalagret. En Azure Functions app läser meddelanden från en Service Bus kö och utför läs-/skrivbegäranden till datalagret. Azure Functions kan skala antalet instanser baserat på eftersläpning i Service Bus med hjälp av målbaserad skalning, inom de konfigurerade skalningsgränserna. Du kan också justera inställningar för samtidighet för utlösare för att skydda datalagret. Vägledning för implementering finns i Målbaserad skalning och Begränsa utskalning. Utan den här justeringen kan arbetslagret återinföra backend-konkurrens.

Som teknikvariant kan du implementera samma mönster med hjälp av Azure Container Apps i stället för Azure Functions. I den metoden använder en containerarbetare meddelanden från Service Bus och skriver till datalagret. Container Apps skalar arbetaren mellan konfigurerade minsta och högsta repliker baserat på körelaterade skalningsregler. Du kan också implementera samma metod med hjälp av Azure Queue Storage som händelsekälla. Vägledning för implementering finns i Ange skalningsregler i Container Apps och Distribuera ett händelsedrivet jobb med hjälp av Container Apps.

Nästa steg

Följande riktlinjer kan även vara relevanta när du implementerar det här mönstret:

• Asynkrona meddelandealternativ i Azure: Meddelandeköer är i sig asynkrona. Du kan behöva utforma om en aktivitets programlogik om den kommunicerar direkt med en tjänst. På samma sätt kan du behöva omstrukturera en tjänst för att acceptera begäranden från en meddelandekö.

• Välj mellan Azure meddelandetjänster: Få mer information som hjälper dig att välja en meddelande- och kömekanism i Azure program.

• Rekommendationer för att utveckla bakgrundsjobb: Använd det här mönstret för bakgrundsjobb så att meddelandeköer kan lagra begäranden för bakgrundsuppgifter när programmet har hög belastning.

• Web-Queue-Worker-arkitekturmönster: Både webbappen och arbetsprocessen är tillståndslösa. Sessionsstatus kan lagras i en distribuerad cache. Arbetaren utför tidskrävande arbete asynkront och kan utlösas av meddelanden i kön eller köras enligt ett schema för batchbearbetning.

Relaterade resurser

• Mönster för konkurrerande konsumenter: Det kan vara möjligt att köra flera instanser av en tjänst, var och en fungerar som meddelandekonsument från belastningsutjämningskön. Med den här metoden kan frekvensen för meddelanden som tas emot och skickas till en tjänst justeras.

• Begränsningsmönster: Ett enkelt sätt att implementera begränsning i en tjänst är att använda köbaserad belastningsutjämning och dirigera alla begäranden till en tjänst via en meddelandekö. Tjänsten kan bearbeta begäranden med en hastighet som säkerställer att den inte uttömmer de resurser den behöver och minskar mängden eventuell konkurrens.