Använd en kö som fungerar som en buffert mellan en aktivitet och en tjänst som den anropar för att jämna ut tillfälliga tunga belastningar som kan orsaka att tjänsten misslyckas eller att aktiviteten överskrider tidsgränsen. Detta kan bidra till att minimera effekten av toppar i efterfrågan på tillgänglighet och svarstider för både uppgiften och tjänsten.
Kontext och problem
För många lösningar i molnet måste aktiviteter som anropar tjänster köras. Om tillfälliga tunga belastningar måste hanteras av en tjänst i en sådan miljö kan det orsaka problem med prestanda eller tillförlitlighet.
En tjänst kan ingå i samma lösning som aktiviteterna som använder den, eller den kan vara en tredjepartstjänst som ger åtkomst till ofta använda resurser, såsom en cache- eller lagringstjänst. Om samma tjänst används av flera aktiviteter som körs samtidigt, kan det vara svårt att förutse volymen av begäranden till tjänsten vid en viss tidpunkt.
Det kan förekomma belastningstoppar för tjänsten som orsakar överbelastning och att begäranden inte kan besvaras inom den förväntade tiden. Om en tjänst överbelastas med ett stort antal samtidiga begäranden kan det också medföra att tjänsten misslyckas om det inte går att hantera konkurrensen mellan dessa begäranden.
Lösning
Omstrukturera lösningen och inför en kö mellan aktiviteten och tjänsten. Aktiviteten och tjänsten körs asynkront. Aktiviteten skickar ett meddelande som innehåller de data som krävs av tjänsten till en kö. Kön fungerar som en buffert där meddelandet lagras tills det hämtas av tjänsten. Tjänsten hämtar meddelanden från kön och bearbetar dem. Begäranden från flera aktiviteter, som kan genereras med mycket varierande frekvens, kan skickas till tjänsten via samma meddelandekö. I den här bilden visas hur en kö används för att utjämna belastningen på en tjänst.
I kön frikopplas aktiviteterna från tjänsten, så att tjänsten kan hantera meddelanden i lämplig takt oavsett mängden begäranden från samtidiga aktiviteter. Det förekommer heller ingen fördröjning till en aktivitet om tjänsten inte är tillgänglig när meddelandet skickas till kön.
Det här mönstret ger följande fördelar:
Det kan bidra till att maximera tillgängligheten eftersom fördröjningar som uppstår i tjänster inte har en omedelbar eller direkt inverkan på programmet, som kan fortsätta att skicka meddelanden till kön även när tjänsten inte är tillgänglig eller inte bearbetar meddelanden.
Det kan bidra till att maximera skalbarheten eftersom både antalet köer och tjänster kan varieras för att möta behovet.
Det kan bidra till att kontrollera kostnader eftersom det endast behövs tillräckligt med instanser av tjänsten för att möta den genomsnittliga belastningen, och inte toppbelastningar.
Vissa tjänster implementerar begränsningar när efterfrågan når ett visst tröskelvärde för att förhindra systemfel om tröskelvärdet överskrids. Begränsningar kan dock minska funktionstillgängligheten. Du kan implementera belastningsutjämning för de här tjänsterna så att tröskelvärdet inte nås.
Problem och överväganden
Tänk på följande när du bestämmer hur du ska implementera mönstret:
- Programlogik som styr tjänsternas hanteringshastighet av meddelanden måste implementeras för att undvika att målresursen överbelastas. Undvik att vidarebefordra toppar i efterfrågan till nästa steg i systemet. Testa systemet under belastning för att se till att lämplig utjämning genomförs, och anpassa antalet köer och instanser av tjänsten som hanterar meddelanden för att uppnå detta.
- Meddelandeköer är en metod för envägskommunikation. Om ett svar förväntas från en tjänst till en aktivitet kan en mekanism implementeras, som tjänsten då använder för att skicka ett svar. Mer information finns i introduktionen till asynkron meddelandehantering.
- Var försiktig om du använder autoskalning för tjänster som lyssnar efter begäranden i kön. Det kan medföra ökad konkurrens för resurser som delas av de här tjänsterna och göra det mindre effektivt att använda kön för belastningsutjämning.
- Beroende på belastningen på tjänsten kan du stöta på en situation där du i praktiken alltid släpar efter, där systemet alltid köar fler begäranden än du bearbetar. Variabiliteten för inkommande trafik till ditt program måste beaktas
- Mönstret kan förlora information beroende på köns beständighet. Om kön kraschar eller släpper information (på grund av systembegränsningar) finns det en möjlighet att du inte har någon garanterad leverans. Beteendet för kö- och systemgränserna måste beaktas baserat på lösningens behov.
När du ska använda det här mönstret
Det här mönstret är praktiskt för program som använder tjänster där överbelastning kan förekomma.
Det här mönstret är inte praktiskt för program som förväntar få svar från tjänsten med minimal svarstid.
Design av arbetsbelastning
En arkitekt bör utvärdera hur mönstret för köbaserad belastningsutjämning kan användas i arbetsbelastningens design för att uppfylla de mål och principer som beskrivs i grundpelarna i Azure Well-Architected Framework. Till exempel:
| Grundpelare | Så här stöder det här mönstret pelarmål |
|---|---|
| Beslut om tillförlitlighetsdesign hjälper din arbetsbelastning att bli motståndskraftig mot fel och se till att den återställs till ett fullt fungerande tillstånd när ett fel inträffar. | Metoden som beskrivs i det här mönstret kan ge motståndskraft mot plötsliga toppar i efterfrågan genom att koppla bort ankomsten av uppgifter från bearbetningen. Det kan också isolera fel i köbearbetningen så att de inte påverkar intaget. - RE:06-skalning - RE:07 Bakgrundsjobb |
| Kostnadsoptimering fokuserar på att upprätthålla och förbättra arbetsbelastningens avkastning på investeringen. | Eftersom belastningsbearbetningen är frikopplad från begäran eller uppgiftsintaget kan du använda den här metoden för att minska behovet av att överetablera resurser för att hantera belastningstoppar. - KOSTNADER FÖR CO:12-skalning |
| Prestandaeffektivitet hjälper din arbetsbelastning att effektivt uppfylla kraven genom optimeringar inom skalning, data och kod. | Den här metoden möjliggör avsiktlig design av dataflödesprestanda eftersom intaget av begäranden inte behöver korrelera med den hastighet som de bearbetas i. - PE:05 Skalning och partitionering |
Som med alla designbeslut bör du överväga eventuella kompromisser mot målen för de andra pelarna som kan införas med det här mönstret.
Exempel
En webbapp skriver data till ett externt datalager. Om ett stort antal 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 ett stort antal samtidiga begäranden från instanser av ett program.
För att lösa detta kan du använda en kö för att utjämna belastningen mellan programinstanserna och datalagret. En Azure Functions-app läser meddelandena från kön och utför läs-/skrivbegäranden till datalagret. Programlogik i funktionsappen kan styra hur snabbt den skickar begäranden till datalagret för att förhindra att arkivet överbelastas. (Annars introducerar funktionsappen bara samma problem i serverdelen igen.)
Nästa steg
Följande riktlinjer kan även vara relevanta när du implementerar det här mönstret:
Asynkron primer för meddelanden. Meddelandeköer är asynkrona till sin natur. Du kanske behöver förändra programlogiken i en aktivitet om den anpassats från att kommunicera direkt med en tjänst till att använda en meddelandekö. På samma sätt kan det vara nödvändigt att omstrukturera en tjänst till att acceptera begäranden från en meddelandekö. Ett möjligt alternativ kan vara att implementera en proxytjänst, som beskrivs i exemplet.
Välj mellan Azure-meddelandetjänster. Information om hur du väljer en mekanism för meddelanden och köer i Azure-program.
Relaterade resurser
- Arkitekturformatet Web-Queue-Worker. Både webb- och arbetsrollerna är tillståndslösa. Sessionsstatus kan lagras i en distribuerad cache. Allt tidskrävande arbetet utförs asynkront av arbetsprocessen. Arbetsprocessen kan utlösas av meddelanden i kön eller köras enligt ett schema för batchbearbetning.
Följande mönster kan också vara relevanta när du implementerar det här mönstret:
Mönster för konkurrerande förbrukare. Det kan vara möjligt att köra flera instanser av en tjänst, där varje instans fungerar som en meddelandekonsument från kön för belastningsutjämning. Med den här metoden kan frekvensen för meddelanden som tas emot och skickas till en tjänst justeras.
Mönster för begränsning. Ett enkelt sätt att implementera begränsning för 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 ser till att de resurser som krävs av tjänsten inte överbelastas, och för att minska mängden konkurrens som kan uppstå.