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 funktioner 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örmåner
- 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.
- Webbklientdelen kan fungera efter att den har sparats i databasen, men innan den skickar meddelandena till kön. Detta kan leda till möjliga konsekvensproblem eftersom arbetaren inte utför sin del av logiken. Tekniker som mönstret för transaktionell utkorg kan användas för att minimera det här problemet, men kräver att du ändrar routningen av utgående meddelanden till den första "loopen tillbaka" via en separat kö. Ett bibliotek som ger stöd för den här tekniken är NServiceBus Transactional Session.
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 det bästa datalagret för jobbet][polyglot].
- 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.
Ladda ned en Visio-fil med den här arkitekturen.
Arbetsflöde
Klientdelen 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 de virtuella datorinstanserna.
Du kan använda antingen 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 låg svarstid.
Azure CDN används för att cachelagrar statiskt innehåll som bilder, CSS eller 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”). För att illustrera den här idén visar diagrammet Azure SQL Database och Azure Cosmos DB.
Mer information finns i referensarkitekturen för App Service-webbprogram och hur du skapar meddelandedrivna affärsprogram med NServiceBus och Azure Service Bus.
Övriga beaktanden
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. 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 föregående version om det är något problem med uppdateringen.