Share via

Rekommendationer för att utveckla bakgrundsjobb

  • Artikel

Gäller för denna checklista för Azure Well-Architected Framework Reliability:

RE:07 Förbättra återhämtning och återställning av din arbetsbelastning genom att implementera självbevarelsedrift och självåterställningsåtgärder. Skapa funktioner i lösningen med hjälp av infrastrukturbaserade tillförlitlighetsmönster och programvarubaserade designmönster för att hantera komponentfel och tillfälliga fel. Skapa funktioner i systemet för att identifiera lösningskomponentfel och initiera automatiskt korrigerande åtgärder medan arbetsbelastningen fortsätter att fungera med fullständig eller nedsatt funktionalitet.

Relaterade guider:Tillfälliga fel | Självbevarande

Den här guiden beskriver rekommendationerna för att utveckla bakgrundsjobb. Bakgrundsjobb körs automatiskt utan behov av användarinteraktion. Många program kräver bakgrundsjobb som körs oberoende av användargränssnittet.

Några exempel på bakgrundsjobb är batchjobb, intensiva bearbetningsuppgifter och långvariga processer, till exempel arbetsflöden. Programmet startar jobbet och bearbetar interaktiva begäranden från användare. Om ett program till exempel behöver generera miniatyrbilder av bilder som användarna laddar upp kan ett bakgrundsjobb utföras för att generera miniatyrbilden och spara den i lagring. Användaren behöver inte vänta tills processen har slutförts. Som ett annat exempel gör en kund en beställning som initierar ett bakgrundsarbetsflöde som bearbetar ordern. Kunden fortsätter att bläddra i webbappen medan bakgrundsjobbet körs. När bakgrundsjobbet är klart uppdaterar det lagrade orderdata och skickar ett e-postmeddelande till kunden för att bekräfta beställningen.

Bakgrundsjobb hjälper till att minimera belastningen på programmets användargränssnitt, vilket förbättrar tillgängligheten och minskar den interaktiva svarstiden.

Viktiga designstrategier

Om du vill välja vilken uppgift som ska anges som ett bakgrundsjobb bör du överväga om aktiviteten körs utan användarinteraktion och om användargränssnittet måste vänta tills aktiviteten har slutförts. Uppgifter som kräver att användaren eller användargränssnittet väntar medan de körs är vanligtvis inte lämpliga bakgrundsjobb.

Typer av bakgrundsjobb

Några exempel på bakgrundsjobb är:

  • Processorintensiva jobb, t.ex matematiska beräkningar eller strukturella modellanalyser.

  • I/O-intensiva jobb, till exempel att köra en serie lagringstransaktioner eller indexera filer.

  • Batchjobb, till exempel datauppdateringar under natten eller schemalagd bearbetning.

  • Långvariga arbetsflöden, till exempel orderuppfyllelse eller etablering av tjänster och system.

  • Bearbetning av känsliga data som överför uppgiften 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

Initiera bakgrundsjobb med:

  • Händelsedrivna utlösare: En händelse, vanligtvis en användaråtgärd eller ett steg i ett arbetsflöde, utlöser uppgiften.

  • Schemadrivna utlösare: Ett schema som baseras på en timer anropar uppgiften. Jobbet kan schemaläggas regelbundet eller för en enda körning.

Händelsedrivna utlösare

En åtgärd utlöser ett händelsedrivet anrop som startar bakgrundsaktiviteten. Exempel på händelsedrivna utlösare är:

  • Användargränssnittet eller ett annat jobb placerar ett meddelande i en kö enligt beskrivningen i arkitekturstilen Web-Queue-Worker. Meddelandet innehåller data om en tidigare utförd åtgärd, till exempel en kund som har gjort en beställning. Bakgrundsjobbet övervakar den här kön och identifierar ankomsten av ett nytt meddelande. Det läser meddelandet och använder meddelandets data 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 som lagras. Bakgrundsjobbet övervakar lagringen och identifierar ändringar. Den läser data och använder dem som indata för 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. Som en del av begäran överför användargränssnittet eller jobbet de data som bakgrundsaktiviteten kräver. Slutpunkten eller webbtjänsten anropar bakgrundsaktiviteten, som använder dessa data som indata.

Andra exempel på uppgifter som passar för händelsedrivna anrop är bildbearbetning, arbetsflöden, skicka information till fjärrtjänster, skicka e-postmeddelanden och etablera nya användare i program med flera klientorganisationer.

Schemadrivna utlösare

En timer utlöser ett schemadrivet anrop som startar bakgrundsaktiviteten. Exempel på 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 anropar bakgrundsaktiviteten efter en tidsfördröjning eller vid en viss tidpunkt.

Andra exempel på uppgifter som passar för schemadrivna anrop är batchbearbetningsrutiner (till exempel uppdatering av relaterade produktlistor för kunder baserat på deras senaste beteende), rutinmässiga databearbetningsuppgifter (till exempel att uppdatera index eller generera ackumulerade resultat), dataanalys för dagliga rapporter, rensning av datakvarhållning och datakonsekvenskontroller.

Om du använder en schemadriven uppgift som måste köras som en enda instans kan du läsa följande överväganden:

  • Om beräkningsinstansen som kör schemaläggaren, till exempel en virtuell dator (VM) som använder schemalagda Windows-uppgifter, skalas, kör du flera instanser av schemaläggaren. Flera instanser av schemaläggaren kan starta flera instanser av uppgiften. Mer information finns i Vad betyder idempotent i programvarusystem?

  • Om aktiviteterna körs längre än perioden mellan schemaläggarhändelserna kan schemaläggaren starta en annan instans av aktiviteten medan den föregående aktiviteten körs.

Returnera 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 bakgrundsjobbet. I bästa fall är bakgrundsjobb brand- och glömåtgärder . Körningsförloppet påverkar inte användargränssnittet eller anropsprocessen, vilket innebär att anropsprocessen inte väntar på att aktiviteterna ska slutföras. Användargränssnittet och anropsprocessen kan inte identifiera när aktiviteten avslutas.

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. Några exempel är att:

  • 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. Andra data som bakgrundsaktiviteten returnerar till anroparen kan placeras i samma lagring.

  • Upprätta en svarskö som användargränssnittet eller anroparen övervakar. Bakgrundsaktiviteten kan skicka meddelanden till kön som anger status. Data som bakgrundsaktiviteten returnerar till anroparen kan placeras i meddelandena. För Azure Service Bus använder ReplyTo du egenskaperna 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. Svaret kan innehålla de data som bakgrundsaktiviteten returnerar till anroparen.

  • Konfigurera bakgrundsaktiviteten så att den anropar tillbaka till användargränssnittet eller anroparen via ett API för att ange status vid fördefinierade punkter eller när den är klar. Du kan använda händelser som genereras lokalt eller en publicerings- och prenumerationsmekanism. Begäran eller händelsenyttolasten kan innehålla de data som bakgrundsaktiviteten returnerar till anroparen.

Partitionsbakgrundsjobb

Om du inkluderar bakgrundsjobb i en befintlig beräkningsinstans bör du överväga hur dessa ändringar påverkar kvalitetsattributen för beräkningsinstansen och bakgrundsjobbet. Tänk på dessa faktorer för att avgöra om aktiviteterna ska samplaceras med den befintliga beräkningsinstansen eller om de ska delas upp i en annan beräkningsinstans:

  • Tillgänglighet: Bakgrundsaktiviteter kanske inte behöver samma tillgänglighetsnivå som andra delar av programmet, särskilt användargränssnittet och delar som direkt involverar användarinteraktion. Bakgrundsaktiviteter kan ha högre tolerans för svarstid, nya anslutningsfel 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äkerhetskopierade begäranden som kan blockera köer och påverka hela programmet.

  • Skalbarhet: Bakgrundsaktiviteter har sannolikt olika skalbarhetskrav jämfört med användargränssnittet och de interaktiva delarna av programmet. Du kan behöva skala användargränssnittet för att uppfylla toppar i efterfrågan. Utestående bakgrundsaktiviteter kan köras under mindre upptagna tider och med färre beräkningsinstanser.

  • Återhämtning: Om en beräkningsinstans som endast är värd för bakgrundsaktiviteter misslyckas kanske det inte påverkar hela programmet allvarligt. Begäranden för dessa aktiviteter kan placeras i kö eller skjutas upp tills uppgiften är tillgänglig. Om beräkningsinstansen eller aktiviteterna kan startas om inom ett lämpligt intervall kanske det inte påverkar programanvändare.

  • Säkerhet: Bakgrundsaktiviteter kan ha olika säkerhetskrav eller begränsningar jämfört med användargränssnittet eller andra delar av programmet. Använd en separat beräkningsinstans för att ange en annan säkerhetsmiljö för aktiviteterna. För att maximera säkerhet och separation kan du också använda mönster som Gatekeeper för att isolera bakgrundsberäkningsinstanserna från användargränssnittet.

  • Prestanda: Välj typ av beräkningsinstans för bakgrundsaktiviteter som specifikt matchar aktivitetens prestandakrav. Du kan använda ett billigare beräkningsalternativ om aktiviteterna inte kräver samma bearbetningsfunktioner som användargränssnittet. Eller så kan du använda en större instans om aktiviteterna kräver mer kapacitet och resurser.

  • Hanterbarhet: Bakgrundsaktiviteter kan ha en annan utvecklings- och distributionsrytm jämfört med huvudprogramkoden eller användargränssnittet. För att förenkla uppdateringar och versionshantering distribuerar du bakgrundsaktiviteter till en separat beräkningsinstans.

  • Kostnad: Om du lägger till beräkningsinstanser för att köra bakgrundsaktiviteter ökar värdkostnaderna. Överväg noggrant kompromissen mellan mer kapacitet och extra kostnader.

Mer information finns i Mönster för val av ledare och Mönster för konkurrerande konsumenter.

Konflikter

Om du har flera instanser av ett bakgrundsjobb kan de konkurrera om åtkomst till resurser och tjänster, till exempel databaser och lagring. Den här samtidiga åtkomsten kan leda till resurskonkurretion, vilket kan orsaka konflikter i tjänstens tillgänglighet och skada integriteten för de data som lagras. Lös resurskonkurration med hjälp av en pessimistisk låsningsmetod. Den här metoden förhindrar att konkurrerande instanser av en aktivitet samtidigt får åtkomst till en tjänst eller skadar data.

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

Kontrollera att bakgrundsaktiviteten kan startas om automatiskt och att den har tillräckligt med kapacitet för att hantera toppar i efterfrågan. Allokera en beräkningsinstans med tillräckligt med resurser, implementera en kömekanism som lagrar begäranden som ska köras när efterfrågan minskar eller använd en kombination av dessa tekniker.

Samordning

Bakgrundsaktiviteter kan vara komplexa och kräva att flera aktiviteter körs. I dessa scenarier är det vanligt att dela upp uppgiften i mindre diskreta steg eller underaktiviteter som flera konsumenter kan köra. Flerstegsjobb är effektivare och mer flexibla eftersom enskilda steg ofta kan återanvändas i flera jobb. Det är också enkelt att lägga till, ta bort eller ändra stegens ordning.

Det kan vara en utmaning att samordna flera uppgifter och steg, men det finns tre vanliga mönster som hjälper din lösning:

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

  • Hantera orkestreringen av stegen för en uppgift. Ett program kan utföra uppgifter som omfattar många steg, varav vissa kan anropa fjärrtjänster eller komma åt fjärrresurser. Ibland är de enskilda stegen oberoende av varandra, men de samordnas av den programlogik som implementerar uppgiften. Mer information finns i Mönster för Scheduler-agentövervakare.

  • Hantera återställningen för uppgiftssteg som misslyckas. Om ett eller flera av stegen misslyckas kan ett program behöva ångra det arbete som en serie steg utför, vilket tillsammans definierar en så småningom konsekvent åtgärd. Mer information finns i Mönster för kompenserande transaktion.

Att tänka på om återhämtning

Skapa elastiska bakgrundsaktiviteter för att tillhandahålla tillförlitliga tjänster för programmet. Tänk på följande när du planerar och utformar bakgrundsaktiviteter:

  • Bakgrundsaktiviteter måste hantera omstarter utan att skada data eller införa inkonsekvens i programmet. Överväg att använda kontrollpunkter för tidskrävande eller flerstegsaktiviteter. Använd kontrollpunkter för att spara tillståndet för jobb i beständig lagring eller som meddelanden i en kö. Du kan till exempel lagra tillståndsinformation i ett meddelande som finns i en kö och stegvis uppdatera den här tillståndsinformationen med uppgiftsstatusen. Uppgiften kan bearbetas från den senast kända kontrollpunkten i stället för att startas om från början.

    För Service Bus-köer använder du meddelandesessioner för detta ändamål. Med meddelandesessioner sparar och hämtar du programbearbetningstillståndet med hjälp av metoderna SetState och GetState . Mer information om hur du utformar tillförlitliga processer och arbetsflöden i flera steg finns i Mönster för 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. Aktiviteterna kan komma ikapp användargränssnittet under perioder med mindre upptagen och omstarter blockerar inte användargränssnittet. Mer information finns i Mönster för köbaserad belastningsutjämning. Om vissa uppgifter är viktigare än andra bör du överväga att implementera mönstret Prioritetskö för att säkerställa att dessa aktiviteter körs först.

Meddelanden

Konfigurera bakgrundsaktiviteter som initieras av meddelanden eller som bearbetar meddelanden för att hantera inkonsekvenser, till exempel meddelanden som tas emot i fel ordning, meddelanden som upprepade gånger orsakar ett fel (skadliga meddelanden) och meddelanden som levereras mer än en gång. Överväg följande rekommendationer:

  • Ibland behöver du meddelanden som ska bearbetas i en viss ordning, till exempel meddelanden som ändrar data baserat på det befintliga datavärdet, till exempel lägga till ett värde i ett befintligt värde. Meddelanden tas inte alltid emot i den ordning som de skickades. Dessutom kan olika instanser av en bakgrundsaktivitet bearbeta meddelanden i olika ordning på grund av varierande belastning på varje instans.

    För meddelanden som måste bearbetas i en viss ordning inkluderar du ett sekvensnummer, en nyckel eller en annan indikator som bakgrundsaktiviteter kan använda för att bearbeta meddelanden i rätt ordning. För Service Bus använder du meddelandesessioner för att garantera rätt leveransordning. Det är mer effektivt att utforma processen så att meddelandeordningen inte är viktig. Mer information finns i meddelandesekvensering och tidsstämplar.

  • Vanligtvis tittar en bakgrundsaktivitet på meddelanden i kön, som tillfälligt döljer dem från andra meddelandekonsumenter. När uppgiften har bearbetat meddelandet tas meddelandet bort. Om en bakgrundsaktivitet misslyckas när den bearbetar ett meddelande visas det meddelandet igen i kön när tidsgränsen för granskning upphör att gälla. En annan instans av aktiviteten bearbetar meddelandet eller nästa bearbetningscykel för den ursprungliga instansen bearbetar meddelandet.

    Om meddelandet konsekvent orsakar ett fel i konsumenten blockerar det uppgiften, kön och så småningom själva programmet när kön blir full. Det är viktigt att identifiera och ta bort skadliga meddelanden från kön. Om du använder Service Bus flyttar du automatiskt eller manuellt giftmeddelanden till en associerad kö med obeställbara meddelanden.

  • Köer är leveransmekanismer minst en gång , men de kan leverera samma meddelande mer än en gång. Om en bakgrundsaktivitet misslyckas när den har bearbetat ett meddelande, men innan den tas bort från kön, är meddelandet tillgängligt för bearbetning igen.

    Bakgrundsaktiviteter ska vara idempotenter, vilket innebär att när aktiviteten bearbetar samma meddelande mer än en gång orsakar det inte ett fel eller inkonsekvens i programmets data. Vissa åtgärder är naturligt idempotent, till exempel om ett lagrat värde anges till ett specifikt nytt värde. Vissa åtgärder orsakar dock inkonsekvenser, till exempel om ett värde läggs till i ett befintligt lagrat värde utan att verifiera att det lagrade värdet fortfarande är detsamma som när meddelandet ursprungligen skickades. Konfigurera Service Bus-köer för att automatiskt ta bort duplicerade meddelanden. Mer information finns i Idempotent meddelandebearbetning.

  • Vissa meddelandesystem, till exempel Azure Storage-köer och Service Bus-köer, stöder en egenskap för antal borttagningar som anger hur många gånger ett meddelande från kön läse. Dessa data är användbara för att hantera upprepade meddelanden och skadliga meddelanden. Mer information finns i Asynkrona meddelandeprimeringar och Idempotensmönster.

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

Bakgrundsaktiviteter måste ge tillräcklig prestanda för att säkerställa att de inte blockerar programmet eller fördröjningsåtgärden när systemet är under belastning. Prestanda förbättras vanligtvis när du skalar de beräkningsinstanser som är värdar för bakgrundsaktiviteterna. När du planerar och utformar bakgrundsaktiviteter bör du tänka på följande punkter som rör skalbarhet och prestanda:

  • Azure Virtual Machines och funktionen Web Apps i Azure App Service kan vara värd för distributioner. De stöder automatisk skalning, både utskalning och inskalning. Den automatiska skalningen bestäms av efterfrågan och belastningen eller ett fördefinierat schema. Använd automatisk skalning för att säkerställa att programmet har tillräckliga prestandafunktioner samtidigt som körningskostnaderna minimeras.

  • Vissa bakgrundsaktiviteter har en annan prestandafunktion jämfört med andra delar av ett program, till exempel användargränssnittet eller komponenter, till exempel dataåtkomstlagret. I det scenariot ska du vara värd för bakgrundsaktiviteterna tillsammans i en separat beräkningstjänst så att användargränssnittet och bakgrundsaktiviteterna kan skalas oberoende för att hantera belastningen. Om flera bakgrundsaktiviteter har betydligt olika prestandafunktioner delar du upp dem och skalar varje typ oberoende av varandra. Den här tekniken kan öka körningskostnaderna.

  • För att förhindra förlust av prestanda under belastning kan du också behöva skala lagringsköer och andra resurser så att en enskild punkt i bearbetningskedjan inte orsakar en flaskhals. Överväg andra begränsningar, till exempel det maximala dataflödet för lagring och andra tjänster som programmet och bakgrundsaktiviteterna förlitar sig på.

  • Utforma bakgrundsaktiviteter för skalning. Bakgrundsaktiviteter måste till exempel dynamiskt identifiera antalet lagringsköer som används för att övervaka meddelanden eller skicka meddelanden till lämplig kö.

  • Som standard skalas ett webbjobb med dess associerade 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 }. Den här metoden tvingar Azure att bara köra en instans av webbjobbet, även om det finns flera instanser av den associerade webbappen. Den här tekniken är användbar för schemalagda jobb som bara måste köras som en enda instans.

  • Bakgrundsjobb kan skapa utmaningar för datasynkronisering och processkoordinering, särskilt om bakgrundsaktiviteterna är beroende av varandra eller på andra datakällor. Bakgrundsjobb kan till exempel hantera problem med datakonsekvens, konkurrensförhållanden, dödlägen eller tidsgränser.

  • Bakgrundsjobb kan påverka användarupplevelsen om resultatet av bakgrundsaktiviteterna visas för användaren. Bakgrundsjobb kan till exempel kräva att användaren väntar på ett meddelande, uppdaterar sidan eller kontrollerar aktivitetens status manuellt. Dessa beteenden kan öka komplexiteten i användarinteraktionen och påverka användarupplevelsen negativt.

Kompromiss: Bakgrundsjobb introducerar fler komponenter och beroenden i systemet, vilket kan öka komplexiteten och underhållskostnaderna för lösningen. Bakgrundsjobb kan till exempel kräva en separat kötjänst, arbetstjänst, övervakningstjänst och återförsöksmekanism.

Azure-underlättande

I följande avsnitt beskrivs de Azure-tjänster som du kan använda som värd för, köra, konfigurera och hantera bakgrundsjobb.

Värdmiljöer

Det finns flera Azure-plattformstjänster som kan vara värdar för bakgrundsaktiviteter:

  • Web Apps och WebJobs: Använd webjobs-funktionen i App Service för att köra anpassade jobb som baseras på olika skript eller program som du kan köra i en webbapp.

  • Azure Functions: Använd funktionsappar för bakgrundsjobb som inte körs på länge. Du kan också använda funktionsappar om du är värd för din arbetsbelastning på en underutnyttad App Service plan.

  • Virtual Machines: Om du har en Windows-tjänst eller vill använda Schemaläggaren i Windows ska du vara värd för dina bakgrundsaktiviteter på en dedikerad virtuell dator.

  • Azure Batch: Batch är en plattformstjänst som du kan använda för att schemalägga beräkningsintensivt arbete som ska köras på en hanterad samling virtuella datorer. Den kan automatiskt skala beräkningsresurserna.

  • Azure Kubernetes Service (AKS): AKS tillhandahåller en hanterad värdmiljö för Kubernetes i Azure.

  • Azure Container Apps: Med Container Apps kan du skapa serverlösa mikrotjänster som baseras på containrar.

Följande avsnitt innehåller överväganden för vart och ett av dessa alternativ som hjälper dig att välja det bästa alternativet för dig.

Web Apps och WebJobs

Du kan använda webjobs-funktionen för att köra anpassade jobb som bakgrundsjobb i en webbapp. Ett webbjobb körs som en kontinuerlig process i webbappens kontext. Ett webbjobb kan också köras som svar på en utlösarhändelse från Logic Apps eller externa faktorer, till exempel ändringar i lagringsblobar eller meddelandeköer. WebJobs 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. Du kan konfigurera återförsöks- och felåtgärder.

När du konfigurerar ett webbjobb:

  • Om du vill att jobbet ska svara på en händelsedriven utlösare konfigurerar du det till 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 konfigurerar du det till 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 jobbet.

Ett webbjobb körs i sandbox-miljön för webbappen. Den har åtkomst till miljövariabler och kan dela information, till exempel anslutningssträngar, med webbappen. Webbjobbet har åtkomst till den unika identifieraren för den dator som kör webbjobbet. Den anslutningssträng med namnet AzureWebJobsStorage ger åtkomst till lagringsköer, blobar och tabeller för programdata. Det ger också åtkomst till Service Bus för meddelanden och kommunikation. Den anslutningssträng med namnet AzureWebJobsDashboard ger åtkomst till webbjobbets åtgärdsloggfiler.

WebJobs har följande egenskaper:

  • Säkerhet: Autentiseringsuppgifterna för distribution av webbappen ger skydd för webbjobb.

  • Filtyper som stöds: Definiera webbjobb med hjälp av kommandoskript (.cmd), batchfiler (.bat), PowerShell-skript (.ps1), Bash-kommandoskript (.sh), PHP-skript (.php), Python-skript (.py), JavaScript-kod (.js) och körbara program (.exe och .jar).

  • Distribution: Du kan distribuera skript och körbara filer med hjälp av Azure Portal, Visual Studio eller WebJobs SDK, eller så kan du kopiera dem direkt till följande platser:

    • För utlöst distribution: site/wwwroot/app_data/jobs/triggered/<job name>

    • För kontinuerlig distribution: site/wwwroot/app_data/jobs/continuous/<job name>

  • Loggfiler: Console.Out behandlas eller markeras som INFO. Console.Error behandlas som ERROR. Använd portalen för att få åtkomst till övervaknings- och diagnostikinformation. Ladda ned loggfiler direkt från webbplatsen. Loggfiler sparas på följande platser:

    • För utlöst distribution: Vfs/data/jobs/triggered/<job name>

    • För kontinuerlig distribution: Vfs/data/jobs/continuous/<job name>

  • Konfiguration: Konfigurera webbjobb med hjälp av portalen, REST-API:et och PowerShell. Använd en konfigurationsfil med namnet settings.job, som finns i samma rotkatalog som webbjobbsskriptet, för att ange konfigurationsinformation för ett webbjobb. Exempel:

    • { "stopping_wait_time": 60 }

    • { "is_singleton": true }

Web Apps- och WebJobs-överväganden

  • Som standard skalas webbjobb med webbappen. Om du vill konfigurera WebJobs att köras på en enda instans anger du 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 samtidiga flera instanser, till exempel omindexering eller dataanalys.

  • För att minimera effekten av webbjobb på webbappens prestanda skapar du en tom webbappinstans i en ny App Service planerar att vara värd för tidskrävande eller resursintensiva webbjobb.

Azure Functions

Azure Functions liknar WebJobs. Azure Functions är serverlös och passar bäst för händelsedrivna utlösare som körs under en kort period. Du kan också använda Azure Functions för att köra schemalagda jobb via timerutlösare om du konfigurerar en funktion som ska köras vid angivna tidpunkter.

Azure Functions rekommenderas inte för stora, långvariga uppgifter eftersom en funktion kan orsaka oväntade timeouter. Beroende på din värdplan bör du dock överväga att använda funktioner för schemadrivna utlösare.

Azure Functions överväganden

Om du förväntar dig att bakgrundsaktiviteten ska köras under en kort tid som svar på en händelse kan du köra aktiviteten i förbrukningsplanen. Du kan konfigurera körningen till en maximal tid. En funktion som körs för längre kostnader kostar mer. 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.

Premiumplanen är lämplig om du har flera uppgifter som är korta men som körs kontinuerligt. Den här planen är dyrare eftersom den behöver mer minne och processor. Som en fördel kan du använda andra funktioner, till exempel integrering av virtuella nätverk.

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

Mer information finns i:

Virtual Machines

Du kan implementera bakgrundsaktiviteter så att de inte distribueras till Web Apps. Du kan till exempel implementera uppgifter med hjälp av Windows-tjänster, verktyg från tredje part eller körbara program. Du kan också använda program som är skrivna för en körningsmiljö som skiljer sig från den miljö som är värd för programmet. Du kan till exempel använda ett Unix- eller Linux-program som du vill köra från ett Windows- eller .NET-program. Välj mellan flera operativsystem för en virtuell Azure-dator och kör tjänsten eller den körbara filen på den virtuella datorn.

Mer information finns i:

Om du vill initiera bakgrundsaktiviteten på en separat virtuell dator kan du:

  • Skicka en begäran till en slutpunkt som aktiviteten exponerar för att köra aktiviteten på begäran direkt från ditt program. Begäran överför data som krävs för uppgiften. Slutpunkten anropar uppgiften.

  • Använd en schemaläggare eller timer från det valda operativsystemet för att konfigurera uppgiften så att den körs enligt ett schema. I Windows kan du till exempel använda Schemaläggaren i Windows för att köra skript och uppgifter. Om du har SQL Server installerat på den virtuella datorn använder du SQL Server Agent för att köra skript och uppgifter.

  • Använd Logic Apps för att initiera uppgiften genom att lägga till ett meddelande i en kö som aktiviteten övervakar eller genom att skicka en begäran till ett API som aktiviteten exponerar.

Mer information om hur du kan initiera bakgrundsaktiviteter finns i föregående avsnitt Utlösare .

Virtual Machines överväganden

Tänk på följande när du distribuerar bakgrundsaktiviteter på en virtuell Azure-dator:

  • Hantera bakgrundsaktiviteter på en separat virtuell Azure-dator för att ge flexibilitet och exakt kontroll över initiering, distribution, schemaläggning och resursallokering. Körningskostnaderna ökar dock om du distribuerar en virtuell dator enbart för bakgrundsaktiviteter.

  • Det finns ingen möjlighet att övervaka aktiviteterna i portalen och ingen automatisk omstartsfunktion för misslyckade uppgifter. Men du kan använda Azure Resource Manager-cmdletar för att övervaka den virtuella datorns status och hantera den. Det finns inga resurser för att styra processer och trådar i beräkningsnoder. Om du använder en virtuell dator måste du vanligtvis implementera en mekanism som samlar in data från instrumentation i uppgiften och även från operativsystemet på den virtuella datorn. Du kan använda System Center Management Pack för Azure för det här ändamålet.

  • Överväg att skapa övervakningsavsökningar som exponeras via HTTP-slutpunkter. Du kan konfigurera koden för dessa avsökningar för att utföra hälsokontroller och samla in driftsinformation och statistik. Du kan också använda avsökningarna för att sortera felinformation och returnera den till ett hanteringsprogram.

Mer information finns i:

Batch

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

Använd Batch för att förbereda de virtuella datorerna, tilldela uppgifter till de virtuella datorerna, köra aktiviteterna, övervaka förloppet och automatiskt skala ut de virtuella datorerna som svar på arbetsbelastningen. Batch tillhandahåller även jobbschemaläggning och har stöd för virtuella Linux- och Windows-datorer.

Batch-överväganden

Batch är lämplig för parallella arbetsbelastningar. Du kan använda Batch för att 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 Batch-jobb körs på en pool med noder eller virtuella datorer. Du kan bara allokera en pool när det behövs och sedan ta bort den när jobbet har slutförts. Den här metoden maximerar användningen eftersom noderna inte är inaktiva, men jobbet måste vänta tills du allokerar noder. 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 noder som är inaktiva.

Mer information finns i:

Azure Kubernetes Service

Använd AKS för att hantera din värdbaserade Kubernetes-miljö så att du enkelt kan distribuera och hantera containerbaserade program.

Containrar är användbara för att köra bakgrundsjobb. Några av fördelarna är:

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

  • Använd containerorkestreraren för att utföra intern belastningsutjämning, konfigurera det interna nätverket och utföra andra konfigurationsuppgifter.

  • Du kan starta och stoppa containrar efter behov.

  • Med Azure Container Registry kan du registrera dina containrar inom Azures gränser för att ge säkerhets-, sekretess- och närhetsfördelar.

AKS-överväganden

AKS kräver en förståelse för hur du använder en containerorkestrerare.

Mer information finns i:

Container Apps

Med Container Apps kan du skapa serverlösa mikrotjänster som baseras på containrar. Containerappar:

  • Är optimerad för att köra containrar för generell användning, särskilt program som omfattar många mikrotjänster som distribueras i containrar.

  • Drivs av Kubernetes och tekniker med öppen källkod, till exempel Dapr, Kubernetes Händelsedriven autoskalning (KEDA) och Envoy.

  • Stöder Kubernetes-appar och mikrotjänster med funktioner som tjänstidentifiering och trafikdelning.

  • Möjliggör händelsedrivna programarkitekturer genom att stödja skalning som baseras på trafik och hämta från händelsekällor som köer, inklusive skala till noll.

  • Stöder långvariga processer och kan köra bakgrundsaktiviteter.

Överväganden för Container Apps

Container Apps ger inte direkt åtkomst till underliggande Kubernetes-API:er. Om du behöver åtkomst till Kubernetes-API:erna och kontrollplanet använder du AKS. Om du vill skapa Kubernetes-liknande program och du inte behöver direkt åtkomst till inbyggda Kubernetes-API:er och klusterhantering använder du Container Apps för en fullständigt hanterad upplevelse. Container Apps passar bäst för att skapa containermikrotjänster.

Mer information finns i:

Checklista för tillförlitlighet

Se den fullständiga uppsättningen rekommendationer.

Checklista för tillförlitlighet