Aanbevelingen voor het ontwikkelen van achtergrondtaken

  • Artikel

Van toepassing op deze aanbeveling voor de betrouwbaarheidschecklist 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 in met behulp van op infrastructuur gebaseerde betrouwbaarheidspatronen en ontwerppatronen op basis van software voor het afhandelen van onderdeelfouten en tijdelijke fouten. Bouw mogelijkheden in het systeem in om fouten met oplossingsonderdelen te detecteren en automatisch corrigerende actie te starten terwijl de workload met volledige of verminderde functionaliteit blijft werken.

Gerelateerde 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 ander voorbeeld is dat een klant een order plaatst, waarmee een achtergrondwerkstroom wordt gestart waarmee de order wordt verwerkt. De klant blijft doorbladeren in de web-app terwijl de achtergrondtaak wordt uitgevoerd. Nadat de achtergrondtaak is voltooid, worden de opgeslagen ordergegevens bijgewerkt en wordt er een e-mailbericht 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 verkort.

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 tot de taak is voltooid. Taken waarvoor de gebruiker of de gebruikersinterface moet wachten terwijl ze worden uitgevoerd, zijn doorgaans geen geschikte achtergrondtaken.

Typen achtergrondtaken

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 het afhandelen van orders of het inrichten van services en systemen.

  • Verwerking van gevoelige gegevens waarmee de taak wordt overgedragen 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.

Triggers

Achtergrondtaken starten 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 worden gepland op terugkerende basis of voor één uitvoering.

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 aankomst van een nieuw bericht. Het bericht wordt gelezen en de gegevens van het bericht gebruikt als invoer voor de achtergrondtaak. Dit patroon wordt asynchrone communicatie op basis van berichten genoemd.

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

  • De gebruikersinterface of een andere taak verzendt een aanvraag naar een eindpunt, zoals een HTTPS-URI of een API die wordt weergegeven als een webservice. Als onderdeel van de aanvraag draagt de gebruikersinterface of taak de gegevens over die de achtergrondtaak vereist. 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 aanroep op basis van een planning waarmee de achtergrondtaak wordt gestart. Voorbeelden van schemagestuurde triggers zijn:

  • Een timer die lokaal in de toepassing of als onderdeel van het besturingssysteem van de toepassing wordt uitgevoerd, 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 planningsgestuurde aanroep zijn batchverwerkingsroutines (zoals het bijwerken van lijsten met gerelateerde producten voor klanten op basis van hun recente gedrag), routinematige gegevensverwerkingstaken (zoals het bijwerken van indexen of het genereren van samengevoegde resultaten), gegevensanalyse voor dagelijkse rapporten, opschoning van gegevensretentie en controles van 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.

Resultaten retourneren

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. In het ideale instantie 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 aanroepproces kunnen niet detecteren 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, waarmee deze waarde kan worden bewaakt of gecontroleerd. Andere gegevens die de achtergrondtaak naar de aanroeper retourneert, kunnen in dezelfde opslag worden geplaatst.

  • Stel een antwoordwachtrij in die door de gebruikersinterface of beller wordt bewaakt. De achtergrondtaak kan berichten naar de wachtrij verzenden die de status aangeven. Gegevens die de achtergrondtaak naar de aanroeper retourneert, kunnen in de berichten worden geplaatst. Gebruik voor Azure Service Bus de ReplyTo eigenschappen en CorrelationId 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 retourneert naar de aanroeper.

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

Achtergrondtaken partitioneren

Als u achtergrondtaken in een bestaand rekenproces opneemt, moet 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, opnieuw geprobeerde verbindingsfouten 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 de hele toepassing kunnen beïnvloeden.

  • Schaalbaarheid: achtergrondtaken hebben waarschijnlijk andere schaalbaarheidsvereisten in vergelijking met 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 alleen achtergrondtaken host, mislukt, heeft dit mogelijk geen gevolgen voor 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 andere 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 dat specifiek overeenkomt met de prestatievereisten van de taak. U kunt een goedkopere rekenoptie gebruiken als de taken niet dezelfde verwerkingsmogelijkheden vereisen als de gebruikersinterface. U kunt ook een grotere instantie gebruiken als de taken meer capaciteit en resources vereisen.

  • Beheerbaarheid: Achtergrondtaken kunnen een ander ontwikkelings- en implementatieritme hebben dan 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. Denk goed na over de afweging tussen meer capaciteit en extra kosten.

Zie Leader Election-patroon en Patroon Concurrerende consumenten voor meer informatie.

Conflicten

Als u meerdere exemplaren van een achtergrondtaak hebt, kunnen ze concurreren om toegang tot resources en services, zoals databases en opslag. Deze gelijktijdige toegang kan leiden tot resourceconflicten, wat kan leiden tot service-beschikbaarheidsconflicten en de integriteit van de gegevens in de opslag kan schaden. Los resourceconflicten op met behulp van een pessimistische vergrendelingsbenadering. Deze benadering voorkomt dat concurrerende exemplaren van een taak gelijktijdig toegang krijgen tot een service of gegevens beschadigen.

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 betrouwbaarheids- en prestatievoordelen die een configuratie met meerdere exemplaren biedt. Dit nadeel geldt met name als de gebruikersinterface voldoende werk levert om meer dan één achtergrondtaak bezig 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 gebruik een combinatie van deze technieken.

Coördinatie

Achtergrondtaken kunnen complex zijn en vereisen dat meerdere taken worden uitgevoerd. In deze scenario's is het gebruikelijk om de taak op te delen in kleinere, discrete stappen of subtaken die meerdere gebruikers kunnen uitvoeren. Taken met meerdere stappen zijn efficiënter en flexibeler omdat afzonderlijke stappen vaak herbruikbaar zijn 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 algemene patronen voor uw oplossing:

  • Een taak opverleden in meerdere herbruikbare stappen. Een toepassing moet mogelijk verschillende taken van verschillende complexiteit uitvoeren op de informatie die wordt verwerkt. Een eenvoudige maar inflexibele benadering voor het implementeren van een dergelijke toepassing is deze verwerking uit te voeren als een monolithische module. Maar deze aanpak vermindert waarschijnlijk de mogelijkheden voor het herstructureren, optimaliseren of hergebruiken van de code als de toepassing delen van dezelfde verwerking elders vereist. Zie het patroon Pipes and Filters (Pijpen en filters) voor meer informatie.

  • De indeling van de stappen voor een taak beheren. Een toepassing kan taken uitvoeren die uit veel stappen bestaan, waarvan sommige externe services kunnen aanroepen of toegang kunnen krijgen 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 een reeks stappen uitvoert, waardoor samen een uiteindelijk consistente bewerking wordt gedefinieerd. Zie Patroon compenserende transactie voor meer informatie.

Overwegingen voor tolerantie

Maak tolerante achtergrondtaken om betrouwbare services voor de toepassing te bieden. Houd bij het plannen en ontwerpen van achtergrondtaken rekening met de volgende punten:

  • Achtergrondtaken moeten opnieuw opstarten probleemloos afhandelen zonder gegevens te beschadigen of inconsistentie in de toepassing te introduceren. Voor langdurige taken of taken met meerdere rijen kunt u het gebruik van controlepunten overwegen. Gebruik controlepunten om de status van taken op te slaan in de permanente opslag of als berichten in een wachtrij. U kunt bijvoorbeeld statusgegevens opslaan in een bericht in een wachtrij en deze statusgegevens stapsgewijs bijwerken met de voortgang van de taak. De taak kan worden verwerkt vanaf het laatst bekende controlepunt in plaats van opnieuw 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 stappen.

  • 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 wanneer de gebruikersinterface opnieuw wordt gestart, wordt de gebruikersinterface niet geblokkeerd. Zie Load Leveling-patroon op basis van wachtrij voor meer informatie. Als sommige taken belangrijker zijn dan andere, kunt u overwegen het patroon Priority Queue te implementeren om ervoor te zorgen dat deze taken eerst worden uitgevoerd.

Berichten

Achtergrondtaken configureren die worden geïnitieerd door berichten of die berichten verwerken om inconsistenties af te handelen, zoals berichten die niet in de juiste volgorde binnenkomen, 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 voor elk exemplaar.

    Voor berichten die in een specifieke volgorde moeten worden verwerkt, voegt u een volgnummer, sleutel of een andere indicator toe die achtergrondtaken kunnen gebruiken om berichten in de juiste volgorde te verwerken. Gebruik voor Service Bus berichtsessies om de juiste volgorde van bezorging te garanderen. Het is efficiënter om het proces zo te ontwerpen dat 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 in de wachtrij weergegeven nadat de time-out voor het bekijken 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, verplaatst u automatisch of handmatig gifberichten naar een bijbehorende wachtrij met onbestelbare berichten.

  • Wachtrijen zijn at-least-once delivery-mechanismen, maar ze kunnen hetzelfde bericht meer dan één keer afleveren. Als een achtergrondtaak mislukt nadat een bericht is verwerkt, maar voordat het uit de wachtrij is verwijderd, kan het bericht opnieuw worden verwerkt.

    Achtergrondtaken moeten idempotent zijn, wat betekent dat wanneer de taak hetzelfde bericht meerdere keren verwerkt, dit geen fout of inconsistentie in de gegevens van de toepassing veroorzaakt. Sommige bewerkingen zijn van nature 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. Service Bus-wachtrijen configureren om dubbele berichten automatisch te verwijderen. Zie Idempotent berichtverwerking voor meer informatie.

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

Overwegingen bij schalen en prestaties

Achtergrondtaken moeten voldoende prestaties bieden om ervoor te zorgen dat ze de toepassing niet blokkeren of de bewerking vertragen wanneer het systeem wordt belast. Doorgaans verbeteren de prestaties wanneer u de rekeninstanties schaalt die als host fungeren voor de achtergrondtaken. Houd bij het plannen en ontwerpen van achtergrondtaken rekening met de volgende punten met betrekking tot schaalbaarheid en prestaties:

  • Azure Virtual Machines en de Web Apps-functie 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 dan andere onderdelen van een toepassing, bijvoorbeeld de gebruikersinterface of onderdelen, zoals de gegevenstoegangslaag. In dat scenario host u de achtergrondtaken samen 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, moet u ze verdelen en elk type afzonderlijk schalen. Deze techniek kan de runtimekosten verhogen.

  • Om te voorkomen dat de prestaties onder belasting afnemen, moet u mogelijk ook opslagwachtrijen en andere resources schalen, zodat één punt van de verwerkingsketen geen knelpunt veroorzaakt. Houd rekening met andere beperkingen, zoals de maximale doorvoer van opslag en andere services waarvan de toepassing en de achtergrondtaken afhankelijk zijn.

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

  • Standaard wordt een webtaak geschaald met de bijbehorende Web Apps exemplaar. Als u echter wilt dat een webtaak slechts als één exemplaar wordt uitgevoerd, kunt u een Settings.job-bestand maken dat de JSON-gegevens { "is_singleton": true }bevat. Deze methode dwingt Azure af om 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 afhankelijk zijn van elkaar of van andere gegevensbronnen. Achtergrondtaken kunnen bijvoorbeeld problemen met gegevensconsistentie, racevoorwaarden, impasses of time-outs verwerken.

  • Achtergrondtaken kunnen van invloed zijn op de gebruikerservaring als de resultaten van de achtergrondtaken aan de gebruiker worden gepresenteerd. Achtergrondtaken kunnen bijvoorbeeld vereisen dat de gebruiker op een melding wacht, de pagina vernieuwt of de status van de taak handmatig controleert. Dit gedrag kan de complexiteit van de gebruikersinteractie vergroten en de gebruikerservaring negatief beïnvloeden.

Afweging: Achtergrondtaken introduceren meer onderdelen en afhankelijkheden in het systeem, waardoor de complexiteit en onderhoudskosten van de oplossing kunnen toenemen. Achtergrondtaken kunnen bijvoorbeeld een afzonderlijke wachtrijservice, werkrolservice, 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 webtaken: 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 lange tijd niet worden uitgevoerd. U kunt ook functie-apps gebruiken als u uw workload host op een onderbenut App Service-abonnement.

  • Virtual Machines: Als u een Windows-service hebt of Windows Task Scheduler wilt gebruiken, host u uw achtergrondtaken in een toegewezen VM.

  • Azure Batch: Batch is een platformservice die u kunt gebruiken om rekenintensief werk te plannen voor uitvoering op een beheerde verzameling vm's. 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 webtaken

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 probleemloos worden afgesloten. Als een continu actieve webtaak mislukt, wordt deze automatisch opnieuw opgestart. 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 op Continu uitvoeren. 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 op Uitvoeren volgens een schema. 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 schema 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 verbindingsreeksen, 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 Storage-wachtrijen, 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 webtaken.

  • Ondersteunde bestandstypen: definieer webtaken 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 de 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/<taaknaam>

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

  • 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. Logboekbestanden rechtstreeks van de website downloaden. Logboekbestanden worden opgeslagen op de volgende locaties:

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

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

  • Configuratie: Configureer WebJobs 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 configuratie-informatie voor een webtaak op te geven. Bijvoorbeeld:

    • { "stopping_wait_time": 60 }

    • { "is_singleton": true }

overwegingen voor Web Apps en webtaken

  • Webtaken worden standaard samen met de web-app geschaald. Als u webtaken wilt configureren om op één exemplaar te worden uitgevoerd, 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 webtaken op de prestaties van de web-app wilt minimaliseren, maakt u een leeg exemplaar van een web-app in een nieuwe App Service langlopende of resource-intensieve webtaken wilt hosten.

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 om op opgegeven tijdstippen te 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 functies gebruiken voor schemagestuurde triggers.

Azure Functions overwegingen

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

Het Premium-abonnement is geschikt als u meerdere taken hebt die kort zijn, maar ze continu worden uitgevoerd. Dit abonnement is duurder omdat er meer geheugen en CPU voor 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 te weinig gebruikte VM's hebt, kunt u het toegewezen plan uitvoeren op dezelfde VM en de 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 Virtuele Azure-machine en voer uw service of uitvoerbare bestand uit op die VM.

Zie voor meer informatie:

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

  • Verzend een aanvraag naar een eindpunt dat de taak beschikbaar maakt om de taak rechtstreeks vanuit uw toepassing uit te voeren. Met de aanvraag worden gegevens overgedragen die voor de taak vereist zijn. Het eindpunt roept de taak aan.

  • Gebruik een planner of timer van het door u gekozen besturingssysteem om de taak zo te configureren dat deze volgens een schema wordt uitgevoerd. 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 Virtual 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 een virtuele machine alleen voor achtergrondtaken implementeert.

  • Er is geen mogelijkheid om de taken in de portal te bewaken en er is geen mogelijkheid om mislukte taken automatisch opnieuw op te starten. 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 waarmee gegevens worden verzameld van instrumentatie in de taak en ook van het besturingssysteem in de VM. Hiervoor kunt u het System Center Management Pack voor Azure gebruiken.

  • Overweeg bewakingstests te maken die beschikbaar worden gemaakt 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 foutinformatie te sorteren en terug te keren naar een beheertoepassing.

Zie voor meer informatie:

Batch

Overweeg Batch als u grote, parallelle HPC-workloads (High Performance Computing) wilt 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.

Overwegingen voor Batch

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) uitvoeren voor parallelle taken waarvoor berichtdoorgifte tussen knooppunten is vereist.

Een Batch-taak wordt uitgevoerd op een pool van 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 totdat u knooppunten hebt toegewezen. U kunt ook van tevoren een pool maken. Deze benadering minimaliseert de tijd die nodig is om een taak te starten, maar kan leiden tot knooppunten die inactief zijn.

Zie voor meer informatie:

Azure Kubernetes Service

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

Containers zijn handig voor het uitvoeren van achtergrondtaken. Enkele voordelen zijn:

  • 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 indien nodig starten en stoppen.

  • Met Azure Container Registry kunt u uw containers binnen de grenzen van Azure registreren om voordelen te bieden op het gebied van beveiliging, privacy en nabijheid.

Overwegingen bij AKS

AKS vereist inzicht in het gebruik van een container-orchestrator.

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 in containers zijn geïmplementeerd.

  • Wordt mogelijk gemaakt door Kubernetes en opensource-technologieën, zoals Dapr, Kubernetes Gebeurtenisgestuurd automatisch schalen (KEDA) en Envoy.

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

  • Maakt gebeurtenisgestuurde toepassingsarchitecturen mogelijk door ondersteuning te bieden voor schalen op basis van verkeer en ophalen uit gebeurtenisbronnen zoals wachtrijen, inclusief 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 toepassingen in Kubernetes-stijl 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