Arkitekturformat för Web-Queue-Worker

Kärnkomponenterna i den här arkitekturen är en webbklientdel som hanterar klientförfrågningar och ett webbarbete som hanterar resurskrävande uppgifter, långa arbetsflöden och batchjobb. Klientdelen kommunicerar med webbarbetet via en meddelandekö.

Andra komponenter som vanligtvis ingår i den här arkitekturen omfattar:

• En eller flera databaser.
• En cache för lagring av värden från databasen för snabb läsning.
• CDN för att hantera statiskt innehåll
• Fjärrtjänster, till exempel e-post eller SMS-tjänst. Dessa tillhandahålls ofta av tredje part.
• Identitetsleverantör för autentisering.

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. Arbetsprocessen är en valfri komponent. Om det inte finns några tidskrävande uppgifter kan arbetsprocessen utelämnas.

Klientdelen kan bestå av ett webb-API. På klientsidan kan webb-API:et användas av en ensidesapplikation som gör AJAX-anrop eller av ett internt klientprogram.

När ska den här arkitekturen användas?

Web-Queue-Worker-arkitekturen implementeras vanligtvis med hanterade beräkningstjänster, antingen Azure App Service eller Azure Cloud Services.

Överväg det här arkitekturformatet för:

• Program med en relativt enkel domän.
• Program med vissa tidskrävande arbetsflöden eller batchåtgärder.
• När du vill använda hanterade tjänster i stället för infrastruktur som en tjänst (IaaS).

Fördelar

• Relativt enkel arkitektur som är lätt att förstå.
• Lätt att distribuera och hantera.
• Tydlig problemseparering.
• Klientdelen kopplas bort från webbarbetet med asynkrona meddelanden.
• Klientdelen och webbarbetet kan skaländras oberoende av varandra.

Utmaningar

• Om de inte utformas noggrant kan klientdelen och webbarbetet bli enormt stora komponenter som är svåra att underhålla och uppdatera.
• Det kan finnas dolda beroenden om klientdelen och webbarbetet delar datascheman eller kodmoduler.

Bästa praxis

• Exponera ett väldesignat API för klienten. Se Metodtips för API-design.
• Använd automatisk skalning för att hantera belastningsändringar. Läs mer om våra metodtips för automatisk skalning.
• Cachelagra delvis statiska data. Läs mer om våra metodtips för cachelagring.
• Använd en CDN som värd för statiskt innehåll. Se Metodtips för CDN.
• Använd flera lagringstekniker (”polyglot persistence”) där det är lämpligt. Se Använd den bästa datalagringen för jobbet.
• Partitionering kan ge bättre skalbarhet, minska konkurrensen och ge bästa möjliga prestanda. Se Metodtips för partitionering.

Web-Queue-Worker på Azure App Service

I det här avsnittet beskrivs en rekommenderad Web-Queue-Worker-arkitektur som använder Azure App Service.

• Frontend implementeras som en Azure App Service webbapp och arbetaren implementeras som en Azure Functions-app. Både webbappen och funktionsappen är associerade med en App Service plan som tillhandahåller VM-instanserna.

• Du kan använda Azure Service Bus- eller Azure Storage-köer för meddelandekön. (Diagrammet visar en Azure Storage-kö.)

• Azure Cache for Redis lagrar sessionstillstånd och andra data som behöver åtkomst med kort svarstid.

• Azure CDN används för att cachelagra statiskt innehåll, som bilder, CSS och HTML.

• För lagring bör du välja de lagringstekniker som är bäst lämpade för programmets behov. Du kan använda flera lagringstekniker (”polyglot persistence”). I diagrammet illustreras detta med Azure SQL Database och Azure Cosmos DB.

Mer information finns i Referensarkitektur för App Service-webbprogram.

Annat som är bra att tänka på

• Alla transaktioner måste gå genom kö- och arbetsrollerna till lagringen. Webbserverdelen kan utföra enkla läs- och skrivåtgärder direkt. Webbarbetena är utformade för resurskrävande uppgifter eller arbetsflöden under långa perioder. I vissa fall kanske du inte alls behöver något webbarbete.

• Använd den inbyggda funktionen för automatisk skalning i App Service för att skala ut antalet VM-instanser. Om belastningen på programmet följer förutsägbara mönster kan du använda schemabaserad automatisk skalning. Om belastningen är oförutsägbar använder du måttbaserade autoskalningsregler.

• Överväg att placera webbappen och funktionsappen i separata App Service planer. På så sätt kan de skalas oberoende av varandra.

• Använd separata App Service-planer för produktion och testning. Om du använder samma plan för produktion och testning innebär det annars att dina tester körs på dina virtuella produktionsdatorer.

• Använd distributionsplatser för att hantera distributioner. Då kan du distribuera en uppdaterad version till en mellanlagringsplats och sedan övergå till den nya versionen. Du kan också växla tillbaka till föregående version om det är något problem med uppdateringen.