Condividi tramite

Suggerimenti per lo sviluppo di processi in background

  • Articolo

Si applica a questa raccomandazione per l'affidabilità del framework ben progettato di Azure:

RE:07 Rafforzare la resilienza e la recuperabilità del carico di lavoro implementando misure di auto-conservazione e riparazione automatica. Creare funzionalità nella soluzione usando modelli di affidabilità basati sull'infrastruttura e modelli di progettazione basati su software per gestire gli errori dei componenti e gli errori temporanei. Creare funzionalità nel sistema per rilevare gli errori dei componenti della soluzione e avviare automaticamente un'azione correttiva mentre il carico di lavoro continua a funzionare con funzionalità complete o ridotte.

Guide correlate: Errori | temporanei di conservazione automatica

Questa guida descrive le raccomandazioni per lo sviluppo di processi in background. I processi in background vengono eseguiti automaticamente senza necessità di interazione dell'utente. Molte applicazioni richiedono processi in background che vengono eseguiti indipendentemente dall'interfaccia utente.

Alcuni esempi di processi in background includono processi batch, attività di elaborazione intensiva e processi a esecuzione prolungata, ad esempio flussi di lavoro. L'applicazione avvia il processo ed elabora richieste interattive dagli utenti. Ad esempio, se un'applicazione deve generare anteprime di immagini caricate dagli utenti, è possibile eseguire un processo in background per generare l'anteprima e salvarla nella risorsa di archiviazione. L'utente non deve attendere il completamento del processo. Come altro esempio, un cliente effettua un ordine, che avvia un flusso di lavoro in background che elabora l'ordine. Il cliente continua a esplorare l'app Web durante l'esecuzione del processo in background. Al termine del processo in background, aggiorna i dati dell'ordine archiviato e invia un messaggio di posta elettronica al cliente per confermare l'ordine.

I processi in background consentono di ridurre al minimo il carico sull'interfaccia utente dell'applicazione, migliorando così la disponibilità e abbreviando il tempo di risposta interattiva.

Strategie di progettazione chiave

Per scegliere quale attività designare come processo in background, valutare se l'attività viene eseguita senza interazione dell'utente e se l'interfaccia utente deve attendere il completamento dell'attività. Le attività che richiedono l'attesa dell'utente o dell'interfaccia utente durante l'esecuzione non sono in genere processi in background appropriati.

Valutare la necessità di processi in background

Ecco alcuni esempi di processi in background:

  • Processi con uso intensivo della CPU, come calcoli matematici o analisi di modelli strutturali.

  • Processi con utilizzo intensivo di I/O, ad esempio l'esecuzione di una serie di transazioni di archiviazione o file di indicizzazione.

  • Processi batch, come gli aggiornamenti dei dati nelle ore notturne o l'elaborazione pianificata.

  • Flussi di lavoro a esecuzione prolungata, ad esempio l'evasione degli ordini o i servizi e i sistemi di provisioning.

  • Elaborazione di dati sensibili che trasferisce l'attività a una posizione più sicura per l'elaborazione. Ad esempio, elaborare dati sensibili in un’app Web potrebbe non essere opportuno e si potrebbe preferire l'uso di un modello come il Gatekeeper per trasferire i dati a un processo in background isolato con accesso a una risorsa di archiviazione protetta.

Scegliere i trigger corretti

Avviare processi in background con:

  • Trigger basati su eventi: un evento, in genere un'azione dell'utente o un passaggio in un flusso di lavoro, attiva l'attività.

  • Trigger basati su pianificazione: una pianificazione basata su un timer richiama l'attività. Il processo può essere pianificato su base ricorrente o per una singola esecuzione.

Trigger guidati dagli eventi

Un'azione attiva una chiamata guidata dagli eventi che avvia l'attività in background. Esempi di trigger basati su eventi includono:

  • L'interfaccia utente o un processo diverso inserisce un messaggio in una coda, come descritto nello stile architetturale Web-Queue-Worker. Il messaggio contiene i dati relativi a un'azione eseguita in precedenza, ad esempio un cliente che ha effettuato un ordine. Il processo in background monitora questa coda e rileva l'arrivo di un nuovo messaggio. Legge il messaggio e usa i dati del messaggio come input per il processo in background. Questo modello è denominato comunicazione asincrona basata su messaggi.

  • L'interfaccia utente o un processo diverso salva o aggiorna un valore in archiviazione. Il processo in background monitora l'archiviazione e rileva le modifiche. Legge i dati e lo usa come input per il processo in background.

  • L'interfaccia utente o un processo diverso effettua una richiesta a un endpoint, ad esempio un URI HTTPS o un'API esposta come servizio Web. Come parte della richiesta, l'interfaccia utente o il processo trasferisce i dati richiesti dall'attività in background. Il servizio Web o l'endpoint richiama l'attività in background che usa i dati come input.

Altri esempi di attività adatte alla chiamata guidata dagli eventi includono l'elaborazione delle immagini, i flussi di lavoro, l'invio di informazioni ai servizi remoti, l'invio di messaggi di posta elettronica e il provisioning di nuovi utenti in applicazioni multi-tenant.

Trigger guidati dalla pianificazione

Un timer attiva una chiamata guidata dalla pianificazione che avvia l'attività in background. Esempi di trigger basati su pianificazione includono:

  • Un timer eseguito localmente all'interno dell'applicazione o come parte del sistema operativo dell'applicazione richiama regolarmente un'attività in background.

  • Un timer eseguito in un'applicazione diversa, ad esempio App per la logica di Azure, invia regolarmente una richiesta a un'API o a un servizio Web. Il servizio Web o l'API richiama l'attività in background.

  • Un processo o un'applicazione separata avvia un timer che richiama l'attività in background dopo un ritardo di tempo o in un momento specifico.

Altri esempi di attività adatte alla chiamata guidata dalla pianificazione includono routine di elaborazione batch (ad esempio l'aggiornamento di elenchi di prodotti correlati per i clienti in base al comportamento recente), attività di elaborazione dei dati di routine (ad esempio l'aggiornamento di indici o la generazione di risultati accumulati), l'analisi dei dati per i report giornalieri, la pulizia della conservazione dei dati e i controlli di coerenza dei dati.

Se si usa un'attività guidata dalla pianificazione che deve essere eseguita come singola istanza, esaminare le considerazioni seguenti:

  • Se l'istanza di calcolo che esegue l'utilità di pianificazione, ad esempio una macchina virtuale (VM) che usa le attività pianificate di Windows, viene ridimensionata, si eseguono più istanze dell'utilità di pianificazione. Più istanze dell'utilità di pianificazione possono avviare più istanze dell'attività. Per altre informazioni, vedere Che cosa significa idempotente nei sistemi software?

  • Se le attività vengono eseguite più a lungo del periodo tra gli eventi dell'utilità di pianificazione, l'utilità di pianificazione potrebbe avviare un'altra istanza dell'attività durante l'esecuzione dell'attività precedente.

Restituire i dati al carico di lavoro

I processi in background vengono eseguiti in modo asincrono in un processo separato, o anche in una posizione separata, dall'interfaccia utente o dal processo che ha richiamato il processo in background. Idealmente, i processi in background vengono attivati e dimenticano le operazioni. Lo stato di avanzamento del runtime non ha alcun effetto sull'interfaccia utente o sul processo chiamante, il che significa che il processo chiamante non attende il completamento delle attività. L'interfaccia utente e il processo chiamante non possono rilevare al termine dell'attività.

Se è necessaria un'attività in background per comunicare con l'attività chiamante per indicare lo stato di avanzamento o il completamento, è necessario implementare un meccanismo. Ecco alcuni esempi:

  • Scrivere un valore dell'indicatore di stato nell'archiviazione accessibile all'interfaccia utente o all'attività del chiamante, che può monitorare o controllare questo valore. Altri dati restituiti dall'attività in background al chiamante possono essere inseriti nella stessa risorsa di archiviazione.

  • Stabilire una coda di risposta monitorata dall'interfaccia utente o dal chiamante. L'attività in background può inviare messaggi alla coda che indicano lo stato. I dati restituiti dall'attività in background al chiamante possono essere inseriti nei messaggi. Per bus di servizio di Azure, usare le ReplyTo proprietà e CorrelationId per implementare questa funzionalità.

  • Esporre un'API o un endpoint dell'attività in background a cui l'interfaccia utente o il chiamante possa accedere per ottenere informazioni sullo stato. La risposta può includere i dati restituiti dall'attività in background al chiamante.

  • Configurare l'attività in background per richiamare l'interfaccia utente o il chiamante tramite un'API per indicare lo stato in punti predefiniti o al completamento. È possibile usare gli eventi generati localmente o un meccanismo di pubblicazione e sottoscrizione. La richiesta o il payload dell'evento può includere i dati restituiti dall'attività in background al chiamante.

Partizionare i processi in background

Se si includono processi in background in un'istanza di calcolo esistente, considerare il modo in cui queste modifiche influiscono sugli attributi di qualità dell'istanza di calcolo e sul processo in background. Considerare questi fattori per decidere se suddividere le attività con l'istanza di calcolo esistente o separarle in un'istanza di calcolo diversa:

  • Disponibilità: le attività in background potrebbero non richiedere lo stesso livello di disponibilità di altre parti dell'applicazione, in particolare l'interfaccia utente e le parti che coinvolgono direttamente l'interazione dell'utente. Le attività in background potrebbero avere una tolleranza maggiore per latenza, errori di connessione ripetuti e altri fattori che influiscono sulla disponibilità perché le operazioni possono essere accodate. Tuttavia, è necessario disporre di capacità sufficiente per impedire le richieste di backup che possono bloccare le code e influire sull'intera applicazione.

  • Scalabilità: le attività in background hanno probabilmente requisiti di scalabilità diversi rispetto all'interfaccia utente e alle parti interattive dell'applicazione. Potrebbe essere necessario ridimensionare l'interfaccia utente per soddisfare i picchi di domanda. Le attività in background in sospeso possono essere eseguite in momenti meno occupati e con meno istanze di calcolo.

  • Resilienza: se un'istanza di calcolo che ospita solo le attività in background ha esito negativo, potrebbe non influire in modo irreversibile sull'intera applicazione. Le richieste per queste attività possono essere accodate o posticipate fino a quando l'attività non è disponibile. Se l'istanza di calcolo o le attività possono essere riavviate entro un intervallo appropriato, potrebbe non influire sugli utenti dell'applicazione.

  • Sicurezza: le attività in background potrebbero avere requisiti di sicurezza o restrizioni diversi rispetto all'interfaccia utente o ad altre parti dell'applicazione. Usare un'istanza di calcolo separata per specificare un ambiente di sicurezza diverso per le attività. Per ottimizzare la sicurezza e la separazione, è anche possibile usare modelli come Gatekeeper per isolare le istanze di calcolo in background dall'interfaccia utente.

  • Prestazioni: scegliere il tipo di istanza di calcolo per le attività in background che soddisfano in modo specifico i requisiti di prestazioni dell'attività. È possibile usare un'opzione di calcolo meno costosa se le attività non richiedono le stesse funzionalità di elaborazione dell'interfaccia utente. In alternativa, è possibile usare un'istanza di dimensioni maggiori se le attività richiedono più capacità e risorse.

  • Gestibilità: le attività in background potrebbero avere un ritmo di sviluppo e distribuzione diverso rispetto al codice dell'applicazione principale o all'interfaccia utente. Per semplificare gli aggiornamenti e il controllo delle versioni, distribuire le attività in background in un'istanza di calcolo separata.

  • Costo: se si aggiungono istanze di calcolo per eseguire attività in background, i costi di hosting aumentano. Considerare attentamente il compromesso tra più capacità e costi aggiuntivi.

Per altre informazioni, vedere Modello di elezione leader e Modello consumer concorrenti.

Evitare conflitti di risorse

Se si dispone di più istanze di un processo in background, potrebbero competere per l'accesso a risorse e servizi, ad esempio database e archiviazione. Questo accesso simultaneo può causare conflitti di risorse, che potrebbero causare conflitti di disponibilità del servizio e danneggiare l'integrità dei dati presenti nell'archiviazione. Risolvere i conflitti di risorse usando un approccio pessimistico di blocco. Questo approccio impedisce alle istanze concorrenti di un'attività di accedere simultaneamente a un servizio o danneggiare i dati.

Un altro approccio per risolvere i conflitti consiste nel definire le attività in background come singleton, in modo che venga eseguita una sola istanza. Tuttavia, questo approccio elimina i vantaggi di affidabilità e prestazioni offerti da una configurazione a più istanze. Questo svantaggio è particolarmente vero se l'interfaccia utente fornisce un lavoro sufficiente per mantenere occupato più di un'attività in background.

Assicurarsi che l'attività in background possa essere riavviata automaticamente e che disponga di capacità sufficiente per gestire i picchi di domanda. Allocare un'istanza di calcolo con risorse sufficienti, implementare un meccanismo di accodamento che archivia le richieste da eseguire quando la domanda diminuisce o usa una combinazione di queste tecniche.

Orchestrare più attività

Le attività in background possono essere complesse e richiedere l'esecuzione di più attività. In questi scenari, è comune dividere l'attività in passaggi discreti o sottoattività più piccoli che possono essere eseguiti da più consumer. I processi con più passaggi sono più efficienti e più flessibili perché i singoli passaggi sono spesso riutilizzabili in più processi. È anche facile aggiungere, rimuovere o modificare l'ordine dei passaggi.

Può trattarsi di una sfida coordinare più attività e passaggi, ma esistono tre modelli comuni per guidare la soluzione:

  • Scomporre un'attività in più passaggi riutilizzabili. Un'applicazione potrebbe essere necessaria per eseguire varie attività di complessità diverse sulle informazioni elaborate. Un approccio semplice ma flessibile per implementare tale applicazione consiste nell'eseguire questa elaborazione come modulo monolitico. Tuttavia, questo approccio potrebbe ridurre le opportunità di refactoring del codice, ottimizzarlo o riutilizzarlo se l'applicazione richiede parti della stessa elaborazione altrove. Per altre informazioni, vedere il modello di pipe e filtri.

  • Gestire l'orchestrazione dei passaggi per un'attività. Un'applicazione può eseguire attività che comprendono molti passaggi, alcuni dei quali possono richiamare servizi remoti o accedere a risorse remote. A volte i singoli passaggi sono indipendenti l'uno dall'altro, ma vengono orchestrati dalla logica dell'applicazione che implementa l'attività. Per altre informazioni, vedere Modello di supervisione agente di pianificazione.

  • Gestire il ripristino per i passaggi dell'attività che hanno esito negativo. Se uno o più passaggi hanno esito negativo, potrebbe essere necessario annullare il lavoro eseguito da una serie di passaggi, che insieme definiscono un'operazione coerente alla fine. Per altre informazioni, vedere Modello di transazione di compensazione.

Rendere resilienti i processi

Creare attività in background resilienti per fornire servizi affidabili per l'applicazione. Quando si pianificano e progettano attività in background, tenere presenti i punti seguenti:

  • Le attività in background devono gestire correttamente i riavvii senza danneggiare i dati o introdurre incoerenze nell'applicazione. Per le attività a esecuzione prolungata o a più passaggi, è consigliabile usare i checkpoint. Usare i checkpoint per salvare lo stato dei processi nell'archiviazione permanente o come messaggi in una coda. Ad esempio, è possibile archiviare le informazioni sullo stato in un messaggio che si trova in una coda e aggiornare in modo incrementale queste informazioni sullo stato con lo stato di avanzamento dell'attività. L'attività può essere elaborata dall'ultimo checkpoint noto invece di riavviare dall'inizio.

    Per bus di servizio code, usare le sessioni di messaggio a questo scopo. Con le sessioni di messaggio, salvare e recuperare lo stato di elaborazione dell'applicazione usando i metodi SetState e GetState . Per altre informazioni sulla progettazione di processi e flussi di lavoro con più passaggi affidabili, vedere Modello supervisore agente di pianificazione.

  • Se si usano code per comunicare con le attività in background, le code possono fungere da buffer in cui archiviare le richieste inviate alle attività quando l'applicazione ha un carico maggiore del solito. Le attività possono essere aggiornate con l'interfaccia utente durante periodi meno occupati e i riavvii non bloccano l'interfaccia utente. Per altre informazioni, vedere Modello di livellamento del carico basato su coda. Se alcune attività sono più importanti di altre, è consigliabile implementare il modello di coda priorità per assicurarsi che queste attività vengano eseguite per prime.

Messaggi

Configurare le attività in background avviate dai messaggi o che elaborano i messaggi per gestire incoerenze, ad esempio messaggi che arrivano fuori ordine, messaggi che causano ripetutamente un errore (messaggi non elaborabili) e messaggi recapitati più volte. Prendi in considerazione le seguenti raccomandazioni:

  • A volte è necessario elaborare i messaggi in un ordine specifico, ad esempio i messaggi che modificano i dati in base al valore di dati esistente, ad esempio aggiungendo un valore a un valore esistente. I messaggi non arrivano sempre nell'ordine in cui sono stati inviati. Inoltre, istanze diverse di un'attività in background possono elaborare i messaggi in un ordine diverso a causa di carichi variabili in ogni istanza.

    Per i messaggi che devono essere elaborati in un ordine specifico, includere un numero di sequenza, una chiave o un altro indicatore che le attività in background possono usare per elaborare i messaggi nell'ordine corretto. Per bus di servizio, usare sessioni di messaggi per garantire l'ordine di recapito corretto. È più efficiente progettare il processo in modo che l'ordine dei messaggi non sia importante. Per altre informazioni, vedere sequenziazione dei messaggi e timestamp.

  • In genere, un'attività in background visualizza i messaggi nella coda, che li nasconde temporaneamente ad altri consumer di messaggi. Dopo che l'attività ha elaborato correttamente il messaggio, il messaggio viene eliminato. Se un'attività in background ha esito negativo quando elabora un messaggio, il messaggio viene visualizzato nuovamente nella coda dopo la scadenza del timeout di visualizzazione. Un'istanza diversa dell'attività elabora il messaggio o il successivo ciclo di elaborazione dell'istanza originale elabora il messaggio.

    Se il messaggio causa in modo coerente un errore nel consumer, blocca l'attività, la coda e infine l'applicazione stessa quando la coda diventa piena. È fondamentale rilevare e rimuovere messaggi non elaborabili dalla coda. Se si usa bus di servizio, spostare automaticamente o manualmente i messaggi non elaborabili in una coda di messaggi non recapitabili associata.

  • Le code sono meccanismi di recapito di almeno una volta , ma possono recapitare lo stesso messaggio più volte. Se un'attività in background non riesce dopo l'elaborazione di un messaggio, ma prima di eliminarla dalla coda, il messaggio sarà nuovamente disponibile per l'elaborazione.

    Le attività in background devono essere idempotenti, il che significa che quando l'attività elabora lo stesso messaggio più di una volta, non causa un errore o un'incoerenza nei dati dell'applicazione. Alcune operazioni sono naturalmente idempotenti, ad esempio se un valore archiviato è impostato su un nuovo valore specifico. Tuttavia, alcune operazioni causano incoerenze, ad esempio se un valore viene aggiunto a un valore archiviato esistente senza verificare che il valore archiviato sia ancora uguale a quando il messaggio è stato originariamente inviato. Configurare bus di servizio code per rimuovere automaticamente i messaggi duplicati. Per altre informazioni, vedere Elaborazione dei messaggi Idempotenti.

  • Alcuni sistemi di messaggistica, ad esempio Archiviazione di Azure code e code bus di servizio, supportano una proprietà conteggio di rimozione dalla coda che indica quante volte viene letto un messaggio dalla coda. Questi dati sono utili per gestire messaggi ripetuti e messaggi non elaborabili. Per altre informazioni, vedere Introduzione alla messaggistica asincrona e Modelli di Idempotenza.

Rendere scalabili i processi

Le attività in background devono offrire prestazioni sufficienti per non bloccare l'applicazione o ritardare le operazioni quando il sistema è in condizioni di carico. In genere, le prestazioni migliorano quando si ridimensionano le istanze di calcolo che ospitano le attività in background. Quando si pianificano e progettano attività in background, considerare i punti seguenti correlati alla scalabilità e alle prestazioni:

  • Azure Macchine virtuali e la funzionalità di App Web del servizio app Azure possono ospitare distribuzioni. Supportano il ridimensionamento automatico, scalabilità orizzontale e scalabilità orizzontale. Il ridimensionamento automatico è determinato dalla domanda e dal carico o da una pianificazione predefinita. Usare il ridimensionamento automatico per garantire che l'applicazione abbia funzionalità di prestazioni sufficienti riducendo al minimo i costi di runtime.

  • Alcune attività in background hanno una funzionalità di prestazioni diversa rispetto ad altre parti di un'applicazione, ad esempio l'interfaccia utente o i componenti, ad esempio il livello di accesso ai dati. In questo scenario, ospitare le attività in background in un servizio di calcolo separato in modo che l'interfaccia utente e le attività in background possano essere ridimensionate in modo indipendente per gestire il carico. Se più attività in background hanno funzionalità di prestazioni notevolmente diverse, dividerle e ridimensionare ogni tipo in modo indipendente. Questa tecnica potrebbe aumentare i costi di runtime.

  • Per evitare la perdita di prestazioni in fase di caricamento, potrebbe anche essere necessario ridimensionare le code di archiviazione e altre risorse, in modo che un singolo punto della catena di elaborazione non causi un collo di bottiglia. Prendere in considerazione altre limitazioni, ad esempio la velocità effettiva massima di archiviazione e altri servizi su cui si basano l'applicazione e le attività in background.

  • Progettare attività in background per il ridimensionamento. Ad esempio, le attività in background devono rilevare dinamicamente il numero di code di archiviazione utilizzate per monitorare i messaggi o inviare messaggi alla coda appropriata.

  • Per impostazione predefinita, un processo Web viene ridimensionato con l'istanza di App Web associata. Tuttavia, se si vuole che un processo Web venga eseguito come una sola istanza, è possibile creare un file Settings.job contenente i dati { "is_singleton": true }JSON . Questo metodo impone ad Azure di eseguire una sola istanza del processo Web, anche se sono presenti più istanze dell'app Web associata. Questa tecnica è utile per i processi pianificati che devono essere eseguiti come una sola istanza.

  • I processi in background possono creare problemi per la sincronizzazione dei dati e il coordinamento dei processi, soprattutto se le attività in background dipendono l'una dall'altra o da altre origini dati. Ad esempio, i processi in background possono gestire problemi di coerenza dei dati, race condition, deadlock o timeout.

  • I processi in background possono influire sull'esperienza utente se i risultati delle attività in background vengono presentati all'utente. Ad esempio, i processi in background potrebbero richiedere all'utente di attendere una notifica, aggiornare la pagina o controllare manualmente lo stato dell'attività. Questi comportamenti possono aumentare la complessità dell'interazione dell'utente e influire negativamente sull'esperienza utente.

Compromesso: i processi in background introducono più componenti e dipendenze al sistema, che possono aumentare la complessità e i costi di manutenzione della soluzione. Ad esempio, i processi in background potrebbero richiedere un servizio di accodamento separato, un servizio di lavoro, un servizio di monitoraggio e un meccanismo di ripetizione dei tentativi.

Facilitazione di Azure

Le sezioni seguenti descrivono i servizi di Azure che è possibile usare per ospitare, eseguire, configurare e gestire processi in background.

Ambienti host

Esistono diversi servizi della piattaforma Azure che possono ospitare attività in background:

  • App Web e processi Web: usare la funzionalità Processi Web di servizio app per eseguire processi personalizzati basati su script o programmi diversi che è possibile eseguire in un'app Web.

  • Funzioni di Azure: usare le app per le funzioni per i processi in background che non vengono eseguiti per molto tempo. È anche possibile usare le app per le funzioni se si ospita il carico di lavoro in un piano di servizio app sottoutilizzato.

  • Macchine virtuali: se si dispone di un servizio Windows o si vuole usare l'Utilità di pianificazione di Windows, ospitare le attività in background in una macchina virtuale dedicata.

  • Azure Batch: Batch è un servizio di piattaforma che è possibile usare per pianificare l'esecuzione di lavoro a elevato utilizzo di calcolo in una raccolta gestita di macchine virtuali. Può scalare automaticamente le risorse di calcolo.

  • servizio Azure Kubernetes (servizio Azure Kubernetes): il servizio Azure Kubernetes fornisce un ambiente di hosting gestito per Kubernetes in Azure.

  • App Contenitore di Azure: con le app contenitore è possibile creare microservizi serverless basati su contenitori.

Le sezioni seguenti forniscono considerazioni per ognuna di queste opzioni che consentono di scegliere l'opzione migliore.

App Web e processi Web

È possibile usare la funzionalità Processi Web per eseguire processi personalizzati come processi in background in un'app Web. Un processo Web viene eseguito come processo continuo nel contesto dell'app Web. Un processo Web può essere eseguito anche in risposta a un evento trigger da App per la logica o da fattori esterni, ad esempio modifiche ai BLOB di archiviazione o alle code di messaggi. I processi Web possono essere avviati e arrestati su richiesta e arrestati normalmente. Se un processo Web in esecuzione continua ha esito negativo, viene riavviato automaticamente. È possibile configurare le azioni di ripetizione dei tentativi e degli errori.

Quando si configura un processo Web:

  • Se si vuole che il processo risponda a un trigger basato su eventi, configurarlo in Esegui in modo continuo. Lo script o il programma viene archiviato nella cartella denominata site/wwwroot/app_data/jobs/continuous.

  • Se si vuole che il processo risponda a un trigger basato su pianificazione, configurarlo in Esegui in base a una pianificazione. Lo script o il programma viene archiviato nella cartella denominata site/wwwroot/app_data/jobs/triggered.

  • Se si sceglie l'opzione Esegui su richiesta quando si configura un processo, viene eseguito lo stesso codice dell'opzione Esegui in base a una pianificazione quando si avvia il processo.

Un processo Web viene eseguito nella sandbox dell'app Web. Ha accesso alle variabili di ambiente e può condividere informazioni, ad esempio stringa di connessione, con l'app Web. Il processo Web ha accesso all'identificatore univoco del computer che esegue il processo Web. Il stringa di connessione denominato AzureWebJobsStorage fornisce l'accesso a code, BLOB e tabelle di archiviazione per i dati dell'applicazione. Fornisce inoltre l'accesso a bus di servizio per la messaggistica e la comunicazione. Il stringa di connessione denominato AzureWebJobsDashboard fornisce l'accesso ai file di log delle azioni del processo Web.

I processi Web presentano le caratteristiche seguenti:

  • Sicurezza: le credenziali di distribuzione dell'app Web forniscono protezione per i processi Web.

  • Tipi di file supportati: definire processi Web usando script di comando (.cmd), file batch (.bat), script di PowerShell (ps1), script della shell Bash (.sh), script PHP (.php), script Python (.py), codice JavaScript (.js) e programmi eseguibili (.exe e .jar).

  • Distribuzione: è possibile distribuire script ed eseguibili usando il portale di Azure, Visual Studio o WebJobs SDK oppure è possibile copiarli direttamente nei percorsi seguenti:

    • Per la distribuzione attivata: site/wwwroot/app_data/jobs/triggered/<job name>

    • Per la distribuzione continua: site/wwwroot/app_data/jobs/continuous/<job name>

  • File di log: Console.Out viene trattato o contrassegnato come INFO. Console.Error viene considerato come ERROR. Usare il portale per accedere alle informazioni di monitoraggio e diagnostica. Scaricare i file di log direttamente dal sito Web. I file di log vengono salvati nei percorsi seguenti:

    • Per la distribuzione attivata: Vfs/data/jobs/triggered/<job name>

    • Per la distribuzione continua: Vfs/data/jobs/continuous/<job name>

  • Configurazione: configurare processi Web usando il portale, l'API REST e PowerShell. Usare un file di configurazione denominato settings.job, che si trova nella stessa directory radice dello script del processo Web, per fornire informazioni di configurazione per un processo Web. Ad esempio:

    • { "stopping_wait_time": 60 }

    • { "is_singleton": true }

considerazioni su App Web e processi Web

  • Per impostazione predefinita, i processi Web sono ridimensionati con l'app Web. Per configurare Processi Web da eseguire in una singola istanza, impostare la is_singleton proprietà di configurazione su true. I processi Web a istanza singola sono utili per le attività che non si desidera ridimensionare o eseguire come più istanze simultanee, ad esempio reindicizzazione o analisi dei dati.

  • Per ridurre al minimo l'effetto dei processi Web sulle prestazioni dell'app Web, creare un'istanza di app Web vuota in un nuovo servizio app pianificare l'hosting di processi Web a esecuzione prolungata o a elevato utilizzo di risorse.

Funzioni di Azure

Funzioni di Azure è simile a Processi Web. Funzioni di Azure è serverless ed è più adatto per i trigger basati su eventi eseguiti per un breve periodo. È anche possibile usare Funzioni di Azure per eseguire processi pianificati tramite trigger timer se si configura una funzione per l'esecuzione in orari specificati.

Funzioni di Azure non è consigliabile per attività di grandi dimensioni a esecuzione prolungata perché una funzione può causare timeout imprevisti. Tuttavia, a seconda del piano di hosting, prendere in considerazione l'uso di funzioni per i trigger basati su pianificazione.

Funzioni di Azure considerazioni

Se si prevede che l'attività in background venga eseguita per un breve periodo di tempo in risposta a un evento, è consigliabile eseguire l'attività nel piano a consumo. È possibile configurare il runtime su un tempo massimo. Maggiore è il tempo di esecuzione, maggiore sarà il costo della funzione. I processi a elevato utilizzo di CPU che utilizzano più memoria possono essere più costosi. Se si usano trigger aggiuntivi per i servizi come parte dell'attività, vengono fatturati separatamente.

Il piano Premium è adatto se si hanno diverse attività brevi, ma vengono eseguite continuamente. Questo piano è più costoso perché richiede più memoria e CPU. Come vantaggio, è possibile usare altre funzionalità, ad esempio l'integrazione della rete virtuale.

Il piano dedicato è adatto per i processi in background se il carico di lavoro è già in esecuzione nel piano dedicato. Se sono presenti macchine virtuali sottoutilizzate, è possibile eseguire il piano dedicato nella stessa macchina virtuale e condividere i costi di calcolo.

Per altre informazioni, vedi:

Macchine virtuali

È possibile implementare attività in background in modo che non vengano distribuite in App Web. Ad esempio, è possibile implementare attività usando servizi Windows, utilità di terze parti o programmi eseguibili. È anche possibile usare programmi scritti per un ambiente di runtime diverso dall'ambiente che ospita l'applicazione. Ad esempio, è possibile usare un programma Unix o Linux che si vuole eseguire da un'applicazione Windows o .NET. Scegliere tra diversi sistemi operativi per una macchina virtuale di Azure ed eseguire il servizio o il file eseguibile in tale macchina virtuale.

Per altre informazioni, vedi:

Per avviare l'attività in background in una macchina virtuale separata, è possibile:

  • Inviare una richiesta a un endpoint esposto dall'attività per eseguire l'attività su richiesta direttamente dall'applicazione. La richiesta trasferisce i dati richiesti dall'attività. L'endpoint richiama l'attività.

  • Usare un'utilità di pianificazione o un timer dal sistema operativo scelto per configurare l'attività da eseguire in base a una pianificazione. In Windows, ad esempio, è possibile usare Utilità di pianificazione di Windows per eseguire script e attività. Se SQL Server è installato nella macchina virtuale, usare SQL Server Agent per eseguire script e attività.

  • Usare App per la logica per avviare l'attività aggiungendo un messaggio a una coda monitorata dall'attività o inviando una richiesta a un'API esposta dall'attività.

Per altre informazioni su come avviare le attività in background, vedere la sezione Trigger precedenti.

Macchine virtuali considerazioni

Quando si distribuiscono attività in background in una macchina virtuale di Azure, tenere presente quanto segue:

  • Ospitare attività in background in una macchina virtuale di Azure separata per offrire flessibilità e controllo preciso sull'avvio, la distribuzione, la pianificazione e l'allocazione delle risorse. Tuttavia, i costi di runtime aumentano se si distribuisce una macchina virtuale esclusivamente per le attività in background.

  • Non esiste alcuna funzionalità per monitorare le attività nel portale e nessuna funzionalità di riavvio automatico per le attività non riuscite. È tuttavia possibile usare i cmdlet di Azure Resource Manager per monitorare lo stato della macchina virtuale e gestirli. Non esistono strutture per controllare i processi e i thread nei nodi di calcolo. In genere, se si usa una macchina virtuale, è necessario implementare un meccanismo che raccoglie i dati dalla strumentazione nell'attività e anche dal sistema operativo nella macchina virtuale. A questo scopo, è possibile usare il Management Pack di System Center per Azure .

  • Prendere in considerazione la creazione di probe di monitoraggio esposti tramite endpoint HTTP. È possibile configurare il codice per questi probe per eseguire controlli di integrità e raccogliere informazioni operative e statistiche. È anche possibile usare i probe per raccogliere informazioni sugli errori e restituirlo a un'applicazione di gestione.

Per altre informazioni, vedi:

Batch

Prendere in considerazione Batch se è necessario eseguire carichi di lavoro HPC (High Performance Computing) di grandi dimensioni in decine, centinaia o migliaia di macchine virtuali.

Usare Batch per preparare le macchine virtuali, assegnare attività alle macchine virtuali, eseguire le attività, monitorare lo stato di avanzamento e aumentare automaticamente le macchine virtuali in risposta al carico di lavoro. Batch fornisce anche la pianificazione dei processi e supporta macchine virtuali Linux e Windows.

Considerazioni su Batch

Batch è adatto per carichi di lavoro intrinsecamente paralleli. È possibile usare Batch per eseguire calcoli paralleli con un passaggio di riduzione alla fine oppure eseguire applicazioni MPI (Message Passing Interface) per attività parallele che richiedono il passaggio di messaggi tra nodi.

Un processo Batch viene eseguito in un pool di nodi o macchine virtuali. È possibile allocare un pool solo quando necessario e quindi eliminarlo al termine del processo. Questo approccio ottimizza l'utilizzo perché i nodi non sono inattivi, ma il processo deve attendere l'allocazione dei nodi. In alternativa, è possibile creare un pool in anticipo. Questo approccio riduce al minimo il tempo necessario per l'avvio di un processo, ma può comportare nodi inattive.

Per altre informazioni, vedi:

Servizio Azure Kubernetes

Usare il servizio Azure Kubernetes per gestire l'ambiente Kubernetes ospitato in modo da poter distribuire e gestire facilmente applicazioni in contenitori.

I contenitori sono utili per l'esecuzione di processi in background. Di seguito sono indicati alcuni dei benefit:

  • I contenitori supportano l'hosting ad alta densità. È possibile isolare un'attività in background in un contenitore, durante l'inserimento di più contenitori in una macchina virtuale.

  • Usare l'agente di orchestrazione contenitori per eseguire il bilanciamento del carico interno, configurare la rete interna ed eseguire altre attività di configurazione.

  • È possibile avviare e arrestare i contenitori in base alle esigenze.

  • Con Registro Azure Container è possibile registrare i contenitori all'interno dei limiti di Azure per offrire vantaggi in termini di sicurezza, privacy e prossimità.

Considerazioni sul servizio Azure Kubernetes

Il servizio Azure Kubernetes richiede una conoscenza dell'uso di un agente di orchestrazione del contenitore.

Per altre informazioni, vedi:

App contenitore

Con App contenitore è possibile creare microservizi serverless basati su contenitori. App contenitore:

  • È ottimizzato per l'esecuzione di contenitori per utilizzo generico, in particolare le applicazioni che si estendono su molti microservizi distribuiti nei contenitori.

  • È basato su Kubernetes e tecnologie open source, ad esempio Dapr, Kubernetes Event-driven Autoscaling (KEDA) e Envoy.

  • Supporta app e microservizi di tipo Kubernetes con funzionalità come l'individuazione dei servizi e la suddivisione del traffico.

  • Abilita le architetture di applicazioni guidate dagli eventi supportando il ridimensionamento basato sul traffico e il pull da origini eventi come code, inclusa la scalabilità a zero.

  • Supporta processi a esecuzione prolungata e può eseguire attività in background.

Considerazioni sulle app contenitore

App contenitore non fornisce l'accesso diretto alle API Kubernetes sottostanti. Se è necessario accedere alle API Kubernetes e al piano di controllo, usare il servizio Azure Kubernetes. Se si vogliono creare applicazioni di tipo Kubernetes e non è necessario l'accesso diretto alle API e alla gestione del cluster Kubernetes nativa, usare App contenitore per un'esperienza completamente gestita. App contenitore è più adatto per la compilazione di microservizi contenitore.

Per altre informazioni, vedi:

Elenco di controllo per l'affidabilità

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per l'affidabilità