Mantenimiento de tareas en segundo plano en un sitio grande

Hace unas semanas pregunté a pregunta similar sobre SO. En pocas palabras, mi enfoque desde hace algún tiempo ha sido desarrollar un servicio de Windows. Usaría NServiceBus (esencialmente MSMQ bajo las cubiertas) para reunir las solicitudes de mi aplicación web a mi servicio. Solía usar WCF, pero hacer que una transacción distribuida funcionara correctamente a través de WCF siempre parecía ser una molestia. NServiceBus hizo el truco, podía ingresar datos y crear tareas en una transacción y no preocuparme de si mi servicio estaba funcionando en ese momento. Como ejemplo simple, si alguna vez tuviera que enviar un correo electrónico (por ejemplo, un correo electrónico de registro), crearía la cuenta de usuario y dispararía una señal a mi Servicio de Windows (para enviar el correo electrónico) en una transacción. El controlador de mensajes en el lado del servicio recogerá el mensaje y lo procesará en consecuencia.

Desde que ASP .NET 4.0 y AppFabric se han lanzado, existen varias alternativas viables al mecanismo anterior. Refiriéndonos a la pregunta que mencioné anteriormente, ahora tenemos AppInitialize de AppFabric (a través de net.pipe), así como la función de inicio automático de ASP .NET 4.0, que hace que el desarrollo de los servicios de Windows como aplicaciones web sea una alternativa viable. He empezado a hacer esto ahora por varias razones (una de las más importantes es que la implementación ya no es un problema):

1. Puede desarrollar una interfaz de usuario web a través de su servicio (ya que se ejecuta como una aplicación web). Esto es extremadamente útil para ver lo que está sucediendo en el tiempo de ejecución.
2. Su modelo de implementación para sus aplicaciones web funcionará para su aplicación de servicio.
3. IIS proporciona algunas características interesantes para manejar fallas de aplicaciones (similar en algunos aspectos a un servicio de Windows).
4. Los desarrolladores web están muy familiarizados con el desarrollo de aplicaciones web (naturalmente), la mayoría no sabe mucho sobre las mejores prácticas al desarrollar un servicio de Windows.
5. Ofrece varias alternativas para exponer una API para que otras aplicaciones la consuman.

Si sigues esta ruta (perdóname por copiar y pegar desde mi publicación original) definitivamente consideraría ejecutar la lógica de fondo en una aplicación web separada. Hay varias razones para esto:

1. Seguridad . Puede haber un modelo de seguridad diferente para la interfaz de usuario que muestra información sobre los procesos en segundo plano en ejecución. No quisiera exponer esta IU a nadie más que al equipo de operaciones. Además, la aplicación web puede ejecutarse como un usuario diferente que tiene un conjunto elevado de permisos.
2. Mantenimiento . Sería genial poder implementar cambios en la aplicación que aloja los procesos en segundo plano sin afectar el uso del usuario en el sitio web frontal.
3. Rendimiento . Tener la aplicación separada del sitio principal que procesa las solicitudes de los usuarios significa que los subprocesos en segundo plano no disminuirán la capacidad de IIS para manejar la cola de solicitudes entrantes. Además, la aplicación que procesa las tareas en segundo plano podría implementarse en un servidor separado si fuera necesario.

Al hacer esto vuelve al aspecto de cálculo de referencias. WCF, NServiceBus / RabbitMQ / ActiveMQ etc., MSMQ de vainilla, RESTful API (piense en MVC) son todas opciones. Si está utilizando Windows Workflow 4.0, podría exponer un punto final de host que su aplicación web podría consumir.

El enfoque de alojamiento web para los servicios todavía es bastante nuevo para mí, solo el tiempo dirá si fue la elección correcta. Hasta ahora todo bien. Por cierto, si no quieres usar AppFabric (no pude porque, por alguna extraña razón, Windows Server Web Edition no es compatible), la función de inicio automático mencionada en la publicación de Gu funciona muy bien. Sin embargo, manténgase alejado del archivo applicationhost.config, todo lo que se encuentra en esa publicación se puede configurar a través de la consola IIS (Editor de configuración en el nivel del servidor principal).

Nota: originalmente había publicado algunos enlaces más en este mensaje, pero ¡ay, esta es mi primera publicación en este intercambio y solo se admite un enlace! Básicamente, había otros dos, para que Google obtuvieran "Muerte a los servicios de Windows ... ¡Larga vida en aplicaciones de Fabric!" y "auto-start-asp-net-applications". Lo siento por eso.

En realidad, existe una tercera forma en Windows para ejecutar servicios en segundo plano, y es muy común en el mundo UNIX. La tercera forma es un trabajo CRON que ejecuta una parte de su infraestructura. En Windows, esto se conoce como task scheduler y es muy común para ejecutar código de forma programada. Para usar esto, debe crear una aplicación de línea de comandos que se ejecute en un horario predefinido. La ventaja de esto es que no tiene que preocuparse si el proceso sigue funcionando como un servicio, porque si falla por alguna razón, la próxima vez se iniciará.

En cuanto a calcular las tareas específicas, realmente solo necesitas almacenar estas tareas en un almacenamiento binario persistente. Hasta que la aplicación de la línea de comandos los saca del almacenamiento y los ejecuta. He hecho esto en el pasado utilizando la base de datos Cassandra como Proveedor de estado de sesión para rellenar tareas en segundo plano para usuarios específicos en la base de datos Cassandra, y luego hacer que la línea de comandos los seleccione y los ejecute para el usuario.

Puede que esta no haya sido la solución de cálculo de referencias típica, pero funcionó muy bien para mí y resultó ser una solución muy elegante, ya que las tareas programadas sobrevivieron a paradas, problemas de red y cualquier máquina podría ejecutar la tarea ya que fue almacenado centralmente.

Promoción descarada, pero este es mi proyecto y la solución que acabo de detallar brevemente es la razón por la que creé el proyecto: enlace

Aplicación web Cron +

Este es un diseño probado en la batalla que se escala horizontalmente junto con su granja de servidores web y garantiza que esté utilizando la pila de tecnología web que ya conoce.

Así es como funciona:

1. Cree un controlador / acción en su aplicación web para manejar las tareas programadas en segundo plano. Por convención, normalmente llamo mía http://mydomain.com/system/cron .
2. Por seguridad, esta acción debe estar bloqueada solo para las direcciones IP autenticadas en la red local.
3. En una máquina separada, instale Wget y configure a Tarea programada para que Wget obtenga el recurso del paso 1. Puede hacer que la tarea se ejecute con la frecuencia que desee (I normalmente optan por 30 segundos). No olvide pasar el argumento de cookie apropiado a Wget para que se autentique en su aplicación web.
4. Para redundancia, también puede instalar un segundo wget programado en una segunda máquina.

¡Hurra! Ahora tienes una ruta que será llamada cada 30 segundos. Y si la solicitud tarda 5 minutos en procesarse, a nadie le importará, porque no forma parte de la solicitud de la página de un usuario.

La acción cron termina pareciendo muy simple: tiene una lista de métodos para ejecutar en una determinada frecuencia. Cuando llega una solicitud, ve si hay un método que debe ejecutarse y llama al método apropiado. Esto significa que puedes controlar la programación en tu base de datos , donde probablemente ya tengas muchos otros datos de configuración importantes para tu sitio.

Más importante (para usted), esto significa que sus trabajos no tienen que ser llamados en un horario fijo. Puede escribir cualquier lógica que desee para determinar cuándo ejecutar un método.

Pros y Contras

• Ya eres muy bueno escribiendo el código MVC de ASP.NET, así que esto te permite escribir tus tareas en segundo plano en la misma plataforma en la que escribes el resto de tu solución.
• Las tareas se ejecutan en el mismo contexto que su aplicación web, de modo que puede compartir el caché y hacer uso de métodos de ayuda que ya existen.
• Si tiene que obtener una URI de carga equilibrada , sus tareas en segundo plano ahora también tienen carga equilibrada.
• Implementación simultánea : no tiene que preocuparse por sincronizar su aplicación web con su lógica de tarea en segundo plano, ya que todas están en la misma implementación.

• A lo largo de los años, algunas personas me han dicho que este diseño está "muy acoplado", pero cuando se presionan no han podido explicar por qué eso es malo.

Nota: Si tiene alguna pregunta o inquietud, agregue un comentario . Estoy feliz de elaborar.

He probado y usado casi todas las formas posibles de hacer esto en mi aplicación actual. Comencé a hacer lo mismo que usted actualmente, a cuestas de una solicitud de un usuario para completar los datos y luego guardarlos en caché. Me di cuenta de que esto también era una mala idea (especialmente a medida que se escala a múltiples servidores web, más usuarios reciben el impacto).

También he tenido un trabajo programado que llega a una URL en la aplicación ASP.NET. Esta es una solución decente, pero comienza a descomponerse en el momento en que se pasa de 1 servidor web.

Actualmente utilizo dos métodos diferentes, ambos utilizando Quartz.NET, que es una pequeña biblioteca. El primero es Quartz.NET ejecutándose en proceso con ASP.NET, se configura en global.asax y se ejecuta cada par de minutos. Lo uso para actualizar el caché de ASP.NET fuera de banda, que es la única razón por la que se ejecuta como parte de ASP.NET.

La segunda es que escribí una biblioteca para envolver Quartz.NET llamada DaemonMaster, que facilita colocar una DLL en un directorio y hacer que se ejecute en un servicio de Windows. Descubrí que ayuda a evitar algunas de las partes molestas de trabajar con un Servicio de Windows y también limpia la API de Quartz.NET. Los servicios que se ejecutan a través de DaemonMaster son de dos tipos diferentes, los primeros son trabajos que deben ejecutarse cada noche o cada X minutos. Los otros trabajos trabajan fuera de una cola en función de los datos provenientes de la aplicación ASP.NET. La aplicación ASP.NET descarta objetos JSON en RabbitMQ y los servicios sondean RabbitMQ y luego procesan los datos.

En base a esto, sugeriría que vaya con un servicio de Windows (y visite DaemonMaster) y si es necesario use una cola como RabbitMQ para pasar los datos de la aplicación ASP.NET a los servicios. Todas estas soluciones. Si está cargando la memoria caché, entonces la ejecución en ASP.NET tiene sentido, de lo contrario no creo que lo haga.

• DaemonMaster: enlace
• Quartz.NET: enlace

Lo haría de la manera correcta y tendría un servicio de Windows ejecutando que monitorea una "cola". Digo "cola" porque la programación con MSMQ es similar a pegar hot poker en tus globos oculares.

Me he enamorado de la simplicidad de Delayed :: Trabajo en Rails, y algo similar podría hacerse fácilmente en .NET.

Básicamente, agregas cualquier tipo de SomethingOperation (algo que tiene un método Perform() ). Luego simplemente serialice los parámetros relevantes, déle una prioridad, algún tipo de comportamiento de reintento predeterminado y rellénelo en una base de datos.

Su servicio solo lo controlaría y trabajaría los trabajos en la cola.

Estamos muy contentos con el enfoque de Service Bus / Message Queue / Service. La arquitectura básica es la siguiente.

El sitio web envía un mensaje a la cola

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

El servicio de Windows recibe y procesa el mensaje en su propio momento

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

La ventaja es que no hay demora para el servicio de front-end que los usuarios también están conectados. El servicio de Windows puede cerrarse y actualizarse sin interrupción al sitio principal. Además, es extremadamente rápido .

Si no puede almacenar todos sus datos dentro del mensaje, siempre puede almacenarlos y recuperarlos más tarde. Sugiero utilizar un mecanismo de almacenamiento de documentos como: RavenDB o MongoDB donde es muy sencillo almacenar tus clases sin cambios.

El sitio web envía un mensaje a la cola

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

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

El servicio de Windows recibe y procesa el mensaje en su propio momento

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

Para simplificar las cosas, usamos: Rhino ESB y Topshelf . La configuración es extremadamente simple y poner esto en práctica para una aplicación existente ha demorado muy poco tiempo.

Tengo curiosidad por qué una combinación de los dos no es una opción viable. En este momento, se activan trabajos en las vistas de página, con un poco de mala suerte que se queda atascado esperando 10 segundos para que aparezca la página. Al menos esa es mi comprensión de tu método actual.

Sin embargo, esos trabajos tardan más y más en ejecutarse a medida que el sitio crece, y no desea descarrilar la experiencia del usuario en el sitio. Ni siquiera para algunos (o quizás muchos) usuarios desafortunados a lo largo del día, por lo que ahora está pensando en programar trabajos en segundo plano.

No veo por qué un trabajo en segundo plano ejecutado a intervalos regulares no puede imitar a un visitante. Ahora no soy programador de Windows, pero en el mundo de Linux configuraría un trabajo cron que se ejecuta en un intervalo regular, y tendría 2 líneas de código.

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

Combina las ventajas de ambos sistemas. Se hace en el fondo. No afecta a los usuarios. Todavía utiliza una vista de página para iniciar el trabajo. He visto este enfoque utilizado antes. Tiende a ser el punto medio entre las formas simples de antaño y las formas más complejas que surgen en el camino.

Actualizar

Creo que puede solucionar el problema de equilibrio de carga ejecutando los ejecutores de trabajos en los servidores web. El corredor de trabajos extrae una URL de la cola de trabajos y la ejecuta así:

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

Debido a la naturaleza de las colas de trabajo / mensajería, los trabajos se distribuirán de manera uniforme entre los corredores de trabajos, lo que significa que special_crafted_url se distribuirá finalmente entre sus servidores web.

Creo que la contra con el enfoque de servicio puro es que tienes un código disperso en el servicio y alejado de la aplicación principal.

Esto es lo que hemos hecho con trabajos de gran tamaño no sensibles al tiempo, que mantienen el código unido y simplifican el servicio:

1. Cree una cola de trabajos (ya sea en memoria o DB, independientemente de la persistencia necesaria para los tipos de trabajos)
2. Cree un servicio web que ejecutará los trabajos en cola
3. La aplicación de servicio simple y simple que llama al servicio web en un intervalo específico, deja todas las cosas complejas (recuperación y ejecución del trabajo) al servicio web en su base de código central.

Aún más simple, solo haga la llamada en una aplicación de consola y use el Programador de tareas o VisualCron para convertirlo en un "servicio".

Me gustó TopShelf. Mantiene la simplicidad y, sin embargo, sigue funcionando correctamente como un servicio de Windows. Básicamente, cree una aplicación de consola, agregue alrededor de 15-20 líneas de código, luego se instala como un servicio.

enlace

¿Qué tal tener un servicio de Windows muy simple que se ejecute en el servidor web y que periódicamente llegue a una URL de mantenimiento que realice sus diversas tareas? Haga que acelere la cantidad de trabajo que realiza en una solicitud determinada.

Voy a oponerme a la tendencia aparente aquí y sugeriré ir por el modelo in-IIS. Lo he usado yo mismo y funciona muy bien. Realmente no es tan difícil implementar una clase de grupo de subprocesos decente (a lo largo de los años, he ampliado mi clase de grupo de subprocesos para admitir la creación y destrucción de subprocesos, reintentar trabajos, etc.) Las ventajas son:

• No hay servicio externo para monitorear
• Simplicidad de la implementación: sin ordenación cruzada de procesos, sin supervisión avanzada de trabajos
• Todavía estás dentro de tu proceso de IIS, por lo que puedes hacer todo tu registro habitual y así sucesivamente (sin necesidad de múltiples archivos de registro)
• Implementación enormemente simplificada (cuando actualiza un servicio, debe detener el servicio, copiar los archivos, iniciar el servicio, además de sus actualizaciones habituales del código del sitio web)

En mi opinión, una solución en IIS es simplemente el "siguiente paso" de llevar el trabajo a vistas de página aleatorias.

Resque es agradable. O incluso Kthxbye si necesita que se le notifique el valor resultante una vez que se complete.

Ambos basados en Redis / Ruby.

Honestamente, si está haciendo un enfoque basado en el servicio, realmente no necesita estar super integrado con su plataforma actual, lo que creo que es una ventaja. Espero que pueda ser un sistema de configuración y olvido que se ejecute (con algún tipo de supervisión) y trabajos completos. No estoy seguro de que deba ejecutarse en la misma plataforma, ya que solo está actualizando / modificando la información de la base de datos.

Bastante seguro de que podría salirse con la suya con mucho más por mucho menos si trabajara en una entidad separada, especialmente porque parece que está lidiando con problemas de subprocesos. Tanto Resque como Kthxbye mueven el procesando procesos separados para permitir que el sistema operativo maneje la concurrencia.

Resque

Kthxbye

Utilizaría un servicio WCF alojado por WAS para escuchar una cola de MSMQ.

Pro's

• Dispare y olvide mensajes de una vía desde la aplicación web

• Limitación y reintento de MSMQ / WCF

• Entrega garantizada; D

• Gestión de carta muerta

• Procesamiento distribuido

• Activación WAS / MSMQ

Con's

• MSMQ (no está muerto ... todavía)

Las características de MSMQ en WCF hacen que el uso de MSMQ sea realmente bueno. Sí, sangrarás en la configuración, pero los beneficios superarán el sacrificio.

Me he encontrado con esto un par de veces al desarrollar aplicaciones web. Lo hemos estado resolviendo creando una aplicación de consola de Windows que lleva a cabo la tarea y creando una tarea programada que se ejecuta cada cierto tiempo para hacer la tarea.     

Puedes derivar el trabajo en un hilo de fondo (o muchos hilos de fondo) usando Rx y algo como lo siguiente:

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

Para usar:

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

Aloje todo eso dentro de una clase de la que solo haya uno (también conocido como singleton, pero hágalo correctamente; use su contenedor IoC para determinar el estilo de vida).

Puede controlar el tamaño del grupo de subprocesos, etc. escribiendo un programador personalizado en lugar de usar el EventLoopScheduler (que ejecuta un solo subproceso).

He implementado este tipo de cosas varias veces. En Windows, configuré un programa de línea de comandos de Python que hace algo en varias ocasiones. Este programa también expone una interfaz xmlrpc en un puerto. Luego, un trabajo de tarea programada se ejecuta cada minuto y consulta las interfaces xmlrpc. Si no están arriba, intenta lanzarlos. Si no puede, me envía un correo electrónico.

La ventaja es que el trabajo que se ejecuta no es cron o enlazado a la programación. Tengo un trabajo de proceso que se ejecuta cada segundo, pero esperará más y más tiempo entre comenzar un nuevo trabajo dependiendo de si tenía trabajo que hacer. Además, se puede utilizar para actuar de forma inteligente en función del resultado. ¿Tienes un error 500? ¿Tienes un retraso muy largo? Hacer algo más. Notificar a otro servicio. Etc.

Y el mismo sistema funciona en Unix, con modificaciones menores.

Yo no tengo una respuesta para ti, pero el problema sonó. Recuerdo que algunos chicos al azar lo comentaron en un podcast una vez .

  

Spolsky: noté una de las   preguntas que hiciste en el blog fue   ¿Cómo debe manejar el mantenimiento?   ¿Tareas recurrentes en general?

     

Atwood: Sí.

     

Spolsky: ¿Es eso una feria?   ¿caracterización? Cada sitio web tiene   algunas tareas que no quieres   ejecutar en el momento en que una página web es   cargando, pero quieres ejecutar con   alguna recurrencia de algún tipo.

     

Atwood: Ya, tareas de fondo como   cosa.

     

Spolsky: Ya, ¿qué pensaste?   fuera?

     

Atwood: Bueno, originalmente pregunté en   Twitter, porque solo quería   algo de peso ligero. Yo realmente   No quería que me gustara escribir una ventana   Servicio. Sentí que eso estaba fuera de   código de la banda. Más el código que en realidad   ¿El trabajo es una página web, de hecho,   Porque para mí eso es una unidad lógica.   de trabajo en un sitio web es una página web.   Entonces, realmente es como estamos llamando   de nuevo en el sitio web, es como   Otra solicitud en el sitio web, así que   visto como algo que debería   Quédate en línea, y el pequeño acercamiento.   que se nos ocurrió que fue recomendado   para mí en Twitter era esencialmente para   añadir algo a la caché de la aplicación   con una caducidad fija, entonces tienes   una llamada de vuelta así que cuando eso expire   llama a una determinada función que hace   El trabajo entonces lo agregas de nuevo a   El caché con la misma caducidad.   Por lo tanto, es un poco, tal vez "gueto"   es la palabra correcta.

Conceptos de tareas
En el procesamiento en segundo plano de App Engine, una tarea es una descripción completa de una pequeña unidad de trabajo. Esta descripción consta de dos partes:

• Una carga útil de datos que parametriza la tarea.
• Código que implementa la tarea.

Tareas como enlaces web sin conexión
Afortunadamente, Internet ya proporciona una solución de este tipo, en forma de una solicitud HTTP y su respuesta. La carga útil de datos es el contenido de la solicitud HTTP, como las variables de formulario web, XML, JSON o datos binarios codificados. La referencia del código es la propia URL; el código real es cualquier lógica que el servidor ejecute al preparar la respuesta.

Haz ambas cosas

Agregue un parámetro opcional a la ruta de la pregunta que realiza el trabajo que actualmente está realizando en las solicitudes de los usuarios:

Mantenimiento de tareas en segundo plano en un sitio grande

Cree una aplicación de consola que se ejecute en cada servidor y abra el registro binario compartido de IIS y lo lea hasta el final actual del archivo. Use un observador del sistema de archivos o un intervalo de tiempo para leer hacia adelante para recopilar actualizaciones a medida que IIS vació el registro.

Utilice esta información para determinar qué páginas se han visto actualmente.

Use las direcciones URL de la página del registro analizado para llamar a la versión "extrastuff" de la URL en localhost con un objeto cliente web.

Agregue algún código para cambiar los archivos al final de cada período de registro o reinicie el proceso cada período de registro.