Manutenção de tarefas em segundo plano em um site grande

Algumas semanas atrás eu pedi um pergunta semelhante em SO. Em uma casca de noz, minha abordagem há algum tempo tem sido desenvolver um serviço do Windows. Eu usaria o NServiceBus (basicamente o MSMQ, sob as coberturas) para organizar solicitações do meu aplicativo da web para o meu serviço. Eu costumava usar o WCF, mas obter uma transação distribuída para funcionar corretamente sobre o WCF sempre parecia uma dor no rabo. O NServiceBus fez o truque, eu poderia comprometer dados e criar tarefas em uma transação e não me preocupar se meu serviço estava funcionando no momento. Como um exemplo simples, se alguma vez eu precisasse enviar um email (por exemplo, um email de registro) eu criaria a conta de usuário e dispararia um sinal para o meu Serviço do Windows (para enviar o email) em uma transação. O manipulador de mensagens no lado do serviço pegaria a mensagem e processaria de acordo.

Desde que o ASP .NET 4.0 e o AppFabric foram lançados, existem várias alternativas viáveis ao mecanismo acima. Voltando à pergunta que mencionei acima, agora temos o AppInitialize (via net.pipe) do AppFabric, bem como o recurso Auto-Start do ASP .NET 4.0, que torna o desenvolvimento dos Serviços do Windows como aplicativos da Web uma alternativa viável. Eu comecei a fazer isso agora por vários motivos (o maior deles sendo a implantação não é mais um problema):

1. Você pode desenvolver uma interface de usuário da web sobre seu serviço (desde que ele esteja sendo executado como um aplicativo da web). Isso é extremamente útil para ver o que está acontecendo no tempo de execução.
2. Seu modelo de implantação para seus aplicativos da Web funcionará para seu aplicativo de serviço.
3. O IIS fornece alguns recursos interessantes para lidar com falhas de aplicativos (semelhantes em alguns aspectos a um serviço do Windows).
4. Os desenvolvedores da Web estão muito familiarizados com o desenvolvimento de aplicativos da Web (naturalmente), a maioria não sabe muito sobre as práticas recomendadas ao desenvolver um serviço do Windows.
5. Ele oferece várias alternativas para expor uma API para consumo de outros aplicativos.

Se você seguir esse caminho (me perdoe por copiar e colar da postagem original), eu definitivamente consideraria a execução da lógica de plano de fundo em um aplicativo da web separado. Há várias razões para isso:

1. Segurança . Pode haver um modelo de segurança diferente para a interface do usuário que exibe informações sobre os processos em segundo plano em execução. Eu não gostaria de expor essa interface para mais ninguém além da equipe de operações. Além disso, o aplicativo da web pode ser executado como um usuário diferente que possui um conjunto elevado de permissões.
2. Manutenção . Seria ótimo poder implantar alterações no aplicativo que hospeda os processos em segundo plano sem afetar o usuário no site do front-end.
3. Desempenho . Ter o aplicativo separado das solicitações do usuário de processamento do site principal significa que os threads de segundo plano não diminuirão a capacidade do IIS de manipular a fila de solicitações de entrada. Além disso, o aplicativo que processa as tarefas em segundo plano pode ser implantado em um servidor separado, se necessário.

Isso retorna ao aspecto do empacotamento. WCF, NServiceBus / RabbitMQ / ActiveMQ etc., baunilha MSMQ, API RESTful (pense MVC) são todas as opções. Se você estiver usando o Windows Workflow 4.0, poderá expor um ponto de extremidade do host que seu aplicativo da Web pode consumir.

A abordagem de hospedagem na web para serviços ainda é relativamente nova para mim, apenas o tempo dirá se foi a escolha correta. Até agora está bom. By the way, se você não quiser usar o AppFabric (eu não poderia porque, por algum motivo bizarro, o Windows Server Web Edition não é suportado), o recurso Auto-Start mencionado no post do Gu funciona muito bem. Fique longe do arquivo applicationhost.config, tudo nessa postagem é possível configurar através do console do IIS (Editor de Configuração no nível do servidor principal).

Nota: originalmente eu tinha postado mais alguns links nesta mensagem, mas, infelizmente, este é o meu primeiro post para esta troca e apenas um link é suportado! Havia basicamente dois outros, para obtê-los do Google "Morte ao Windows Services ... Long Live AppFabric!" e "auto-start-asp-net-applications". Desculpe por isso.

Na verdade, existe uma terceira maneira no Windows para executar serviços de segundo plano, e é muito comum no mundo do UNIX. A terceira maneira é um trabalho CRON que executa uma parte de sua infraestrutura. No Windows, isso é conhecido como task scheduler e é muito comum para executar código de forma programada. Para usá-lo, você criaria um aplicativo de linha de comando executado em um agendamento predefinido. A vantagem disso é que você não precisa se preocupar se o processo continuar funcionando como um serviço, porque se ele falhar por algum motivo, ele será inicializado da próxima vez.

Quanto ao empacotamento de tarefas específicas, você realmente só precisa armazenar essas tarefas em um armazenamento binário persistente. Até que o aplicativo de linha de comando os retire do armazenamento e os execute. Eu fiz isso no passado usando o banco de dados do Cassandra como um Provedor do Estado da Sessão para preencher tarefas em segundo plano para usuários específicos no banco de dados do Cassandra, e depois ter a linha de comando selecioná-los e executá-los para o usuário.

Esta pode não ter sido a típica solução de empacotamento, mas funcionou muito bem para mim e acabou sendo uma solução muito elegante, porque as tarefas agendadas sobreviveram a desligamentos, problemas de rede e qualquer máquina poderia executar a tarefa desde foi armazenado centralmente.

Promoção sem vergonha, mas este é o meu projeto e a solução que acabei de detalhar é por isso que criei o projeto: link

Cron + Web App

Esse é um design testado em batalha que é dimensionado horizontalmente junto com seu farm da web e garante que você esteja usando a pilha de tecnologia da web que você já conhece.

Veja como funciona:

1. Crie um controlador / ação em seu aplicativo da web para lidar com tarefas em segundo plano planejadas. Por convenção, eu geralmente chamo o meu http://mydomain.com/system/cron .
2. Por segurança, essa ação deve ser bloqueada apenas para endereços IP autenticados na rede local.
3. Em uma máquina separada, instale Wget e configure um Tarefa Programada para que o wget busque o recurso da etapa 1. Você pode executar a tarefa com a frequência desejada (I geralmente optar por 30 segundos). Não se esqueça de passar o argumento de cookie apropriado para o Wget para que ele seja autenticado no seu aplicativo da Web.
4. Para redundância, você também pode instalar um segundo wget agendado em uma segunda máquina.

Hooray! Agora você tem uma rota que será chamada a cada 30 segundos. E se a solicitação levar 5 minutos para ser processada, ninguém se importará, porque não faz parte da solicitação de uma página do usuário.

A ação cron acaba parecendo muito simples: ele tem uma lista de métodos para executar em uma determinada frequência. Quando uma solicitação chega, ele vê se há um método que precisa ser executado e chama o método apropriado. Isso significa que você pode controlar o agendamento no seu banco de dados , onde você provavelmente já possui muitos outros dados de configuração importantes para o seu site.

Mais importante (para você), isso significa que seus trabalhos não precisam ser chamados em um horário fixo. Você pode escrever qualquer lógica que quiser para determinar quando executar um método.

Prós e Contras

• Você já é muito bom em escrever código ASP.NET MVC, então isso permite que você escreva suas tarefas em segundo plano na mesma plataforma em que você escreve o restante da sua solução.
• As tarefas são executadas no mesmo contexto que seu aplicativo da Web, para que você possa compartilhar o cache e fazer uso dos métodos auxiliares já existentes.
• Se você tiver que buscar uma URI com balanceamento de carga , suas tarefas em segundo plano agora também terão balanceamento de carga.
• Implantação simultânea - você não precisa se preocupar com a sincronização do seu aplicativo da Web com sua lógica de tarefa em segundo plano, pois todos eles estão na mesma implantação.

• Ao longo dos anos, algumas pessoas me disseram que esse design é "altamente acoplado", mas, quando pressionadas, não conseguem articular por que isso é ruim.

Observação: se houver dúvidas ou preocupações, adicione um comentário . Fico feliz em elaborar.

Eu tentei e usei quase todas as maneiras possíveis de fazer isso em meu aplicativo atual. Eu comecei fazendo a mesma coisa que você faz atualmente, acesse um pedido do usuário para preencher os dados e, em seguida, armazene-os em cache daqui para frente. Eu percebi que esta era uma má ideia também (especialmente quando você escala para múltiplos servidores web, mais usuários pegam o hit).

Eu também tive um trabalho agendado que bate em uma URL no aplicativo ASP.NET - esta é uma solução decente, mas começa a quebrar o minuto que você escalar passado 1 servidor web.

Atualmente eu uso dois métodos diferentes, ambos usando o Quartz.NET, que é uma ótima biblioteca. O primeiro é o Quartz.NET em execução no processo com o ASP.NET, ele é configurado no global.asax e é executado a cada dois minutos. Eu uso isso para atualizar o cache do ASP.NET fora da banda, que é a única razão pela qual ele é executado como parte do ASP.NET.

Com base nisso eu sugiro que você vá com um serviço do Windows (e confira DaemonMaster) e, se necessário, use uma fila como o RabbitMQ para passar os dados do aplicativo ASP.NET para os serviços - funcionou da melhor maneira possível. todas essas soluções. Se você estiver carregando o cache, a execução no ASP.NET faz sentido, caso contrário, não acho.

• DaemonMaster: link
• Quartz.NET: link

Eu faria do jeito certo e teria um serviço do Windows em execução que monitora uma "fila". Eu digo "fila" porque a programação com o MSMQ é semelhante a colocar os "hot pokers" nos seus globos oculares.

Me apaixonei pela simplicidade do Adiado :: Job no Rails, e algo similar poderia ser feito facilmente no .NET.

Basicamente, você adiciona qualquer tipo de SomethingOperation (algo que tem um método Perform() ). Em seguida, basta serializar os parâmetros relevantes, dar a ele uma prioridade, algum tipo de comportamento de repetição padrão e inseri-lo em um banco de dados.

Seu serviço apenas monitoraria isso e trabalharia os trabalhos na fila.

Ficamos muito felizes com uma abordagem de Barramento de Serviços / Fila de Mensagens / Serviço. A arquitetura básica é essa.

O site envia uma mensagem para a fila

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

O serviço do Windows recebe e processa a mensagem em seu próprio horário

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

A vantagem é que não há atraso para o serviço front-end em que os usuários também estão conectados. O serviço do Windows pode ser encerrado e atualizado sem interrupção para o site principal. Além disso, é extremamente rápido .

Se você não puder armazenar todos os seus dados na mensagem, sempre poderá armazená-los e recuperá-los posteriormente. Sugiro usar um mecanismo de armazenamento de documentos, como: RavenDB ou MongoDB onde é muito simples armazenar suas aulas sem alterações.

O site envia uma mensagem para a fila

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

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

O serviço do Windows recebe e processa a mensagem em seu próprio horário

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

Para simplificar, usamos: Rhino ESB e Topshelf . A configuração é extremamente simples e colocar isso em prática para um aplicativo existente provou demorar muito pouco tempo.

Estou curioso porque uma combinação dos dois não é uma opção viável. Agora você aciona trabalhos em visualizações de páginas, com alguma sorte infeliz esperando 10 segundos para a página aparecer. Pelo menos essa é a minha compreensão do seu método atual.

No entanto, esses trabalhos estão demorando mais e mais para serem executados à medida que o site cresce, e você não quer atrapalhar a experiência do usuário no site. Nem mesmo para alguns (ou talvez muitos) usuários infelizes durante o dia, então agora você está pensando em agendar trabalhos em segundo plano.

Não vejo por que um trabalho em segundo plano executado em intervalos regulares não pode imitar um visitante. Agora eu não sou um programador do Windows, mas no mundo Linux eu configuraria um cron job que fosse executado em um intervalo regular, e teria duas linhas de código.

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

Ele combina as vantagens de ambos os sistemas. É feito em segundo plano. Isso não afeta os usuários. Ele ainda usa uma visualização de página para iniciar o trabalho. Eu já vi essa abordagem usada antes. Ele tende a ser o meio-termo entre os caminhos simples do passado e os caminhos mais complexos que vêm pelo caminho.

Atualizar

Acho que você pode contornar o problema de balanceamento de carga executando os corredores de trabalho nos próprios servidores da web. O job runner puxa uma URL para fora da fila de tarefas e a executa da seguinte forma:

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

Devido à natureza das filas de tarefas / mensagens, as tarefas serão distribuídas uniformemente entre os executores da tarefa, o que significa que a especialmente_crafted_url é eventualmente distribuída entre os servidores da Web.

Acho que o problema da abordagem de serviço puro é que você tem código disperso no serviço e longe do aplicativo principal.

Veja o que fizemos com grandes tarefas em segundo plano que não são sensíveis ao tempo, o que mantém o código unido e simplifica o serviço:

1. Crie uma fila de trabalhos (na memória ou no banco de dados, seja qual for a persistência necessária para os tipos de tarefas)
2. Crie um serviço da web que executará os trabalhos na fila
3. Aplicativo de serviço simples inativo que chama o serviço da Web em um intervalo especificado, deixe todas as coisas complexas (recuperação e execução de tarefas) para o serviço da Web em sua base de código principal.

Ainda mais simples, basta fazer a chamada em um aplicativo de console e usar o Agendador de Tarefas ou o VisualCron para transformá-lo em um "serviço".

Eu gostei do TopShelf. Mantém a simplicidade, mas ainda o faz da maneira correta como um serviço do Windows. Basicamente, crie um aplicativo de console, adicione cerca de 15 a 20 linhas de código e, em seguida, instale como um serviço.

link

Que tal ter um serviço do Windows muito simples que é executado no servidor da Web e periodicamente atinge uma URL de manutenção que executa suas tarefas diversas. Aperte o quanto de trabalho ele faz em qualquer solicitação.

Eu vou contrariar a tendência aparente aqui e sugiro ir para o modelo in-IIS. Eu mesmo usei e funciona muito bem. Não é tão difícil implementar uma classe de pool de threads decente (ao longo dos anos, estendi minha classe de pool de threads para dar suporte à criação e destruição dinâmicas de threads, novas tarefas e assim por diante). As vantagens são:

• Nenhum serviço externo para monitorar
• Simplicidade de implementação: sem empacotamento entre processos, sem monitoramento avançado de tarefas
• Você ainda está dentro do processo do IIS, portanto, pode fazer todo o seu registro normal e assim por diante (sem necessidade de vários arquivos de log)
• Implantação simplificada (quando você atualiza um serviço, você precisa interromper o serviço, copiar os arquivos, iniciar o serviço - isso é uma adição às atualizações habituais do código do site)

Na minha opinião, uma solução in-IIS é simplesmente o "próximo passo" de pegar carona no trabalho em visualizações de página aleatórias.

Resque é legal. Ou até mesmo Kthxbye se você precisar ser notificado sobre o valor resultante quando estiver concluído.

Ambos Redis / Ruby baseiam tho.

Tenho certeza que você poderia se safar com muito mais por muito menos se você criasse esse tipo de trabalho para uma entidade separada, especialmente porque parece que você está lidando com problemas de encadeamento. Ambos Resque e Kthxbye movem o processando para separar processos para permitir que o SO manipule a simultaneidade.

Resque

Kthxbye

Eu usaria um serviço WCF hospedado no WAS para ouvir uma fila do MSMQ.

Pro

• Ative e esqueça mensagens de uma forma do aplicativo da Web

• Limitação e repetição do MSMQ / WCF

• Entrega garantida; D

• Gerenciamento de devoluções

• Processamento distribuído

• Ativação do WAS / MSMQ

Con's

• MSMQ (não está morto ... Ainda)

Os recursos do MSMQ no WCF tornam o uso do MSMQ realmente legal. Sim, você vai sangrar na configuração, mas os benefícios superam o sacrifício.

Eu me deparei com isso algumas vezes ao desenvolver aplicativos da web. Estamos resolvendo isso criando um aplicativo de console do Windows que executa a tarefa e criando uma tarefa agendada que é executada com frequência para realizar a tarefa.

Você pode desviar o trabalho para um thread de segundo plano (ou muitos threads de segundo plano) usando o Rx e algo como o seguinte:

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

Hospede tudo o que estiver dentro de uma classe que só existe um (também conhecido como singleton, mas faça-o corretamente - use seu contêiner IoC para determinar o estilo de vida).

Você pode controlar o tamanho do conjunto de encadeamentos, etc., gravando um planejador personalizado no lugar de usar o EventLoopScheduler (que executa um único encadeamento).

Eu tenho implementado esse tipo de coisa algumas vezes. No Windows, eu configurei um programa de linha de comando em Python que faz algo em vários momentos. Este programa também expõe uma interface xmlrpc em uma porta. Em seguida, um trabalho de tarefa agendada é executado a cada minuto e consulta as interfaces xmlrpc. Se eles não estiverem ativos, ele tenta iniciá-los. Se não puder, me envia um email.

A vantagem é que o trabalho executado não é cron ou agendado. Eu tenho um trabalho de processo que é executado a cada segundo, mas vai esperar mais e mais entre iniciar um novo trabalho, dependendo se ele tinha trabalho a fazer. Além disso, pode ser usado para agir de forma inteligente com base no resultado. Tem um erro 500? Tem um atraso muito longo? Faça outra coisa. Notifique outro serviço. Etc.

E o mesmo sistema funciona no unix, com pequenas modificações.

Eu mesmo não tenho uma resposta para você, mas o problema chamou a atenção - eu me lembro de alguns caras aleatórios discutindo isso em um podcast uma vez .

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.

Visão geral da API Java da fila de tarefas

Conceitos de tarefas
No processamento em segundo plano do App Engine, uma tarefa é uma descrição completa de uma pequena unidade de trabalho. Esta descrição consiste em duas partes:

• Uma carga de dados que parametriza a tarefa.
• Código que implementa a tarefa.

Tarefas como ganchos da Web off-line
Felizmente, a Internet já oferece essa solução, na forma de uma solicitação HTTP e sua resposta. A carga útil de dados é o conteúdo da solicitação HTTP, como variáveis de formulário da web, XML, JSON ou dados binários codificados. A referência de código é a própria URL; o código atual é a lógica que o servidor executa na preparação da resposta.

Faça os dois

Adicione um parâmetro opcional ao caminho da pergunta que faz o trabalho no qual você está atualmente fazendo backup das solicitações do usuário:

Atendendo a tarefas em segundo plano em um site grande

Crie um aplicativo de console que seja executado em cada servidor e abra o log do IIS compartilhado e leia-o no final atual do arquivo. Use um sistema de monitoramento de arquivos ou um intervalo de tempo para ler para frente para coletar atualizações enquanto o IIS limpa o log.

Use essas informações para determinar quais páginas foram visualizadas no momento.

Use os URLs de página do log analisado para chamar a versão "extrastuff" do URL no host local com um objeto webclient.

Adicione algum código para alternar arquivos ao final de cada período de registro ou reinicie o processo a cada período de registro.