Dela via

Bakgrundsjobb

Många typer av program kräver bakgrundsaktiviteter som körs oberoende av användargränssnittet (UI). Exempel är batchjobb, intensiva bearbetningsuppgifter och tidskrävande processer som arbetsflöden. Bakgrundsjobb kan köras utan att användaren behöver interagera – programmet kan starta jobbet och sedan fortsätta att bearbeta interaktiva begäranden från användare. Detta kan bidra till att minimera belastningen på programmets användargränssnitt, vilket kan förbättra tillgängligheten och minska antalet interaktiva svarstider.

Om ett program till exempel krävs för att generera miniatyrbilder av bilder som laddas upp av användare kan det göra detta som ett bakgrundsjobb och spara miniatyrbilden i lagringen 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 gör en beställning initiera ett bakgrundsarbetsflöde som bearbetar ordern, medan användargränssnittet gör att användaren kan fortsätta bläddra i webbappen. När bakgrundsjobbet är klart kan det uppdatera data för lagrade beställningar och skicka ett e-postmeddelande till användaren som bekräftar ordern.

När du funderar på om du vill implementera en uppgift som ett bakgrundsjobb är huvudkriterierna om aktiviteten 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 har slutförts kanske inte är lämpliga som bakgrundsjobb.

Typer av bakgrundsjobb

Bakgrundsjobb innehåller vanligtvis en eller flera av följande typer av jobb:

  • CPU-intensiva jobb, till exempel matematiska beräkningar eller strukturell modellanalys.
  • I/O-intensiva jobb, till exempel att köra en serie lagringstransaktioner eller indexera filer.
  • Batchjobb, till exempel nattliga datauppdateringar eller schemalagd bearbetning.
  • Långvariga arbetsflöden, till exempel orderuppfyllelse eller etablering av tjänster och system.
  • Bearbetning av känsliga data där uppgiften överlämnas till en säkrare plats för bearbetning. Du kanske till exempel 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 är indelade i någon av följande kategorier:

  • Händelsedrivna utlösare. Uppgiften startas som svar på en händelse, vanligtvis en åtgärd som vidtas av en användare eller ett steg i ett arbetsflöde.
  • Schemadrivna utlösare. Uppgiften anropas enligt ett schema baserat på en timer. Detta kan vara ett återkommande schema eller en engångsanrop som anges för en senare tid.

Händelsestyrda utlösare

Händelsedrivet anrop använder en utlösare för att starta bakgrundsaktiviteten. Exempel på hur du använder händelsedrivna utlösare är:

  • Användargränssnittet eller ett annat jobb placerar ett meddelande i en kö. Meddelandet innehåller data om en åtgärd som har vidtagits, till exempel användaren som gör en beställning. Bakgrundsaktiviteten lyssnar på den här kön och identifierar ankomsten av ett nytt meddelande. Det läser meddelandet och använder data i det som indata till bakgrundsjobbet. Det här mönstret kallas asynkron meddelandebaserad kommunikation.
  • Användargränssnittet eller ett annat jobb sparar eller uppdaterar ett värde i lagringen. Bakgrundsaktiviteten övervakar lagringen och identifierar ändringar. Den läser data och använder dem som indata till bakgrundsjobbet.
  • Användargränssnittet eller ett annat jobb skickar en begäran till en slutpunkt, till exempel en HTTPS-URI eller ett API som exponeras som en webbtjänst. Den skickar de data som krävs för att slutföra bakgrundsaktiviteten som en del av begäran. En slutpunkt eller webbtjänst aktiverar bakgrundsuppgiften där data används som indata.

Vanliga exempel på uppgifter som passar 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 klienter.

Schemastyrda utlösare

Schemadriven anrop använder en timer för att starta bakgrundsaktiviteten. Exempel på användning av schemadrivna utlösare är:

  • 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 ett program startar en timer som gör att bakgrundsaktiviteten anropas en gång efter en angiven tidsfördröjning eller vid en viss tidpunkt.

Vanliga exempel på uppgifter som passar för schemadrivna anrop är batchbearbetningsrutiner (till exempel uppdatering av listor över relaterade produkter för användare baserat på deras senaste beteende), rutinuppgifter för databearbetning (till exempel uppdatering av index eller generering av ackumulerade 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 enda instans bör du vara medveten om följande:

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

Returnerar resultat

Bakgrundsjobb körs asynkront i en separat process, eller till och med på en separat plats, frå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 anropsprocessen inte väntar på att aktiviteterna ska slutföras. Därför kan den inte automatiskt identifiera när aktiviteten slutar.

Om du behöver en bakgrundsaktivitet för att kommunicera med den anropande aktiviteten för att indikera förlopp eller slutförande måste du implementera en mekanism för detta. Några exempel är:

  • Skriv ett statusindikatorvärde till lagring som är tillgänglig för användargränssnittet eller anroparaktiviteten, som kan övervaka eller kontrollera det här värdet när det behövs. Andra data som bakgrundsaktiviteten måste returnera till anroparen kan placeras i samma lagring.
  • 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 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.
  • Visa ett API eller en slutpunkt från den bakgrundsuppgift som användargränssnittet eller anroparen har åtkomst till för att få statusinformation . Data som bakgrundsaktiviteten måste returnera till anroparen kan inkluderas i svaret.
  • Låt bakgrundsaktiviteten anropa tillbaka till användargränssnittet eller anroparen via ett API för att ange status vid fördefinierade punkter eller vid slutförande. Detta kan bero på händelser som genereras lokalt eller via en publicerings- och prenumerationsmekanism. Data som bakgrundsaktiviteten måste returnera till anroparen kan ingå i begäran eller händelsenyttolasten.

Värdmiljö

Du kan vara värd för bakgrundsaktiviteter med hjälp av en rad olika Azure-plattformstjänster:

  • Azure Web Apps och WebJobs. Du kan använda WebJobs för att köra anpassade jobb baserat på en rad olika typer av skript eller körbara program i kontexten för en webbapp.
  • Azure Functions. Du kan använda funktioner till bakgrundsjobb som inte är avsedda att köras under lång tid. Ett annat användningsfall är om din arbetsbelastning redan finns i App Service-planen och är underutnyttad.
  • Virtuella Azure-datorer. Om du har en Windows-tjänst eller vill använda Schemaläggaren för Windows är det vanligt att vara värd för dina bakgrundsuppgifter på en dedikerad virtuell dator.
  • Azure Batch. Batch är en plattformstjänst som schemalägger beräkningsintensivt arbete som ska köras på en hanterad samling virtuella datorer. Den kan automatiskt skala beräkningsresurser.
  • 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 i kontexten för din webbapp 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 stängas av på ett smidigt sätt. Om ett webbjobb som körs kontinuerligt misslyckas startas det om automatiskt. Omförsök och felåtgärder kan konfigureras.

När du konfigurerar ett webbjobb:

  • Om du vill att jobbet ska svara på en händelsedriven utlösare bör 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 bör du konfigurera det som Kör enligt ett 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 alternativet Kör enligt ett schema när du startar det.

Azure WebJobs körs inom webbapplikationens sandlåda. Det innebär att de kan komma åt miljövariabler och dela information, till exempel anslutningssträngar, med webbappen. Jobbet har åtkomst till den unika identifieraren för den dator som kör jobbet. Anslutningssträngen 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 jobbåtgärdsloggfilerna.

Azure WebJobs har följande egenskaper:

  • Säkerhet: Webbjobb skyddas av autentiseringsuppgifterna för distributionen av webbappen.
  • 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/{job name}
    • För kontinuerlig körning: site/wwwroot/app_data/jobs/continuous/{job name}
  • Loggning: Console.Out behandlas (markerad) som INFO. Console.Error behandlas som FEL. Du kan komma åt övervaknings- och diagnostikinformation med hjälp av Azure-portalen. Du kan ladda ned loggfiler direkt från webbplatsen. De sparas på följande platser:
    • För triggad 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:et och PowerShell. Du kan använda en konfigurationsfil med namnet settings.job i samma rotkatalog som jobbskriptet för att ange konfigurationsinformation för ett jobb. Till exempel:
    • { "stopping_wait_time": 60 }
    • { "är_singleton": sant }

Överväganden

  • I normala fall skalas WebJobs med webbappen. Du kan dock konfigurera jobb att köras på en enda instans genom att ange is_singleton konfigurationsegenskapen till true. Webbjobb med en instans är användbara för uppgifter som du inte vill skala eller köra som samtidiga flera instanser, till exempel omindexering, dataanalys 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-funktioner

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.

Överväganden

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 längre kostar 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.

Mer information finns i följande artiklar:

Virtuella maskiner i Azure

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 från tredje part och körbara program. Ett annat exempel kan vara program som skrivits för en körningsmiljö som skiljer sig från den som är värd för programmet. Det kan till exempel vara ett Unix- eller Linux-program som du vill köra från ett Windows- eller .NET-program. Du kan välja mellan en mängd 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örelse 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 operativsystem och fördefinierade avbildningar som är tillgängliga för virtuella datorer finns i Azure Virtual Machines Marketplace.

Om du vill initiera bakgrundsaktiviteten på en separat virtuell dator har du ett antal 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 in alla data som uppgiften kräver. Den här API-slutpunkten anropar uppgiften.
  • Du kan konfigurera aktiviteten så att den körs enligt ett schema med hjälp av en schemaläggare eller timer som är tillgänglig i det valda operativsystemet. I Windows kan du till exempel använda Schemaläggaren för Windows för att köra skript och uppgifter. Om du har SQL Server installerat på den virtuella datorn kan du använda SQL Server-agenten 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.

Mer information om hur du kan initiera bakgrundsaktiviteter finns i det tidigare avsnittet Utlösare .

Överväganden

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

  • Att vara värd för bakgrundsuppgifter i en separat virtuell Azure-dator ger flexibilitet och ger exakt kontroll över initiering, körning, schemaläggning och resursallokering. Det ökar dock driftkostnaden om en virtuell dator måste driftsättas bara för att köra bakgrundsuppgifter.
  • Det finns ingen möjlighet att övervaka uppgifterna i Azure-portalen och ingen automatisk omstartsfunktion för misslyckade uppgifter – även om du kan övervaka den virtuella datorns grundläggande status och hantera den med hjälp av Azure Resource Manager-cmdletarna. 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 ytterligare arbete för att implementera en mekanism som samlar in data från instrumentation i uppgiften och från operativsystemet på den virtuella datorn. En lämplig lösning är att använda System Center Management Pack för Azure.
  • Du kan överväga att skapa övervakningsprober som exponeras via HTTP-slutpunkter. Koden för dessa sonder kan utföra hälsokontroller, samla in driftinformation och statistik – eller sammanställa felinformation och returnera den till en hanteringsapplikation. 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 etablerar 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 även jobbschemaläggning. Azure Batch stöder både virtuella Linux- och Windows-datorer.

Överväganden

Batch fungerar bra med inbyggt parallella arbetsbelastningar. Den kan också utföra parallella beräkningar med ett reduce-steg i slutet eller köra MPI-program (Message Passing Interface) för parallella uppgifter som kräver meddelandeöverföring mellan noder.

Ett Azure Batch-jobb körs på en pool med noder (VM). En metod är att endast allokera en pool när det behövs 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. Den här metoden minimerar den tid det tar för ett jobb att starta, men kan resultera i att noder är inaktiva. Mer information finns i Livslängd för pool- 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. Några av fördelarna är:

  • Containrar stöder högdensitetsvärd. Du kan isolera en bakgrundsaktivitet i en container samtidigt som du placerar flera containrar på varje virtuell dator.
  • Containerorkestreraren hanterar intern belastningsutjämning, konfigurerar det interna nätverket och andra konfigurationsuppgifter.
  • Containrar kan startas och stoppas efter behov.
  • Med Azure Container Registry kan du registrera dina containrar inom Azure-gränser. Detta kommer med säkerhets-, sekretess- och närhetsfördelar.

Överväganden

  • Kräver en förståelse för hur man använder en containerorkestrerare. Beroende på kompetensnivån hos ditt DevOps-team kan det här vara ett problem, eller kanske inte.

Mer information finns i:

Azure Container-applikationer

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

Överväganden

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. De här faktorerna hjälper dig att avgöra om du ska samplacera aktiviteterna med den befintliga beräkningsinstansen eller dela upp dem i en separat beräkningsinstans:

  • Tillgänglighet: Bakgrundsaktiviteter kanske inte behöver ha samma tillgänglighetsnivå som andra delar av programmet, särskilt användargränssnittet och andra delar som är direkt involverade i användarinteraktion. Bakgrundsaktiviteter kan vara mer toleranta mot svarstid, anslutningsfel som har gjorts om och andra faktorer som påverkar tillgängligheten eftersom åtgärderna kan placeras i kö. Det måste dock finnas tillräckligt med kapacitet för att förhindra säkerhetskopiering av begäranden som kan blockera köer och påverka programmet som helhet.

  • Skalbarhet: Bakgrundsaktiviteter kommer sannolikt att ha ett annat skalbarhetskrav än användargränssnittet och de interaktiva delarna i 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: Fel i en beräkningsinstans som bara är värd för bakgrundsaktiviteter kanske inte påverkar programmet som helhet allvarligt om begäranden för dessa aktiviteter kan placeras i kö eller skjutas upp tills uppgiften är tillgänglig igen. Om beräkningsinstansen eller uppgifterna kan startas om inom ett lämpligt intervall kanske användarna av programmet inte påverkas.

  • Säkerhet: Bakgrundsuppgifter 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 som Gatekeeper för att isolera bakgrundsberäkningsinstanserna från användargränssnittet för att maximera säkerhet och separation.

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

  • Hanterbarhet: Bakgrundsuppgifter kan ha en annan utvecklings- och distributionsrytm än huvudprogramkoden eller användargränssnittet. Att distribuera dem till en separat beräkningsinstans kan förenkla uppdateringar och versionshantering.

  • Kostnad: Om du lägger till beräkningsinstanser för att köra bakgrundsaktiviteter ökar värdkostnaderna. Du bör noga överväga kompromissen mellan ytterligare kapacitet och 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 konkurrerar om åtkomst till resurser och tjänster, till exempel databaser och lagring. Den här samtidiga åtkomsten kan leda till resurskonkurrering, vilket kan orsaka konflikter i tillgängligheten för tjänsterna och integriteten för data i lagringen. Du kan lösa resurskonkurration med hjälp av en pessimistisk låsningsmetod. Detta hindrar konkurrerande instanser av en uppgift från att samtidigt komma åt en tjänst eller skada data.

En annan metod för att lösa konflikter är att definiera bakgrundsuppgifter som en singleton, så att det bara finns en instans som körs vid varje tillfälle. Detta eliminerar dock de tillförlitlighets- och prestandafördelar som en konfiguration med flera instanser kan ge. 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 automatiskt kan startas om och att den har tillräcklig kapacitet för att hantera toppar i efterfrågan. Du kan uppnå 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 med hjälp av en kombination av dessa tekniker.

Koordination

Bakgrundsuppgifterna kan vara komplexa och kan kräva flera enskilda uppgifter för att generera ett resultat eller för att uppfylla alla krav. I dessa scenarier är det vanligt att dela upp uppgiften i mindre diskreta steg eller underaktiviteter som kan köras av flera konsumenter. Flerstegsjobb kan vara effektivare och mer flexibla eftersom enskilda steg kan återanvändas i flera jobb. Det är också enkelt att lägga till, ta bort eller ändra stegens ordning.

Det kan vara svårt att samordna flera uppgifter och steg, men det finns tre vanliga mönster som du kan använda för att vägleda implementeringen av en lösning:

  • Dela upp en aktivitet i flera återanvändbara steg. Ett program kan krävas för att utföra en mängd olika uppgifter med varierande komplexitet på den information som bearbetas. En enkel men oflexibel metod för att implementera det här programmet kan vara att utföra den här bearbetningen som en monolitisk modul. Den här metoden kommer dock sannolikt att minska möjligheterna att omstrukturera koden, optimera den eller återanvända den om delar av samma bearbetning krävs någon annanstans i programmet. Mer information finns i mönstret Rör och filter.

  • Hantera utförandet av stegen för en uppgift. Ett program kan utföra uppgifter som omfattar ett antal steg (varav vissa kan anropa fjärrtjänster eller komma åt fjärrresurser). 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. Ett program kan behöva ångra det arbete som utförs av en serie steg (som tillsammans definierar en så småningom konsekvent åtgärd) om ett eller flera av stegen misslyckas. Mer information finns i mönstret Kompenserande transaktion.

Att tänka på angående resiliens

Bakgrundsuppgifter måste vara motståndskraftiga för att kunna tillhandahålla tillförlitliga tjänster till programmet. Tänk på följande när du planerar och utformar bakgrundsaktiviteter:

  • Bakgrundsaktiviteter måste kunna hantera omstarter på ett korrekt sätt utan att skada data eller införa inkonsekvens i programmet. För tidskrävande eller flerstegsaktiviteter bör du överväga att använda kontrollmarkering genom att spara tillståndet för jobb i beständig lagring eller som meddelanden i en kö om detta är lämpligt. Du kan till exempel spara tillståndsinformation i ett meddelande i en kö och stegvis uppdatera den här tillståndsinformationen med aktivitetsförloppet så att aktiviteten kan bearbetas från den senast kända bra kontrollpunkten – i stället för att starta om från början. När du använder Azure Service Bus-köer kan du använda meddelandesessioner för att aktivera samma scenario. Med sessioner kan du spara och hämta programbearbetningstillståndet 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 bakgrundsuppgifter kan köerna fungera som en buffert för att lagra förfrågningar som skickas till uppgifterna medan programmet är under högre belastning än vanligt. På så sätt kan aktiviteterna komma ikapp användargränssnittet under mindre upptagna perioder. Det innebär också att omstarter inte blockerar användargränssnittet. För mer information, se Queue-Based-mönstret för 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, till exempel meddelanden som kommer ur ordning, meddelanden som upprepade gånger orsakar ett fel (kallas ofta giftmeddelanden) och meddelanden som levereras mer än en gång. Tänk på följande:

    • Meddelanden som måste bearbetas i en viss ordning, till exempel sådana som ändrar data baserat på det befintliga datavärdet (till exempel att lägga till ett värde i ett befintligt värde), kanske inte kommer i den ursprungliga ordning som de skickades. Alternativt kan de hanteras av olika instanser av en bakgrundsaktivitet i en annan ordning på grund av varierande belastning på varje instans. Meddelanden som måste bearbetas i en viss ordning bör innehålla ett sekvensnummer, en 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 dock vanligtvis effektivare, där det är möjligt, att utforma processen så att meddelandeordningen inte är viktig.

    • Vanligtvis tittar en bakgrundsaktivitet på meddelanden i kön, vilket tillfälligt döljer dem från andra meddelandekonsumenter. Sedan tas meddelandena bort när de har bearbetats. Om en bakgrundsaktivitet misslyckas när ett meddelande bearbetas visas meddelandet igen i kön när tidsgränsen för granskning upphör att gälla. Den bearbetas av en annan instans av uppgiften eller under nästa bearbetningscykel för den här instansen. Om meddelandet konsekvent orsakar ett fel i konsumenten blockeras uppgiften, kön och så småningom själva programmet när kön blir full. Därför är det viktigt att identifiera och ta bort förgiftade meddelanden från köen. Om du använder Azure Service Bus kan meddelanden som orsakar ett fel flyttas automatiskt eller manuellt till en associerad dödbrevskö.

    • Köer garanteras minst en gång leveransmekanismer, men de kan leverera samma meddelande mer än en gång. Om en bakgrundsaktivitet misslyckas efter bearbetningen av ett meddelande, men innan den tas bort från kön, blir meddelandet dessutom tillgängligt för bearbetning igen. 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 ställa in ett lagrat värde till ett specifikt nytt värde. Åtgärder som att lägga till ett värde i ett befintligt lagrat värde utan att kontrollera att det lagrade värdet fortfarande är detsamma som när meddelandet ursprungligen skickades orsakar dock inkonsekvenser. Azure Service Bus-köer kan konfigureras för att automatiskt ta bort duplicerade meddelanden. 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. Detta kan vara användbart vid hantering av upprepade och giftiga meddelanden. Mer information finns i Introduktion till asynkron meddelandehantering och Idempotensmönster.

Överväganden om skalning och prestanda

Bakgrundsaktiviteter måste ge tillräcklig prestanda för att säkerställa att de inte blockerar programmet, eller orsaka inkonsekvenser på grund av fördröjd åtgärd när systemet är under belastning. Prestandan förbättras vanligtvis genom att de beräkningsinstanser som är värdar för bakgrundsuppgifterna skalas. När du planerar och utformar bakgrundsaktiviteter bör du tänka på följande punkter kring 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 som helhet har tillräckliga prestandafunktioner samtidigt som körningskostnaderna minimeras.

  • 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 skala lagringsköer och andra resurser för att förhindra att en enda punkt i den övergripande bearbetningskedjan blir en flaskhals. Tänk också på andra begränsningar, till exempel det maximala dataflödet för lagring och andra tjänster som programmet och bakgrundsuppgifterna förlitar sig på.

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

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

Nästa steg