Compartilhar via

Trabalhos em segundo plano

Muitos tipos de aplicativos exigem tarefas em segundo plano que são executadas independentemente da interface do usuário (interface do usuário). Os exemplos incluem trabalhos em lotes, tarefas de processamento intensivas e processos de execução longa, como fluxos de trabalho. Trabalhos em segundo plano podem ser executados sem a necessidade de interação do usuário– o aplicativo pode iniciar o trabalho e continuar a processar solicitações interativas dos usuários. Isso pode ajudar a minimizar a carga na interface do usuário do aplicativo, o que pode melhorar a disponibilidade e reduzir os tempos de resposta interativos.

Por exemplo, se um aplicativo for necessário para gerar miniaturas de imagens que são carregadas pelos usuários, ele poderá fazer isso como um trabalho em segundo plano e salvar a miniatura no armazenamento quando estiver concluída , sem que o usuário precise aguardar a conclusão do processo. Da mesma forma, um usuário que faz um pedido pode iniciar um fluxo de trabalho em segundo plano que processa a ordem, enquanto a interface do usuário permite que o usuário continue navegando no aplicativo Web. Quando o trabalho em segundo plano é concluído, ele pode atualizar os dados de pedidos armazenados e enviar um email para o usuário que confirma o pedido.

Quando você considera se deseja implementar uma tarefa como um trabalho em segundo plano, os principais critérios são se a tarefa pode ser executada sem interação do usuário e sem que a interface do usuário precise aguardar a conclusão do trabalho. Tarefas que exigem que o usuário ou a interface do usuário aguardem enquanto estão concluídas podem não ser apropriadas como trabalhos em segundo plano.

Tipos de trabalhos em segundo plano

Os trabalhos em segundo plano geralmente incluem um ou mais dos seguintes tipos de trabalhos:

  • Trabalhos com uso intensivo de CPU, como cálculos matemáticos ou análise de modelo estrutural.
  • Trabalhos com uso intensivo de E/S, como executar uma série de transações de armazenamento ou indexar arquivos.
  • Trabalhos em lote, como atualizações de dados noturnas ou processamento agendado.
  • Fluxos de trabalho de execução longa, como o processamento de pedidos ou o provisionamento de serviços e sistemas.
  • Processamento de dados confidenciais em que a tarefa é entregue a um local mais seguro para processamento. Por exemplo, talvez você não queira processar dados confidenciais em um aplicativo Web. Em vez disso, você pode usar um padrão como o padrão Gatekeeper para transferir os dados para um processo isolado em segundo plano que tenha acesso ao armazenamento protegido.

Gatilhos

Trabalhos em segundo plano podem ser iniciados de várias maneiras diferentes. Eles se enquadram em uma das seguintes categorias:

  • Gatilhos controlados por eventos. A tarefa é iniciada em resposta a um evento, normalmente uma ação executada por um usuário ou uma etapa em um fluxo de trabalho.
  • Gatilhos controlados por agendamento. A tarefa é invocada em um agendamento com base em um temporizador. Esse pode ser um agendamento recorrente ou uma invocação única especificada para um horário posterior.

Gatilhos orientados por evento

A invocação controlada por eventos usa um gatilho para iniciar a tarefa em segundo plano. Exemplos de uso de gatilhos controlados por eventos incluem:

  • A interface do usuário ou outro trabalho coloca uma mensagem em uma fila. A mensagem contém dados sobre uma ação que ocorreu, como o usuário fazendo um pedido. A tarefa em segundo plano monitora esta fila e detecta a chegada de uma nova mensagem. Ele lê a mensagem e usa os dados nela como a entrada para o trabalho em segundo plano. Esse padrão é conhecido como comunicação assíncrona baseada em mensagem.
  • A interface do usuário ou outro trabalho salva ou atualiza um valor no armazenamento. A tarefa em segundo plano monitora o armazenamento e detecta alterações. Ele lê os dados e os usa como entrada para o trabalho em segundo plano.
  • A interface do usuário ou outro trabalho faz uma solicitação a um ponto de extremidade, como um URI HTTPS, ou a uma API exposta como um serviço Web. Ele passa os dados necessários para concluir a tarefa em segundo plano como parte da solicitação. O ponto de extremidade ou o serviço Web invoca a tarefa em segundo plano, que usa os dados como entrada.

Exemplos típicos de tarefas que são adequadas para invocação controlada por eventos incluem processamento de imagem, fluxos de trabalho, envio de informações para serviços remotos, envio de mensagens de email e provisionamento de novos usuários em aplicativos multilocatários.

Gatilhos orientados por agendamento

A invocação controlada por agenda usa um temporizador para iniciar a tarefa em segundo plano. Exemplos de uso de gatilhos controlados por agendamento incluem:

  • Um temporizador que está sendo executado localmente dentro do aplicativo ou como parte do sistema operacional do aplicativo invoca uma tarefa em segundo plano regularmente.
  • Um temporizador em execução em um aplicativo diferente, como os Aplicativos Lógicos do Azure, envia uma solicitação a uma API ou serviço Web regularmente. A API ou o serviço Web invoca a tarefa em segundo plano.
  • Um processo ou aplicativo separado inicia um temporizador que faz com que a tarefa em segundo plano seja invocada uma vez após um atraso de tempo especificado ou em um momento específico.

Exemplos típicos de tarefas que são adequadas à invocação orientada por agendamento incluem rotinas de processamento em lote (como atualizar listas de produtos relacionados para usuários com base em seu comportamento recente), tarefas de processamento de dados rotineiras (como atualizar índices ou gerar resultados acumulados), análise de dados para relatórios diários, limpeza de retenção de dados e verificações de consistência de dados.

Se você usar uma tarefa controlada por agendamento que deve ser executada como uma única instância, lembre-se do seguinte:

  • Se a instância de computação que está executando o agendador (como uma máquina virtual usando tarefas agendadas do Windows) for dimensionada, você terá várias instâncias do agendador em execução. Esses elementos podem iniciar várias instâncias da tarefa. Para obter mais informações sobre isso, leia esta postagem no blog sobre idempotência.
  • Se as tarefas forem executadas por mais tempo do que o período entre os eventos do agendador, o agendador poderá iniciar outra instância da tarefa enquanto a anterior ainda estiver em execução.

Retornando resultados

Trabalhos em segundo plano são executados de forma assíncrona em um processo separado ou até mesmo em um local separado, da interface do usuário ou do processo que invocou a tarefa em segundo plano. O ideal é que as tarefas em segundo plano sejam operações de "executar e esquecer" e que sua execução não tenha impacto na interface do usuário ou no processo de chamada. Isso significa que o processo de chamada não aguarda a conclusão das tarefas. Portanto, ele não pode detectar automaticamente quando a tarefa termina.

Se você precisar de uma tarefa em segundo plano para se comunicar com a tarefa de chamada para indicar o progresso ou a conclusão, deverá implementar um mecanismo para isso. Alguns exemplos são:

  • Grave um valor de indicador de status no armazenamento acessível à interface do usuário ou à tarefa do chamador, que pode monitorar ou verificar esse valor quando necessário. Outros dados que a tarefa em segundo plano deve retornar ao chamador podem ser colocados no mesmo armazenamento.
  • Estabeleça uma fila de resposta que a interface do usuário ou o chamador escuta. A tarefa em segundo plano pode enviar mensagens para a fila que indicam status e conclusão. Os dados que a tarefa em segundo plano deve retornar ao chamador podem ser colocados nas mensagens. Se você estiver usando o Barramento de Serviço do Azure, poderá usar as propriedades ReplyTo e CorrelationId para implementar essa funcionalidade.
  • Exponha uma API ou um ponto de extremidade da tarefa em segundo plano que a interface do usuário ou o chamador possa acessar para obter informações de status. Os dados que a tarefa em segundo plano deve retornar ao chamador podem ser incluídos na resposta.
  • Faça com que a tarefa em segundo plano retorne à interface do usuário ou ao chamador por uma API para indicar o status nos pontos predefinidos ou na conclusão. Isso pode ser por meio de eventos gerados localmente ou por meio de um mecanismo de publicação e assinatura. Os dados que a tarefa em segundo plano deve retornar ao chamador podem ser incluídos na solicitação ou na carga do evento.

Ambiente de hospedagem

Você pode hospedar tarefas em segundo plano usando uma variedade de diferentes serviços de plataforma do Azure:

  • Aplicativos Web e WebJobs do Azure. Você pode usar WebJobs para executar trabalhos personalizados com base em uma variedade de diferentes tipos de scripts ou programas executáveis no contexto de um aplicativo Web.
  • Azure Functions. Você pode usar funções para trabalhos em segundo plano que não são executados por muito tempo. Outro caso de uso é se sua carga de trabalho já estiver hospedada no plano do Serviço de Aplicativo e estiver subutilizada.
  • Máquinas Virtuais do Azure. Se você tiver um serviço windows ou quiser usar o Agendador de Tarefas do Windows, é comum hospedar suas tarefas em segundo plano em uma máquina virtual dedicada.
  • Lote do Azure. Batch é um serviço de plataforma que programa trabalho intensivo de computação para ser executado em uma coleção gerenciada de máquinas virtuais. Ele pode dimensionar automaticamente os recursos de computação.
  • AKS (Serviço de Kubernetes do Azure). O Serviço de Kubernetes do Azure fornece um ambiente de hospedagem gerenciado para Kubernetes no Azure.
  • Aplicativos de Contêiner do Azure. Os Aplicativos de Contêiner do Azure permitem que você crie microsserviços sem servidor com base em contêineres.

As seções a seguir descrevem essas opções com mais detalhes e incluem considerações para ajudá-lo a escolher a opção apropriada.

Aplicativos Web e WebJobs do Azure

Você pode usar o Azure WebJobs para executar trabalhos personalizados como tarefas em segundo plano em um Aplicativo Web do Azure. WebJobs são executados no contexto do aplicativo Web como um processo contínuo. Os WebJobs também são executados em resposta a um evento de gatilho dos Aplicativos Lógicos do Azure ou fatores externos, como alterações em blobs de armazenamento e filas de mensagens. Os trabalhos podem ser iniciados e interrompidos sob demanda, e serem desligados normalmente. Se um WebJob em execução contínua falhar, ele será reiniciado automaticamente. Ações de tentativa e erro podem ser configuradas.

Ao configurar um WebJob:

  • Se você quiser que o trabalho responda a um gatilho controlado por eventos, configure-o como Executar continuamente. O script ou programa é armazenado na pasta denominada site/wwwroot/app_data/jobs/continuous.
  • Se você quiser que o trabalho responda a um gatilho controlado por agendamento, configure-o como Executar em um agendamento. O script ou programa é armazenado na pasta denominada site/wwwroot/app_data/jobs/triggered.
  • Se você escolher a opção Executar sob demanda ao configurar um trabalho, ele executará o mesmo código que a opção Executar em uma agenda ao iniciá-lo.

Os WebJobs do Azure são executados na sandbox do aplicativo web. Isso significa que eles podem acessar variáveis de ambiente e compartilhar informações, como cadeias de conexão, com o aplicativo Web. O trabalho tem acesso ao identificador exclusivo do computador que o executa. A cadeia de conexão chamada AzureWebJobsStorage fornece acesso às filas, blobs e tabelas de Armazenamento do Azure para dados de aplicações, além de acesso ao Service Bus para mensagens e comunicação. A cadeia de conexão chamada AzureWebJobsDashboard fornece acesso aos arquivos de log de ação de trabalho.

Os WebJobs do Azure têm as seguintes características:

  • Segurança: WebJobs são protegidos pelas credenciais de implantação do aplicativo Web.
  • Tipos de arquivo com suporte: você pode definir WebJobs usando scripts de comando (.cmd), arquivos em lote (.bat), scripts do PowerShell (.ps1), scripts de shell bash (.sh), scripts PHP (.php), scripts Python (.py), código JavaScript (.js) e programas executáveis (.exe.jare muito mais).
  • Implantação: você pode implantar scripts e executáveis usando o portal do Azure usando o Visual Studio usando o SDK do Azure WebJobs ou copiando-os diretamente para os seguintes locais:
    • Para execução acionada: site/wwwroot/app_data/jobs/triggered/{nome do trabalho}
    • Para execução contínua: site/wwwroot/app_data/jobs/continuous/{nome do trabalho}
  • Registro em log: Console.Out é tratado (marcado) como INFO. Console.Error é tratado como ERROR. Você pode acessar informações de monitoramento e diagnóstico usando o portal do Azure. Você pode baixar arquivos de log diretamente do site. Eles são salvos nos seguintes locais:
    • Para execução disparada: Vfs/data/jobs/triggered/jobName
    • Para execução contínua: Vfs/data/jobs/continuous/jobName
  • Configuração: você pode configurar o WebJobs usando o portal, a API REST e o PowerShell. Você pode usar um arquivo de configuração chamado settings.job no mesmo diretório raiz que o script de trabalho para fornecer informações de configuração para um trabalho. Por exemplo:
    • { "tempo_de_espera_para_parada": 60 }
    • { "is_singleton": true }

Considerações

  • Por padrão, os WebJobs são dimensionados com o aplicativo Web. No entanto, você pode configurar trabalhos para serem executados em uma única instância definindo a propriedade de configuração is_singleton como true. WebJobs de instância única são úteis para tarefas que você não deseja dimensionar ou executar como várias instâncias simultâneas, como reindexação, análise de dados e tarefas semelhantes.
  • Para minimizar o impacto dos trabalhos no desempenho do aplicativo Web, considere a criação de uma instância vazia do Aplicativo Web do Azure em um novo plano do Serviço de Aplicativo para hospedar WebJobs de longa execução ou com uso intensivo de recursos.

Funções do Azure

Uma opção semelhante ao WebJobs é o Azure Functions. Esse serviço é sem servidor que é mais adequado para gatilhos controlados por eventos que são executados por um curto período. Uma função também pode ser usada para executar trabalhos agendados por meio de gatilhos de temporizador, quando configurada para ser executada em horários definidos.

O Azure Functions não é uma opção recomendada para tarefas grandes e de execução longa, pois elas podem causar problemas inesperados de tempo limite. No entanto, dependendo do plano de hospedagem, ele pode ser considerado para gatilhos controlados por agendamento.

Considerações

Se espera-se que a tarefa em segundo plano seja executada por uma curta duração em resposta a um evento, considere executar a tarefa em um plano de consumo. O tempo de execução é configurável até um tempo máximo. Uma função que é executada por mais tempo custa mais. Além disso, trabalhos com uso intensivo de CPU que consomem mais memória podem ser mais caros. Se você usar gatilhos adicionais para serviços como parte de sua tarefa, eles serão cobrados separadamente.

O plano Premium é mais adequado se você tiver um alto número de tarefas que são curtas, mas que devem ser executadas continuamente. Esse plano é mais caro porque precisa de mais memória e CPU. O benefício é que você pode usar recursos como integração de rede virtual.

O plano Dedicado é mais adequado para trabalhos em segundo plano se sua carga de trabalho já for executada nele. Se você tiver VMs subutilizadas, poderá executá-la na mesma VM e compartilhar custos de computação.

Para obter mais informações, consulte estes artigos:

Máquinas Virtuais do Azure

Tarefas em segundo plano podem ser implementadas de uma maneira que as impeça de serem implantadas nos Aplicativos Web do Azure ou essas opções podem não ser convenientes. Exemplos típicos são serviços windows e utilitários de terceiros e programas executáveis. Outro exemplo pode ser programas gravados para um ambiente de execução diferente daquele que hospeda o aplicativo. Por exemplo, pode ser um programa Unix ou Linux que você deseja executar de um aplicativo Windows ou .NET. Você pode escolher entre um intervalo de sistemas operacionais para uma máquina virtual do Azure e executar seu serviço ou executável nessa máquina virtual.

Para ajudá-lo a escolher quando usar máquinas virtuais, consulte a comparação de Serviços de Aplicativo, Serviços de Nuvem e Máquinas Virtuais do Azure. Para obter informações sobre as opções de Máquinas Virtuais, consulte Tamanhos para máquinas virtuais do Windows no Azure. Para obter mais informações sobre os sistemas operacionais e imagens predefinidas que estão disponíveis para máquinas virtuais, consulte o Marketplace de Máquinas Virtuais do Azure.

Para iniciar a tarefa em segundo plano em uma máquina virtual separada, você tem uma variedade de opções:

  • Você pode executar a tarefa sob demanda diretamente do seu aplicativo, enviando uma solicitação para um ponto de extremidade que a tarefa expõe. Isso transmite todos os dados que a tarefa requer. Este endpoint invoca a tarefa.
  • Você pode configurar a tarefa para ser executada em um agendamento usando um agendador ou temporizador disponível no sistema operacional escolhido. Por exemplo, no Windows, você pode usar o Agendador de Tarefas do Windows para executar scripts e tarefas. Ou, se você tiver o SQL Server instalado na máquina virtual, poderá usar o SQL Server Agent para executar scripts e tarefas.
  • Você pode usar o Azure Logic Apps para iniciar a tarefa adicionando uma mensagem a uma fila que a tarefa monitora ou enviando uma solicitação para uma API que a tarefa expõe.

Consulte a seção anterior Gatilhos para obter mais informações sobre como você pode iniciar tarefas em segundo plano.

Considerações

Considere os seguintes pontos ao decidir se deseja implantar tarefas em segundo plano em uma máquina virtual do Azure:

  • Hospedar tarefas em segundo plano em uma máquina virtual separada do Azure oferece flexibilidade e permite o controle preciso sobre iniciação, execução, agendamento e alocação de recursos. No entanto, aumentará o custo do runtime se uma máquina virtual precisar ser implantada apenas para executar tarefas em segundo plano.
  • Não há nenhum recurso para monitorar as tarefas no portal do Azure nem funcionalidade de reinicialização automatizada para tarefas com falha, embora seja possível monitorar o status básico da máquina virtual e gerenciá-la usando os Cmdlets do Azure Resource Manager. Porém, não há recursos para controlar os processos e threads nos nós de computação. Normalmente, o uso de uma máquina virtual exigirá esforço adicional para implementar um mecanismo que coleta dados da instrumentação na tarefa e do sistema operacional na máquina virtual. Uma solução que pode ser apropriada é usar o System Center Management Pack para o Azure.
  • Você pode considerar a criação de sondas de monitoramento expostas através de endpoints HTTP. O código dessas investigações pode executar verificações de integridade, coletar informações operacionais e estatísticas ou agrupar informações de erro e devolvê-las a um aplicativo de gerenciamento. Para obter mais informações, consulte o Padrão de monitoramento do ponto de extremidade de integridade.

Para obter mais informações, consulte:

Lote do Azure

Considere o Lote do Azure se você precisar executar cargas de trabalho de HPC (computação de alto desempenho) grandes e paralelas em dezenas, centenas ou milhares de VMs.

O serviço lote provisiona as VMs, atribui tarefas às VMs, executa as tarefas e monitora o progresso. O Lote pode dimensionar automaticamente as VMs em resposta à carga de trabalho. O Lote também fornece agendamento de trabalho. Azure Batch oferece suporte a VMs Linux e Windows.

Considerações

O processamento em lotes funciona bem com cargas de trabalho que são intrinsecamente paralelas. Ele também pode executar cálculos paralelos com uma etapa de redução no final ou executar aplicativos de MPI (Interface de Passagem de Mensagem) para tarefas paralelas que exigem a passagem de mensagens entre nós.

Um trabalho do Lote do Azure é executado em um pool de nós (VMs). Uma abordagem é alocar um pool somente quando necessário e excluí-lo após a conclusão do trabalho. Isso maximiza o uso porque os nós não estão ociosos, mas o trabalho deverá aguardar a alocação dos nós. Como alternativa, você pode criar um pool com antecedência. Essa abordagem minimiza o tempo que leva para um trabalho Iniciar, mas pode resultar em nós ociosos. Para obter mais informações, consulte Tempo de vida do nó de computação e pool.

Para obter mais informações, consulte:

Serviço de Kubernetes do Azure

O AKS (Serviço de Kubernetes do Azure) gerencia seu ambiente hospedado do Kubernetes, o que facilita a implantação e o gerenciamento de aplicativos em contêineres.

Os contêineres podem ser úteis para executar trabalhos em segundo plano. Alguns do benefícios incluem:

  • Os contêineres dão suporte à hospedagem de alta densidade. Você pode isolar uma tarefa em segundo plano em um contêiner, colocando vários contêineres em cada VM.
  • O orquestrador de contêiner manipula o balanceamento de carga interno, configurando a rede interna e outras tarefas de configuração.
  • Os contêineres podem ser iniciados e interrompidos conforme necessário.
  • O Registro de Contêiner do Azure permite que você registre seus contêineres dentro dos limites do Azure. Isso vem com benefícios de segurança, privacidade e proximidade.

Considerações

  • Requer uma compreensão de como usar um orquestrador de contêineres. Dependendo do conjunto de habilidades da sua equipe de DevOps, isso pode ou não ser um problema.

Para obter mais informações, consulte:

Aplicativos de Contêiner do Azure

Os Aplicativos de Contêiner do Azure permitem que você crie microsserviços sem servidor com base em contêineres. Entre os recursos diferenciados dos Aplicativos de Contêiner estão:

Considerações

Os Aplicativos de Contêiner do Azure não fornecem acesso direto às APIs Kubernetes subjacentes. Se você precisar de acesso às APIs do Kubernetes e ao painel de controle, deverá usar o Serviço de Kubernetes do Azure. No entanto, se você quiser criar aplicativos no estilo Kubernetes e não precisar de acesso direto a todas as APIs Kubernetes nativas e ao gerenciamento de clusters, os Aplicativos de Contêiner fornecerão uma experiência totalmente gerenciada com base nas melhores práticas. Por esses motivos, muitas equipes podem preferir começar a criar microsserviços de contêiner com os Aplicativos de Contêiner do Azure.

Para obter mais informações, consulte:

Você pode começar a criar seu primeiro aplicativo de contêiner usando os guias de início rápido.

Particionamento

Se você decidir incluir tarefas em segundo plano em uma instância de computação existente, deverá considerar como isso afetará os atributos de qualidade da instância de computação e a própria tarefa em segundo plano. Esses fatores ajudarão você a decidir se deseja colocar as tarefas com a instância de computação existente ou se as separar em uma instância de computação separada:

  • Disponibilidade: as tarefas em segundo plano podem não precisar ter o mesmo nível de disponibilidade que outras partes do aplicativo, em particular a interface do usuário e outras partes que estão diretamente envolvidas na interação do usuário. As tarefas em segundo plano podem ser mais tolerantes a falhas de conexão repetida, latência e outros fatores que afetam a disponibilidade porque as operações podem ser colocadas na fila. No entanto, deve haver capacidade suficiente para impedir o backup de solicitações que possam bloquear filas e afetar o aplicativo como um todo.

  • Escalabilidade: é provável que as tarefas em segundo plano tenham um requisito de escalabilidade diferente da interface do usuário e das partes interativas do aplicativo. O dimensionamento da interface do usuário pode ser necessário para atender aos picos de demanda, enquanto as tarefas pendentes em segundo plano podem ser concluídas em tempos menos movimentados por menos instâncias de computação.

  • Resiliência: a falha de uma instância de computação que apenas hospeda tarefas em segundo plano pode não afetar fatalmente o aplicativo como um todo se as solicitações para essas tarefas puderem ser enfileiradas ou adiadas até que a tarefa esteja disponível novamente. Se a instância de computação ou as tarefas puderem ser reiniciadas em um intervalo apropriado, os usuários do aplicativo poderão não ser afetados.

  • Segurança: as tarefas em segundo plano podem ter requisitos ou restrições de segurança diferentes da interface do usuário ou de outras partes do aplicativo. Usando uma instância de computação separada, você pode especificar um ambiente de segurança diferente para as tarefas. Você também pode usar padrões como o Gatekeeper para isolar as instâncias de computação em segundo plano da interface do usuário para maximizar a segurança e a separação.

  • Desempenho: você pode escolher o tipo de instância de computação para tarefas em segundo plano para corresponder especificamente aos requisitos de desempenho das tarefas. Isso pode significar usar uma opção de computação mais barata se as tarefas não exigirem os mesmos recursos de processamento que a interface do usuário ou uma instância maior se exigirem capacidade e recursos adicionais.

  • Capacidade de gerenciamento: as tarefas em segundo plano podem ter um ritmo de desenvolvimento e implantação diferente do código principal do aplicativo ou da interface do usuário. Implantá-los em uma instância de computação separada pode simplificar atualizações e controle de versão.

  • Custo: adicionar instâncias de computação para executar tarefas em segundo plano aumenta os custos de hospedagem. Você deve considerar cuidadosamente a compensação entre a capacidade adicional e esses custos extras.

Para obter mais informações, consulte o padrão de Eleição de Líder e o padrão Consumidores Concorrentes.

Conflitos

Se você tiver várias instâncias de um trabalho em segundo plano, é possível que elas concorram pelo acesso a recursos e serviços, como bancos de dados e armazenamento. Esse acesso simultâneo pode resultar em contenção de recursos, o que pode causar conflitos na disponibilidade dos serviços e na integridade dos dados no armazenamento. Você pode resolver a contenção de recursos usando uma abordagem de bloqueio pessimista. Isso impede que instâncias concorrentes de uma tarefa acessem simultaneamente um serviço ou corrompam dados.

Outra abordagem para resolver conflitos é definir tarefas em segundo plano como um singleton, para que haja sempre apenas uma instância em execução. No entanto, isso elimina os benefícios de confiabilidade e desempenho que uma configuração de várias instâncias pode fornecer. Isso é especialmente verdadeiro se a interface do usuário puder fornecer trabalho suficiente para manter mais de uma tarefa em segundo plano ocupada.

É vital garantir que a tarefa em segundo plano possa ser reiniciada automaticamente e que ela tenha capacidade suficiente para lidar com picos de demanda. Você pode conseguir isso alocando uma instância de computação com recursos suficientes, implementando um mecanismo de fila que pode armazenar solicitações para execução posterior quando a demanda diminui ou usando uma combinação dessas técnicas.

Coordenação

As tarefas em segundo plano podem ser complexas e podem exigir que várias tarefas individuais sejam executadas para produzir um resultado ou atender a todos os requisitos. É comum nesses cenários dividir a tarefa em etapas ou subtarefas discretas menores que podem ser executadas por vários consumidores. Trabalhos com várias etapas podem ser mais eficientes e flexíveis porque etapas individuais podem ser reutilizáveis em vários trabalhos. Também é fácil adicionar, remover ou modificar a ordem das etapas.

Coordenar várias tarefas e etapas pode ser desafiador, mas há três padrões comuns que você pode usar para orientar sua implementação de uma solução:

  • Decompor uma tarefa em várias etapas reutilizáveis. Um aplicativo pode ser necessário para executar uma variedade de tarefas de complexidade variável nas informações que processa. Uma abordagem simples, mas inflexível, para implementar esse aplicativo pode ser executar esse processamento como um módulo monolítico. No entanto, essa abordagem provavelmente reduzirá as oportunidades de refatoração do código, otimizando-o ou reutilizando-o se partes do mesmo processamento forem necessárias em outro lugar dentro do aplicativo. Para obter mais informações, consulte o padrão Pipes e Filtros.

  • Gerenciando a execução das etapas de uma tarefa. Um aplicativo pode executar tarefas que compõem várias etapas (algumas das quais podem invocar serviços remotos ou acessar recursos remotos). As etapas individuais podem ser independentes umas das outras, mas elas são organizadas pela lógica de aplicativo que implementa a tarefa. Para obter mais informações, consulte Padrão do Supervisor do Agente do Agendador.

  • Gerenciamento da recuperação para etapas de tarefas que falham. Um aplicativo pode precisar desfazer o trabalho executado por uma série de etapas (que juntas definem uma operação eventualmente consistente) se uma ou mais das etapas falharem. Para obter mais informações, consulte o padrão de Transação de Compensação.

Considerações de resiliência

As tarefas em segundo plano devem ser resilientes para fornecer serviços confiáveis ao aplicativo. Ao planejar e criar tarefas em segundo plano, considere os seguintes pontos:

  • As tarefas em segundo plano devem ser capazes de lidar normalmente com reinicializações sem corromper dados ou introduzir inconsistência no aplicativo. Para tarefas de execução prolongada ou de várias etapas, considere usar pontos de verificação, salvando o estado dos trabalhos no armazenamento persistente ou como mensagens em uma fila, se for apropriado. Por exemplo, você pode manter informações de estado em uma mensagem em uma fila e atualizar incrementalmente essas informações de estado com o progresso da tarefa para que a tarefa possa ser processada do último ponto de verificação válido conhecido, em vez de reiniciar desde o início. Ao usar as filas do Barramento de Serviço do Azure, você pode usar sessões de mensagens para habilitar o mesmo cenário. As sessões permitem salvar e recuperar o estado de processamento do aplicativo usando os métodos SetState e GetState . Para obter mais informações sobre como criar processos e fluxos de trabalho de várias etapas confiáveis, consulte o padrão supervisor do Agente do Agendador.

  • Quando você usa filas para se comunicar com tarefas em segundo plano, as filas podem funcionar como um buffer a fim de armazenar solicitações enviadas para as tarefas enquanto o aplicativo está sob uma carga maior do que a normal. Isso permite que as tarefas acompanhem a interface do usuário durante períodos menos ocupados. Isso também significa que as reinicializações não bloquearão a interface do usuário. Para obter mais informações, consulte o padrão de Nivelamento de CargaQueue-Based. Se algumas tarefas forem mais importantes do que outras, considere implementar o padrão de Fila de Prioridade para garantir que essas tarefas sejam executadas antes das menos importantes.

  • Tarefas em segundo plano iniciadas por mensagens ou mensagens de processo devem ser projetadas para lidar com inconsistências, como mensagens que chegam fora de ordem, mensagens que causam repetidamente um erro (muitas vezes conhecidas como mensagens suspeitas) e mensagens que são entregues mais de uma vez. Considere o seguinte:

    • Mensagens que devem ser processadas em uma ordem específica, como aquelas que alteram dados com base no valor de dados existente (por exemplo, adicionando um valor a um valor existente), podem não chegar na ordem original em que foram enviadas. Como alternativa, eles podem ser tratados por diferentes instâncias de uma tarefa em segundo plano em uma ordem diferente devido a cargas variadas em cada instância. As mensagens que devem ser processadas em uma ordem específica devem incluir um número de sequência, chave ou algum outro indicador que as tarefas em segundo plano podem usar para garantir que sejam processadas na ordem correta. Se você estiver usando o Barramento de Serviço do Azure, pode usar sessões de mensagens para garantir a ordem de entrega. No entanto, geralmente é mais eficiente, sempre que possível, projetar o processo para que a ordem da mensagem não seja importante.

    • Normalmente, uma tarefa em segundo plano inspeciona as mensagens na fila, ocultando-as temporariamente de outros consumidores de mensagens. Em seguida, ele exclui as mensagens depois de terem sido processadas com êxito. Se uma tarefa em segundo plano falhar ao processar uma mensagem, essa mensagem reaparecerá na fila depois que o tempo limite de observação expirar. Ele será processado por outra instância da tarefa ou durante o próximo ciclo de processamento dessa instância. Se a mensagem causar consistentemente um erro no consumidor, ela bloqueará a tarefa, a fila e, eventualmente, o próprio aplicativo quando a fila ficar cheia. Portanto, é vital detectar e remover mensagens suspeitas da fila. Se você estiver usando o Barramento de Serviço do Azure, as mensagens que causam um erro poderão ser movidas automaticamente ou manualmente para uma fila de mensagens de inatividade associada.

    • As filas são garantidas no mínimo uma vez nos mecanismos de entrega, mas elas podem entregar a mesma mensagem mais de uma vez. Além disso, se uma tarefa em segundo plano falhar após o processamento de uma mensagem, mas antes de excluí-la da fila, a mensagem ficará disponível para processamento novamente. As tarefas em segundo plano devem ser idempotentes, o que significa que processar a mesma mensagem mais de uma vez não causa um erro ou inconsistência nos dados do aplicativo. Algumas operações são naturalmente idempotentes, como definir um valor armazenado para um novo valor específico. No entanto, operações como adicionar um valor a um valor armazenado existente sem verificar se o valor armazenado ainda é o mesmo de quando a mensagem foi enviada originalmente causará inconsistências. As filas do Barramento de Serviço do Azure podem ser configuradas para remover automaticamente as mensagens duplicadas. Para obter mais informações sobre os desafios com entrega de mensagens pelo menos uma vez, consulte as diretrizes sobre o processamento de mensagens idempotentes.

    • Alguns sistemas de mensagens, como o Armazenamento de Filas do Azure e filas do Barramento de Serviço do Azure, dão suporte a uma propriedade de contagem de filas que indica o número de vezes que uma mensagem foi lida na fila. Isso pode ser útil no tratamento de mensagens repetidas e danosas. Para obter mais informações, consulte Guia de Mensagens Assíncronas e Padrões de Idempotência.

Considerações sobre escala e desempenho

As tarefas em segundo plano devem oferecer desempenho suficiente para garantir que elas não bloqueiem o aplicativo ou causem inconsistências devido à operação atrasada quando o sistema estiver sob carga. Normalmente, o desempenho é melhorado dimensionando as instâncias de computação que hospedam as tarefas em segundo plano. Ao planejar e projetar tarefas em segundo plano, considere os seguintes pontos em relação à escalabilidade e ao desempenho:

  • O Azure dá suporte ao dimensionamento automático (escalar horizontalmente e escalar verticalmente de volta) com base na demanda atual e na carga ou em um planejamento predefinido para aplicativos Web e implantações de máquinas virtuais hospedadas. Use esse recurso para garantir que o aplicativo como um todo tenha recursos de desempenho suficientes, minimizando os custos de runtime.

  • Quando as tarefas em segundo plano têm uma capacidade de desempenho diferente das outras partes de um aplicativo (por exemplo, a interface do usuário ou componentes, como a camada de acesso a dados), hospedar as tarefas em segundo plano em um serviço de computação separado permite que a interface do usuário e as tarefas em segundo plano sejam dimensionadas independentemente para gerenciar a carga. Se várias tarefas em segundo plano tiverem funcionalidades de desempenho significativamente diferentes umas das outras, considere dividi-las e dimensionar cada tipo de forma independente. No entanto, observe que isso pode aumentar os custos de runtime.

  • Simplesmente dimensionar os recursos de computação pode não ser suficiente para evitar a perda de desempenho sob carga. Talvez você também precise dimensionar filas de armazenamento e outros recursos para impedir que um único ponto da cadeia de processamento geral se torne um gargalo. Além disso, considere outras limitações, como a taxa de transferência máxima de armazenamento e outros serviços dos quais o aplicativo e as tarefas em segundo plano dependem.

  • As tarefas em segundo plano devem ser projetadas para se adaptar ao crescimento. Por exemplo, eles devem ser capazes de detectar dinamicamente o número de filas de armazenamento em uso para escutar ou enviar mensagens para a fila apropriada.

  • Por padrão, os WebJobs são dimensionados com a instância associada dos Aplicativos Web do Azure. No entanto, se você quiser que um WebJob seja executado como apenas uma única instância, poderá criar um arquivo Settings.job que contenha os dados JSON { "is_singleton": true }. Isso força o Azure a executar apenas uma instância do WebJob, mesmo que haja várias instâncias do aplicativo Web associado. Essa pode ser uma técnica útil para trabalhos agendados que devem ser executados como apenas uma única instância.

Próximas etapas