Recomendações para desenvolver tarefas em segundo plano

  • Artigo

Aplica-se a esta recomendação de lista de verificação de Fiabilidade do Azure Well-Architected Framework:

RE:07 Fortaleça a resiliência e a capacidade de recuperação da carga de trabalho ao implementar medidas de auto-preservação e auto-recuperação. Crie capacidades para a solução através de padrões de fiabilidade baseados na infraestrutura e padrões de conceção baseados em software para lidar com falhas de componentes e erros transitórios. Crie capacidades no sistema para detetar falhas de componentes da solução e iniciar automaticamente a ação corretiva enquanto a carga de trabalho continua a funcionar com funcionalidades completas ou reduzidas.

Guias relacionados:Falhas transitórias | Auto-preservação

Este guia descreve as recomendações para desenvolver tarefas em segundo plano. As tarefas em segundo plano são executadas automaticamente sem a necessidade de interação do utilizador. Muitas aplicações necessitam de tarefas em segundo plano que são executadas independentemente da IU.

Alguns exemplos de tarefas em segundo plano incluem tarefas em lote, tarefas de processamento intensiva e processos de execução prolongada, como fluxos de trabalho. A aplicação inicia a tarefa e processa pedidos interativos de utilizadores. Por exemplo, se uma aplicação precisar de gerar miniaturas de imagens que os utilizadores carregam, pode ser realizada uma tarefa em segundo plano para gerar a miniatura e guardá-la no armazenamento. O utilizador não tem de esperar que o processo seja concluído. Como outro exemplo, um cliente faz uma encomenda, que inicia um fluxo de trabalho em segundo plano que processa a encomenda. O cliente continua a navegar na aplicação Web enquanto a tarefa em segundo plano é executada. Após a conclusão da tarefa em segundo plano, atualiza os dados da encomenda armazenada e envia um e-mail ao cliente para confirmar a encomenda.

As tarefas em segundo plano ajudam a minimizar a carga na IU da aplicação, o que melhora a disponibilidade e reduz o tempo de resposta interativo.

Principais estratégias de design

Para escolher que tarefa designar como tarefa em segundo plano, considere se a tarefa é executada sem interação do utilizador e se a IU precisa de aguardar pela conclusão da tarefa. Normalmente, as tarefas que exigem que o utilizador ou a IU aguardem enquanto são executadas não são tarefas em segundo plano adequadas.

Tipos de tarefas em segundo plano

Alguns exemplos de tarefas em segundo plano são:

  • Tarefas com utilização intensiva da CPU, como cálculos matemáticos ou a análise estrutural de modelo.

  • Tarefas de E/S intensivas, como executar uma série de transações de armazenamento ou ficheiros de indexação.

  • Tarefas de lote, como atualizações noturnas de dados ou processamento agendado.

  • Fluxos de trabalho de execução prolongada, como serviços e sistemas de cumprimento de encomendas ou aprovisionamento.

  • Processamento de dados confidenciais que transfere a tarefa para uma localização mais segura para processamento. Por exemplo, não deverá processar dados confidenciais numa aplicação Web. Em vez disso, pode utilizar um padrão como o padrão do Controlador de Porta para transferir os dados para um processo em segundo plano isolado que tenha acesso ao armazenamento protegido.

Acionadores

Inicie tarefas em segundo plano com:

Acionadores desencadeados por eventos

Uma ação aciona uma invocação baseada em eventos que inicia a tarefa em segundo plano. Exemplos de acionadores orientados por eventos incluem:

  • A IU ou uma tarefa diferente coloca uma mensagem numa fila, conforme descrito no estilo de arquitetura Web-Queue-Worker. A mensagem contém dados sobre uma ação executada anteriormente, como um cliente que efetuou uma encomenda. A tarefa em segundo plano monitoriza esta fila e deteta a chegada de uma nova mensagem. Lê a mensagem e utiliza os dados da mensagem como entrada para a tarefa em segundo plano. Este padrão é denominado comunicação baseada em mensagens assíncrona.

  • A IU ou uma tarefa diferente guarda ou atualiza um valor que está no armazenamento. A tarefa em segundo plano monitoriza o armazenamento e deteta alterações. Lê os dados e utiliza-os como entrada para a tarefa em segundo plano.

  • A IU ou uma tarefa diferente faz um pedido para um ponto final, como um URI HTTPS ou uma API que é exposta como um serviço Web. Como parte do pedido, a IU ou a tarefa transfere os dados necessários para a tarefa em segundo plano. O ponto final ou o serviço Web invoca a tarefa em segundo plano, que utiliza os dados como entrada.

Outros exemplos de tarefas adequadas à invocação baseada em eventos incluem processamento de imagens, fluxos de trabalho, envio de informações para serviços remotos, envio de mensagens de e-mail e aprovisionamento de novos utilizadores em aplicações multi-inquilino.

Acionadores desencadeados pela agenda

Um temporizador aciona uma invocação baseada na agenda que inicia a tarefa em segundo plano. Exemplos de acionadores orientados por agendas incluem:

  • Um temporizador que é executado localmente na aplicação ou como parte do sistema operativo da aplicação invoca regularmente uma tarefa em segundo plano.

  • Um temporizador que é executado numa aplicação diferente, como o Azure Logic Apps, envia regularmente um pedido para uma API ou serviço Web. A API ou o serviço Web invoca a tarefa em segundo plano.

  • Um processo ou aplicação separado inicia um temporizador que invoca a tarefa em segundo plano após um atraso de tempo ou numa hora específica.

Outros exemplos de tarefas adequadas à invocação orientada por agendas incluem rotinas de processamento em lote (como atualizar listas de produtos relacionados para clientes com base no comportamento recente), tarefas de processamento de dados de rotina (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 utilizar uma tarefa condicionada por agendamento que tem de ser executada como uma única instância, reveja as seguintes considerações:

  • Se a instância de computação que executa o agendador, como uma máquina virtual (VM) que utiliza tarefas agendadas do Windows, for dimensionada, está a executar várias instâncias do agendador. Várias instâncias do agendador podem iniciar várias instâncias da tarefa. Para obter mais informações, consulte O que significa idempotente em sistemas de software?

  • Se as tarefas forem executadas durante mais tempo do que o período entre os eventos do agendador, o agendador poderá iniciar outra instância da tarefa enquanto a tarefa anterior é executada.

Devolver resultados

As tarefas em segundo plano são executadas de forma assíncrona num processo separado, ou mesmo numa localização separada, da IU ou do processo que invocou a tarefa em segundo plano. Idealmente, as tarefas em segundo plano são operações de acionar e esquecer . O progresso do runtime não tem um efeito na IU ou no processo de chamada, o que significa que o processo de chamada não aguarda que as tarefas estejam concluídas. A IU e o processo de chamada não conseguem detetar quando a tarefa termina.

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

  • Escreva um valor de indicador de estado no armazenamento que esteja acessível à IU ou à tarefa de autor da chamada, que pode monitorizar ou verificar este valor. Outros dados que a tarefa em segundo plano devolve ao autor da chamada podem ser colocados no mesmo armazenamento.

  • Estabeleça uma fila de resposta que a IU ou o autor da chamada monitorize. A tarefa em segundo plano pode enviar mensagens para a fila que indicam o estado. Os dados que a tarefa em segundo plano devolve ao autor da chamada podem ser colocados nas mensagens. Para Azure Service Bus, utilize as ReplyTo propriedades e CorrelationId para implementar esta capacidade.

  • Exponha uma API ou ponto final a partir da tarefa em segundo plano que a IU ou o autor da chamada podem aceder para obter informações do estado. A resposta pode incluir os dados que a tarefa em segundo plano devolve ao autor da chamada.

  • Configure a tarefa em segundo plano para voltar a chamar a IU ou o autor da chamada através de uma API para indicar o estado em pontos predefinidos ou após a conclusão. Pode utilizar eventos gerados localmente ou um mecanismo de publicação e subscrição. O pedido ou o payload do evento podem incluir os dados que a tarefa em segundo plano devolve ao autor da chamada.

Tarefas em segundo plano de partição

Se incluir tarefas em segundo plano numa instância de computação existente, considere como estas alterações afetam os atributos de qualidade da instância de computação e da tarefa em segundo plano. Considere estes fatores para decidir se coloca as tarefas com a instância de computação existente ou se as separa numa instância de computação diferente:

  • Disponibilidade: as tarefas em segundo plano podem não precisar do mesmo nível de disponibilidade que outras partes da aplicação, em particular a IU e as partes que envolvem diretamente a interação do utilizador. As tarefas em segundo plano podem ter uma maior tolerância à latência, falhas de ligação repetidas e outros fatores que afetam a disponibilidade porque as operações podem ser em fila de espera. No entanto, tem de haver capacidade suficiente para impedir pedidos de cópia de segurança que possam bloquear filas e afetar toda a aplicação.

  • Escalabilidade: as tarefas em segundo plano provavelmente têm diferentes requisitos de escalabilidade em comparação com a IU e as partes interativas da aplicação. Poderá ter de dimensionar a IU para satisfazer os picos de procura. As tarefas em segundo plano pendentes podem ser executadas durante tempos menos ocupados e com menos instâncias de computação.

  • Resiliência: se uma instância de computação que aloja apenas tarefas em segundo plano falhar, poderá não afetar fatalmente toda a aplicação. Os pedidos para estas tarefas podem ser em fila de espera ou adiados até que a tarefa esteja disponível. Se a instância de computação ou as tarefas puderem ser reiniciadas num intervalo adequado, poderá não afetar os utilizadores da aplicação.

  • Segurança: as tarefas em segundo plano podem ter diferentes requisitos de segurança ou restrições em comparação com a IU ou outras partes da aplicação. Utilize uma instância de computação separada para especificar um ambiente de segurança diferente para as tarefas. Para maximizar a segurança e a separação, também pode utilizar padrões como o Gatekeeper para isolar as instâncias de computação em segundo plano da IU.

  • Desempenho: escolha o tipo de instância de computação para tarefas em segundo plano que correspondem especificamente aos requisitos de desempenho da tarefa. Poderá utilizar uma opção de computação menos dispendiosa se as tarefas não exigirem as mesmas capacidades de processamento que a IU. Em alternativa, poderá utilizar uma instância maior se as tarefas exigirem mais capacidade e recursos.

  • Capacidade de gestão: as tarefas em segundo plano podem ter um ritmo de desenvolvimento e implementação diferente em comparação com o código da aplicação principal ou a IU. Para simplificar as atualizações e o controlo de versões, implemente tarefas em segundo plano numa instância de computação separada.

  • Custo: se adicionar instâncias de computação para executar tarefas em segundo plano, os custos de alojamento aumentam. Considere cuidadosamente a desvantagem entre mais capacidade e custos adicionais.

Para obter mais informações, veja Padrão de Eleição de Coordenador e Padrão de Consumidores Concorrentes.

Conflitos

Se tiver várias instâncias de uma tarefa em segundo plano, estas poderão competir pelo acesso a recursos e serviços, como bases de dados e armazenamento. Este acesso simultâneo pode resultar na contenção de recursos, o que pode causar conflitos de disponibilidade do serviço e prejudicar a integridade dos dados que estão no armazenamento. Resolva a contenção de recursos com uma abordagem de bloqueio pessimista. Esta abordagem impede que instâncias concorrentes de uma tarefa acedam simultaneamente a um serviço ou corrompem dados.

Outra abordagem para resolver conflitos é definir tarefas em segundo plano como singleton, para que apenas uma instância seja executada. No entanto, esta abordagem elimina os benefícios de fiabilidade e desempenho que uma configuração de várias instâncias proporciona. Esta desvantagem é especialmente verdadeira se a IU fornecer trabalho suficiente para manter mais do que uma tarefa em segundo plano ocupada.

Certifique-se de que a tarefa em segundo plano pode ser reiniciada automaticamente e que tem capacidade suficiente para lidar com picos de procura. Aloque uma instância de computação com recursos suficientes, implemente um mecanismo de colocação em fila que armazena pedidos para serem executados quando a procura diminui ou utilize uma combinação destas técnicas.

Coordenação

As tarefas em segundo plano podem ser complexas e exigir a execução de várias tarefas. Nestes cenários, é comum dividir a tarefa em pequenos passos discretos ou subtarefas que podem ser executados por vários consumidores. As tarefas de vários passos são mais eficientes e flexíveis porque os passos individuais são muitas vezes reutilizáveis em várias tarefas. Também é fácil adicionar, remover ou modificar a ordem dos passos.

Pode ser um desafio coordenar várias tarefas e passos, mas existem três padrões comuns para orientar a sua solução:

  • Decompor uma tarefa em vários passos reutilizáveis. Pode ser necessária uma aplicação para executar várias tarefas de complexidade diferente nas informações que processa. Uma abordagem simples, mas inflexível, para implementar tal aplicação é efetuar este processamento como um módulo monolítico. No entanto, é provável que esta abordagem reduza as oportunidades para refatorizar o código, otimizá-lo ou reutilizá-lo se a aplicação exigir partes do mesmo processamento noutro local. Para obter mais informações, veja o padrão Pipes e Filtros.

  • Gerir a orquestração dos passos de uma tarefa. Uma aplicação pode executar tarefas que incluem muitos passos, alguns dos quais podem invocar serviços remotos ou aceder a recursos remotos. Por vezes, os passos individuais são independentes uns dos outros, mas são orquestrados pela lógica da aplicação que implementa a tarefa. Para obter mais informações, veja Padrão do Supervisor do Agente do Scheduler.

  • Gerir a recuperação dos passos de tarefa que falham. Se um ou mais dos passos falharem, uma aplicação poderá ter de anular o trabalho executado por uma série de passos, o que, em conjunto, define uma operação eventualmente consistente. Para obter mais informações, veja Padrão de Transação de Compensação.

Considerações de resiliência

Crie tarefas em segundo plano resilientes para fornecer serviços fiáveis para a aplicação. Quando planear e estruturar tarefas em segundo plano, considere os seguintes pontos:

  • As tarefas em segundo plano têm de processar corretamente reinícios sem danificar dados ou introduzir inconsistências na aplicação. Para tarefas de execução prolongada ou de vários passos, considere utilizar pontos de verificação. Utilize pontos de verificação para guardar o estado das tarefas no armazenamento persistente ou como mensagens numa fila. Por exemplo, pode armazenar informações de estado numa mensagem que esteja numa fila e atualizar incrementalmente estas informações de estado com o progresso da tarefa. A tarefa pode ser processada a partir do último ponto de verificação conhecido em vez de reiniciar a partir do início.

    Para filas do Service Bus, utilize sessões de mensagens para esta finalidade. Com as sessões de mensagens, guarde e obtenha o estado de processamento da aplicação com os métodos SetState e GetState . Para obter mais informações sobre a conceção de processos e fluxos de trabalho de vários passos fiáveis, veja Padrão do Supervisor do Agente do Scheduler.

  • Quando utiliza filas para comunicar com tarefas em segundo plano, as filas podem atuar como uma memória intermédia para armazenar os pedidos que são enviados para as tarefas enquanto a aplicação se encontra sob uma carga superior ao habitual. As tarefas podem acompanhar a IU durante períodos menos ocupados e os reinícios não bloqueiam a IU. Para obter mais informações, veja Padrão de Redistribuição de Carga Baseada em Filas. Se algumas tarefas forem mais importantes do que outras, considere implementar o padrão Fila de Prioridade para garantir que estas tarefas são executadas primeiro.

Mensagens

Configure tarefas em segundo plano que são iniciadas por mensagens ou que processam mensagens para processar inconsistências, como mensagens que chegam fora de ordem, mensagens que causam repetidamente um erro (mensagens venenosas) e mensagens que são entregues mais do que uma vez. Considere as seguintes recomendações:

  • Por vezes, precisa que as mensagens sejam processadas por uma ordem específica, como mensagens que alteram dados com base no valor de dados existente, por exemplo, adicionar um valor a um valor existente. As mensagens nem sempre chegam pela ordem em que foram enviadas. Além disso, diferentes instâncias de uma tarefa em segundo plano podem processar mensagens por uma ordem diferente devido a cargas variadas em cada instância.

    Para mensagens que têm de ser processadas por uma ordem específica, inclua um número de sequência, chave ou outro indicador que as tarefas em segundo plano podem utilizar para processar mensagens pela ordem correta. Para o Service Bus, utilize sessões de mensagens para garantir a ordem de entrega correta. É mais eficiente conceber o processo para que a ordem das mensagens não seja importante. Para obter mais informações, veja Sequência de mensagens e carimbos de data/hora.

  • Normalmente, uma tarefa em segundo plano espreita as mensagens na fila, o que as oculta temporariamente de outros consumidores de mensagens. Depois de a tarefa processar a mensagem com êxito, elimina a mensagem. Se uma tarefa em segundo plano falhar quando processa uma mensagem, essa mensagem reaparece na fila após o tempo limite de pré-visualização expirar. Uma instância diferente da tarefa processa a mensagem ou o próximo ciclo de processamento da instância original processa a mensagem.

    Se a mensagem causar consistentemente um erro no consumidor, bloqueia a tarefa, a fila e, eventualmente, a própria aplicação quando a fila fica cheia. É vital detetar e remover mensagens venenosas da fila. Se utilizar o Service Bus, mova automaticamente ou manualmente mensagens venenosas para uma fila de mensagens não entregues associada.

  • As filas são mecanismos de entrega pelo menos uma vez , mas podem entregar a mesma mensagem mais do que uma vez. Se uma tarefa em segundo plano falhar depois de processar uma mensagem, mas antes de a eliminar da fila, a mensagem estará novamente disponível para processamento.

    As tarefas em segundo plano devem ser idempotentes, o que significa que, quando a tarefa processa a mesma mensagem mais do que uma vez, não causa um erro ou inconsistência nos dados da aplicação. Algumas operações são naturalmente idempotentes, por exemplo, se um valor armazenado estiver definido para um novo valor específico. No entanto, algumas operações causam inconsistências, por exemplo, se um valor for adicionado a um valor armazenado existente sem verificar se o valor armazenado continua a ser o mesmo que quando a mensagem foi originalmente enviada. Configure as filas do Service Bus para remover automaticamente mensagens duplicadas. Para obter mais informações, veja Processamento de mensagens Idempotentes.

  • Alguns sistemas de mensagens, como filas do Armazenamento do Azure e filas do Service Bus, suportam uma propriedade de contagem de pedidos que indica quantas vezes uma mensagem da fila é lida. Estes dados são úteis para processar mensagens repetidas e mensagens venenosas. Para obter mais informações, veja Padrões de Idempotência e primer de mensagens assíncronas.

Considerações de desempenho e dimensionamento

As tarefas em segundo plano têm de oferecer desempenho suficiente para garantir que não bloqueiam a aplicação nem atrasam a operação quando o sistema está sob carga. Normalmente, o desempenho melhora quando dimensiona as instâncias de computação que alojam as tarefas em segundo plano. Quando planear e estruturar tarefas em segundo plano, considere os seguintes pontos relacionados com a escalabilidade e o desempenho:

  • O Azure Máquinas Virtuais e a funcionalidade Aplicações Web do Serviço de Aplicações do Azure podem alojar implementações. Suportam o dimensionamento automático, ao aumentar horizontalmente e ao aumentar horizontalmente. O dimensionamento automático é determinado pela procura e carga ou por um agendamento predefinido. Utilize o dimensionamento automático para ajudar a garantir que a aplicação tem capacidades de desempenho suficientes, minimizando simultaneamente os custos de runtime.

  • Algumas tarefas em segundo plano têm uma capacidade de desempenho diferente em comparação com outras partes de uma aplicação, por exemplo, a IU ou componentes, como a camada de acesso a dados. Nesse cenário, aloje as tarefas em segundo plano num serviço de computação separado para que a IU e as tarefas em segundo plano possam ser dimensionadas de forma independente para gerir a carga. Se várias tarefas em segundo plano tiverem capacidades de desempenho significativamente diferentes, divida-as e dimensione cada tipo de forma independente. Esta técnica pode aumentar os custos de runtime.

  • Para evitar a perda de desempenho sob carga, também poderá ter de dimensionar as filas de armazenamento e outros recursos para que um único ponto da cadeia de processamento não cause um estrangulamento. Considere outras limitações, como o débito máximo de armazenamento e outros serviços em que a aplicação e as tarefas em segundo plano dependem.

  • Criar tarefas em segundo plano para dimensionamento. Por exemplo, as tarefas em segundo plano têm de detetar dinamicamente o número de filas de armazenamento utilizadas para monitorizar mensagens ou enviar mensagens para a fila adequada.

  • Por predefinição, um WebJob dimensiona com a respetiva instância de Aplicações Web associada. No entanto, se quiser que um WebJob seja executado apenas como uma única instância, pode criar um ficheiro Settings.job que contenha os dados { "is_singleton": true }JSON. Este método força o Azure a executar apenas uma instância do WebJob, mesmo que existam várias instâncias da aplicação Web associada. Esta técnica é útil para tarefas agendadas que têm de ser executadas apenas como uma única instância.

  • As tarefas em segundo plano podem criar desafios para a sincronização de dados e a coordenação de processos, especialmente se as tarefas em segundo plano dependerem umas das outras ou de outras origens de dados. Por exemplo, as tarefas em segundo plano podem lidar com problemas de consistência de dados, condições de corrida, impasses ou tempos limite.

  • As tarefas em segundo plano poderão afetar a experiência do utilizador se os resultados das tarefas em segundo plano forem apresentados ao utilizador. Por exemplo, as tarefas em segundo plano podem exigir que o utilizador aguarde por uma notificação, atualize a página ou verifique manualmente o estado da tarefa. Estes comportamentos podem aumentar a complexidade da interação do utilizador e afetar negativamente a experiência do utilizador.

Desvantagem: as tarefas em segundo plano introduzem mais componentes e dependências para o sistema, o que pode aumentar os custos de complexidade e manutenção da solução. Por exemplo, as tarefas em segundo plano podem exigir um serviço de fila separado, um serviço de trabalho, um serviço de monitorização e um mecanismo de repetição.

Facilitação do Azure

As secções seguintes descrevem os serviços do Azure que pode utilizar para alojar, executar, configurar e gerir tarefas em segundo plano.

Ambientes de anfitrião

Existem vários serviços de plataforma do Azure que podem alojar tarefas em segundo plano:

  • Aplicações Web e WebJobs: utilize a funcionalidade WebJobs do Serviço de Aplicações para executar tarefas personalizadas baseadas em diferentes scripts ou programas que pode executar numa aplicação Web.

  • Funções do Azure: utilize aplicações de funções para tarefas em segundo plano que não são executadas durante muito tempo. Também pode utilizar aplicações de funções se alojar a carga de trabalho num plano de Serviço de Aplicações subutilizado.

  • Máquinas Virtuais: se tiver um serviço Windows ou quiser utilizar o Programador de Tarefas do Windows, aloje as suas tarefas em segundo plano numa VM dedicada.

  • Azure Batch: o Batch é um serviço de plataforma que pode utilizar para agendar trabalhos de computação intensiva para serem executados numa coleção gerida de VMs. Pode dimensionar automaticamente recursos de computação.

  • Azure Kubernetes Service (AKS): o AKS fornece um ambiente de alojamento gerido para o Kubernetes no Azure.

  • Azure Container Apps: com as Container Apps, pode criar microsserviços sem servidor baseados em contentores.

As secções seguintes fornecem considerações para cada uma destas opções para o ajudar a escolher a melhor opção para si.

Aplicações Web e WebJobs

Pode utilizar a funcionalidade WebJobs para executar tarefas personalizadas como tarefas em segundo plano numa aplicação Web. Um WebJob é executado como um processo contínuo no contexto da sua aplicação Web. Um WebJob também pode ser executado em resposta a um evento de acionador do Logic Apps ou de fatores externos, como alterações a blobs de armazenamento ou filas de mensagens. Os WebJobs podem ser iniciados e parados a pedido e encerrados corretamente. Se um WebJob em execução contínua falhar, será reiniciado automaticamente. Pode configurar ações de repetição e erro.

Quando configura um WebJob:

  • Se quiser que a tarefa responda a um acionador orientado por eventos, configure-o para Executar continuamente. O script ou programa é armazenado na pasta com o nome site/wwwroot/app_data/jobs/continuous.

  • Se quiser que a tarefa responda a um acionador orientado pela agenda, configure-o para Executar com base numa agenda. O script ou o programa é armazenado na pasta site/wwwroot/aplicação_dados/tarefas/acionada.

  • Se escolher a opção Executar a pedido quando configurar uma tarefa, esta executa o mesmo código que a opção Executar com base numa agenda quando inicia a tarefa.

Um WebJob é executado no sandbox da aplicação Web. Tem acesso a variáveis de ambiente e pode partilhar informações, como cadeias de ligação, com a aplicação Web. O WebJob tem acesso ao identificador exclusivo do computador que executa o WebJob. O cadeia de ligação com o nome AzureWebJobsStorage fornece acesso a Filas de armazenamento, blobs e tabelas para dados da aplicação. Também fornece acesso ao Service Bus para mensagens e comunicações. O cadeia de ligação com o nome AzureWebJobsDashboard fornece acesso aos ficheiros de registo de ações do WebJob.

Os WebJobs têm as seguintes características:

  • Segurança: as credenciais de implementação da aplicação Web fornecem proteção para WebJobs.

  • Tipos de ficheiro suportados: defina WebJobs com scripts de comandos (.cmd), ficheiros em lote (.bat), scripts do PowerShell (.ps1), scripts de shell do Bash (.sh), scripts PHP (.php), scripts python (.py), código JavaScript (.js) e programas executáveis (.exe e .jar).

  • Implementação: pode implementar scripts e executáveis com o portal do Azure, o Visual Studio ou o SDK do WebJobs ou pode copiá-los diretamente para as seguintes localizações:

    • Para implementação acionada: site/wwwroot/app_data/jobs/triggered/<job name>

    • Para implementação contínua: site/wwwroot/app_data/jobs/continuous/<job name>

  • Ficheiros de registo: Console.Out são tratados ou marcados como INFO. Console.Error é tratado como ERROR. Utilize o portal para aceder às informações de monitorização e diagnóstico. Transfira ficheiros de registo diretamente a partir do site. Os ficheiros de registo são guardados nas seguintes localizações:

    • Para a implementação acionada: Vfs/data/jobs/triggered/<job name>

    • Para implementação contínua: Vfs/data/jobs/continuous/<job name>

  • Configuração: configure o WebJobs com o portal, a API REST e o PowerShell. Utilize um ficheiro de configuração com o nome settings.job, que está no mesmo diretório de raiz que o script de WebJob, para fornecer informações de configuração para um WebJob. Por exemplo:

    • { "stopping_wait_time": 60 }

    • { "is_singleton": true }

considerações sobre Aplicações Web e WebJobs

  • Por predefinição, o WebJobs é ajustado com a aplicação Web. Para configurar o WebJobs para ser executado numa única instância, defina a propriedade de is_singleton configuração como true. Os WebJobs de instância única são úteis para tarefas que não pretende dimensionar ou executar como várias instâncias simultâneas, como reindexação ou análise de dados.

  • Para minimizar o efeito do WebJobs no desempenho da aplicação Web, crie uma instância de aplicação Web vazia num novo plano de Serviço de Aplicações para alojar WebJobs de execução prolongada ou com muitos recursos.

Funções do Azure

Funções do Azure é semelhante ao WebJobs. Funções do Azure é sem servidor e é mais adequado para acionadores orientados por eventos que são executados durante um curto período de tempo. Também pode utilizar Funções do Azure para executar tarefas agendadas através de acionadores de temporizador se configurar uma função para ser executada em horas especificadas.

Funções do Azure não é recomendado para tarefas grandes e de execução prolongada porque uma função pode causar tempos limite inesperados. No entanto, dependendo do seu plano de alojamento, considere utilizar funções para acionadores orientados pela agenda.

considerações Funções do Azure

Se espera que a tarefa em segundo plano seja executada durante um curto período de tempo em resposta a um evento, considere executar a tarefa no plano de consumo. Pode configurar o runtime para um tempo máximo. Uma função que é executada durante mais tempo custa mais. As tarefas com utilização intensiva da CPU que consomem mais memória podem ser mais dispendiosas. Se utilizar acionadores adicionais para serviços como parte da sua tarefa, estes são cobrados separadamente.

O plano premium é adequado se tiver várias tarefas curtas, mas que são executadas continuamente. Este plano é mais caro porque precisa de mais memória e CPU. Como benefício, pode utilizar outras funcionalidades, como a integração da rede virtual.

O plano dedicado é adequado para tarefas em segundo plano se a carga de trabalho já estiver em execução no plano dedicado. Se tiver VMs subutilizadas, pode executar o plano dedicado na mesma VM e partilhar os custos de computação.

Para obter mais informações, consulte:

Máquinas Virtuais

Pode implementar tarefas em segundo plano para que não sejam implementadas no Aplicações Web. Por exemplo, pode implementar tarefas através de serviços do Windows, utilitários de terceiros ou programas executáveis. Também pode utilizar programas escritos para um ambiente de runtime diferente do ambiente que aloja a aplicação. Por exemplo, pode utilizar um programa Unix ou Linux que pretende executar a partir de uma aplicação Windows ou .NET. Escolha entre vários sistemas operativos para uma VM do Azure e execute o seu serviço ou executável nessa VM.

Para obter mais informações, consulte:

Para iniciar a tarefa em segundo plano numa VM separada, pode:

  • Envie um pedido para um ponto final que a tarefa expõe para executar a tarefa a pedido diretamente a partir da sua aplicação. O pedido transfere os dados necessários para a tarefa. O ponto final invoca a tarefa.

  • Utilize um agendador ou temporizador do sistema operativo escolhido para configurar a tarefa a executar com base numa agenda. Por exemplo, no Windows, pode utilizar o Programador de Tarefas do Windows para executar scripts e tarefas. Se tiver SQL Server instalado na VM, utilize SQL Server Agent para executar scripts e tarefas.

  • Utilize o Logic Apps para iniciar a tarefa ao adicionar uma mensagem a uma fila que a tarefa monitoriza ou ao enviar um pedido para uma API que a tarefa expõe.

Para obter mais informações sobre como pode iniciar tarefas em segundo plano, veja a secção Acionadores anteriores.

considerações de Máquinas Virtuais

Considere os seguintes pontos ao implementar tarefas em segundo plano numa VM do Azure:

  • Alojar tarefas em segundo plano numa VM do Azure separada para fornecer flexibilidade e controlo preciso sobre a iniciação, implementação, agendamento e alocação de recursos. No entanto, os custos de runtime aumentam se implementar uma VM apenas para tarefas em segundo plano.

  • Não existe nenhuma instalação para monitorizar as tarefas no portal e nenhuma capacidade de reinício automatizado para tarefas falhadas. No entanto, pode utilizar os cmdlets do Azure Resource Manager para monitorizar o estado da VM e geri-la. Não existem instalações para controlar processos e threads em nós de computação. Normalmente, se utilizar uma VM, tem de implementar um mecanismo que recolhe dados da instrumentação na tarefa e também do sistema operativo na VM. Pode utilizar o Pacote de Gestão do System Center para o Azure para esta finalidade.

  • Considere criar pesquisas de monitorização que são expostas através de pontos finais HTTP. Pode configurar o código para estas sondas efetuar verificações de estado de funcionamento e recolher informações operacionais e estatísticas. Também pode utilizar as pesquisas para agrupar as informações de erro e devolvê-la a uma aplicação de gestão.

Para obter mais informações, consulte:

Batch

Considere o Batch se precisar de executar grandes cargas de trabalho de computação de alto desempenho (HPC) paralelas em dezenas, centenas ou milhares de VMs.

Utilize o Batch para preparar as VMs, atribuir tarefas às VMs, executar as tarefas, monitorizar o progresso e aumentar horizontalmente automaticamente as VMs em resposta à carga de trabalho. O Batch também fornece agendamento de trabalhos e suporta VMs do Linux e do Windows.

Considerações sobre o Batch

O Batch é adequado para cargas de trabalho intrinsecamente paralelas. Pode utilizar o Batch para realizar cálculos paralelos com um passo de redução no final ou executar aplicações de Interface de Passagem de Mensagens (MPI) para tarefas paralelas que requerem a transmissão de mensagens entre nós.

Uma tarefa do Batch é executada num conjunto de nós ou VMs. Só pode alocar um conjunto quando for necessário e, em seguida, eliminá-lo após a conclusão da tarefa. Esta abordagem maximiza a utilização porque os nós não estão inativos, mas a tarefa tem de aguardar que aloque nós. Em alternativa, pode criar um conjunto com antecedência. Esta abordagem minimiza o tempo que uma tarefa demora a iniciar, mas pode resultar em nós que ficam inativos.

Para obter mais informações, consulte:

Azure Kubernetes Service

Utilize o AKS para gerir o seu ambiente alojado do Kubernetes para que possa facilmente implementar e gerir aplicações em contentores.

Os contentores são úteis para executar tarefas em segundo plano. Alguns dos benefícios incluem:

  • Os contentores suportam alojamento de alta densidade. Pode isolar uma tarefa em segundo plano num contentor enquanto coloca vários contentores em cada VM.

  • Utilize o orquestrador de contentores para efetuar o balanceamento de carga interno, configurar a rede interna e executar outras tarefas de configuração.

  • Pode iniciar e parar os contentores conforme necessário.

  • Com Azure Container Registry, pode registar os seus contentores dentro dos limites do Azure para proporcionar benefícios de segurança, privacidade e proximidade.

Considerações sobre o AKS

O AKS requer uma compreensão de como utilizar um orquestrador de contentores.

Para obter mais informações, consulte:

Container Apps

Com as Container Apps, pode criar microsserviços sem servidor baseados em contentores. Aplicações de Contentor:

  • Está otimizado para executar contentores para fins gerais, especialmente aplicações que abrangem muitos microsserviços implementados em contentores.

  • É alimentado pelo Kubernetes e tecnologias open source, como Dapr, Kubernetes Event-driven Autoscaling (KEDA) e Envoy.

  • Suporta microsserviços e aplicações de estilo Kubernetes com funcionalidades como a deteção de serviços e a divisão de tráfego.

  • Permite arquiteturas de aplicações condicionadas por eventos ao suportar dimensionamento baseado no tráfego e extração de origens de eventos, como filas, incluindo dimensionar para zero.

  • Suporta processos de execução prolongada e pode executar tarefas em segundo plano.

Considerações sobre aplicações de contentor

As Container Apps não fornecem acesso direto às APIs do Kubernetes subjacentes. Se precisar de acesso às APIs do Kubernetes e ao plano de controlo, utilize o AKS. Se quiser criar aplicações do estilo Kubernetes e não precisar de acesso direto às APIs nativas do Kubernetes e à gestão de clusters, utilize as Container Apps para uma experiência totalmente gerida. O Container Apps é mais adequado para criar microsserviços de contentor.

Para obter mais informações, consulte:

Lista de verificação de fiabilidade

Veja o conjunto completo de recomendações.

Lista de verificação de fiabilidade