Condividi tramite

Attività in background

Molti tipi di applicazioni richiedono attività in background eseguite indipendentemente dall'interfaccia utente. Gli esempi includono processi batch, attività di elaborazione intensiva e processi a esecuzione prolungata, ad esempio i flussi di lavoro. I processi in background possono essere eseguiti senza richiedere l'interazione dell'utente: l'applicazione può avviare il processo e quindi continuare a elaborare richieste interattive dagli utenti. Ciò consente di ridurre al minimo il carico nell'interfaccia utente dell'applicazione, che può migliorare la disponibilità e ridurre i tempi di risposta interattivi.

Ad esempio, se un'applicazione è necessaria per generare anteprime di immagini caricate dagli utenti, può eseguire questa operazione come processo in background e salvare l'anteprima nella risorsa di archiviazione al termine, senza che l'utente debba attendere il completamento del processo. Allo stesso modo, un utente che effettua un ordine può avviare un flusso di lavoro in background che elabora l'ordine, mentre l'interfaccia utente consente all'utente di continuare a esplorare l'app Web. Al termine del processo in background, può aggiornare i dati degli ordini archiviati e inviare un messaggio di posta elettronica all'utente che conferma l'ordine.

Quando si valuta se implementare un'attività come processo in background, i criteri principali sono se l'attività può essere eseguita senza interazione dell'utente e senza che l'interfaccia utente debba attendere il completamento del processo. Le attività che richiedono l'attesa dell'utente o dell'interfaccia utente durante il completamento potrebbero non essere appropriate come processi in background.

Tipi di attività in background

I processi in background in genere includono uno o più dei seguenti tipi di processi:

  • Processi a elevato utilizzo di CPU, ad esempio calcoli matematici o analisi del modello strutturale.
  • Processi con utilizzo intensivo di I/O, ad esempio l'esecuzione di una serie di transazioni di archiviazione o di file di indicizzazione.
  • Processi batch, come aggiornamenti notturni dei dati o elaborazioni pianificate.
  • Flussi di lavoro a esecuzione prolungata, ad esempio l'evasione degli ordini o i servizi e i sistemi di provisioning.
  • Elaborazione dei dati sensibili in cui l'attività viene passata a una posizione più sicura per l'elaborazione. Ad esempio, è consigliabile non elaborare dati sensibili all'interno di un'app Web. È invece possibile usare un modello, ad esempio il modello Gatekeeper , per trasferire i dati in un processo in background isolato che ha accesso all'archiviazione protetta.

Attivatori

Le attività in background possono essere avviate in vari modi. Rientrano in una delle categorie seguenti:

  • Trigger basati su eventi. L'attività viene avviata in risposta a un evento, in genere un'azione eseguita da un utente o da un passaggio in un flusso di lavoro.
  • Trigger guidati dal programma. L'attività viene richiamata in base a una pianificazione basata su un timer. Potrebbe trattarsi di una pianificazione ricorrente o di una chiamata occasionale specificata per un secondo momento.

Trigger guidati dagli eventi

La chiamata guidata dagli eventi usa un trigger per avviare l'attività in background. Esempi di utilizzo di trigger basati su eventi includono:

  • L'interfaccia utente o un'altra attività inserisce un messaggio in una coda. Il messaggio contiene dati su un'azione eseguita, ad esempio l'utente che effettua un ordine. L'attività in background ascolta questa coda e rileva l'arrivo di un nuovo messaggio. Legge il messaggio e usa i dati in esso contenuti come input per il processo in background. Questo modello è noto come comunicazione asincrona basata su messaggi.
  • L'interfaccia utente o un altro processo salva o aggiorna un valore nell'archiviazione. L'attività 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 altro processo effettua una richiesta a un endpoint, ad esempio un URI HTTPS o un'API esposta come servizio Web. Passa i dati necessari per completare l'attività in background come parte della richiesta. L'endpoint o il servizio web richiama l'attività in background, che utilizza i dati come input.

Esempi tipici 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 nelle applicazioni multi-tenant.

Trigger basati sulla pianificazione

La chiamata guidata dalla pianificazione usa un timer per avviare l'attività in background. Esempi di uso di trigger basati su pianificazione includono:

  • Un timer in esecuzione in locale all'interno dell'applicazione o come parte del sistema operativo dell'applicazione richiama regolarmente un'attività in background.
  • Un timer in esecuzione in un'applicazione diversa, ad esempio App per la logica di Azure, invia regolarmente una richiesta a un'API o a un servizio Web. L'API o il servizio Web richiama l'attività in background.
  • Un processo o un'applicazione separata avvia un timer che fa sì che l'attività in background venga richiamata una volta dopo un ritardo di tempo specificato o in un momento specifico.

Esempi tipici di attività adatte alla chiamata guidata dalla pianificazione includono routine di elaborazione batch (ad esempio l'aggiornamento di elenchi di prodotti correlati per gli utenti 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, tenere presente quanto segue:

  • Se l'istanza di calcolo che esegue l'utilità di pianificazione , ad esempio una macchina virtuale che usa attività pianificate di Windows, viene ridimensionata, si avranno più istanze dell'utilità di pianificazione in esecuzione. Possono avviare più istanze dell'attività. Per altre informazioni su questo argomento, leggere questo post di blog sull'idempotenza.
  • Se le attività vengono eseguite per più tempo del periodo tra gli eventi dell'utilità di pianificazione, l'utilità di pianificazione può avviare un'altra istanza dell'attività mentre quella precedente è ancora in esecuzione.

Restituzione dei risultati

I processi in background sono eseguiti in modo asincrono in un processo separato, o anche in una posizione separata, dall'interfaccia utente o dal processo che ha richiamato l'attività in background. Idealmente, le attività in background sono operazioni di tipo "fire and forget" e lo stato di avanzamento dell'esecuzione non ha alcun impatto sull'interfaccia utente o sul processo chiamante. Ciò significa che il processo chiamante non attende che le attività siano completate. Di conseguenza, non può rilevare automaticamente 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 per questo. Ecco alcuni esempi:

  • Scrivere un valore dell'indicatore di stato nell'archiviazione accessibile all'interfaccia utente o all'attività chiamante, che può monitorare o controllare questo valore quando necessario. Gli altri dati che l'attività in background deve restituire al chiamante possono essere inseriti nella stessa risorsa di archiviazione.
  • Stabilire una coda di risposta a cui l'interfaccia utente o il chiamante possono ascoltare. L'attività in background può inviare alla coda messaggi che indicano lo stato e il completamento. I dati che l'attività in background deve restituire al chiamante possono essere inseriti nei messaggi. Se si usa il bus di servizio di Azure, è possibile usare le proprietà ReplyTo e CorrelationId per implementare questa funzionalità.
  • Rendi disponibile un'API e un endpoint dell'attività di background a cui l'interfaccia utente o il chiamante può accedere per acquisire informazioni sullo stato. I dati che l'attività in background deve restituire al chiamante possono essere inclusi nella risposta.
  • Fare in modo che l'attività in background venga richiamata all'interfaccia utente o al chiamante tramite un'API per indicare lo stato in punti predefiniti o al completamento. Può trattarsi di eventi generati localmente o tramite un meccanismo di pubblicazione e sottoscrizione. I dati che l'attività in background deve restituire al chiamante possono essere inclusi nel payload della richiesta o dell'evento.

Ambiente di hosting

È possibile ospitare attività in background usando una gamma di diversi servizi della piattaforma Azure:

  • App Web di Azure e WebJobs. È possibile usare Processi Web per eseguire processi personalizzati in base a diversi tipi di script o programmi eseguibili all'interno del contesto di un'app Web.
  • Funzioni di Azure. È possibile usare le funzioni per i processi in background che non vengono eseguiti per molto tempo. Un altro caso d'uso è se il carico di lavoro è già ospitato nel piano di servizio app ed è sottoutilizzato.
  • Macchine virtuali di Azure. Se si dispone di un servizio Windows o si vuole usare l'Utilità di pianificazione di Windows, è comune ospitare le attività in background all'interno di una macchina virtuale dedicata.
  • Azure Batch. Batch è un servizio di piattaforma che pianifica operazioni a elevato utilizzo di calcolo da eseguire in una raccolta gestita di macchine virtuali. Può ridimensionare automaticamente le risorse di calcolo.
  • Azure Kubernetes Service (AKS). Il servizio Azure Kubernetes offre un ambiente di hosting gestito per Kubernetes in Azure.
  • App container di Azure. Il servizio App contenitore di Azure consente di creare microservizi serverless basati su contenitori.

Le sezioni seguenti descrivono queste opzioni in modo più dettagliato e includono considerazioni che consentono di scegliere l'opzione appropriata.

App Web di Azure e WebJobs

È possibile usare Processi Web di Azure per eseguire processi personalizzati come attività in background all'interno di un'app Web di Azure. Le WebJobs vengono eseguite nel contesto della tua app web come processo continuo. I WebJobs vengono eseguiti anche in risposta a un trigger da Azure Logic Apps o fattori esterni, come modifiche ai BLOB di archiviazione e alle code di messaggi. I lavori possono essere avviati e fermati su richiesta e chiusi in modo ordinato. Se un WebJob di Azure in esecuzione continua fallisce, viene riavviato automaticamente. Le azioni di ripetizione e errore sono configurabili.

Quando si configura un WebJob:

  • Se si vuole che il processo risponda a un trigger basato su eventi, è necessario configurarlo come 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, è necessario configurarlo come 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, verrà eseguito lo stesso codice dell'opzione Esegui in base a una pianificazione all'avvio.

I processi Web di Azure vengono eseguiti all'interno della sandbox dell'app Web. Ciò significa che possono accedere alle variabili di ambiente e condividere informazioni, ad esempio stringhe di connessione, con l'app Web. L'attività ha accesso all'identificatore univoco della macchina che esegue l'attività. La stringa di connessione denominata AzureWebJobsStorage consente l'accesso a code, BLOB e tabelle di Archiviazione di Azure per i dati dell'applicazione e l'accesso al bus di servizio per la messaggistica e la comunicazione. La stringa di connessione denominata AzureWebJobsDashboard consente di accedere ai file di log delle azioni del processo.

I WebJobs di Azure presentano le seguenti caratteristiche:

  • Sicurezza: i WebJobs sono protetti dalle credenziali di distribuzione dell'applicazione web.
  • Tipi di file supportati: è possibile definire processi Web usando script di comando (.cmd), file batch (.bat), script di PowerShell (.ps1), script della shell Bash (.sh), script PHP (), script Python (.php.py), codice JavaScript (.js) e programmi eseguibili (.exe, .jare altro ancora).
  • Distribuzione: è possibile distribuire script ed eseguibili usando il portale di Azure, usando Visual Studio, usando Azure WebJobs SDK o copiandoli direttamente nei percorsi seguenti:
    • Per l'esecuzione attivata: site/wwwroot/app_data/jobs/triggered/{nome lavoro}
    • Per l'esecuzione continua: site/wwwroot/app_data/jobs/continuous/{nome attività}
  • Registrazione: Console.Out viene contrassegnato come INFO. Console.Error viene considerato come ERROR. È possibile accedere alle informazioni di monitoraggio e diagnostica usando il portale di Azure. È possibile scaricare i file di log direttamente dal sito. Vengono salvati nelle posizioni seguenti:
    • Per l'esecuzione attivata: Vfs/data/jobs/triggered/jobName
    • Per l'esecuzione continua: Vfs/data/jobs/continuous/jobName
  • Configurazione: è possibile configurare processi Web usando il portale, l'API REST e PowerShell. È possibile usare un file di configurazione denominato settings.job nella stessa directory radice dello script del processo per fornire informazioni di configurazione per un processo. Per esempio:
    • { "tempo_attesa_arresto": 60 }
    • { "is_singleton": true }

Considerazioni

  • Per impostazione predefinita, i WebJobs si ridimensionano con l'app Web. È tuttavia possibile configurare i processi per l'esecuzione in un'istanza singola impostando la proprietà di configurazione is_singletonsu 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, analisi dei dati e attività simili.
  • Per ridurre al minimo l'impatto dei processi sulle prestazioni dell'app Web, è consigliabile creare un'istanza vuota di App Web di Azure in un nuovo piano di servizio app per ospitare processi Web a esecuzione prolungata o a elevato utilizzo di risorse.

Funzioni di Azure

Un'opzione simile a WebJobs è Azure Functions. Questo servizio è serverless, ideale per i trigger guidati da eventi che vengono eseguiti per un breve periodo. Una funzione può essere usata anche per eseguire processi pianificati tramite trigger timer, se configurati per l'esecuzione in momenti prestabiliti.

Funzioni di Azure non è un'opzione consigliata per attività di grandi dimensioni a esecuzione prolungata perché possono causare problemi di timeout imprevisti. Tuttavia, a seconda del piano di hosting, possono essere considerati per i trigger basati sulla pianificazione.

Considerazioni

Se si prevede che un'attività in background venga eseguita per un breve periodo di tempo in risposta a un evento, considerare di eseguire l'attività in un piano a consumo. Il tempo di esecuzione è configurabile fino a un massimo di tempo. Funzione che viene eseguita per costi più lunghi. Anche 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à, questi vengono fatturati separatamente.

Il piano Premium è più adatto se si dispone di un numero elevato di attività brevi ma previste per l'esecuzione continua. Questo piano è più costoso perché richiede più memoria e CPU. Il vantaggio è che è possibile usare funzionalità come l'integrazione della rete virtuale.

Il piano dedicato è più adatto per i processi in background se il carico di lavoro è già operativo su di esso. Se sono presenti macchine virtuali sottoutilizzate, è possibile eseguirla nella stessa macchina virtuale e condividere i costi di calcolo.

Per altre informazioni, vedere questi articoli:

Macchine virtuali di Azure

Le attività in background potrebbero essere implementate in modo da impedire la distribuzione in App Web di Azure oppure queste opzioni potrebbero non essere utili. Esempi tipici sono i servizi Windows e le utilità di terze parti e i programmi eseguibili. Un altro esempio può essere costituito da programmi scritti per un ambiente di esecuzione diverso da quello che ospita l'applicazione. Ad esempio, potrebbe trattarsi di un programma Unix o Linux che si vuole eseguire da un'applicazione Windows o .NET. È possibile scegliere tra un'ampia gamma di sistemi operativi per una macchina virtuale di Azure ed eseguire il servizio o il file eseguibile in tale macchina virtuale.

Per scegliere quando usare macchine virtuali, vedere Confronto tra Servizi app di Azure, Servizi cloud e macchine virtuali. Per informazioni sulle opzioni per le macchine virtuali, vedere Dimensioni per le macchine virtuali Windows in Azure. Per altre informazioni sui sistemi operativi e sulle immagini predefinite disponibili per le macchine virtuali, vedere Azure Virtual Machines Marketplace.

Per avviare l'attività in background in una macchina virtuale separata, sono disponibili diverse opzioni:

  • È possibile eseguire l'attività su richiesta direttamente dall'applicazione inviando una richiesta a un endpoint esposto dall'attività. In questo modo vengono passati tutti i dati richiesti dall'attività. Questo endpoint richiama l'attività.
  • È possibile configurare l'attività per l'esecuzione in base a una pianificazione usando un'utilità di pianificazione o un timer disponibile nel sistema operativo scelto. Ad esempio, in Windows è possibile usare Utilità di pianificazione di Windows per eseguire script e attività. In alternativa, se SQL Server è installato nella macchina virtuale, è possibile usare SQL Server Agent per eseguire script e attività.
  • È possibile usare App per la logica di Azure per avviare l'attività aggiungendo un messaggio a una coda su cui l'attività è in ascolto o inviando una richiesta a un'API esposta dall'attività.

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

Considerazioni

Quando si decide se distribuire le attività in background in una macchina virtuale di Azure, tenere presente quanto segue:

  • L'hosting di attività in background in una macchina virtuale di Azure separata offre flessibilità e consente un controllo preciso sull'avvio, l'esecuzione, la pianificazione e l'allocazione delle risorse. Tuttavia, aumenterà il costo di runtime se una macchina virtuale deve essere distribuita solo per eseguire attività in background.
  • Non esiste alcuna funzionalità per monitorare le attività nel portale di Azure e nessuna funzionalità di riavvio automatico per le attività non riuscite, anche se è possibile monitorare lo stato di base della macchina virtuale e gestirla usando i cmdlet di Azure Resource Manager. Tuttavia, non esistono strutture per controllare i processi e i thread nei nodi di calcolo. In genere, l'uso di una macchina virtuale richiederà ulteriore sforzo per implementare un meccanismo che raccoglie i dati dalla strumentazione nell'attività e dal sistema operativo nella macchina virtuale. Una soluzione che potrebbe essere appropriata consiste nell'usare il Management Pack di System Center per Azure.
  • È possibile prendere in considerazione la creazione di probe di monitoraggio esposti tramite endpoint HTTP. Il codice per queste sonde può eseguire controlli di integrità, raccogliere informazioni operative e statistiche, oppure aggregare le informazioni sugli errori e restituirle a un'applicazione di gestione. Per ulteriori informazioni, vedere il Modello di monitoraggio dell'integrità degli endpoint.

Per altre informazioni, vedere:

Azure Batch

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

Il servizio Batch effettua il provisioning delle macchine virtuali, assegna attività alle macchine virtuali, esegue le attività e monitora lo stato di avanzamento. Batch può scalare orizzontalmente le istanze delle macchine virtuali automaticamente in risposta al carico di lavoro. Batch fornisce anche la pianificazione dei lavori. Azure Batch supporta sia macchine virtuali Linux che Windows.

Considerazioni

Batch funziona bene con carichi di lavoro intrinsecamente paralleli. Può anche eseguire calcoli paralleli con un passaggio di riduzione alla fine o eseguire applicazioni MPI (Message Passing Interface) per attività parallele che richiedono il passaggio di messaggi tra nodi.

Un processo di Azure Batch viene eseguito in un pool di nodi (VM). Un approccio consiste nell'allocare un pool solo quando necessario e quindi eliminarlo al termine del processo. In questo modo si ottimizza l'utilizzo, perché i nodi non sono inattivi, ma l'incarico deve attendere che i nodi siano allocati. 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 la presenza di nodi inattive. Per altre informazioni, vedere Durata del pool e dei nodi di calcolo.

Per altre informazioni, vedere:

Servizio Azure Kubernetes

Il servizio Azure Kubernetes gestisce l'ambiente Kubernetes ospitato, semplificando la distribuzione e la gestione di applicazioni in contenitori.

I contenitori possono essere utili per l'esecuzione di processi in background. Alcuni dei vantaggi includono:

  • I contenitori supportano l'hosting ad alta densità. È possibile isolare un'attività in background in un contenitore, inserendo più contenitori in ogni macchina virtuale.
  • L'agente di orchestrazione del contenitore gestisce il bilanciamento del carico interno, la configurazione della rete interna e altre attività di configurazione.
  • I contenitori possono essere avviati e arrestati in base alle esigenze.
  • Registro Azure Container consente di registrare i contenitori all'interno dei limiti di Azure. Questo è dotato di vantaggi di sicurezza, privacy e prossimità.

Considerazioni

  • Richiede una conoscenza di come usare un orchestratore di contenitori. A seconda del set di competenze del team DevOps, questo potrebbe essere o meno un problema.

Per altre informazioni, vedere:

App contenitore di Azure

Il servizio App contenitore di Azure consente di creare microservizi serverless basati su contenitori. Caratteristiche distintive di Container Apps includono:

  • Ottimizzato per l'esecuzione di contenitori per utilizzo generico, in particolare per le applicazioni che si estendono su molti microservizi distribuiti nei contenitori.
  • Basato su Kubernetes e tecnologie open source come Dapr, Kubernetes Event-driven Autoscaling (KEDA) e envoy.
  • Supporta app e microservizi di tipo Kubernetes con funzionalità come individuazione dei servizi e suddivisione del traffico.
  • Abilita le architetture di applicazioni guidate dagli eventi scalando in base al traffico e prelevando da fonti di eventi come le code, compresa la possibilità di scalare fino a zero.
  • Supporto di processi a esecuzione prolungata e può eseguire attività in background.

Considerazioni

Le app contenitore di Azure non forniscono l'accesso diretto alle API di Kubernetes sottostanti. Se è necessario accedere alle API e al piano di controllo di Kubernetes, è consigliabile usare il servizio Azure Kubernetes. Tuttavia, se si vogliono creare applicazioni di tipo Kubernetes e non richiedono l'accesso diretto a tutte le API e la gestione del cluster Kubernetes nativa, App contenitore offre un'esperienza completamente gestita in base alle procedure consigliate. Per questi motivi, molti team potrebbero voler iniziare a creare microservizi contenitore con App contenitore di Azure.

Per altre informazioni, vedere:

È possibile iniziare a creare la tua prima app container usando le guide introduttive.

Partizionamento

Se si decide di includere le attività in background all'interno di un'istanza di calcolo esistente, è necessario considerare in che modo questo influisce sugli attributi di qualità dell'istanza di calcolo e sull'attività in background stessa. Questi fattori consentono di decidere se raggruppare le attività con l'istanza di calcolo esistente o separarle in un'istanza di calcolo separata:

  • Disponibilità: le attività in background potrebbero non dover avere lo stesso livello di disponibilità di altre parti dell'applicazione, in particolare l'interfaccia utente e altre parti direttamente coinvolte nell'interazione dell'utente. Le attività in background potrebbero essere più tolleranti alla latenza, ripetuti errori di connessione e altri fattori che influiscono sulla disponibilità perché le operazioni possono essere accodate. Tuttavia, è necessario disporre di capacità sufficiente per impedire il backup delle richieste che potrebbero bloccare le code e influire sull'applicazione nel suo complesso.

  • Scalabilità: è probabile che le attività in background abbiano requisiti di scalabilità diversi rispetto all'interfaccia utente e alle parti interattive dell'applicazione. Il ridimensionamento dell'interfaccia utente potrebbe essere necessario per soddisfare i picchi di domanda, mentre le attività in background in sospeso potrebbero essere completate in momenti meno occupati da un minor numero di istanze di calcolo.

  • Resilienza: l'errore di un'istanza di calcolo che ospita solo attività in background potrebbe non influire in modo irreversibile sull'applicazione nel suo complesso se le richieste per queste attività possono essere accodate o posticipate fino a quando l'attività non sarà nuovamente disponibile. Se l'istanza di calcolo o le attività possono essere riavviate entro un intervallo appropriato, gli utenti dell'applicazione potrebbero non essere interessati.

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

  • Prestazioni: è possibile scegliere il tipo di istanza di calcolo per le attività in background per soddisfare in modo specifico i requisiti di prestazioni delle attività. Questo potrebbe significare l'uso di un'opzione di calcolo meno costosa se le attività non richiedono le stesse funzionalità di elaborazione dell'interfaccia utente o un'istanza più grande se richiedono capacità e risorse aggiuntive.

  • Gestibilità: le attività in background potrebbero avere un ritmo di sviluppo e distribuzione diverso dal codice dell'applicazione principale o dall'interfaccia utente. La distribuzione in un'istanza di calcolo separata può semplificare gli aggiornamenti e il controllo delle versioni.

  • Costo: l'aggiunta di istanze di calcolo per eseguire attività in background aumenta i costi di hosting. È consigliabile considerare attentamente il compromesso tra capacità aggiuntiva e questi costi aggiuntivi.

Per altre informazioni, vedere il modello Elezione del leader e il modello Consumatori concorrenti.

Conflitti

Se si dispone di più istanze di un processo in background, è possibile che competano per l'accesso a risorse e servizi, ad esempio database e archiviazione. Questo accesso simultaneo può comportare conflitti di risorse, che potrebbero causare conflitti nella disponibilità dei servizi e nell'integrità dei dati nell'archiviazione. È possibile risolvere i conflitti di risorse usando un approccio di blocco pessimistico. Ciò 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 sia in esecuzione una sola istanza. Tuttavia, ciò elimina i vantaggi di affidabilità e prestazioni che una configurazione a più istanze può offrire. Ciò è particolarmente vero se l'interfaccia utente può fornire un lavoro sufficiente per mantenere occupato più di un'attività in background.

È fondamentale assicurarsi che l'attività in background possa essere riavviata automaticamente e che disponga di capacità sufficiente per far fronte ai picchi di domanda. È possibile ottenere questo risultato allocando un'istanza di calcolo con risorse sufficienti, implementando un meccanismo di accodamento in grado di archiviare le richieste per un'esecuzione successiva quando la richiesta diminuisce o usando una combinazione di queste tecniche.

Coordinamento

Le attività in background potrebbero essere complesse e potrebbero richiedere l'esecuzione di più singole attività per produrre un risultato o per soddisfare tutti i requisiti. 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 possono essere più efficienti e più flessibili perché i singoli passaggi potrebbero essere riutilizzabili in più processi. È anche facile aggiungere, rimuovere o modificare l'ordine dei passaggi.

Il coordinamento di più attività e passaggi può risultare complesso, ma esistono tre modelli comuni che è possibile usare per guidare l'implementazione di una soluzione:

  • Scomposizione di un'attività in più passaggi riutilizzabili. Un'applicazione potrebbe essere necessaria per eseguire un'ampia gamma di attività di complessità variabile sulle informazioni elaborate. Un approccio semplice ma inflessibile per implementare questa applicazione potrebbe essere quello di eseguire questa elaborazione come modulo monolitico. Tuttavia, questo approccio potrebbe ridurre le opportunità di refactoring del codice, ottimizzarlo o riutilizzarlo se sono necessarie parti della stessa elaborazione altrove all'interno dell'applicazione. Per altre informazioni, vedere il modello Pipe e Filtri.

  • Gestione dell'esecuzione dei passaggi per un'attività. Un'applicazione può eseguire attività che comprendono diversi passaggi( alcuni dei quali possono richiamare servizi remoti o accedere a risorse remote). I singoli passaggi potrebbero essere indipendenti tra loro, ma sono coordinati dalla logica dell'applicazione che implementa l'attività. Per ulteriori informazioni, vedere il modello Supervisor dell'agente di pianificazione.

  • Gestione del ripristino per le fasi dell'attività non riuscite. Un'applicazione potrebbe dover annullare il lavoro eseguito da una serie di passaggi (che insieme definiscono un'operazione coerente alla fine) se uno o più passaggi hanno esito negativo. Per altre informazioni, vedere il modello di transazione di compensazione.

Considerazioni sulla resilienza

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

  • Le attività in background devono essere in grado di 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 il check-pointing, salvando lo stato dei processi nella memoria persistente o come messaggi in una coda, se appropriato. Ad esempio, è possibile rendere persistenti le informazioni sullo stato in un messaggio in una coda e aggiornare in modo incrementale queste informazioni sullo stato con lo stato di avanzamento dell'attività in modo che l'attività possa essere elaborata dall'ultimo checkpoint valido noto, anziché riavviare dall'inizio. Quando si usano le code del bus di servizio di Azure, è possibile usare sessioni di messaggi per abilitare lo stesso scenario. Le sessioni consentono di salvare e recuperare lo stato di elaborazione dell'applicazione usando i metodi SetState e GetState . Per ulteriori informazioni sulla progettazione di processi e flussi di lavoro affidabili a più passaggi, vedere il modello Scheduler Agent Supervisor.

  • Quando si utilizzano le code per comunicare con attività in background, le code possono fungere da buffer per archiviare le richieste inviate alle attività mentre l'applicazione è sottoposta a un carico superiore al normale. In questo modo le attività possono raggiungere la sincronizzazione con l'interfaccia utente durante i periodi di minore attività. Significa anche che i riavvii non bloccano l'interfaccia utente. Per altre informazioni, vedere il modello di livellamento del caricoQueue-Based. Se alcune attività sono più importanti di altre, è consigliabile implementare il modello di coda priorità per assicurarsi che queste attività vengano eseguite prima di quelle meno importanti.

  • Le attività in background avviate da messaggi o messaggi di elaborazione devono essere progettate per gestire incoerenze, ad esempio i messaggi che arrivano fuori ordine, i messaggi che causano ripetutamente un errore (spesso definiti messaggi non elaborabili) e i messaggi recapitati più volte. Tenere presente quanto segue:

    • I messaggi che devono essere elaborati in un ordine specifico, ad esempio quelli che modificano i dati in base al valore di dati esistente ,ad esempio aggiungendo un valore a un valore esistente, potrebbero non arrivare nell'ordine originale in cui sono stati inviati. In alternativa, possono essere gestiti da istanze diverse di un'attività in background in un ordine diverso a causa di carichi variabili in ogni istanza. I messaggi che devono essere elaborati in un ordine specifico devono includere un numero di sequenza, una chiave o un altro indicatore che le attività in background possono usare per assicurarsi che vengano elaborate nell'ordine corretto. Se si usa il bus di servizio di Azure, è possibile usare sessioni di messaggi per garantire l'ordine di recapito. Tuttavia, è in genere più efficiente, laddove possibile, progettare il processo in modo che l'ordine dei messaggi non sia importante.

    • In genere, un'attività in background controlla i messaggi nella coda, nascondendoli temporaneamente ad altri consumer di messaggi. Elimina quindi i messaggi dopo che sono stati elaborati correttamente. Se un'attività in background non riesce durante l'elaborazione di un messaggio, il messaggio verrà nuovamente visualizzato nella coda dopo la scadenza del timeout di visualizzazione. Verrà elaborato da un'altra istanza dell'attività o durante il ciclo di elaborazione successivo di questa istanza. Se il messaggio causa in modo coerente un errore nel consumer, bloccherà l'attività, la coda e infine l'applicazione stessa quando la coda diventa piena. Pertanto, è vitale rilevare e rimuovere i messaggi dannosi dalla coda. Se si usa il bus di servizio di Azure, i messaggi che causano un errore possono essere spostati automaticamente o manualmente in una coda di messaggi non recapitabili associata.

    • Le code garantiscono meccanismi di consegna almeno una volta, ma potrebbero recapitare lo stesso messaggio più di una volta. Inoltre, se un'attività in background non riesce dopo l'elaborazione di un messaggio, ma prima di eliminarla dalla coda, il messaggio diventerà nuovamente disponibile per l'elaborazione. Le attività in background devono essere idempotenti, il che significa che l'elaborazione dello stesso messaggio più di una volta non causa un errore o un'incoerenza nei dati dell'applicazione. Alcune operazioni sono naturalmente idempotenti, ad esempio l'impostazione di un valore archiviato su un nuovo valore specifico. Tuttavia, operazioni come l'aggiunta di un valore a un valore archiviato esistente senza verificare che il valore archiviato sia ancora uguale a quando il messaggio è stato originariamente inviato causerà incoerenze. Le code del bus di servizio di Azure possono essere configurate per rimuovere automaticamente i messaggi duplicati. Per ulteriori informazioni sulle problematiche relative al recapito di messaggi consegnati almeno una volta, vedere le indicazioni sull'elaborazione dei messaggi idempotenti.

    • Alcuni sistemi di messaggistica, ad esempio Archiviazione code di Azure e code del bus di servizio di Azure, supportano una proprietà di conteggio delle code che indica il numero di volte in cui un messaggio è stato letto dalla coda. Ciò può essere utile nella gestione di messaggi ripetuti e messaggi dannosi. Per altre informazioni, vedere Introduzione alla messaggistica asincrona e Modelli di Idempotenza.

Considerazioni sulla scala e le prestazioni

Le attività in background devono offrire prestazioni sufficienti per assicurarsi che non blocchino l'applicazione o causi incoerenze a causa di un'operazione ritardata quando il sistema è in carico. In genere, le prestazioni sono migliorate ridimensionando le istanze di calcolo che ospitano le attività in background. Quando si pianificano e progettano attività in background, considerare i punti seguenti relativi alla scalabilità e alle prestazioni:

  • Azure supporta la scalabilità automatica (sia scalare verso l'alto che verso il basso) in base alla domanda e al carico corrente o a una pianificazione predefinita, per app Web e distribuzioni di macchine virtuali ospitate. Usare questa funzionalità per assicurarsi che l'applicazione nel suo complesso abbia funzionalità di prestazioni sufficienti riducendo al minimo i costi di runtime.

  • Se le attività in background hanno una funzionalità di prestazioni diversa rispetto alle altre parti di un'applicazione (ad esempio, l'interfaccia utente o i componenti, ad esempio il livello di accesso ai dati), l'hosting delle attività in background in un servizio di calcolo separato consente all'interfaccia utente e alle attività in background di ridimensionare in modo indipendente per gestire il carico. Se più attività in background hanno funzionalità di prestazioni notevolmente diverse l'una dall'altra, valutare la possibilità di dividerle e ridimensionare ogni tipo in modo indipendente. Si noti tuttavia che questo potrebbe aumentare i costi di runtime.

  • La semplice scalabilità delle risorse di calcolo potrebbe non essere sufficiente per evitare la perdita di prestazioni in caso di carico. Potrebbe anche essere necessario ridimensionare le code di archiviazione e altre risorse per impedire che un singolo punto della catena di elaborazione complessiva diventi un collo di bottiglia. Considerare anche altre limitazioni, ad esempio la velocità effettiva massima di archiviazione e altri servizi su cui si basano l'applicazione e le attività in background.

  • Le attività in background devono essere progettate per il ridimensionamento. Ad esempio, devono essere in grado di rilevare dinamicamente il numero di code di archiviazione in uso per ascoltare o inviare messaggi alla coda appropriata.

  • Per impostazione predefinita, i WebJob si scalano con la loro istanza di App Web di Azure associata. Tuttavia, se si vuole che un processo Web venga eseguito come una sola istanza, è possibile creare un file Settings.job contenente i dati JSON { "is_singleton": true }. In questo modo Azure deve eseguire una sola istanza del processo Web, anche se sono presenti più istanze dell'app Web associata. Può trattarsi di una tecnica utile per i processi pianificati che devono essere eseguiti come una sola istanza.

Passaggi successivi