Delen via

Aanbevelingen voor het ontwikkelen van achtergrondtaken

  • Artikel

Is van toepassing op deze aanbeveling voor de controlelijst voor betrouwbaarheid van Azure Well-Architected Framework:

RE:07 Verbeter de tolerantie en herstelbaarheid van uw workload door zelfbehoud en zelfherstelmaatregelen te implementeren. Bouw mogelijkheden in de oplossing met behulp van op infrastructuur gebaseerde betrouwbaarheidspatronen en op software gebaseerde ontwerppatronen voor het afhandelen van onderdeelfouten en tijdelijke fouten. Bouw mogelijkheden in het systeem in om fouten in het oplossingsonderdeel te detecteren en automatisch corrigerende actie te starten terwijl de workload volledig of beperkt blijft werken.

Verwante handleidingen: Tijdelijke fouten | zelfbehoud

In deze handleiding worden de aanbevelingen voor het ontwikkelen van achtergrondtaken beschreven. Achtergrondtaken worden automatisch uitgevoerd zonder tussenkomst van de gebruiker. Veel toepassingen vereisen achtergrondtaken die onafhankelijk van de gebruikersinterface worden uitgevoerd.

Enkele voorbeelden van achtergrondtaken zijn batchtaken, intensieve verwerkingstaken en langlopende processen, zoals werkstromen. De toepassing start de taak en verwerkt interactieve aanvragen van gebruikers. Als een toepassing bijvoorbeeld miniaturen moet genereren van afbeeldingen die gebruikers uploaden, kan een achtergrondtaak worden uitgevoerd om de miniatuur te genereren en op te slaan in de opslag. De gebruiker hoeft niet te wachten tot het proces is voltooid. Een andere voorbeeld: een klant plaatst een order, waarmee een achtergrondwerkstroom wordt gestart waarmee de order wordt verwerkt. De klant blijft door de web-app bladeren terwijl de achtergrondtaak wordt uitgevoerd. Nadat de achtergrondtaak is voltooid, worden de opgeslagen ordergegevens bijgewerkt en wordt er een e-mail naar de klant verzonden om de bestelling te bevestigen.

Achtergrondtaken helpen de belasting van de gebruikersinterface van de toepassing te minimaliseren, waardoor de beschikbaarheid wordt verbeterd en de interactieve reactietijd wordt verminderd.

Belangrijke ontwerpstrategieën

Als u wilt kiezen welke taak moet worden aangewezen als achtergrondtaak, moet u overwegen of de taak wordt uitgevoerd zonder tussenkomst van de gebruiker en of de gebruikersinterface moet wachten totdat de taak is voltooid. Taken waarvoor de gebruiker of de gebruikersinterface moet wachten terwijl ze worden uitgevoerd, zijn doorgaans niet de juiste achtergrondtaken.

De behoefte aan achtergrondtaken evalueren

Enkele voorbeelden van achtergrondtaken zijn:

  • CPU-intensieve taken, zoals wiskundige berekeningen of structurele modelanalyses.

  • I/O-intensieve taken, zoals het uitvoeren van een reeks opslagtransacties of het indexeren van bestanden.

  • Batchtaken, zoals nachtelijke gegevensupdates of geplande verwerking.

  • Langlopende werkstromen, zoals orderafhandeling of inrichtingsservices en -systemen.

  • Gevoelige gegevensverwerking die de taak overdraagt naar een veiligere locatie voor verwerking. Het is bijvoorbeeld mogelijk dat u geen gevoelige gegevens binnen een web-app wilt verwerken. In plaats daarvan kunt u een patroon zoals het Gatekeeper-patroon gebruiken om de gegevens over te dragen naar een geïsoleerd achtergrondproces dat toegang heeft tot beveiligde opslag.

De juiste triggers kiezen

Achtergrondtaken initiëren met:

  • Gebeurtenisgestuurde triggers: Een gebeurtenis, meestal een gebruikersactie of een stap in een werkstroom, activeert de taak.

  • Schemagestuurde triggers: Een planning die is gebaseerd op een timer roept de taak aan. De taak kan op terugkerende basis of voor één uitvoering worden gepland.

Gebeurtenisgestuurde triggers

Een actie activeert een gebeurtenisgestuurde aanroep waarmee de achtergrondtaak wordt gestart. Voorbeelden van gebeurtenisgestuurde triggers zijn:

  • De gebruikersinterface of een andere taak plaatst een bericht in een wachtrij, zoals beschreven in de architectuurstijl Web-Queue-Worker. Het bericht bevat gegevens over een eerder uitgevoerde actie, zoals een klant die een bestelling heeft geplaatst. De achtergrondtaak bewaakt deze wachtrij en detecteert de komst van een nieuw bericht. Het leest het bericht en gebruikt de gegevens van het bericht als invoer voor de achtergrondtaak. Dit patroon wordt asynchrone communicatie op basis van berichten genoemd.

  • In de gebruikersinterface of een andere taak wordt een waarde opgeslagen of bijgewerkt die zich in de opslag bevinden. De achtergrondtaak bewaakt de opslag en detecteert wijzigingen. De gegevens worden gelezen en gebruikt deze als invoer voor de achtergrondtaak.

  • De gebruikersinterface of een andere taak doet een aanvraag naar een eindpunt, zoals een HTTPS-URI of een API die beschikbaar wordt gesteld als een webservice. Als onderdeel van de aanvraag draagt de gebruikersinterface of taak de gegevens over die de achtergrondtaak nodig heeft. Het eindpunt of de webservice roept de achtergrondtaak aan, die de gegevens gebruikt als invoer.

Andere voorbeelden van taken die geschikt zijn voor gebeurtenisgestuurde aanroep, zijn afbeeldingsverwerking, werkstromen, het verzenden van informatie naar externe services, het verzenden van e-mailberichten en het inrichten van nieuwe gebruikers in multitenant-toepassingen.

Planninggestuurde triggers

Een timer activeert een planninggestuurde aanroep waarmee de achtergrondtaak wordt gestart. Voorbeelden van schemagestuurde triggers zijn:

  • Een timer die lokaal wordt uitgevoerd binnen de toepassing of als onderdeel van het besturingssysteem van de toepassing roept regelmatig een achtergrondtaak aan.

  • Een timer die wordt uitgevoerd in een andere toepassing, zoals Azure Logic Apps, verzendt regelmatig een aanvraag naar een API of webservice. De API of webservice roept de achtergrondtaak aan.

  • Een afzonderlijk proces of een afzonderlijke toepassing start een timer die de achtergrondtaak aanroept na een tijdsvertraging of op een bepaald tijdstip.

Andere voorbeelden van taken die geschikt zijn voor geplande aanroep zijn routines voor batchverwerking (zoals het bijwerken van gerelateerde productenlijsten voor klanten op basis van hun recente gedrag), routinetaken voor gegevensverwerking (zoals het bijwerken van indexen of het genereren van samengevoegde resultaten), gegevensanalyse voor dagelijkse rapporten, opschoning van gegevens en controles voor gegevensconsistentie.

Als u een planningsgestuurde taak gebruikt die als één exemplaar moet worden uitgevoerd, bekijkt u de volgende overwegingen:

  • Als het rekenproces waarop de scheduler wordt uitgevoerd, zoals een virtuele machine (VM) die gebruikmaakt van geplande Windows-taken, wordt geschaald, voert u meerdere exemplaren van de scheduler uit. Meerdere exemplaren van de scheduler kunnen meerdere exemplaren van de taak starten. Zie Wat betekent idempotent in softwaresystemen voor meer informatie ?

  • Als taken langer worden uitgevoerd dan de periode tussen de scheduler-gebeurtenissen, kan de planner een ander exemplaar van de taak starten terwijl de vorige taak wordt uitgevoerd.

Gegevens retourneren aan de workload

Achtergrondtaken worden asynchroon uitgevoerd in een afzonderlijk proces, of zelfs op een afzonderlijke locatie, vanuit de gebruikersinterface of het proces dat de achtergrondtaak heeft aangeroepen. Idealiter zijn achtergrondtaken brand- en vergeetbewerkingen . De voortgang van de runtime heeft geen invloed op de gebruikersinterface of het aanroepende proces, wat betekent dat het aanroepende proces niet wacht totdat de taken zijn voltooid. De gebruikersinterface en het aanroepende proces kunnen niet worden gedetecteerd wanneer de taak eindigt.

Als u een achtergrondtaak nodig hebt om te communiceren met de aanroepende taak om de voortgang of voltooiing aan te geven, moet u een mechanisme implementeren. Enkele voorbeelden zijn:

  • Schrijf een statusindicatorwaarde naar de opslag die toegankelijk is voor de gebruikersinterface of de aanroepertaak, die deze waarde kan bewaken of controleren. Andere gegevens die door de achtergrondtaak naar de aanroeper worden geretourneerd, kunnen in dezelfde opslag worden geplaatst.

  • Stel een antwoordwachtrij in die door de gebruikersinterface of beller wordt bewaakt. De achtergrondtaak kan berichten verzenden naar de wachtrij die de status aangeven. Gegevens die door de achtergrondtaak naar de aanroeper worden geretourneerd, kunnen in de berichten worden geplaatst. Gebruik voor Azure Service Bus de ReplyTo en CorrelationId eigenschappen om deze mogelijkheid te implementeren.

  • Geef een API of eindpunt uit de achtergrondtaak weer die de gebruikersinterface of de aanroepende taak kan openen om statusinformatie op te halen. Het antwoord kan de gegevens bevatten die de achtergrondtaak naar de aanroeper retourneert.

  • Configureer de achtergrondtaak om terug te roepen naar de gebruikersinterface of aanroeper via een API om de status op vooraf gedefinieerde punten of na voltooiing aan te geven. U kunt gebeurtenissen die lokaal zijn gegenereerd of een mechanisme voor publiceren en abonneren gebruiken. De aanvraag of de nettolading van de gebeurtenis kan de gegevens bevatten die de achtergrondtaak naar de aanroeper retourneert.

Achtergrondtaken partitioneren

Als u achtergrondtaken in een bestaand rekenproces opneemt, kunt u overwegen hoe deze wijzigingen van invloed zijn op de kwaliteitskenmerken van het rekenproces en de achtergrondtaak. Houd rekening met deze factoren om te bepalen of de taken moeten worden gekoppeld aan het bestaande rekenproces of dat ze moeten worden gescheiden in een ander rekenproces:

  • Beschikbaarheid: achtergrondtaken hebben mogelijk niet hetzelfde beschikbaarheidsniveau nodig als andere onderdelen van de toepassing, met name de gebruikersinterface en onderdelen die rechtstreeks betrekking hebben op gebruikersinteractie. Achtergrondtaken hebben mogelijk een hogere tolerantie voor latentie, mislukte verbindingen opnieuw geprobeerd en andere factoren die van invloed zijn op de beschikbaarheid, omdat de bewerkingen in de wachtrij kunnen worden geplaatst. Er moet echter voldoende capaciteit zijn om back-ups van aanvragen te voorkomen die wachtrijen kunnen blokkeren en van invloed kunnen zijn op de hele toepassing.

  • Schaalbaarheid: achtergrondtaken hebben waarschijnlijk verschillende schaalbaarheidsvereisten ten opzichte van de gebruikersinterface en de interactieve onderdelen van de toepassing. Mogelijk moet u de gebruikersinterface schalen om te voldoen aan pieken in de vraag. Openstaande achtergrondtaken kunnen worden uitgevoerd tijdens minder drukke tijden en met minder rekeninstanties.

  • Tolerantie: Als een rekenproces dat als host fungeert voor alleen achtergrondtaken mislukt, heeft dit mogelijk geen fatale invloed op de hele toepassing. De aanvragen voor deze taken kunnen in de wachtrij worden geplaatst of uitgesteld totdat de taak beschikbaar is. Als het rekenproces of de taken binnen een geschikt interval opnieuw kunnen worden opgestart, is dit mogelijk niet van invloed op de gebruikers van de toepassing.

  • Beveiliging: achtergrondtaken kunnen verschillende beveiligingsvereisten of beperkingen hebben in vergelijking met de gebruikersinterface of andere onderdelen van de toepassing. Gebruik een afzonderlijk rekenproces om een andere beveiligingsomgeving voor de taken op te geven. Als u de beveiliging en scheiding wilt maximaliseren, kunt u ook patronen zoals Gatekeeper gebruiken om de rekenprocessen op de achtergrond te isoleren van de gebruikersinterface.

  • Prestaties: kies het type rekenproces voor achtergrondtaken die specifiek overeenkomen met de prestatievereisten van de taak. U kunt een goedkopere rekenoptie gebruiken als de taken niet dezelfde verwerkingsmogelijkheden nodig hebben als de gebruikersinterface. U kunt ook een groter exemplaar gebruiken als voor de taken meer capaciteit en resources nodig zijn.

  • Beheerbaarheid: achtergrondtaken hebben mogelijk een ander ontwikkelings- en implementatieritme vergeleken met de hoofdtoepassingscode of de gebruikersinterface. Als u updates en versiebeheer wilt vereenvoudigen, implementeert u achtergrondtaken in een afzonderlijk rekenproces.

  • Kosten: Als u rekeninstanties toevoegt om achtergrondtaken uit te voeren, nemen de hostingkosten toe. Houd zorgvuldig rekening met de afweging tussen meer capaciteit en extra kosten.

Zie het patroon Leader Election en het patroon Concurrerende consumenten voor meer informatie.

Resourceconflict voorkomen

Als u meerdere exemplaren van een achtergrondtaak hebt, kunnen ze concurreren voor toegang tot resources en services, zoals databases en opslag. Deze gelijktijdige toegang kan leiden tot conflicten tussen resources, waardoor service-beschikbaarheidsconflicten kunnen ontstaan en de integriteit van de gegevens die zich in de opslag bevinden, kan worden beschadigd. Los resourceconflicten op met behulp van een pessimistische vergrendelingsbenadering. Deze aanpak voorkomt dat concurrerende exemplaren van een taak gelijktijdig toegang krijgen tot een service of beschadigde gegevens.

Een andere benadering voor het oplossen van conflicten is het definiëren van achtergrondtaken als een singleton, zodat slechts één exemplaar wordt uitgevoerd. Deze aanpak elimineert echter de betrouwbaarheid en prestatievoordelen die een configuratie met meerdere exemplaren biedt. Dit nadeel geldt vooral als de gebruikersinterface voldoende werk levert om meer dan één achtergrondtaak bezet te houden.

Zorg ervoor dat de achtergrondtaak automatisch opnieuw kan worden opgestart en dat deze voldoende capaciteit heeft om pieken in de vraag te verwerken. Wijs een rekenproces toe met voldoende resources, implementeer een wachtrijmechanisme waarmee aanvragen worden opgeslagen die moeten worden uitgevoerd wanneer de vraag afneemt of een combinatie van deze technieken gebruikt.

Meerdere taken organiseren

Achtergrondtaken kunnen complex zijn en vereisen dat meerdere taken worden uitgevoerd. In deze scenario's is het gebruikelijk om de taak te verdelen in kleinere afzonderlijke stappen of subtaken die meerdere consumenten kunnen uitvoeren. Taken met meerdere stappen zijn efficiënter en flexibeler omdat afzonderlijke stappen vaak opnieuw kunnen worden gebruikt in meerdere taken. Het is ook eenvoudig om de volgorde van de stappen toe te voegen, te verwijderen of te wijzigen.

Het kan een uitdaging zijn om meerdere taken en stappen te coördineren, maar er zijn drie veelvoorkomende patronen om uw oplossing te begeleiden:

  • Een taak opsmalen in meerdere herbruikbare stappen. Een toepassing kan vereist zijn om verschillende taken van verschillende complexiteit uit te voeren op de informatie die door de toepassing wordt verwerkt. Een eenvoudige maar inflexibele benadering voor het implementeren van een dergelijke toepassing is het uitvoeren van deze verwerking als een monolithische module. Maar deze aanpak vermindert waarschijnlijk de mogelijkheden voor het herstructureren van de code, het optimaliseren ervan of het hergebruik ervan als de toepassing onderdelen van dezelfde verwerking elders vereist. Zie het patroon Pipes en Filters voor meer informatie.

  • Beheer de indeling van de stappen voor een taak. Een toepassing kan taken uitvoeren die uit veel stappen bestaan, waarvan sommige externe services kunnen aanroepen of toegang hebben tot externe resources. Soms zijn de afzonderlijke stappen onafhankelijk van elkaar, maar worden ze ingedeeld door de toepassingslogica waarmee de taak wordt geïmplementeerd. Zie scheduler Agent Supervisor-patroon voor meer informatie.

  • Beheer het herstel voor taakstappen die mislukken. Als een of meer van de stappen mislukken, moet een toepassing mogelijk het werk ongedaan maken dat door een reeks stappen wordt uitgevoerd, waarmee samen een uiteindelijk consistente bewerking wordt gedefinieerd. Zie Het patroon Compenserende transactie voor meer informatie.

Taken tolerant maken

Maak tolerante achtergrondtaken om betrouwbare services voor de toepassing te bieden. Houd rekening met de volgende punten wanneer u achtergrondtaken plant en ontwerpt:

  • Achtergrondtaken moeten opnieuw opstarten zonder beschadigde gegevens te verwerken of inconsistentie in de toepassing te introduceren. Voor langlopende of multistep-taken kunt u overwegen controlepunten te gebruiken. Gebruik controlepunten om de status van taken op te slaan in permanente opslag of als berichten in een wachtrij. U kunt bijvoorbeeld statusgegevens opslaan in een bericht dat zich in een wachtrij bevindt en deze statusgegevens incrementeel bijwerken met de voortgang van de taak. De taak kan worden verwerkt vanaf het laatst bekende controlepunt in plaats van opnieuw op te starten vanaf het begin.

    Gebruik voor Service Bus-wachtrijen berichtsessies voor dit doel. Met berichtsessies slaat u de verwerkingsstatus van de toepassing op en haalt u deze op met behulp van de methoden SetState en GetState . Zie scheduler Agent Supervisor-patroon voor meer informatie over het ontwerpen van betrouwbare processen en werkstromen met meerdere taken.

  • Wanneer u wachtrijen gebruikt om te communiceren met achtergrondtaken, kunnen de wachtrijen fungeren als buffer voor het opslaan van aanvragen die naar de taken worden verzonden terwijl de toepassing zwaarder belast is dan normaal. De taken kunnen de gebruikersinterface inhalen tijdens minder drukke perioden en opnieuw opstarten blokkeert de gebruikersinterface niet. Zie het patroon Load Leveling op basis van wachtrijen voor meer informatie. Als sommige taken belangrijker zijn dan andere, kunt u overwegen het patroon Prioriteitswachtrij te implementeren om ervoor te zorgen dat deze taken eerst worden uitgevoerd.

Berichten

Configureer achtergrondtaken die worden geïnitieerd door berichten of die berichten verwerken om inconsistenties af te handelen, zoals berichten die niet in orde zijn, berichten die herhaaldelijk een fout veroorzaken (gifberichten) en berichten die meer dan één keer worden bezorgd. Bekijk de volgende aanbevelingen:

  • Soms moet u berichten in een specifieke volgorde verwerken, zoals berichten die gegevens wijzigen op basis van de bestaande gegevenswaarde, bijvoorbeeld het toevoegen van een waarde aan een bestaande waarde. Berichten komen niet altijd binnen in de volgorde waarin ze zijn verzonden. Bovendien kunnen verschillende exemplaren van een achtergrondtaak berichten in een andere volgorde verwerken vanwege verschillende belastingen op elk exemplaar.

    Voor berichten die in een specifieke volgorde moeten worden verwerkt, moet u een volgnummer, sleutel of een andere indicator opnemen die achtergrondtaken kunnen gebruiken om berichten in de juiste volgorde te verwerken. Gebruik voor Service Bus berichtensessies om de juiste leveringsvolgorde te garanderen. Het is efficiënter om het proces te ontwerpen, zodat de berichtvolgorde niet belangrijk is. Zie berichtvolgorde en tijdstempels voor meer informatie.

  • Normaal gesproken bekijkt een achtergrondtaak berichten in de wachtrij, waardoor ze tijdelijk worden verborgen voor andere gebruikers van berichten. Nadat de taak het bericht heeft verwerkt, wordt het bericht verwijderd. Als een achtergrondtaak mislukt wanneer een bericht wordt verwerkt, wordt dat bericht opnieuw weergegeven in de wachtrij nadat de time-out voor de korte weergave is verlopen. Een ander exemplaar van de taak verwerkt het bericht of de volgende verwerkingscyclus van het oorspronkelijke exemplaar verwerkt het bericht.

    Als het bericht consistent een fout veroorzaakt in de consument, blokkeert het de taak, de wachtrij en uiteindelijk de toepassing zelf wanneer de wachtrij vol raakt. Het is essentieel om gifberichten uit de wachtrij te detecteren en te verwijderen. Als u Service Bus gebruikt, worden gifberichten automatisch of handmatig verplaatst naar een gekoppelde wachtrij met dode brieven.

  • Wachtrijen zijn ten minste eenmaal bezorgingsmechanismen, maar ze kunnen hetzelfde bericht meer dan één keer bezorgen. Als een achtergrondtaak mislukt nadat een bericht is verwerkt, maar voordat deze uit de wachtrij wordt verwijderd, is het bericht weer beschikbaar voor verwerking.

    Achtergrondtaken moeten idempotent zijn, wat betekent dat wanneer de taak hetzelfde bericht meerdere keren verwerkt, dit geen fout of inconsistentie veroorzaakt in de gegevens van de toepassing. Sommige bewerkingen zijn natuurlijk idempotent, bijvoorbeeld als een opgeslagen waarde is ingesteld op een specifieke nieuwe waarde. Sommige bewerkingen veroorzaken echter inconsistenties, bijvoorbeeld als een waarde wordt toegevoegd aan een bestaande opgeslagen waarde zonder te controleren of de opgeslagen waarde nog steeds hetzelfde is als toen het bericht oorspronkelijk werd verzonden. Configureer Service Bus-wachtrijen om dubbele berichten automatisch te verwijderen. Zie Idempotent message processing (Idempotent message processing) voor meer informatie.

  • Sommige berichtensystemen, zoals Azure Storage-wachtrijen en Service Bus-wachtrijen, ondersteunen een eigenschap voor het aantal wachtrijen die aangeeft hoe vaak een bericht uit de wachtrij wordt gelezen. Deze gegevens zijn handig voor het verwerken van herhaalde berichten en gifberichten. Zie Asynchrone bericht primer en Idempotentiepatronen voor meer informatie.

Taken schaalbaar maken

Achtergrondtaken moeten voldoende prestaties bieden om ervoor te zorgen dat ze de toepassing niet blokkeren of de bewerking vertragen wanneer het systeem wordt belast. De prestaties worden doorgaans verbeterd wanneer u de rekeninstanties schaalt die als host fungeren voor de achtergrondtaken. Houd rekening met de volgende punten met betrekking tot schaalbaarheid en prestaties wanneer u achtergrondtaken plant en ontwerpt:

  • Azure Virtual Machines en de functie Web Apps van Azure-app Service kunnen implementaties hosten. Ze ondersteunen automatisch schalen, zowel uitschalen als inschalen. De automatische schaalaanpassing wordt bepaald door de vraag en belasting of een vooraf gedefinieerd schema. Gebruik automatisch schalen om ervoor te zorgen dat de toepassing over voldoende prestatiemogelijkheden beschikt en tegelijkertijd de runtimekosten minimaliseert.

  • Sommige achtergrondtaken hebben een andere prestatiemogelijkheid in vergelijking met andere onderdelen van een toepassing, zoals de gebruikersinterface of onderdelen, zoals de gegevenstoegangslaag. In dat scenario host u de achtergrondtaken in een afzonderlijke rekenservice, zodat de gebruikersinterface en achtergrondtaken onafhankelijk kunnen worden geschaald om de belasting te beheren. Als meerdere achtergrondtaken aanzienlijk verschillende prestatiemogelijkheden hebben, verdeelt u deze en schaalt u elk type afzonderlijk. Deze techniek kan de runtimekosten verhogen.

  • Om te voorkomen dat de prestaties onder belasting verloren gaan, moet u mogelijk ook opslagwachtrijen en andere resources schalen, zodat een enkel punt van de verwerkingsketen geen knelpunt veroorzaakt. Overweeg andere beperkingen, zoals de maximale doorvoer van opslag en andere services waarvan de toepassing en de achtergrondtaken afhankelijk zijn.

  • Ontwerp achtergrondtaken voor schalen. Achtergrondtaken moeten bijvoorbeeld het aantal gebruikte opslagwachtrijen dynamisch detecteren om berichten te bewaken of berichten naar de juiste wachtrij te verzenden.

  • Standaard wordt een webtaak geschaald met het bijbehorende Web Apps-exemplaar. Als u echter wilt dat een webtaak wordt uitgevoerd als slechts één exemplaar, kunt u een Settings.job-bestand maken dat de JSON-gegevens { "is_singleton": true }bevat. Met deze methode dwingt Azure slechts één exemplaar van de webtaak uit te voeren, zelfs als er meerdere exemplaren van de gekoppelde web-app zijn. Deze techniek is handig voor geplande taken die slechts als één exemplaar moeten worden uitgevoerd.

  • Achtergrondtaken kunnen uitdagingen opleveren voor gegevenssynchronisatie en procescoördinatie, met name als de achtergrondtaken van elkaar of van andere gegevensbronnen afhankelijk zijn. Achtergrondtaken kunnen bijvoorbeeld problemen met gegevensconsistentie, racevoorwaarden, impasses of time-outs afhandelen.

  • Achtergrondtaken kunnen van invloed zijn op de gebruikerservaring als de resultaten van de achtergrondtaken aan de gebruiker worden gepresenteerd. Voor achtergrondtaken moet de gebruiker bijvoorbeeld wachten op een melding, de pagina vernieuwen of de status van de taak handmatig controleren. Dit gedrag kan de complexiteit van de gebruikersinteractie vergroten en de gebruikerservaring negatief beïnvloeden.

Compromis: achtergrondtaken introduceren meer onderdelen en afhankelijkheden van het systeem, waardoor de complexiteit en onderhoudskosten van de oplossing kunnen worden verhoogd. Achtergrondtaken kunnen bijvoorbeeld een afzonderlijke wachtrijservice, werkservice, bewakingsservice en mechanisme voor opnieuw proberen vereisen.

Azure-facilitering

In de volgende secties worden de Azure-services beschreven die u kunt gebruiken voor het hosten, uitvoeren, configureren en beheren van achtergrondtaken.

Hostomgevingen

Er zijn verschillende Azure-platformservices die achtergrondtaken kunnen hosten:

  • Web Apps en WebJobs: gebruik de functie WebJobs van App Service om aangepaste taken uit te voeren die zijn gebaseerd op verschillende scripts of programma's die u in een web-app kunt uitvoeren.

  • Azure Functions: gebruik functie-apps voor achtergrondtaken die niet lang worden uitgevoerd. U kunt ook functie-apps gebruiken als u uw workload host op een onderbenut App Service-plan.

  • Virtuele machines: als u een Windows-service hebt of Windows Task Scheduler wilt gebruiken, moet u uw achtergrondtaken hosten op een toegewezen VM.

  • Azure Batch: Batch is een platformservice die u kunt gebruiken om rekenintensief werk te plannen voor uitvoering op een beheerde verzameling virtuele machines. Hiermee kunnen rekenresources automatisch worden geschaald.

  • Azure Kubernetes Service (AKS):AKS biedt een beheerde hostingomgeving voor Kubernetes in Azure.

  • Azure Container Apps: Met Container Apps kunt u serverloze microservices bouwen die zijn gebaseerd op containers.

De volgende secties bevatten overwegingen voor elk van deze opties om u te helpen de beste optie voor u te kiezen.

Web Apps en WebJobs

U kunt de functie WebJobs gebruiken om aangepaste taken uit te voeren als achtergrondtaken in een web-app. Een webtaak wordt uitgevoerd als een doorlopend proces in de context van uw web-app. Een webtaak kan ook worden uitgevoerd als reactie op een trigger-gebeurtenis van Logic Apps of externe factoren, zoals wijzigingen in opslagblobs of berichtenwachtrijen. WebJobs kunnen op aanvraag worden gestart en gestopt en correct worden afgesloten. Als een continu uitgevoerde webtaak mislukt, wordt deze automatisch opnieuw gestart. U kunt acties voor opnieuw proberen en fouten configureren.

Wanneer u een webtaak configureert, geldt het volgende:

  • Als u wilt dat de taak reageert op een gebeurtenisgestuurde trigger, configureert u deze zo dat deze continu wordt uitgevoerd. Het script of programma wordt opgeslagen in de map met de naam site/wwwroot/app_data/jobs/continuous.

  • Als u wilt dat de taak reageert op een schemagestuurde trigger, configureert u deze zo dat deze volgens een schema wordt uitgevoerd. Het script of het programma wordt opgeslagen in de map site/wwwroot/app_data/jobs/triggered.

  • Als u de optie Uitvoeren op aanvraag kiest wanneer u een taak configureert, wordt dezelfde code uitgevoerd als de optie Uitvoeren volgens een planning wanneer u de taak start.

Een webtaak wordt uitgevoerd in de sandbox van de web-app. Het heeft toegang tot omgevingsvariabelen en kan informatie, zoals verbindingsreeks s, delen met de web-app. De webtaak heeft toegang tot de unieke id van de computer waarop de webtaak wordt uitgevoerd. De verbindingsreeks met de naam AzureWebJobsStorage biedt toegang tot Opslagwachtrijen, blobs en tabellen voor toepassingsgegevens. Het biedt ook toegang tot Service Bus voor berichten en communicatie. De verbindingsreeks met de naam AzureWebJobsDashboard biedt toegang tot de logboekbestanden van de webtaakactie.

WebJobs hebben de volgende kenmerken:

  • Beveiliging: De implementatiereferenties van de web-app bieden beveiliging voor WebJobs.

  • Ondersteunde bestandstypen: WebJobs definiëren met behulp van opdrachtscripts (.cmd), batchbestanden (.bat), PowerShell-scripts (.ps1), Bash-shellscripts (.sh), PHP-scripts (.php), Python-scripts (.py), JavaScript-code (.js) en uitvoerbare programma's (.exe en .jar).

  • Implementatie: U kunt scripts en uitvoerbare bestanden implementeren met behulp van Azure Portal, Visual Studio of de WebJobs SDK, of u kunt ze rechtstreeks naar de volgende locaties kopiëren:

    • Voor geactiveerde implementatie: site/wwwroot/app_data/jobs/triggered/<job name>

    • Voor continue implementatie: site/wwwroot/app_data/jobs/continuous/<job name>

  • Logboekbestanden: Console.Out wordt behandeld of gemarkeerd als INFO. Console.Error wordt behandeld als ERROR. Gebruik de portal voor toegang tot bewakings- en diagnostische gegevens. Download logboekbestanden rechtstreeks vanaf de website. Logboekbestanden worden op de volgende locaties opgeslagen:

    • Voor geactiveerde implementatie: Vfs/data/jobs/triggered/<job name>

    • Voor continue implementatie: Vfs/data/jobs/continuous/<job name>

  • Configuratie: Webjobs configureren met behulp van de portal, de REST API en PowerShell. Gebruik een configuratiebestand met de naam settings.job, dat zich in dezelfde hoofdmap bevindt als het webtaakscript, om configuratiegegevens voor een webtaak op te geven. Voorbeeld:

    • { "stopping_wait_time": 60 }

    • { "is_singleton": true }

Overwegingen voor Web Apps en WebJobs

  • Webtaken worden standaard samen met de web-app geschaald. Als u WebJobs wilt configureren voor uitvoering op één exemplaar, stelt u de is_singleton configuratie-eigenschap in op true. Webtaken met één exemplaar zijn handig voor taken die u niet wilt schalen of uitvoeren als gelijktijdige meerdere exemplaren, zoals opnieuw indexeren of gegevensanalyse.

  • Als u het effect van WebJobs op de prestaties van de web-app wilt minimaliseren, maakt u een leeg exemplaar van een web-app in een nieuw App Service-plan voor het hosten van langlopende of resource-intensieve webtaken.

Azure Functions

Azure Functions is vergelijkbaar met WebJobs. Azure Functions is serverloos en is het meest geschikt voor gebeurtenisgestuurde triggers die gedurende een korte periode worden uitgevoerd. U kunt Azure Functions ook gebruiken om geplande taken uit te voeren via timertriggers als u een functie configureert die op opgegeven tijdstippen moet worden uitgevoerd.

Azure Functions wordt niet aanbevolen voor grote, langlopende taken, omdat een functie onverwachte time-outs kan veroorzaken. Afhankelijk van uw hostingabonnement kunt u echter overwegen om functies te gebruiken voor schemagestuurde triggers.

Overwegingen voor Azure Functions

Als u verwacht dat de achtergrondtaak gedurende een korte duur wordt uitgevoerd als reactie op een gebeurtenis, kunt u overwegen om de taak in het verbruiksabonnement uit te voeren. U kunt de runtime configureren tot een maximale tijd. Een functie die wordt uitgevoerd voor langere kosten. CPU-intensieve taken die meer geheugen verbruiken, kunnen duurder zijn. Als u extra triggers gebruikt voor services als onderdeel van uw taak, worden deze afzonderlijk gefactureerd.

Het Premium-abonnement is geschikt als u verschillende taken hebt die kort zijn, maar continu worden uitgevoerd. Dit abonnement is duurder omdat er meer geheugen en CPU nodig zijn. Als voordeel kunt u andere functies gebruiken, zoals integratie van virtuele netwerken.

Het toegewezen plan is geschikt voor achtergrondtaken als uw workload al wordt uitgevoerd op het toegewezen plan. Als u niet-gebruikte VM's hebt, kunt u het toegewezen abonnement uitvoeren op dezelfde VIRTUELE machine en rekenkosten delen.

Zie voor meer informatie:

Virtual Machines

U kunt achtergrondtaken implementeren zodat ze niet worden geïmplementeerd in Web Apps. U kunt bijvoorbeeld taken implementeren met behulp van Windows-services, hulpprogramma's van derden of uitvoerbare programma's. U kunt ook programma's gebruiken die zijn geschreven voor een runtime-omgeving die anders is dan de omgeving die als host fungeert voor de toepassing. U kunt bijvoorbeeld een Unix- of Linux-programma gebruiken dat u wilt uitvoeren vanuit een Windows- of .NET-toepassing. Kies uit verschillende besturingssystemen voor een Azure-VM en voer uw service of uitvoerbaar bestand uit op die VM.

Zie voor meer informatie:

Als u de achtergrondtaak in een afzonderlijke VIRTUELE machine wilt initiëren, kunt u het volgende doen:

  • Verzend een aanvraag naar een eindpunt dat de taak op aanvraag beschikbaar maakt om de taak rechtstreeks vanuit uw toepassing uit te voeren. De aanvraag draagt gegevens over die de taak nodig heeft. Het eindpunt roept de taak aan.

  • Gebruik een scheduler of timer van uw gekozen besturingssysteem om de taak te configureren voor uitvoering volgens een schema. In Windows kunt u bijvoorbeeld Windows Task Scheduler gebruiken om scripts en taken uit te voeren. Als u SQL Server op de VIRTUELE machine hebt geïnstalleerd, gebruikt u SQL Server Agent om scripts en taken uit te voeren.

  • Gebruik Logic Apps om de taak te initiëren door een bericht toe te voegen aan een wachtrij die door de taak wordt bewaakt of door een aanvraag te verzenden naar een API die door de taak wordt weergegeven.

Zie de vorige sectie Triggers voor meer informatie over hoe u achtergrondtaken kunt initiëren.

Overwegingen voor virtuele machines

Houd rekening met de volgende punten wanneer u achtergrondtaken implementeert in een Azure-VM:

  • Host achtergrondtaken in een afzonderlijke Azure-VM om flexibiliteit en nauwkeurige controle te bieden over het starten, implementeren, plannen en toewijzen van resources. De runtimekosten nemen echter toe als u alleen een VIRTUELE machine implementeert voor achtergrondtaken.

  • Er is geen mogelijkheid om de taken in de portal te bewaken en er is geen mogelijkheid om de taken automatisch opnieuw op te starten voor mislukte taken. Maar u kunt de Azure Resource Manager-cmdlets gebruiken om de status van de virtuele machine te bewaken en te beheren. Er zijn geen faciliteiten voor het beheren van processen en threads in rekenknooppunten. Als u een virtuele machine gebruikt, moet u doorgaans een mechanisme implementeren dat gegevens verzamelt uit instrumentatie in de taak en ook van het besturingssysteem in de VIRTUELE machine. Hiervoor kunt u het System Center Management Pack voor Azure gebruiken.

  • Overweeg om bewakingstests te maken die beschikbaar zijn via HTTP-eindpunten. U kunt de code voor deze tests configureren om statuscontroles uit te voeren en operationele informatie en statistieken te verzamelen. U kunt de tests ook gebruiken om foutgegevens samen te vouwen en terug te keren naar een beheertoepassing.

Zie voor meer informatie:

Batch

Overweeg Batch als u grote, parallelle HPC-workloads (High Performance Computing) moet uitvoeren op tientallen, honderden of duizenden VM's.

Gebruik Batch om de VM's voor te bereiden, taken toe te wijzen aan de VM's, de taken uit te voeren, de voortgang te bewaken en de VM's automatisch uit te schalen als reactie op de workload. Batch biedt ook taakplanning en ondersteunt Linux- en Windows-VM's.

Batchoverwegingen

Batch is geschikt voor intrinsiek parallelle workloads. U kunt Batch gebruiken om parallelle berekeningen uit te voeren met een reductiestap aan het einde of MPI-toepassingen (Message Passing Interface) uit te voeren voor parallelle taken waarvoor berichten tussen knooppunten moeten worden doorgegeven.

Een Batch-taak wordt uitgevoerd op een pool met knooppunten of VM's. U kunt een pool alleen toewijzen wanneer dat nodig is en deze vervolgens verwijderen nadat de taak is voltooid. Deze benadering maximaliseert het gebruik omdat knooppunten niet inactief zijn, maar de taak moet wachten tot u knooppunten toewijst. U kunt ook van tevoren een pool maken. Deze aanpak minimaliseert de tijd die nodig is om een taak te starten, maar kan leiden tot knooppunten die niet actief zijn.

Zie voor meer informatie:

Azure Kubernetes Service

Gebruik AKS om uw gehoste Kubernetes-omgeving te beheren, zodat u eenvoudig containertoepassingen kunt implementeren en beheren.

Containers zijn handig voor het uitvoeren van achtergrondtaken. Dit zijn enkele voordelen:

  • Containers ondersteunen hosting met hoge dichtheid. Bij het plaatsen van meerdere containers in elke virtuele machine kunt u een achtergrondtaak in een container isoleren.

  • Gebruik de containerorchestrator om interne taakverdeling uit te voeren, het interne netwerk te configureren en andere configuratietaken uit te voeren.

  • U kunt containers zo nodig starten en stoppen.

  • Met Azure Container Registry kunt u uw containers binnen Azure-grenzen registreren om beveiligings-, privacy- en nabijheidsvoordelen te bieden.

Overwegingen voor AKS

AKS vereist een goed begrip van het gebruik van een containerorchestrator.

Zie voor meer informatie:

Container Apps

Met Container Apps kunt u serverloze microservices bouwen die zijn gebaseerd op containers. Container Apps:

  • Is geoptimaliseerd voor het uitvoeren van containers voor algemeen gebruik, met name toepassingen die veel microservices omvatten die zijn geïmplementeerd in containers.

  • Wordt mogelijk gemaakt door Kubernetes en opensource-technologieën, zoals Dapr, Kubernetes Event Driven Autoscaling (KEDA) en Envoy.

  • Ondersteunt Kubernetes-apps en microservices met functies zoals servicedetectie en het splitsen van verkeer.

  • Maakt gebeurtenisgestuurde toepassingsarchitecturen mogelijk door ondersteuning te bieden voor schalen op basis van verkeer en het ophalen van gebeurtenisbronnen zoals wachtrijen, waaronder schalen naar nul.

  • Ondersteunt langlopende processen en kan achtergrondtaken uitvoeren.

Overwegingen voor Container Apps

Container Apps biedt geen directe toegang tot de onderliggende Kubernetes-API's. Als u toegang tot de Kubernetes-API's en het besturingsvlak nodig hebt, gebruikt u AKS. Als u Kubernetes-toepassingen wilt bouwen en u geen directe toegang nodig hebt tot de systeemeigen Kubernetes-API's en clusterbeheer, gebruikt u Container Apps voor een volledig beheerde ervaring. Container Apps is het meest geschikt voor het bouwen van containermicroservices.

Zie voor meer informatie:

Controlelijst voor betrouwbaarheid

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor betrouwbaarheid