Manutenzione delle attività in background su un sito di grandi dimensioni

Alcune settimane fa ho chiesto a domanda simile su SO. In un guscio di noce, il mio approccio da tempo è stato quello di sviluppare un servizio di Windows. Vorrei utilizzare NServiceBus (essenzialmente MSMQ sotto le copertine) per inoltrare le richieste dalla mia app Web al mio servizio. Usavo WCF ma ottenere una transazione distribuita per funzionare correttamente su WCF mi sembrava sempre un rompicapo. NServiceBus ha fatto il trucco, ho potuto impegnare i dati e creare attività in una transazione e non mi preoccupavo se il mio servizio era attivo e funzionante al momento. Come semplice esempio, se mai avessi bisogno di inviare un messaggio di posta elettronica (ad esempio un'e-mail di registrazione) creerei l'account utente e sparerei un segnale al mio servizio Windows (per inviare l'e-mail) in una transazione. Il gestore di messaggi sul lato del servizio avrebbe raccolto il messaggio ed elaborato di conseguenza.

Da quando sono stati rilasciati ASP .NET 4.0 e AppFabric, ci sono un certo numero di valide alternative al meccanismo di cui sopra. Facendo riferimento alla domanda che ho menzionato sopra, ora abbiamo AppInitialize di AppFabric (via net.pipe) così come la funzione di avvio automatico di ASP .NET 4.0 che rende lo sviluppo di servizi di Windows come applicazioni web un'alternativa praticabile. Ho iniziato a farlo ora per una serie di motivi (il più grande è la distribuzione non è più un rompicapo):

1. È possibile sviluppare un'interfaccia utente Web sul proprio servizio (poiché è in esecuzione come app Web). Questo è estremamente utile per vedere cosa sta succedendo in fase di runtime.
2. Il modello di implementazione per le tue app Web funzionerà per l'applicazione di servizio.
3. IIS offre alcune funzionalità per la gestione degli errori delle applicazioni (simile per alcuni aspetti a un servizio di Windows).
4. Gli sviluppatori Web hanno molta familiarità con lo sviluppo di applicazioni Web (naturalmente), la maggior parte non sa molto delle best practice quando sviluppa un servizio Windows.
5. Fornisce una serie di alternative all'esposizione di un'API da utilizzare per altre app.

Se segui questo percorso (perdonami per aver copiato e incollato dal mio post originale), prenderei sicuramente in considerazione l'esecuzione della logica di background in un'applicazione web separata. Ci sono diversi motivi per questo:

1. Sicurezza . Potrebbe esserci un diverso modello di sicurezza per l'interfaccia utente che visualizza informazioni sui processi in background in esecuzione. Non vorrei esporre questa interfaccia utente a nessun altro ma al team ops. Inoltre, l'applicazione web può essere eseguita come utente diverso con un set di autorizzazioni elevato.
2. Manutenzione . Sarebbe fantastico poter distribuire le modifiche all'applicazione che ospita i processi in background senza influenzare l'utente che utilizza il sito Web front-end.
3. Prestazioni . Avere l'applicazione separata dalle richieste dell'utente di elaborazione del sito principale significa che i thread in background non diminuiranno la capacità di IIS di gestire la coda di richieste in entrata. Inoltre, l'applicazione che elabora le attività in background potrebbe essere distribuita su un server separato, se necessario.

Questa operazione torna all'aspetto di marshalling. WCF, NServiceBus / RabbitMQ / ActiveMQ ecc., Vanilla MSMQ, RESTful API (pensa MVC) sono tutte opzioni. Se si utilizza Windows Workflow 4.0, è possibile esporre un endpoint host che potrebbe essere utilizzato dall'app Web.

L'approccio di hosting web per i servizi è ancora abbastanza nuovo per me, solo il tempo dirà se è stata la scelta giusta. Però fin qui è andato tutto bene. A proposito, se non vuoi usare AppFabric (non potrei, perché per qualche strana ragione, Windows Server Web Edition non è supportato), la funzionalità Auto-Start menzionata nel post di Gu funziona bene. Stare lontano dal file applicationhost.config però, tutto ciò che in quel post è possibile impostare tramite la console di IIS (Configuration Editor al livello del server principale).

Nota: originariamente avevo postato qualche altro link in questo messaggio ma ahimè, questo è il mio primo post su questo scambio e solo un link è supportato! C'erano fondamentalmente altri due, per ottenere Google "Death to Windows Services ... Long Live AppFabric!" e "auto-start-asp-net-applications". Mi dispiace.

In Windows esiste un terzo modo per eseguire servizi in background ed è molto comune nel mondo UNIX. Il terzo modo è un lavoro CRON che esegue un pezzo della tua infrastruttura. In Windows questo è noto come task scheduler ed è molto comune per il codice in esecuzione su base pianificata. Per usarlo si crea una app da riga di comando che viene eseguita su una pianificazione predefinita. Il vantaggio di questo è che non devi preoccuparti se il processo rimane attivo e funzionante come un servizio, perché se fallisce per qualche motivo, si avvierà la prossima volta.

Come per il marshalling di attività specifiche, è davvero necessario archiviare queste attività in una memoria binaria persistente. Fino a quando l'app della riga di comando li preleva dallo storage e li esegue. L'ho fatto in passato, utilizzando il database Cassandra come fornitore stato sessione per le attività di riempimento di sfondo per utenti specifici nel database Cassandra, e poi avere la riga di comando raccoglierli e li esegue per l'utente.

Questa potrebbe non essere la tipica soluzione di marshalling, ma ha funzionato molto bene per me e si è rivelata una soluzione molto elegante, poiché le attività pianificate sono sopravvissute a spegnimenti, problemi di rete e qualsiasi macchina può eseguire l'attività dal è stato archiviato centralmente.

Promozione spudorata, ma questo è il mio progetto e la soluzione che ho brevemente descritto è il motivo per cui ho creato il progetto: link

Cron + Web App

Questo è un design collaudato che scala orizzontalmente insieme alla tua web farm e ti assicura di utilizzare lo stack tecnologico web che già conosci.

Ecco come funziona:

1. Crea un controller / azione nella tua applicazione web per gestire attività in background pianificate. Per convenzione, di solito chiamo il mio http://mydomain.com/system/cron .
2. Per motivi di sicurezza, questa azione deve essere bloccata su solo indirizzi IP autenticati sulla rete locale.
3. Su una macchina separata, installa Wget e configura un Attività pianificata per fare in modo che wget recuperi la risorsa dal passaggio 1. È possibile eseguire l'attività tutte le volte che si desidera (I di solito optare per 30 secondi). Non dimenticare di passare l'argomento del cookie appropriato a Wget in modo che venga autenticato sulla tua app Web.
4. Per la ridondanza, è anche possibile installare un secondo wget pianificato su una seconda macchina.

Evviva! Ora hai un percorso che verrà chiamato ogni 30 secondi. E se la richiesta richiede 5 minuti per l'elaborazione, a nessuno importa, perché non fa parte della richiesta di una pagina dell'utente.

L'azione cron finisce per sembrare molto semplice: ha una lista di metodi da eseguire su una certa frequenza. Quando arriva una richiesta, vede se c'è un metodo che deve essere eseguito e chiama il metodo appropriato. Ciò significa che puoi controllare la pianificazione nel tuo database , dove probabilmente hai già molti altri importanti dati di configurazione per il tuo sito.

Ancora più importante (per te), questo significa che i tuoi lavori non devono essere chiamati su un programma fisso. Puoi scrivere qualsiasi logica tu voglia per determinare quando eseguire un metodo.

Pro e contro

• Sei già molto bravo a scrivere codice ASP.NET MVC, quindi questo ti consente di scrivere le tue attività in background nella stessa piattaforma in cui scrivi il resto della tua soluzione.
• Le attività vengono eseguite nello stesso contesto dell'app Web, quindi puoi condividere la cache e utilizzare i metodi di supporto già esistenti.
• Se wget recupera un URI con bilanciamento del carico , anche le attività in background vengono ora bilanciate in base al carico.
• Implementazione simultanea : non devi preoccuparti di sincronizzare la tua app web con la tua logica di attività in background, perché sono tutti nella stessa implementazione.

• Nel corso degli anni, alcune persone mi hanno detto che questo design è "altamente accoppiato", ma quando premuti non sono stati in grado di articolare il motivo per cui è una brutta cosa.

Nota: se ci sono domande o dubbi, si prega di aggiungere un commento . Sono felice di elaborare.

Ho provato e utilizzato praticamente tutti i modi possibili per farlo nella mia attuale applicazione. Ho iniziato a fare la stessa cosa che fai al momento, a porcellini su una richiesta utente per riempire i dati e poi li memorizza nella cache andando avanti. Mi sono reso conto che anche questa era una pessima idea (specialmente quando si ridimensiona a più server Web, più utenti prendono il colpo).

Ho anche avuto un lavoro programmato che ha colpito un URL nell'app ASP.NET - questa è una soluzione decente ma inizia a scomparire nel momento in cui scala 1 server web.

Attualmente utilizzo due metodi diversi, entrambi con Quartz.NET che è una piccola grande libreria. Il primo è Quartz.NET in esecuzione in-process con ASP.NET, è configurato in global.asax e viene eseguito ogni due minuti. Lo uso per aggiornare la cache ASP.NET fuori banda, che è l'unica ragione per cui viene eseguito come parte di ASP.NET.

Il secondo è che ho scritto una libreria per racchiudere Quartz.NET chiamato DaemonMaster: rende facile l'inserimento di una DLL in una directory e l'esecuzione in un servizio di Windows. Ho trovato che aiuta ad evitare alcune delle parti fastidiose di lavorare con un servizio di Windows e pulisce anche l'API Quartz.NET. I servizi che eseguono DaemonMaster sono di due gusti diversi, i primi sono lavori che devono essere eseguiti ogni notte o ogni X minuti. Gli altri lavori funzionano da una coda in base ai dati provenienti dall'applicazione ASP.NET. L'app ASP.NET rilascia oggetti JSON su RabbitMQ e i servizi eseguono il polling su RabbitMQ, quindi elaborano i dati.

Sulla base di questo suggerirei di andare con un servizio Windows (e controllare DaemonMaster) e se necessario utilizzare una coda come RabbitMQ per passare i dati dall'app ASP.NET ai servizi - ha funzionato al meglio tutte queste soluzioni. Se stai caricando la cache, allora l'esecuzione in ASP.NET ha senso, altrimenti non credo che lo faccia.

• DaemonMaster: link
• Quartz.NET: link

Lo farei nel modo giusto e ho un servizio di Windows in esecuzione che monitora una "coda". Dico "coda" perché programmare con MSMQ è come attaccare mazze bollenti nei bulbi oculari.

Mi sono innamorato della semplicità di Ritardato :: Lavoro in Rails, e qualcosa di simile potrebbe essere fatto facilmente in .NET.

Fondamentalmente si aggiunge qualsiasi tipo di SomethingOperation (qualcosa che ha un metodo Perform() ). Quindi serializzate semplicemente i parametri rilevanti, assegnategli una priorità, una sorta di comportamento di retry predefinito e inseritelo in un database.

Il tuo servizio controllerebbe solo questo e lavorerebbe i lavori in coda.

Siamo stati molto contenti di un approccio basato sul bus di servizio / coda di messaggi / servizio. L'architettura di base è questa.

Il sito Web invia un messaggio alla coda

bus.Send(new ProjectApproved()); // returns immediately

Il servizio Windows riceve ed elabora il messaggio a suo tempo

public class DoesSomethingAwesome : ConsumerOf<ProjectApproved>
{
   public void Consume(ProjectApproved Message)
   {
      // Do something "offline"
   }
}

Il vantaggio è che non vi è alcun ritardo per il servizio front-end che anche gli utenti sono connessi. Il servizio Windows può essere arrestato e aggiornato senza interruzioni sul sito principale. Inoltre è estremamente veloce .

Se non riesci a memorizzare tutti i tuoi dati all'interno del messaggio, puoi sempre memorizzarlo e recuperarlo in seguito. Suggerisco di utilizzare un meccanismo di archiviazione dei documenti come: RavenDB o MongoDB dove è molto semplice memorizzare le tue lezioni senza modifiche.

Il sito Web invia un messaggio alla coda

// Save your object
store.Save(completeProject);

// Send a message indicating its ready to be processed
bus.Send(new ProjectApproved() { ProjectId = completeProject.Id });

Il servizio Windows riceve ed elabora il messaggio a suo tempo

public class DoesSomethingAwesome : ConsumerOf<ProjectApproved>
{
   public void Consume(ProjectApproved Message)
   {
      // Retrieve your object back
      var completeProject = store.Get(Message.ProjectId);
   }
}

Per semplificare le cose usiamo: Rhino ESB e Topshelf . La configurazione è estremamente semplice e l'implementazione di un'applicazione esistente ha richiesto molto tempo.

Sono curioso del perché una combinazione dei due non sia un'opzione praticabile. In questo momento si attivano i processi nelle visualizzazioni di pagina, con qualche sfortunato linfasto che rimane bloccato in attesa di 10 secondi per la pagina. Almeno questa è la mia comprensione del tuo metodo attuale.

Tuttavia, questi lavori richiedono sempre più tempo per essere eseguiti man mano che il sito cresce e non si vuole far deragliare l'esperienza utente sul sito. Nemmeno per pochi (o forse molti) sfortunati utenti durante tutto il giorno, quindi ora stai pensando di pianificare i lavori in background.

Non vedo perché un lavoro in background eseguito ad intervalli regolari non possa imitare un visitatore. Ora non sono un programmatore di Windows, ma nel mondo di Linux vorrei impostare un cron job che funzioni a intervalli regolari, e avrebbe 2 linee di codice.

#!/bin/bash
wget -O /dev/null http://stackoverflow.com/specially_crafted_url

Combina i vantaggi di entrambi i sistemi. È fatto in background. Non ha effetto sugli utenti. Utilizza ancora una visualizzazione di pagina per avviare il lavoro. Ho visto questo approccio usato prima. Tende ad essere la via di mezzo tra i semplici modi del passato e le vie più complesse che scendono lungo la strada.

Aggiorna

Penso che tu possa aggirare il problema del bilanciamento del carico eseguendo i job runner sui server web stessi. Il job runner estrae un URL dalla coda dei lavori e lo esegue in questo modo:

wget -O /dev/null http://localhost/specially_crafted_url

A causa della natura delle code di lavoro / di messaggistica, i lavori verranno equamente distribuiti tra i job runner, il che significa che il file SPECIAL_crafted_url verrà infine distribuito tra i server Web.

Penso che l'approccio con il puro servizio sia che il codice è sparpagliato nel servizio e lontano dall'app principale.

Ecco cosa abbiamo fatto con lavori di grandi dimensioni in background non sensibili al tempo, che mantengono unito il codice e semplifica il servizio:

1. Crea una coda lavori (in memoria o DB, qualunque sia la persistenza necessaria per i tipi di lavori)
2. Crea un servizio Web che eseguirà i lavori in coda
3. L'app di servizio Morto semplice che chiama il servizio web a intervalli specificati, lascia tutte le cose complesse (recupero ed esecuzione del lavoro) al servizio web nella base di codice principale.

Ancora più semplice, è sufficiente effettuare la chiamata in un'app console e utilizzare Task Scheduler o VisualCron per trasformarlo in un "servizio".

Mi è piaciuto TopShelf. Mantiene la semplicità, ma continua a farlo nel modo corretto come servizio Windows. Fondamentalmente crea un'app Console, aggiungi circa 15-20 righe di codice, quindi si installa come un servizio.

link

Che ne dici di avere un servizio Windows molto semplice che gira sul server web e colpisce periodicamente un URL di manutenzione che svolge le tue attività varie. Abbassa la quantità di lavoro che fa in una determinata richiesta.

Ho intenzione di invertire la tendenza apparente qui e suggerire di andare per il modello in-IIS. L'ho usato da solo e funziona davvero bene. Non è davvero così difficile implementare una discreta classe di pool di thread (nel corso degli anni, ho esteso la mia classe di thread pool per supportare la creazione dinamica e la distruzione di thread, riprovare i lavori e così via). I vantaggi sono:

• Nessun servizio esterno da monitorare
• Semplicità di implementazione: nessun marshalling tra processi, nessun monitoraggio avanzato del lavoro
• Sei ancora all'interno del tuo processo IIS, così puoi fare tutto il tuo solito logging e così via (non c'è bisogno di più file di log)
• Implementazione estremamente semplificata (quando si aggiorna un servizio, è necessario interrompere il servizio, copiare i file, avviare il servizio - questo è in aggiunta ai normali aggiornamenti del codice del sito Web)

A mio parere, una soluzione in-IIS è semplicemente il "prossimo passo in avanti" dal portare a grandi linee il lavoro su viste di pagina casuali.

Resque è bello. O anche Kthxbye se devi ricevere una notifica del valore risultante una volta completato.

Sia per Redis / Ruby che per

Onestamente, se stai facendo un approccio basato sul servizio, non ha davvero bisogno di essere super-integrato con la tua attuale piattaforma, che ritengo sia un vantaggio. Spero che potrebbe essere un sistema di set-and-forget che dovrebbe essere eseguito (con il monitoraggio di qualche tipo) e completare i lavori. Non sono sicuro che debba essere eseguito sulla stessa piattaforma a partire dal suo aggiornamento / modifica delle informazioni del database.

Abbastanza sicuro che potresti farcela con molto di più per molto meno se hai coltivato questo tipo di lavoro su un'entità separata, specialmente perché sembra che tu abbia a che fare con problemi di threading. Entrambi Resque e Kthxbye spostano il elaborazione per separare i processi per consentire al sistema operativo di gestire la concorrenza.

Resque

Kthxbye

Utilizzerei un servizio WCF ospitato da WAS ascoltando una coda MSMQ.

Professionisti

• attiva e dimentica i messaggi unidirezionali dall'app Web

• Limitazione e riprogrammazione MSMQ / WCF

• Consegna garantita; D

• Gestione della lettera morta

• Elaborazione distribuita

• Attivazione WAS / MSMQ

Con di

• MSMQ (non è morto ... ancora)

Le funzionalità MSMQ in WCF rendono davvero piacevole l'utilizzo di MSMQ. Sì, sanguinerete nella configurazione ma i benefici supereranno il sacrificio.

Mi sono imbattuto in questo un paio di volte quando sviluppavo applicazioni web. Lo stiamo risolvendo creando un'applicazione per console Windows che svolge l'attività e creando un'attività pianificata che viene eseguita ogni tanto per eseguire effettivamente l'attività.

Puoi eseguire lo shunt di lavoro su un thread in background (o su molti thread in background) usando Rx e qualcosa di simile al seguente:

var scheduler = new EventLoopScheduler( SchedulerThreadName );
_workToDo = new Subject<Action>();
var queueSubscription = _workToDo.ObserveOn( scheduler ).Subscribe( work => work() );
_cleanup = new CompositeDisposable( queueSubscription, scheduler );

Da usare:

var work = () => { ... };
_workToDo.OnNext( work ); // Can also put on error / on complete in here

Ospita tutto ciò che all'interno di una classe che ne esiste sempre uno (o anche un singleton, ma fallo correttamente - usa il contenitore IoC per determinare lo stile di vita).

Puoi controllare la dimensione del pool di thread ecc. scrivendo uno scheduler personalizzato invece di usare EventLoopScheduler (che esegue un singolo thread).

Ho implementato questo tipo di cose un paio di volte. Su Windows, ho creato un programma da riga di comando Python che fa qualcosa in vari momenti. Questo programma espone anche un'interfaccia xmlrpc su una porta. Quindi, un processo pianificato esegue ogni minuto e interroga le interfacce xmlrpc. Se non sono attivi, prova a lanciarli. Se non può, mi invia un messaggio di posta elettronica.

Il vantaggio è che il lavoro che viene eseguito non è cron o programmato. Ho un processo che viene eseguito ogni secondo, ma aspetterà sempre più a lungo tra l'avvio di un nuovo lavoro a seconda del lavoro da svolgere. Inoltre, può essere utilizzato per agire in modo intelligente in base al risultato. Hai un errore 500? Hai un ritardo molto lungo? Fai qualcos'altro. Notifica un altro servizio. Ecc.

E lo stesso sistema funziona su Unix, con piccole modifiche.

Non ho una risposta per te, ma il problema ha suonato un campanello - ricordo alcuni ragazzi casuali discutendone su un podcast una volta .

Spolsky: I noticed one of the questions you asked on the blog was how should you handle maintenance recurring tasks in general?

Atwood: Yes.

Spolsky: Is that a fair characterization? Every website has some tasks that you don't want to execute at the time a web page is loading, but you want to execute with some recurrence of some sort.

Atwood: Ya, background tasks sort of thing.

Spolsky: Ya, so what did you figure out?

Atwood: Well, I originally asked on Twitter, because I just wanted something light weight. I really didn't want to like write a windows service. I felt like that was out of band code. Plus the code that actually does the work is a web page in fact, because to me that is a logical unit of work on a website is a web page. So, it really is like we are calling back into the web site, it's just like another request in the website, so I viewed it as something that should stay inline, and the little approach that we came up that was recommended to me on Twitter was to essentially to add something to the application cache with a fixed expiration, then you have a call back so when that expires it calls a certain function which does the work then you add it back in to the cache with the same expiration. So, it's a little bit, maybe "ghetto" is the right word.

Panoramica dell'API Java della coda delle attività

Concetti relativi alle attività Nell'elaborazione in background di App Engine, un'attività è una descrizione completa di una piccola unità di lavoro. Questa descrizione è composta da due parti:

• Un carico utile di dati che parametrizza l'obiettivo.
• Codice che implementa l'attività.

Attività come hook Web offline
Fortunatamente Internet fornisce già una soluzione del genere, sotto forma di una richiesta HTTP e della sua risposta. Il carico utile dei dati è il contenuto della richiesta HTTP, come variabili del modulo Web, XML, JSON o dati binari codificati. Il codice di riferimento è l'URL stesso; il codice effettivo è la logica che il server esegue nella preparazione della risposta.

Effettua entrambi

Aggiungi un parametro facoltativo al percorso della domanda che esegue il lavoro su cui stai attualmente piggybacking sulle richieste degli utenti:

Manutenzione delle attività in background su un sito di grandi dimensioni

Crea un'app console che viene eseguita su ciascun server e apre il file binario condiviso del registro IIS e lo legge alla fine corrente del file. Utilizzare un filesystemwatcher o un intervallo di tempo per leggere avanti per raccogliere gli aggiornamenti mentre IIS ha scaricato il log.

Utilizza queste informazioni per determinare quali pagine sono state visualizzate al momento.

Usa gli URL delle pagine del log analizzato per chiamare la versione "extrastuff" dell'URL su localhost con un oggetto webclient.

Aggiungi del codice per cambiare file alla fine di ogni periodo di registrazione o riavvia il processo per ciascun periodo di registrazione.