Dela via

Arkitekturformat för webbaseradeQueue-Worker

Azure App Service

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ö.

Logiskt diagram över arkitekturformatet Web-Queue-Worker.

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

  • En eller flera databaser.
  • En cache för att lagra värden från databasen för snabblä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.
  • Identitetsprovider för autentisering.

Både webben och arbetaren är tillståndslösa. Sessionstillstånd kan lagras i en distribuerad cache. Allt tidskrävande arbete utförs asynkront av arbetaren. Arbetaren kan utlösas av meddelanden i kön eller köras enligt ett schema för batchbearbetning. Arbetaren är en valfri komponent. Om det inte finns några tidskrävande åtgärder kan arbetaren utelämnas.

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

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

Arkitekturen webbaseradeQueue-Worker implementeras vanligtvis med hanterade beräkningstjänster, antingen Azure App Service eller Azure Cloud Services.

Överväg den här arkitekturstilen för:

  • Program med en relativt enkel domän.
  • Program med några långvariga 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 uppdelning av oro.
  • Klientdelen frikopplas från arbetaren med asynkrona meddelanden.
  • Klientdelen och arbetaren kan skalas separat.

Utmaningar

  • Utan noggrann design kan klientdelen och arbetaren bli stora, monolitiska komponenter som är svåra att underhålla och uppdatera.
  • Det kan finnas dolda beroenden om klientdelen och arbetaren 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.

Metodtips

Webb-Queue-Worker i Azure App Service

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

Fysiskt diagram över webb-Queue-Worker arkitekturformat.

Ladda ned en Visio-fil av 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 väljer du de lagringstekniker som bäst passar programmets behov. Du kan använda flera lagringstekniker (flerspråkig beständighet). 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.

Andra överväganden

  • Alla transaktioner behöver inte gå igenom kön och arbetaren till lagringen. Webbklientdelen kan utföra enkla läs-/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 autoskalningsfunktionen i App Service för att skala ut antalet VM-instanser. Om belastningen på programmet följer förutsägbara mönster använder du schemabaserad autoskalning. Om belastningen är oförutsägbar använder du måttbaserade regler för automatisk skalning.

  • Ö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. Annars innebär det att dina tester körs på dina virtuella produktionsdatorer om du använder samma plan för produktion och testning.

  • 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 den tidigare versionen om det uppstod ett problem med uppdateringen.