Web-Queue-Worker arkitekturstil

Kärnkomponenterna i den här arkitekturen är en webbklientdel som hanterar klientbegäranden och en arbetare som utför resursintensiva uppgifter, långvariga arbetsflöden eller batchjobb. Webbklientdelen kommunicerar med arbetaren via en meddelandekö.

Följande komponenter ingår ofta i den här arkitekturen:

• En eller flera databaser

• En cache för att lagra värden från databasen för snabbläsning

• Ett nätverk för innehållsleverans för att hantera statiskt innehåll

• Fjärrtjänster, t.ex. e-post eller sms (Short Message Service), som tjänsteleverantörer som inte kommer från Microsoft vanligtvis tillhandahåller

• En identitetsprovider för autentisering

Både webben och arbetarprocessen är tillståndslösa och sessionsstatusen kan lagras i en distribuerad cache. Arbetaren hanterar långvarigt arbete asynkront. Meddelanden i kön kan starta arbetaren, eller så kan ett schema köra det för batchbearbetning. Arbetaren är valfri om programmet inte har några tidskrävande åtgärder.

Klientdelen kan innehålla ett webb-API. Ett ensidesprogram kan använda webb-API:et genom att göra AJAX-anrop, eller så kan ett internt klientprogram använda det direkt.

När du ska använda den här arkitekturen

Web-Queue-Worker-arkitekturen implementeras vanligtvis med hjälp av hanterade beräkningstjänster som Azure App Service eller Azure Kubernetes Service.

Överväg den här arkitekturen för följande användningsfall:

• Program som har en relativt enkel domän

• Program som har långvariga arbetsflöden eller batchåtgärder

• Scenarier där du föredrar hanterade tjänster framför infrastruktur som en tjänst (IaaS)

Fördelar

• En arkitektur som är enkel och lätt att följa

• Distribution och hantering med minimal ansträngning

• Tydlig ansvarsfördelning

• Avkoppling av frontend och arbetaren via asynkrona meddelanden

• Oberoende skalning av klientdelen och arbetaren

Utmaningar

• Utan noggrann design kan frontend och worker-process bli stora monolitiska komponenter som är svåra att underhålla och uppdatera.

• Om klientdelen och arbetaren delar datascheman eller kodmoduler kan det finnas dolda beroenden.

• Webbklientdelen kan krascha efter att ha sparat till databasen men innan meddelanden skickas till kön, vilket orsakar konsekvensproblem eftersom arbetsprocessen inte genomför sin del av logiken. För att åtgärda det här problemet kan du använda tekniker som mönstret Transaktionell utkorg, som kräver routning av utgående meddelanden för att först loopa tillbaka via en separat kö. Biblioteket NServiceBus Transactional Session stöder den här tekniken.

Metodtips

• Exponera ett väl utformat API för klienten. Mer information finns i metodtips för API-design.

• Skala automatiskt för att hantera ändringar i belastningen. Mer information finns i Metodtips för automatisk skalning.

• Cachea semistatisk data. Mer information finns i Metodtips för cachelagring.

• Använd ett nätverk för innehållsleverans som värd för statiskt innehåll. Mer information finns i Metodtips för innehållsleveransnätverk.

• Använd polyglotpersistence när det är lämpligt. Mer information finns i Förstå datamodeller.

• Partitioneringsdata för att förbättra skalbarheten, minska konkurrensen och optimera prestanda. Mer information finns i Metodtips för datapartitionering.

Webb-Queue-Worker på App Service

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

Arkitekturdiagram som visar användare som har åtkomst till webbprogram via Azure CDN för statisk innehållsleverans. Trafik flödar till App Service-webbappar som hanterar användarbegäranden och skickar meddelanden till Azure Service Bus- eller Azure Storage-köer. Azure Functions-arbetare bearbetar meddelanden från köerna för att hantera resursintensiva uppgifter. Systemet innehåller Azure Managed Redis för sessionstillstånd och dataåtkomst med låg svarstid, Azure Blob Storage för fil- och dokumentlagring samt polyglot datalagring med Azure SQL Database och Azure Cosmos DB. Webbappar och funktioner körs båda i App Service-planer för beräkningsinfrastruktur.

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsflöde

• Klientdelen implementeras som en App Service-webbapp och arbetaren implementeras som en Azure Functions-app . Webbappen och Functions-appen är båda associerade med en App Service-plan som tillhandahåller de virtuella datorinstanserna (VM).

• Du kan använda antingen Azure Service Bus - eller Azure Storage-köer för meddelandekön. I föregående diagram används en lagringskö.

• Azure Managed Redis lagrar sessionstillstånd och andra data som kräver åtkomst med låg svarstid.

• Azure Content Delivery Network används för att cachelagrar statiskt innehåll som bilder, CSS eller HTML.

• För lagring väljer du de tekniker som passar bäst för programmets behov. Den här metoden, som kallas polyglotpersistence, använder flera lagringstekniker i samma system för att uppfylla olika krav. För att illustrera den här idén visar diagrammet både Azure SQL Database och Azure Cosmos DB.

Mer information finns i zonredundant webbtjänst med hög tillgänglighet och Utveckla meddelandedrivna affärsapplikationer med NServiceBus och Service Bus.

Andra överväganden

• Alla transaktioner måste inte gå genom kön och arbetaren till lagring. Webbklientdelen kan utföra enkla läs- och skrivåtgärder direkt. Arbetare är utformade för resursintensiva uppgifter eller långvariga arbetsflöden. I vissa fall kanske du inte behöver någon arbetare alls.

• Använd den inbyggda funktionen för autoskalning i beräkningsplattformen för att skala ut antalet instanser. Om belastningen på programmet följer förutsägbara mönster använder du schemabaserad autoskalning. Om belastningen är oförutsägbar, bör du använda måttbaserad autoskalning.

• Överväg att placera webbappen och Functions-appen i separata App Service-planer så att de kan skalas separat.

• Använd separata App Service-planer för produktion och testning.

• Använd deploymentslots för att hantera distributioner. Med den här metoden kan du distribuera en uppdaterad version till ett mellanlagringsfack och sedan växla över till den nya versionen. Du kan också växla tillbaka till den tidigare versionen om det uppstår ett problem under uppdateringen.

Relaterad resurs

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