Bakgrundsjobb

  • Artikel

Många typer av program kräver bakgrundsuppgifter som körs oberoende av användargränssnittet (UI). Det kan vara batchjobb, beräkningsintensiva bearbetningar och tidskrävande processer, till exempel arbetsflöden. Bakgrundsjobb kan köras utan användaråtgärder – programmet kan starta jobbet och sedan fortsätta att bearbeta interaktiva begäranden från användarna. Det kan hjälpa dig för att minimera belastningen på programmets användargränssnitt, vilket kan förbättra tillgängligheten och minska interaktiva svarstider.

Om ett program krävs för att generera miniatyrer av bilder som har laddats upp av användare, kan det göra detta i bakgrunden och spara miniatyren när den är klar – utan att användaren behöver vänta tills processen har slutförts. På samma sätt kan en användare som lägger en order starta ett arbetsflöde i bakgrunden som bearbetar ordern, medan användaren kan fortsätta bläddra i webbprogrammet med användargränssnittet. När bakgrundsjobbet har slutförts kan det uppdatera lagrade orderdata och skicka ett e-postmeddelande med orderbekräftelse till användaren.

Om du funderar på att implementera en uppgift som en bakgrundsaktivitet är det viktigaste kriteriet huruvida uppgiften kan köras utan användarinteraktion och utan att användargränssnittet behöver vänta tills jobbet har slutförts. Uppgifter som kräver att användaren eller användargränssnittet väntar medan de slutförs kanske inte är så lämpliga som bakgrundsaktiviteter.

Typer av bakgrundsjobb

Bakgrundsjobb är vanligtvis en eller flera av följande typer av jobb:

  • Processorintensiva jobb, t.ex matematiska beräkningar eller strukturella modellanalyser.
  • I/O-intensiva jobb, till exempel att köra en serie lagringstransaktioner eller indexering av filer.
  • Batchjobb, till exempel datauppdateringar under natten eller schemalagd bearbetning.
  • Långvariga arbetsflöden, till exempel orderhantering eller att tillhandahålla tjänster och system.
  • Bearbetning av känsliga data där uppgiften skickas till en säkrare plats för bearbetning. Till exempel kanske du inte vill bearbeta känsliga data i en webbapp. I stället kan du använda ett mönster som Gatekeeper-mönstret för att överföra data till en isolerad bakgrundsprocess som har åtkomst till skyddad lagring.

Utlösare

Bakgrundsjobb kan initieras på flera olika sätt. De delas in i följande kategorier:

  • Händelsedrivna utlösare. Uppgiften startats när en händelse inträffar, vanligtvis en åtgärd av en användare eller ett steg i ett arbetsflöde.
  • Schemadrivna utlösare. Uppgiften anropas enligt ett schema som baseras på en timer. Det kan vara ett återkommande schema eller ett engångsanrop som har angetts för ett senare tillfälle.

Händelsedrivna utlösare

Händelsedrivet anrop använder en utlösare för att starta bakgrundsaktiviteten. Några exempel på händelsedrivna utlösare:

  • Användargränssnittet eller ett annat jobb placerar ett meddelande i en kö. Meddelandet innehåller data om en åtgärd som har utförts, till exempel att användaren har lagt en order. Bakgrundsaktiviteten lyssnar i den här kön och känner av att nytt meddelande har kommit. Den läser meddelandet och använder data i det som indata för bakgrundsjobbet. Det här mönstret kallas asynkron meddelandebaserad kommunikation.
  • Användargränssnittet eller ett annat jobb sparar eller uppdaterar ett värde i minnet. Bakgrundsaktiviteten övervakar lagringsutrymmet och identifierar ändringar. Den läser dessa data och använder dem som indata för bakgrundsjobbet.
  • Användargränssnittet eller ett annat jobb skickar en förfrågan till en slutpunkt, till exempel en HTTPS-URI eller ett API som visas som en webbtjänst. Det skickar data som krävs för att slutföra bakgrundsaktiviteten som en del av förfrågan. Slutpunkten eller webbtjänsten anropar bakgrundsaktiviteten, som använder dessa data som indata.

Typexempel på uppgifter som passar bra för händelsedrivna anrop är bildbearbetning, arbetsflöden, att skicka information till fjärrtjänster, skicka e-postmeddelanden och etablera nya användare i program med flera organisationer i samma installation.

Schemadrivna utlösare

Schemadrivet anrop använder en timer för att starta bakgrundsaktiviteten. Några exempel på schemadrivna utlösare:

  • En timer som körs lokalt i programmet eller som en del av programmets operativsystem anropar regelbundet en bakgrundsaktivitet.
  • En timer som körs i ett annat program, till exempel Azure Logic Apps, skickar regelbundet en begäran till ett API eller en webbtjänst. API:et eller webbtjänsten anropar bakgrundsaktiviteten.
  • En separat process eller program startar en timer som anropar bakgrundsaktiviteten en gång efter en angiven tidsfördröjning eller vid en viss tidpunkt.

Typexempel på uppgifter som passar bra för schemadrivna anrop är batchbearbetningar (till exempel att uppdatera listor över relaterade produkter för användare baserat på deras senaste beteende), rutinuppgifter av databearbetning (till exempel att uppdatera index eller generera ackumulerat resultat), dataanalys för dagliga rapporter, rensning av datakvarhållning och kontroller av datakonsekvens.

Om du använder en schemadriven uppgift som måste köras som en enskild instans ska du tänka på följande:

  • Om beräkningsinstansen som kör i schemaläggaren (till exempel en virtuell dator med Windows-schemalagda aktiviteter) skalas upp, kommer du att köra flera instanser av schemaläggaren. Dessa kan starta flera instanser av uppgiften. Mer information om detta finns i det här blogginlägget om idempotens.
  • Om uppgifter körs under en längre tid än perioden mellan schemalagda händelser kan det hända att schemaläggaren startar en till instans av aktiviteten medan den föregående fortfarande körs.

Returnerade resultat

Bakgrundsjobb utföras asynkront i en separat process, eller till och med på en annan plats, än användargränssnittet eller den process som anropade bakgrundsaktiviteten. I bästa fall är bakgrundsaktiviteter "eld och glöm"-åtgärder, och deras körningsframsteg påverkar inte användargränssnittet eller anropsprocessen. Det innebär att den anropsprocessen inte väntar på att uppgifterna ska slutföras. Därför kan den inte automatiskt känna av när uppgiften avslutas.

Om du vill att en bakgrundsaktivitet ska kommunicera förlopp eller slutförande till den anropande uppgiften måste du implementera en mekanism för detta. Några exempel är:

  • Skriva ett statusvärde i lagringsutrymmet som är tillgängligt för användargränssnittet eller den anropande uppgiften som kan övervaka eller kontrollera det här värdet vid behov. Andra data som bakgrundsaktiviteten måste returnera till anroparen kan placeras i samma lagringsutrymme.
  • Upprätta en svarskö som användargränssnittet eller anroparen lyssnar på. Bakgrundsaktiviteten kan skicka meddelanden till kön som anger status och slutförande. Data som bakgrundsaktiviteten måste returnera till anroparen kan också placeras i meddelandena. Om du använder Azure Service Bus kan du använda egenskaperna ReplyTo och CorrelationId för att implementera den här funktionen.
  • Exponera ett API eller en slutpunkt från bakgrundsaktiviteten som användargränssnittet eller anroparen kan komma åt för att hämta statusinformation. Data som bakgrundsaktiviteten måste returnera till anroparen kan infogas i svaret.
  • Låt bakgrundsaktivitet anropa användargränssnittet eller anroparen via ett API för att ange status vid fördefinierade punkter eller vid slutförande. Det kan göras via händelser som inträffar lokalt eller via en publicera–prenumerera-mekanism. Data som bakgrundsaktiviteten måste returnera till anroparen kan infogas i förfrågan eller händelsens nyttolast.

Värdmiljö

Du kan använda en mängd olika tjänster på Azure-plattformen som värd för bakgrundsaktiviteter:

  • Azure Web Apps och WebJobs. Du kan använda webbjobb för att köra anpassade jobb baserat på en mängd olika typer av skript eller körbara program inom kontexten för en webbapp.
  • Azure Functions. Du kan använda funktioner för bakgrundsjobb som inte körs på länge. Ett annat användningsfall är om din arbetsbelastning redan finns i App Service-planen och är underutnyttad.
  • Azure Virtual Machines. Om du har en Windows-tjänst eller om du vill använda Schemaläggaren i Windows är det vanligt att använda en dedikerad virtuell dator som värd för bakgrundsaktiviteterna.
  • Azure Batch. Batch är en plattformstjänst som schemalägger beräkningsintensiva arbeten att köras på en hanterad samling av virtuella datorer. Den kan automatiskt skala beräkningsresurserna.
  • Azure Kubernetes Service (AKS). Azure Kubernetes Service tillhandahåller en hanterad värdmiljö för Kubernetes i Azure.
  • Azure Container Apps. Med Azure Container Apps kan du skapa serverlösa mikrotjänster baserat på containrar.

I följande avsnitt beskrivs de här alternativen mer detaljerat och innehåller överväganden som hjälper dig att välja lämpligt alternativ.

Azure Web Apps och WebJobs

Du kan använda Azure WebJobs för att köra anpassade jobb som bakgrundsaktiviteter i en Azure-webbapp. Webbjobb körs inom webbappens kontext som en kontinuerlig process. WebJobs körs också som svar på en utlösarhändelse från Azure Logic Apps eller externa faktorer, till exempel ändringar i lagringsblobar och meddelandeköer. Jobb kan startas och stoppas på begäran och avslutas på vanligt sätt. Om ett webbjobb som körs kontinuerligt misslyckas startas det om automatiskt. Åtgärder vid nya försök och fel kan konfigureras.

När du konfigurerar ett webbjobb:

  • Om du vill att jobbet ska svara på en händelsedriven utlösare ska du konfigurera det som Kör kontinuerligt. Skriptet eller programmet lagras i mappen med namnet site/wwwroot/app_data/jobs/continuous.
  • Om du vill att jobbet ska svara på en schemadriven utlösare ska du konfigurera det som Kör enligt schema. Skriptet eller programmet lagras i mappen med namnet site/wwwroot/app_data/jobs/triggered.
  • Om du väljer alternativet Kör på begäran när du konfigurerar ett jobb, körs samma kod som för alternativet Kör enligt schema när det startas.

Azure WebJobs körs i webbappens sandbox-miljö. Det innebär att de kan få åtkomst till miljövariabler och dela information, som anslutningssträngar, med webbappen. Jobbet har åtkomst till den unika identifieraren för den dator som kör jobbet. Den anslutningssträng med namnet AzureWebJobsStorage ger åtkomst till Azure Storage-köer, blobbar och tabeller för programdata och åtkomst till Service Bus för meddelanden och kommunikation. Anslutningssträngen med namnet AzureWebJobsDashboard ger åtkomst till loggfiler för jobbåtgärder.

Azure WebJobs har följande egenskaper:

  • Säkerhet: WebJobs skyddas av webbappens autentiseringsuppgifter för distribution.
  • Filtyper som stöds: Du kan definiera WebJobs med hjälp av kommandoskript (.cmd), batchfiler (.bat), PowerShell-skript (.ps1), Bash-gränssnittsskript (.sh), PHP-skript (.php), Python-skript (.py), JavaScript-kod (.js) och körbara program (.exe, .jaroch mycket mer).
  • Distribution: Du kan distribuera skript och körbara filer med hjälp av Azure-portalen med hjälp av Visual Studio, med hjälp av Azure WebJobs SDK eller genom att kopiera dem direkt till följande platser:
    • För utlöst körning: site/wwwroot/app_data/jobs/triggered/{jobbnamn}
    • För kontinuerlig körning: site/wwwroot/app_data/jobs/continuous/{jobbnamn}
  • Loggning: Console.Out behandlas (markeras) som information. Console.Error behandlas som fel. Du kan komma åt övervaknings- och diagnostikinformation via Azure Portal. Du kan ladda ned loggfiler direkt från webbplatsen. De sparas på följande platser:
    • För utlöst körning: Vfs/data/jobs/triggered/jobName
    • För kontinuerlig körning: Vfs/data/jobs/continuous/jobName
  • Konfiguration: Du kan konfigurera webbjobb med hjälp av portalen, REST-API och PowerShell. Du kan använda en konfigurationsfil med namnet settings.job i samma rotkatalog som jobbskriptet för att tillhandahålla konfigurationsinformation för ett jobb. Till exempel:
    • { "stopping_wait_time": 60 }
    • { "is_singleton": true }

Att tänka på

  • Som standard skalas webbjobb med webbappen. Men du kan konfigurera jobb att köra på en enskild instans genom att ange konfigurationsegenskapen is_singleton till true. Webbjobb för enskilda instanser är användbara för uppgifter som du inte vill skala eller köra som flera samtidiga instanser, som omindexering, dataanalyser och liknande uppgifter.
  • För att minimera effekten av jobb på webbappens prestanda bör du överväga att skapa en tom Azure Web App-instans i en ny App Service-plan som värd för långvariga eller resursintensiva webbjobb.

Azure Functions

Ett alternativ som liknar WebJobs är Azure Functions. Den här tjänsten är serverlös och passar bäst för händelsedrivna utlösare som körs under en kort period. En funktion kan också användas för att köra schemalagda jobb via timerutlösare när den är konfigurerad att köras vid angivna tider.

Azure Functions är inte ett rekommenderat alternativ för stora, långvariga uppgifter eftersom de kan orsaka oväntade timeout-problem. Beroende på värdplanen kan de dock övervägas för schemadrivna utlösare.

Att tänka på

Om bakgrundsaktiviteten förväntas köras under en kort tid som svar på en händelse kan du överväga att köra aktiviteten i en förbrukningsplan. Körningstiden kan konfigureras upp till en maximal tid. En funktion som körs för längre kostnader mer. Även processorintensiva jobb som förbrukar mer minne kan vara dyrare. Om du använder ytterligare utlösare för tjänster som en del av din uppgift debiteras de separat.

Premium-planen är mer lämplig om du har ett stort antal uppgifter som är korta men som förväntas köras kontinuerligt. Den här planen är dyrare eftersom den behöver mer minne och processor. Fördelen är att du kan använda funktioner som integrering av virtuella nätverk.

Den dedikerade planen passar bäst för bakgrundsjobb om din arbetsbelastning redan körs på den. Om du har underutnytttagna virtuella datorer kan du köra den på samma virtuella dator och dela beräkningskostnader.

För mer information, se dessa artiklar:

Azure Virtual Machines

Bakgrundsuppgifter kan implementeras på ett sätt som förhindrar att de distribueras till Azure Web Apps, eller så är de här alternativen kanske inte praktiska. Vanliga exempel är Windows-tjänster och verktyg och körbara program från tredje part. Ett annat exempel kan vara program som är skrivna för en annan körningsmiljö än den som är värd för programmet. Du kanske vill köra ett Unix- eller Linux-program från en Windows- eller .NET-program. Du kan välja mellan olika operativsystem för en virtuell Azure-dator och köra din tjänst eller körbara fil på den virtuella datorn.

Information om hur du väljer när du ska använda virtuella datorer finns i jämförelsen mellan Azure App Services, Cloud Services och Virtual Machines. Information om alternativen för virtuella datorer finns i Storlekar för virtuella Windows-datorer i Azure. Mer information om vilka operativsystem och färdiga avbildningar som är tillgängliga för Virtual Machines finns under virtuella datorer på Azure Marketplace.

Om du vill initiera bakgrundsaktiviteten i en separat, virtuell dator har en rad alternativ:

  • Du kan köra uppgiften på begäran direkt från ditt program genom att skicka en begäran till en slutpunkt som aktiviteten exponerar. Detta skickar alla data som krävs. Slutpunkten anropar uppgiften.
  • Du kan konfigurera att uppgiften ska köras enligt ett schema genom att använda en schemaläggare eller timer i operativsystemet. I Windows kan du till exempel använda Schemaläggaren för att köra skript och uppgifter. Om du har installerat SQL Server på den virtuella datorn kan du använda SQL Server Agent för att köra skript och uppgifter.
  • Du kan använda Azure Logic Apps för att initiera uppgiften genom att lägga till ett meddelande i en kö som uppgiften lyssnar på, eller genom att skicka en begäran till ett API som aktiviteten exponerar.

Se det tidigare avsnittet om utlösare för mer information om hur du kan starta bakgrundsaktiviteter.

Att tänka på

Tänk på följande när du bestämmer om du vill distribuera bakgrundsaktiviteter på en virtuell Azure-dator:

  • Att köra bakgrundsaktiviteter med en separat virtuell Azure-dator som värd ger flexibilitet och tillåter fullständig kontroll över inledande, körning, schemaläggning och resursallokering. Men körningskostnaden ökar om en virtuell dator måste distribueras bara för att köra bakgrundsaktiviteter.
  • Det finns ingen möjlighet att övervaka aktiviteterna i Azure-portalen och ingen automatisk omstart vid misslyckade aktiviteter – men du kan övervaka grundläggande status för den virtuella datorn och hantera den med hjälp av Azure Resource Manager-Cmdletar. Det finns dock inga resurser för att styra processer och trådar i beräkningsnoder. Normalt kräver användning av en virtuell dator extra arbete för att implementera en mekanism som samlar in data från instrumentation i aktiviteten och från operativsystemet på den virtuella datorn. En lösning som kan vara lämplig är att använda System Center Management Pack för Azure.
  • Du kanske ska fundera på att skapa övervakningsavsökning som är tillgänglig via HTTP-slutpunkter. Koden för dessa avsökningar kan utföra hälsokontroller, samla in driftinformation och statistik – eller samla felinformation och returnera den till ett hanteringsprogram. Mer information finns i mönstret Hälsoslutpunktsövervakning.

Mer information finns i:

Azure Batch

Överväg Azure Batch om du behöver köra stora, parallella HPC-arbetsbelastningar (databehandling med höga prestanda) över tiotals, hundratals eller tusentals virtuella datorer.

Batch-tjänsten tillhandahåller de virtuella datorerna, tilldelar uppgifter till de virtuella datorerna, kör uppgifterna och övervakar förloppet. Batch kan automatiskt skala ut de virtuella datorerna som svar på arbetsbelastningen. Batch tillhandahåller också jobbschemaläggning. Azure Batch stöder både virtuella Linux- och Windows-datorer.

Att tänka på

Batch fungerar bra med verkligt parallella arbetsbelastningar. Det kan också utföra parallella beräkningar med ett minskningssteg i slutet eller köra MPI-program (Message Passing Interface) för parallella åtgärder som kräver meddelandehantering mellan noder.

Ett Azure Batch-jobb körs i en pool av noder (virtuella datorer). En metod är att allokera en pool vid behov och sedan ta bort den när jobbet har slutförts. Detta maximerar användningen eftersom noderna inte är inaktiva, men jobbet måste vänta tills noderna har allokerats. Du kan också skapa en pool i förväg. Denna metod minimerar den tid det tar för ett jobb för att starta, men kan leda till att noder är inaktiva. Läs mer i Livslängd för pooler och beräkningsnoder.

Mer information finns i:

Azure Kubernetes Service

Azure Kubernetes Service (AKS) hanterar din värdbaserade Kubernetes-miljö, vilket gör det enkelt att distribuera och hantera containerbaserade program.

Containrar kan vara användbara för att köra bakgrundsjobb. Här är några av fördelarna:

  • Containrar stöder värdar med hög densitet. Du kan isolera en bakgrundsaktivitet i en container och placera flera containrar på varje virtuell dator.
  • Containerinitieraren hanterar intern belastningsutjämning, konfigurerar det interna nätverket och andra konfigurationsåtgärder.
  • Containrar kan startas och stoppas efter behov.
  • Med Azure Container Registry kan du registrera dina behållare inom Azure-gränser. Det innebär säkerhets-, sekretess- och närhetsfördelar.

Att tänka på

  • Kräver kunskap om hur du använder en containerinitierare. Beroende på kompetensuppsättningen för ditt DevOps-team kan det vara ett problem.

Mer information finns i:

Azure Container Apps

Med Azure Container Apps kan du skapa serverlösa mikrotjänster baserat på containrar. Bland de utmärkande funktionerna i Container Apps finns:

  • Optimerad för att köra containrar för generell användning, särskilt för program som omfattar många mikrotjänster som distribueras i containrar.
  • Drivs av Kubernetes och tekniker med öppen källkod som Dapr, KEDA och envoy.
  • Stöder Kubernetes-liknande appar och mikrotjänster med funktioner som tjänstidentifiering och trafikdelning.
  • Aktiverar händelsedrivna programarkitekturer genom att stödja skalning baserat på trafik och hämta från händelsekällor som köer, inklusive skala till noll.
  • Stöd för tidskrävande processer och kan köra bakgrundsaktiviteter.

Att tänka på

Azure Container Apps ger inte direkt åtkomst till underliggande Kubernetes-API:er. Om du behöver åtkomst till Kubernetes-API:erna och kontrollplanet bör du använda Azure Kubernetes Service. Men om du vill skapa Kubernetes-liknande program och inte kräver direkt åtkomst till alla inbyggda Kubernetes-API:er och klusterhantering ger Container Apps en fullständigt hanterad upplevelse baserat på bästa praxis. Därför kanske många team föredrar att börja skapa containermikrotjänster med Azure Container Apps.

Mer information finns i:

Du kan komma igång med att skapa din första containerapp med hjälp av snabbstarterna.

Partitionering

Om du bestämmer dig för att inkludera bakgrundsaktiviteter i en befintlig beräkningsinstans måste du överväga hur detta påverkar kvalitetsattributen för beräkningsinstansen och själva bakgrundsaktiviteten. Dessa faktorer hjälper dig att bestämma om du vill samordna aktiviteterna med den befintliga beräkningsinstansen eller dela upp dem på en separat beräkningsinstans:

  • Tillgänglighet: Bakgrundsaktiviteter kanske inte behöver ha samma nivå av tillgänglighet som andra delar av programmet, i synnerhet användargränssnittet och andra delar som är direkt inblandade i användarinteraktion. Bakgrundsaktiviteter kan vara mer toleranta för svarstider, nya försök vid anslutningsfel och andra faktorer som påverkar tillgängligheten eftersom åtgärderna som kan köas. Men det måste finnas tillräckligt med kapacitet för att förhindra en för lång kö av begäranden som kan blockera köer och påverka programmet i helhet.

  • Skalbarhet: Bakgrundsaktiviteter har sannolikt andra krav på skalbarhet än användargränssnittet och interaktiva delar av programmet. Det kan vara nödvändigt att skala användargränssnittet för att uppfylla toppar i efterfrågan, medan enastående bakgrundsaktiviteter kan slutföras under mindre upptagna tider av färre beräkningsinstanser.

  • Återhämtning: Om det blir fel i en beräkningsinstans som endast är värd för bakgrundsaktiviteter kanske det inte påverkar programmet i sin helhet om begäranden för dessa aktiviteter kan sättas i kö eller skjutas upp tills aktiviteten är tillgänglig igen. Om beräkningsinstansen och/eller aktiviteterna kan startas om inom ett lämpligt tidsintervall behöver användare av programmet inte påverkas.

  • Säkerhet: Bakgrundsaktiviteter kan ha andra säkerhetskrav eller -begränsningar än användargränssnittet eller andra delar av programmet. Genom att använda en separat beräkningsinstans kan du ange en annan säkerhetsmiljö för aktiviteterna. Du kan också använda mönster, till exempel Gatekeeper, för att isolera bakgrundberäkningsinstanserna från användargränssnittet för att maximera säkerhet och uppdelning.

  • Prestanda: Du kan välja typ av beräkningsinstans för bakgrundsaktiviteterna för att specifikt matcha aktiviteternas prestandakrav. Detta kan innebära att du använder ett billigare beräkningsalternativ om aktiviteterna inte kräver samma bearbetningsfunktioner som användargränssnittet, eller en större instans om de kräver ytterligare kapacitet och resurser.

  • Hanterbarhet: Bakgrundsaktiviteter kan ha en annan utvecklings- och distributionstakt än den huvudsakliga programkoden eller användargränssnittet. Att distribuera dem i en separat beräkningsinstans kan förenkla uppdateringar och versionshantering.

  • Kostnad: Att lägga till beräkningsinstanser för att köra bakgrundsaktiviteter ökar värdkostnaderna. Du bör noggrant väga den ytterligare kapacitet mot dessa extra kostnader.

Mer information finns i leader-valmönstret och mönstret Konkurrerande konsumenter.

Konflikter

Om du har flera instanser av ett bakgrundsjobb, är det möjligt att de kommer att konkurrera om åtkomsten till resurser och tjänster, till exempel databaser och lagringsutrymme. Samtidig åtkomst kan leda till resurskonkurrens vilket kan orsaka konflikter i tillgängligheten för tjänsterna och integriteten hos data i lagring. Du kan lösa resurskonkurrensen med pessimistisk låsning. Detta förhindrar konkurrerande instanser av en aktivitet från att samtidigt få åtkomst till en tjänst eller skada data.

En annan metod för att lösa konflikter är att definiera bakgrundsaktiviteter som singleton, så att endast en enda instans körs. Detta eliminerar dock tillförlitlighets- och prestandafördelarna som finns i en konfiguration med flera instanser. Detta gäller särskilt om användargränssnittet kan tillhandahålla tillräckligt med arbete för att hålla mer än en bakgrundsaktivitet upptagen.

Det är viktigt att se till att bakgrundsaktiviteten kan startas om automatiskt och att det finns tillräckligt med kapacitet för att hantera toppar i efterfrågan. Du kan åstadkomma detta genom att allokera en beräkningsinstans med tillräckliga resurser, genom att implementera en kömekanism som kan lagra begäranden för senare körning när efterfrågan minskar eller genom att använda en kombination av dessa metoder.

Samordning

Bakgrundsuppgifterna kan vara komplexa och kan kräva flera enskilda uppgifter för att generera ett resultat eller för att uppfylla alla krav. Det är i dessa scenarier vanligt att dela upp aktiviteten i kortare steg eller underaktiviteter som kan utföras av flera användare. Flerstegsjobb kan vara effektivare och mer flexibel eftersom enskilda steg kan återanvändas i flera jobb. Det är också lätt att lägga till, ta bort eller ändra ordningen på stegen.

Samordning av flera aktiviteter och steg kan vara en utmaning, men det finns tre vanliga mönster som du kan använda som hjälp för att implementera en lösning:

  • Bryta ned en aktivitet i flera, återanvändbara steg. Ett program kan behöva utföra olika uppgifter av varierande komplexitet på den information som bearbetas. Ett enkelt men oflexibelt sätt att implementera det här programmet kan vara att utföra den här bearbetning som en monolitisk modul. Den här metoden minskar dock troligtvis möjligheterna att omstrukturera koden, optimera den eller återanvända den om delar av samma bearbetning behövs någon annanstans i programmet. Mer information finns i mönstret Rör och filter.

  • Hantera körningen av stegen för att en aktivitet. Ett program kanske utför uppgifter som omfattar ett antal steg (varav en del kan anropa fjärrtjänster eller använda fjärranslutna resurser). De enskilda stegen kan vara oberoende av varandra, men de orkestreras av den programlogik som implementerar aktiviteten. Mer information finns i Scheduler Agent Supervisor-mönster.

  • Hantera återställning för aktivitetssteg som misslyckas. Om ett eller flera av stegen misslyckas kanske ett program behöver ångra det arbete som utförts av en serie steg (som tillsammans definierar en så småningom konsekvent åtgärd). Mer information finns i mönstret Kompenserande transaktion.

Att tänka på om återhämtning

Bakgrundsaktiviteter måste vara elastiska för att tillhandahålla tillförlitliga tjänster för programmet. När du planerar och utformar bakgrundsaktiviteter bör du tänka på följande:

  • Bakgrundsaktiviteter måste kunna hantera omstarter på ett korrekt sätt utan att skada data eller införa inkonsekvens i programmet. För långvariga aktiviteter eller aktiviteter med flera steg kanske du ska överväga att använda kontrollpunkter genom att spara status för jobben i permanent lagring eller som meddelanden i en kö om det är lämpligt. Du kan till exempel bevara statusinformation i ett meddelande i en kö och stegvis uppdatera statusinformationen med aktivitetsförloppet så att aktiviteten kan bearbetas från den senaste kända godkända kontrollpunkten – i stället för att börja om från början. När du använder Azure Service Bus-köer kan använda du meddelandesessioner för samma scenario. Med sessioner kan du spara och hämta programmets bearbetningsstatus med hjälp av metoderna SetState och GetState. Mer information om hur du utformar tillförlitliga processer och arbetsflöden med flera steg finns i mönstret Scheduler Agent Supervisor.

  • När du använder köer för att kommunicera med bakgrundsaktiviteter kan köerna fungera som en buffert för att lagra förfrågningar som skickas till aktiviteterna när programmet är under högre belastningen än vanligt. På så sätt kan aktiviteterna komma ikapp användargränssnittet under perioder med mindre belastning. Det innebär också att omstarter inte blockerar användargränssnittet. Mer information finns i mönstret Köbaserad belastningsutjämning. Om vissa uppgifter är viktigare än andra kan du överväga att implementera mönstret Prioritetskö för att säkerställa att dessa uppgifter körs före mindre viktiga uppgifter.

  • Bakgrundsuppgifter som initieras av meddelanden eller processmeddelanden måste utformas för att hantera inkonsekvenser, som meddelanden som inkommer i fel ordning, meddelanden som upprepade gånger orsakar ett fel (skadliga meddelanden) och meddelanden som levereras mer än en gång. Tänk också på följande:

    • Meddelanden som måste bearbetas i en viss ordning, som sådana som ändrar data utifrån befintligt datavärde (genom att till exempel lägga till ett värde på ett befintligt värde) kanske inte ankommer i den ursprungliga ordningen som de skickades i. De kan också hanteras av olika instanser av en bakgrundsaktivitet i en annan ordning på grund av olika belastningar på varje instans. Meddelanden som måste bearbetas i en viss ordning bör innehålla ett sekvensnummer, nyckel eller någon annan indikator som bakgrundsaktiviteter kan använda för att säkerställa att de bearbetas i rätt ordning. Om du använder Azure Service Bus kan du använda meddelandesessioner för att garantera leveransordningen. Det är emellertid oftast mer effektivt att, där det är möjligt, utforma processen så att meddelandeordningen inte är viktig.

    • En bakgrundsaktivitet granskar vanligtvis meddelandena i kön, som tillfälligt döljer dem från andra meddelandekonsumenter. Sedan tar den bort meddelanden när de har behandlats. Om en bakgrundsaktivitet misslyckas vid bearbetningen av ett meddelande visas meddelandet igen i kön när granskningstidsgränsen löper ut. Det behandlas av en annan instans av aktiviteten eller under nästa bearbetningscykel av den här instansen. Om meddelandet konsekvent orsakar ett fel hos konsumenten blockeras aktiviteten, kön, och slutligen själva programmet när kön är full. Därför är det viktigt att identifiera och ta bort skadliga meddelanden från kön. Om du använder Azure Service Bus kan meddelanden som orsakar ett fel flyttas automatiskt eller manuellt till en associerad kö med obeställbara meddelanden.

    • Köer har garanterat minst en leveransmekanismer, men de kan leverera samma meddelande flera gånger. Dessutom blir meddelandet tillgängligt för bearbetning igen om en bakgrundsaktivitet misslyckas efter det att meddelandet har bearbetats men innan det tas bort från kön. Bakgrundsaktiviteter bör vara idempotenter, vilket innebär att bearbetning av samma meddelande mer än en gång inte orsakar ett fel eller inkonsekvens i programmets data. Vissa åtgärder är naturligt idempotenta, till exempel att ange ett lagrat värdet till ett nytt värde. Åtgärder som att lägga till ett värde till ett befintligt lagrat värde utan att kontrollera att det lagrade värdet fortfarande är densamma som när meddelandet först skickades kommer att orsaka inkonsekvenser. Azure Service Bus-köer kan konfigureras för att automatiskt ta bort dubblettmeddelanden. Mer information om utmaningarna med meddelandeleverans minst en gång finns i vägledningen för idempotent meddelandebearbetning.

    • Vissa meddelandesystem, till exempel Azure Queue Storage och Azure Service Bus-köer, stöder en de-queue count-egenskap som anger hur många gånger ett meddelande har lästs från kön. Det kan vara användbart för att hantera upprepade och skadliga meddelanden. Mer information finns i artiklarna om introduktion till asynkron meddelandehantering och idempotensmönster.

Saker att tänka på gällande skalning och prestanda

Bakgrundsaktiviteter måste ge tillräcklig prestanda så att de inte blockerar programmet eller orsakar inkonsekvenser på grund av fördröjningar när systemet är under belastning. Normalt förbättras prestanda genom att skalanpassa beräkningsinstanserna som är värdar för bakgrundsaktiviteter. När du planerar och utformar bakgrundsaktiviteter bör du tänka på följande angående skalbarhet och prestanda:

  • Azure har stöd för automatisk skalning (både utskalning och skalning tillbaka) baserat på aktuell efterfrågan och belastning eller enligt ett fördefinierat schema för webappar och virtuella datorer med värdbaserade distributioner. Använd den här funktionen för att säkerställa att programmet i helhet har tillräckliga prestandafunktioner och ändå minimerar körningskostnader.

  • Om bakgrundsaktiviteter har en annan prestandafunktion än de andra delarna av ett program (till exempel användargränssnittet eller komponenterna, till exempel dataåtkomstlagret), kan gränssnitts- och bakgrundsuppgifterna skalas separat för att hantera belastningen genom att hantera bakgrundsaktiviteterna tillsammans i en separat beräkningstjänst. Om flera bakgrundsaktiviteter har betydligt olika prestandafunktioner från varandra kan du överväga att dela upp dem och skala varje typ separat. Observera dock att detta kan öka körningskostnaderna.

  • Att bara skala beräkningsresurserna kanske inte räcker för att förhindra prestandaförlust under belastning. Du kan också behöva skalanpassa lagringsköer och andra resurser för att förhindra att en viss punkt i kedjan blir en flaskhals. Överväg även andra begränsningar, till exempel maximalt dataflöde för lagring och andra tjänster som programmet och bakgrundsaktiviteterna förlitar sig på.

  • Bakgrundsaktiviteter måste utformas för skalning. De måste till exempel kunna dynamiskt identifiera antalet lagringsköer som används för att lyssna på eller skicka meddelanden till lämplig kö.

  • Som standard skalanpassas webbjobb med den associerade Azure Web Apps-instansen. Men om du vill att ett webbjobb ska köras som en enda instans måste du dock skapa filen Settings.job som innehåller JSON-data { "is_singleton": true }. Detta gör att Azure endast kör en enda instans av webbjobbet, även om det finns flera instanser av den associerade webbappen. Det kan vara en användbar teknik för schemalagda jobb som måste köras som en enda instans.

Nästa steg