Suggerimenti per lo sviluppo di processi in background

  • Articolo

Si applica a questa raccomandazione per l'affidabilità di Azure Well-Architected Framework:

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:Manutenzione automatica degli | errori temporanei

Questa guida descrive i consigli per lo sviluppo di processi in background. I processi in background vengono eseguiti automaticamente senza la 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 intensive 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 nell'interfaccia utente dell'applicazione, migliorando la disponibilità e riducendo il tempo di risposta interattivo.

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 all'utente o all'interfaccia utente di attendere durante l'esecuzione non sono in genere processi in background appropriati.

Tipi 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 a elevato utilizzo di I/O, ad esempio l'esecuzione di una serie di transazioni di archiviazione o di indicizzazione di file.

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

Trigger

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 da 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 dell'architettura 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 nella risorsa di 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. Nell'ambito 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 basata su 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), le 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 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.

Risultati restituiti

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 eseguire il callback all'interfaccia utente o al 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 possono 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 come 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 ritentati 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 di 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 più grande se le attività richiedono una maggiore 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 attività in background in un'istanza di calcolo separata.

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

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

Conflitti

Se si dispone di più istanze di un processo in background, possono competere per l'accesso alle risorse e ai 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 che si trovano nell'archiviazione. Risolvere la contesa delle risorse usando un approccio di blocco pessimistico. 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 più attività in background occupato.

Assicurarsi che l'attività in background possa riavviare automaticamente e che abbia capacità sufficiente per gestire i picchi in richiesta. 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.

Coordinamento

Le attività in background possono essere complesse e richiedono più attività da eseguire. In questi scenari, è comune dividere l'attività in passaggi discreti più piccoli o sottotask che più consumer possono eseguire. I processi multistep 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ò essere una sfida per coordinare più attività e passaggi, ma esistono tre modelli comuni per guidare la soluzione:

  • Decomponere 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 inflessibile 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 alle risorse remote. A volte i singoli passaggi sono indipendenti tra loro, 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 delle attività che hanno esito negativo. Se uno o più passaggi hanno esito negativo, un'applicazione potrebbe dover annullare il lavoro eseguito da una serie di passaggi, che insieme definisce un'operazione coerente. Per altre informazioni, vedere Modello di transazione di compensazione.

Considerazioni sulla resilienza

Creare attività in background resilienti per fornire servizi affidabili per l'applicazione. Quando si pianificano e progettano attività in background, prendere in considerazione 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 multisegua, è consigliabile usare i checkpoint. Usare i checkpoint per salvare lo stato dei processi nell'archiviazione persistente o come messaggi in una coda. Ad esempio, è possibile archiviare le informazioni sullo stato in un messaggio presente 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 anziché riavviare dall'inizio.

    Per le code del bus di servizio, usare sessioni di messaggio per 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 multistep affidabili, vedere Modello di 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 recuperare l'interfaccia utente durante periodi meno occupati e i riavvii non bloccano l'interfaccia utente. Per altre informazioni, vedere Modello di bilanciamento del carico basato su coda. Se alcune attività sono più importanti di altre, è consigliabile implementare il modello di coda di priorità per assicurarsi che queste attività vengano eseguite prima.

Messaggi

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

  • A volte è necessario elaborare 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, diverse istanze di un'attività in background potrebbero 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 il bus di servizio, usare sessioni di messaggio 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 da altri consumer di messaggi. Dopo aver elaborato correttamente il messaggio, l'attività elimina il messaggio. Se un'attività in background ha esito negativo quando elabora un messaggio, tale messaggio viene visualizzato nella coda dopo la scadenza del timeout di anteprima. Un'istanza diversa dell'attività elabora il messaggio o il ciclo di elaborazione successivo 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 elaborati dalla coda. Se si usa il bus di servizio, spostare automaticamente o manualmente i messaggi non aggiornati in una coda di messaggi non recapitabili associati.

  • Le code sono meccanismi di recapito almeno una volta , ma potrebbero recapitare più volte lo stesso messaggio. Se un'attività in background ha esito negativo dopo aver elaborato un messaggio ma prima di eliminarla dalla coda, il messaggio è disponibile di nuovo per l'elaborazione.

    Le attività in background devono essere idempotenti, ovvero quando l'attività elabora lo stesso messaggio più di una volta, non causa un errore o una 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 le code del bus di servizio per rimuovere automaticamente i messaggi duplicati. Per altre informazioni, vedere Elaborazione dei messaggi Idempotente.

  • Alcuni sistemi di messaggistica, ad esempio code di archiviazione di Azure e code del bus di servizio, supportano una proprietà conteggio dequeue che indica il numero di volte in cui viene letto un messaggio dalla coda. Questi dati sono utili per la gestione di messaggi ripetuti e messaggi non elaborati. Per altre informazioni, vedere Introduzione alla messaggistica asincrona e modelli di Idempotenza.

Considerazioni su ridimensionamento e prestazioni

Le attività in background devono offrire prestazioni sufficienti per assicurarsi che non blocchino l'operazione dell'applicazione o del ritardo quando il sistema è in 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, prendere in considerazione i punti seguenti correlati alla scalabilità e alle prestazioni:

  • Azure Macchine virtuali e la funzionalità App Web di Servizio app di Azure possono ospitare distribuzioni. Supportano la scalabilità automatica, sia il ridimensionamento orizzontale che il ridimensionamento. Il ridimensionamento automatico è determinato dalla domanda e dal carico o da una pianificazione predefinita. Usare il ridimensionamento automatico per garantire che l'applicazione disponga di 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 ridimensionare in modo indipendente per gestire il carico. Se più attività in background hanno funzionalità di prestazioni significativamente diverse, dividerle e ridimensionare ogni tipo in modo indipendente. Questa tecnica potrebbe aumentare i costi di runtime.

  • Per evitare la perdita delle prestazioni in carico, potrebbe anche essere necessario ridimensionare le code di archiviazione e altre risorse in modo che un singolo punto della catena di elaborazione non causa un collo di bottiglia. Prendere in considerazione altre limitazioni, ad esempio la velocità effettiva massima di archiviazione e altri servizi basati sull'applicazione e sulle 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 usate 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 unica istanza, è possibile creare un file Settings.job contenente i dati { "is_singleton": true }JSON . Questo metodo impone ad Azure di eseguire solo un'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 sfide per la sincronizzazione dei dati e il coordinamento dei processi, soprattutto se le attività in background dipendono tra loro o da altre origini dati. Ad esempio, i processi in background possono gestire problemi di coerenza dei dati, condizioni di gara, deadlock o timeout.

  • I processi in background potrebbero 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 coda separato, servizio di lavoro, servizio di monitoraggio e 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 di piattaforma di 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 eseguite 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 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 il lavoro a elevato utilizzo di calcolo da eseguire in una raccolta gestita di macchine virtuali. Può scalare automaticamente le risorse di calcolo.

  • servizio Azure Kubernetes (Servizio Azure Kubernetes): servizio Azure Kubernetes offre un ambiente di hosting gestito per Kubernetes in Azure.

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

Le sezioni seguenti forniscono considerazioni su ognuna di queste opzioni per aiutarti a scegliere l'opzione migliore per te.

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 in modo normale. 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 vengono archiviati 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 su 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 stringhe 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 alle code, ai BLOB e alle tabelle di archiviazione per i dati dell'applicazione. Fornisce anche l'accesso al bus di servizio per la messaggistica e la comunicazione. L'stringa di connessione denominata AzureWebJobsDashboard fornisce l'accesso ai file di log delle azioni web.

I processi Web hanno le caratteristiche seguenti:

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

  • Tipi di file supportati: Definire processi Web usando script di comando (con estensione cmd), file batch (.bat), script di PowerShell (.ps1), script 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 i portale di Azure, Visual Studio o WebJobs SDK oppure 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/trigger</job>

    • 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 processo Web, per fornire informazioni di configurazione per un processo Web. Ad esempio:

    • { "stopping_wait_time": 60 }

    • { "is_singleton": true }

considerazioni App Web e processi Web

  • Per impostazione predefinita, i processi Web sono ridimensionati con l'app Web. Per configurare i processi Web da eseguire in una singola istanza, impostare la is_singleton proprietà di configurazione su true. I processi Web di istanza singola sono utili per le attività che non si desidera ridimensionare o eseguire come più istanze simultanee, ad esempio reindexing 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 una nuova servizio app pianificare l'hosting di processi Web a esecuzione prolungata o a elevato utilizzo di risorse.

Funzioni di Azure

Funzioni di Azure è simile ai processi Web. Funzioni di Azure è serverless ed è più adatto per i trigger basati su eventi che vengono eseguiti per un breve periodo. È anche possibile usare Funzioni di Azure per eseguire processi pianificati tramite trigger timer se si configura una funzione da eseguire in momenti specificati.

Funzioni di Azure non è consigliato per le attività a esecuzione prolungata di grandi dimensioni 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 una breve durata in risposta a un evento, prendere in considerazione l'esecuzione dell'attività nel piano di consumo. È possibile configurare il runtime in un tempo massimo. Maggiore è il tempo di esecuzione, maggiore sarà il costo della funzione. I processi a elevato utilizzo della CPU che usano 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 si dispone di macchine virtuali sottoutilizzate, è possibile eseguire il piano dedicato nella stessa macchina virtuale e condividere i costi di calcolo.

Per altre informazioni, vedere:

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 da 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, vedere:

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. Ad esempio, in Windows è possibile usare Utilità di pianificazione di Windows per eseguire script e attività. Se nella macchina virtuale è installato SQL Server, usare SQL Server Agent per eseguire script e attività.

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

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

Macchine virtuali considerazioni

Prendere in considerazione i punti seguenti quando si distribuiscono attività in background in una macchina virtuale di Azure:

  • 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 è possibile monitorare le attività nel portale e non è possibile eseguire il riavvio automatico per le attività non riuscite. È tuttavia possibile usare i cmdlet di Azure Resource Manager per monitorare lo stato della macchina virtuale e gestirla. Non sono disponibili 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 le informazioni sugli errori e restituirla a un'applicazione di gestione.

Per altre informazioni, vedere:

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, vedere:

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. Alcuni dei vantaggi sono i seguenti:

  • 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 del contenitore 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 di come usare un agente di orchestrazione del contenitore.

Per altre informazioni, vedere:

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 basate su 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 compilare 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, vedere:

Elenco di controllo per l'affidabilità

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per l'affidabilità