evento
17/03, 23 - 21/03, 23
Junte-se à série meetup para criar soluções de IA escaláveis com base em casos de uso do mundo real com outros desenvolvedores e especialistas.
Registe-se agoraEste browser já não é suportado.
Atualize para o Microsoft Edge para tirar partido das mais recentes funcionalidades, atualizações de segurança e de suporte técnico.
Muitos tipos de aplicações precisam de tarefas em segundo plano que são executadas independentemente da interface de utilizador (IU). Os exemplos incluem tarefas de lote, tarefas de processamento intensivas e processos de longa execução, como os fluxos de trabalho. As tarefas em segundo plano podem ser executadas sem interação do utilizador – a aplicação pode iniciar a tarefa e, em seguida, continuar a processar pedidos interativos dos utilizadores. Isto pode ajudar a minimizar a carga sobre a IU da aplicação, o que pode melhorar a disponibilidade e reduzir os tempos de resposta interativos.
Por exemplo, se uma aplicação precisar de gerar miniaturas de imagens que são carregadas por utilizadores, pode fazê-lo como uma tarefa em segundo plano e guardar a miniatura no armazenamento quando estiver concluída – sem que o utilizador tenha de aguardar que o processo seja concluído. Da mesma forma, um utilizador que faz um pedido pode iniciar um fluxo de trabalho em segundo plano que processa o pedido, enquanto a IU permite ao utilizador continuar a navegar na aplicação Web. Quando a tarefa em segundo plano estiver concluída, pode atualizar os dados dos pedidos armazenados e enviar um e-mail ao utilizador que confirma o pedido.
Quando considerar se deseja implementar uma tarefa como uma tarefa em segundo plano, o critério principal é se a tarefa pode ser executada sem interação do utilizador e sem a IU ter de aguardar que a tarefa seja concluída. As tarefas que exigem que o utilizador ou a IU tenha de esperar enquanto estas são concluídas, podem não ser apropriadas como tarefas em segundo plano.
As tarefas em segundo plano incluem, geralmente, um ou mais dos seguintes tipos de tarefas:
As tarefas em segundo plano podem ser iniciadas de várias formas diferentes. Elas enquadram-se numa das seguintes categorias:
A invocação desencadeada por eventos utiliza um acionador para iniciar a tarefa em segundo plano. Exemplos de como utilizar acionadores desencadeados por eventos:
Os exemplos típicos de tarefas que são adequadas para a invocação desencadeada por eventos incluem o processamento de imagens, fluxos de trabalho, enviar informações para serviços remotos, enviar mensagens de e-mail e aprovisionar novos utilizadores em aplicações multi-inquilino.
A invocação desencadeada pela agenda utiliza um temporizador para iniciar a tarefa em segundo plano. Exemplos de como utilizar acionadores desencadeados pela agenda:
Os exemplos típicos de tarefas que são adequadas para a invocação desencadeada pela agenda incluem rotinas de processamento em lote (por exemplo, atualizar listas relacionadas com produtos para utilizadores com base no seu comportamento recente), tarefas de processamento de dados de rotina (por exemplo, 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 dos dados.
Se utilizar uma tarefa desencadeada pela agenda que deve ser executada como uma única instância, tenha em atenção o seguinte:
As tarefas em segundo plano são executadas de forma assíncrona num processo separado, ou mesmo numa localização separada, a partir da IU ou do processo que invocou a tarefa em segundo plano. Idealmente, as tarefas em segundo plano são operações de "disparar e esquecer", e seu progresso de execução não tem impacto na interface do usuário ou no processo de chamada. Isto significa que o processo da chamada não aguarda pela conclusão das tarefas. Por isso, não consegue detetar automaticamente quando a tarefa termina.
Se precisar de uma tarefa em segundo plano para comunicar com a tarefa da chamada para indicar o progresso ou a conclusão, tem de implementar um mecanismo para isto. Alguns exemplos são:
Pode alojar tarefas em segundo plano com uma variedade de diferentes serviços da plataforma do Azure:
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.
Pode utilizar o WebJobs do Azure para executar tarefas personalizadas como tarefas em segundo plano numa aplicação Web do Azure. O WebJobs é executado no contexto da sua aplicação 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 a fatores externos, como alterações em blobs de armazenamento e filas de mensagens. As tarefas podem ser iniciadas e paradas a pedido, e encerradas facilmente. Se um WebJob em execução contínua falhar, é reiniciado automaticamente. As ações de repetição e erro são configuráveis.
Quando configura um WebJob:
O WebJobs do Azure é executado na sandbox da aplicação Web. Isto significa que pode aceder a variáveis de ambiente e partilhar informações, como cadeias de ligação com a aplicação Web. A tarefa tem acesso ao identificador exclusivo do computador que está a executar a tarefa. A cadeia de conexão chamada AzureWebJobsStorage fornece acesso a filas, blobs e tabelas do Armazenamento do Azure para dados de aplicativos e acesso ao Service Bus para mensagens e comunicação. A cadeia de ligação AzureWebJobsDashboard concede acesso aos ficheiros de registo da ação de tarefa.
O WebJobs do Azure tem as seguintes características:
.cmd
), arquivos em lote (.bat
), scripts PowerShell (.ps1
), scripts shell Bash (.sh
), scripts PHP (.php
), scripts Python (.py
), código JavaScript (.js
) e programas executáveis (.exe
, .jar
e muito mais).Uma opção semelhante ao WebJobs é o Azure Functions. Este 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 através 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 longa execução porque podem causar problemas inesperados de tempo limite. No entanto, dependendo do plano de hospedagem, eles podem ser considerados para gatilhos orientados por agendamento.
Se se espera que a tarefa em segundo plano seja executada por uma curta duração em resposta a um evento, considere executá-la em um plano de consumo. O tempo de execução é configurável até um tempo máximo. Uma função que funciona por mais tempo custa mais. Além disso, trabalhos intensivos em 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 grande número de tarefas que são curtas, mas espera-se que sejam executadas continuamente. Este plano é mais caro porque precisa de mais memória e CPU. A vantagem é que você pode usar recursos como a integração de rede virtual.
O plano Dedicado é mais adequado para trabalhos em segundo plano se a sua carga de trabalho já for executada nele. Se você tiver VMs subutilizadas, poderá executá-las na mesma VM e compartilhar os custos de computação.
Para mais informações, consulte estes artigos:
As tarefas em segundo plano podem ser implementadas de uma forma que impeça que sejam implantadas nos Aplicativos Web do Azure ou essas opções podem não ser convenientes. Os exemplos típicos incluem os serviços Windows, utilitários de terceiros e programas executáveis. Outro exemplo poderá ser os programas escritos para um ambiente de execução que é diferente do que aloja a aplicação. Por exemplo, poderá ser um programa Unix ou Linux que pretende executar a partir de uma aplicação do Windows ou .NET. Pode escolher entre uma variedade de sistemas operativos para uma máquina virtual do Azure e executar o serviço ou a executável nessa máquina virtual.
Para o ajudar a escolher quando deve utilizar Máquinas Virtuais, veja Serviço de Aplicações do Azure, Serviços Cloud e Máquinas Virtuais. 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 operativos e as imagens pré-criadas que estão disponíveis para as Máquinas Virtuais, veja Marketplace das Máquinas Virtuais do Azure.
Para iniciar a tarefa em segundo plano numa máquina virtual separada, tem diversas opções:
Veja a secção anterior Acionadores para obter mais informações sobre como pode iniciar tarefas em segundo plano.
Quando estiver a decidir se vai implementar tarefas em segundo plano numa máquina virtual do Azure, considere os seguintes pontos:
Para obter mais informações, consulte:
Considere o Azure Batch se precisar de executar cargas de trabalho de computação grandes e paralelas de elevado desempenho (HPC) em dezenas, centenas ou milhares de VMs.
O serviço do Batch aprovisiona as VMs, atribui tarefas às VMs, executa as tarefas e monitoriza o progresso. O Batch pode aumentar horizontalmente as VMs de forma automática em resposta à carga de trabalho. O Batch também concede o agendamento de tarefas. O Azure Batch suporta VMs do Linux e do Windows.
O Batch funciona bem com cargas de trabalho intrinsecamente paralelas. Também pode 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 exigem a passagem de mensagens entre nós.
É executada uma tarefa do Azure Batch num conjunto de nós (VMs). Uma abordagem é alocar um conjunto apenas quando for necessário e, em seguida, eliminá-lo assim que a tarefa for concluída. Isto maximiza a utilização porque os nós não estão inativos, mas a tarefa tem de aguardar que os nós estejam alocados. Em alternativa, pode criar um conjunto antecipadamente. Essa abordagem minimiza o tempo que a tarefa demora a iniciar, mas pode resultar em nós que ficam inativos. Para obter mais informações, veja Duração do nó de computação e do conjunto.
Para obter mais informações, consulte:
O Serviço Kubernetes do Azure (AKS) gerencia seu ambiente Kubernetes hospedado, o que facilita a implantação e o gerenciamento de aplicativos em contêineres.
Os contentores podem ser úteis para executar tarefas em segundo plano. Alguns dos benefícios incluem:
Para obter mais informações, consulte:
Os Aplicativos de Contêiner do Azure permitem que você crie microsserviços sem servidor com base em contêineres. Os recursos distintivos dos Container Apps incluem:
Os Aplicativos de Contêiner do Azure não fornecem acesso direto às APIs subjacentes do Kubernetes. Se você precisar de acesso às APIs do Kubernetes e ao plano de controle, deverá usar o Serviço Kubernetes do Azure. No entanto, se você quiser criar aplicativos no estilo Kubernetes e não precisar de acesso direto a todas as APIs nativas do Kubernetes e gerenciamento de cluster, o Container Apps oferece uma experiência totalmente gerenciada com base nas práticas recomendadas. 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 inícios rápidos.
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. Estes fatores irão ajudá-lo a decidir se pretende colocar as tarefas com a instância de computação existente ou separá-las numa instância de computação separada:
Disponibilidade: as tarefas em segundo plano não precisam de ter o mesmo nível de disponibilidade como as outras partes da aplicação, em particular a IU e outras partes diretamente envolvidas na interação do utilizador. As tarefas em segundo plano podem ter mais tolerância à latência, falhas de nova tentativa de ligação e outros fatores que afetam a disponibilidade, porque as operações podem ser colocadas em fila. No entanto, tem de existir capacidade suficiente para impedir a cópia de segurança de pedidos que pode bloquear filas e afetar a aplicação como um todo.
Escalabilidade: é provável que as tarefas em segundo plano tenham um requisito de escalabilidade diferente da IU e das partes interativas da aplicação. O dimensionamento da interface do usuário pode ser necessário para atender a picos de demanda, enquanto tarefas pendentes em segundo plano podem ser concluídas durante períodos menos ocupados por menos instâncias de computação.
Resiliência: a falha de uma instância de computação que aloja apenas tarefas em segundo plano pode não afetar fatalmente a aplicação como um todo se os pedidos para estas tarefas puderem ser colocados em fila ou adiados até que a tarefa esteja novamente disponível. Se a instância ou tarefas de computação puderem ser reiniciadas dentro de um intervalo apropriado, os usuários do aplicativo poderão não ser afetados.
Segurança: as tarefas em segundo plano podem ter diferentes requisitos de segurança ou restrições da IU ou de outras partes da aplicação. Ao utilizar uma instância de computação separada, pode especificar um ambiente de segurança diferente para as tarefas. Também pode utilizar padrões como o Gatekeeper para isolar as instâncias de computação em segundo plano da IU, para maximizar a segurança e a separação.
Desempenho: pode escolher o tipo de instância de computação para as tarefas em segundo plano para corresponder especificamente aos requisitos de desempenho das tarefas. Isto pode significar a utilização de uma opção de computação menos dispendiosa, se as tarefas não exigirem as mesmas capacidades de processamento que a IU, ou uma instância maior se exigirem capacidade adicional e recursos.
Capacidade de gestão: as tarefas em segundo plano podem ter um ritmo de desenvolvimento e implementação diferentes do código da aplicação principal ou da IU. Pode simplificar as atualizações e o controlo de versões ao implementá-las numa instância de computação separada.
Custo: adicionar instâncias de computação para executar tarefas em segundo plano aumenta os custos de alojamento. Pondere cuidadosamente o equilíbrio entre a capacidade adicional e estes custos adicionais.
Para obter mais informações, consulte o padrão Eleição do líder e o padrão Consumidores concorrentes.
Se tiver várias instâncias de uma tarefa em segundo plano, é possível que estas compitam para terem acesso a recursos e serviços, como bases de dados e armazenamento. Este acesso simultâneo pode resultar em contenção de recursos, o que poderá causar conflitos na disponibilidade dos serviços e na integridade dos dados no armazenamento. Pode resolver a contenção de recursos com uma abordagem de bloqueio pessimista. Isto impede que as instâncias concorrentes de uma tarefa acedam simultaneamente a um serviço ou danifiquem dados.
Outra abordagem para resolver conflitos consiste em definir tarefas em segundo plano como singleton, de modo a que exista sempre e apenas uma única instância em execução. No entanto, isto elimina as vantagens de fiabilidade e desempenho que uma configuração de várias instâncias pode oferecer. O que é particularmente verdadeiro se a IU fornecer trabalho suficiente para manter mais do que uma tarefa em segundo plano ocupada.
É fundamental assegurar que a tarefa em segundo plano pode reiniciar automaticamente e ter capacidade suficiente para lidar com picos a pedido. Pode conseguir isto ao alocar uma instância de computação com recursos suficientes, através da implementação de um mecanismo de colocação em fila que pode armazenar pedidos para posterior execução quando a procura diminui ou através da combinação destas técnicas.
As tarefas em segundo plano podem ser complexas e podem exigir várias tarefas individuais a serem executadas para produzir um resultado ou para cumprir todos os requisitos. É comum nestes cenários dividir a tarefa em passos mais pequenos e discretos ou subtarefas que podem ser executadas por vários consumidores. As tarefas com vários passos podem ser mais eficientes e flexíveis porque os passos individuais podem ser reutilizáveis em várias tarefas. Também é fácil adicionar, remover ou modificar a ordem dos passos.
Coordenar várias tarefas e passos pode ser um desafio, mas existem três padrões comuns que pode utilizar para guiar a sua implementação de uma solução:
Decompor uma tarefa em vários passos reutilizáveis. Pode ser preciso uma aplicação para realizar uma série de tarefas de complexidade variada nas informações que vai processar. Uma abordagem simples, mas inflexível, para implementar esta aplicação pode consistir em realizar este processamento como um módulo monolítico. No entanto, é provável que esta abordagem reduza as oportunidades para refatorizar o código, ao otimizá-lo ou reutilizá-lo se forem precisas partes do mesmo processamento noutro local na aplicação. Para obter mais informações, consulte o padrão Pipes and Filters.
Gerir a execução dos passos para uma tarefa. Uma aplicação pode realizar tarefas que compõem um número de passos (alguns dos quais podem invocar serviços remotos ou aceder a recursos remotos). Os passos individuais podem ser independentes entre si, mas são orquestrados pela lógica da aplicação que implementa a tarefa. Para obter mais informações, consulte Scheduler Agent Supervisor pattern.
Gestão da recuperação para passos com falhas. Uma aplicação pode precisar de anular o trabalho realizado por uma série de passos, que em conjunto definem uma operação eventualmente consistente, em caso de falha de um ou mais passos. Para obter mais informações, consulte o padrão de transação de compensação.
As tarefas em segundo plano têm de ser resilientes para oferecer serviços fiáveis à aplicação. Quando estiver a planear e a 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 longa execução ou com vários passos, considere utilizar o apontador de verificação ao guardar o estado das tarefas no armazenamento persistente ou como mensagens numa fila se esta ação for adequada. Por exemplo, pode manter as informações de estado de uma mensagem numa fila e atualizar incrementalmente estas informações de estado com o progresso da tarefa, para que a tarefa possa ser processada a partir do último bom ponto de verificação conhecido – em vez de reiniciar a partir do início. Quando utilizar filas do Azure Service Bus, pode utilizar sessões de mensagens para ativar o mesmo cenário. As sessões permitem-lhe guardar e obter o estado de processamento da aplicação com os métodos SetState e GetState. Para obter mais informações sobre como projetar processos e fluxos de trabalho confiáveis de várias etapas, consulte o padrão Scheduler Agent Supervisor.
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. Isto permite que as tarefas alcancem a IU em 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 carga baseado em fila. Se algumas tarefas forem mais importantes do que outras, considere implementar o padrão de fila de prioridades para garantir que essas tarefas sejam executadas antes das menos importantes.
As tarefas em segundo plano, que são iniciadas por mensagens ou processam mensagens, têm de ser criadas para lidar com inconsistências, como mensagens que chegam desordenadas, mensagens que originam um erro repetidamente (normalmente designadas como mensagens não processáveis) e mensagens que são enviadas mais do que uma vez. Considere o seguinte:
As mensagens que têm de ser processadas numa ordem específica, como as que alteram dados com base no valor dos dados existentes (por exemplo, ao adicionar um valor a um valor existente), podem não chegar pela ordem original em que foram enviadas. Em alternativa, podem ser processadas por várias instâncias de uma tarefa em segundo plano por uma ordem diferente devido a cargas variadas em cada instância. As mensagens que têm de ser processadas numa ordem específica devem incluir um número de sequência, uma chave ou outro indicador que as tarefas em segundo plano podem utilizar para se certificarem que são processadas na ordem correta. Se estiver a utilizar o Azure Service Bus, pode utilizar sessões de mensagens para garantir a ordem de entrega. No entanto, sempre que possível, é geralmente mais eficiente criar o processo, para que a ordem da mensagem não seja importante.
Normalmente, uma tarefa em segundo plano irá espreitar as mensagens na fila, o que as esconde temporariamente dos outros consumidores de mensagens. Em seguida, elimina as mensagens após terem sido processadas com êxito. Se uma tarefa em segundo plano falhar ao processar uma mensagem, essa mensagem voltará a aparecer na fila após o tempo limite da espreita expirar. Voltará a ser processada por outra instância da tarefa ou durante o próximo ciclo de processamento desta instância. Se a mensagem causa um erro consistentemente no consumidor, esta irá bloquear a tarefa, a fila e, eventualmente, a própria aplicação quando a fila encher. Por conseguinte, é fundamental detetar e remover mensagens não processáveis da fila. Se você estiver usando o Barramento de Serviço do Azure, as mensagens que causam um erro podem ser movidas automática ou manualmente para uma fila de letras mortas associada.
As filas são garantidas em, pelo menos, um mecanismo de entrega, mas poderão enviar a mesma mensagem mais do que uma vez. Além disso, se uma tarefa em segundo plano falhar após o processamento de uma mensagem mas antes da eliminação da fila, a mensagem estará disponível para ser novamente processada. 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 que o valor armazenado é o mesmo quando a mensagem foi originalmente enviada irá causar inconsistências. As filas do Azure Service Bus podem ser configuradas para remover automaticamente mensagens duplicadas. Para obter mais informações sobre os desafios com a entrega de mensagens pelo menos uma vez, consulte as orientações sobre processamento idempotente de mensagens.
Alguns sistemas de mensagens, como o Armazenamento de Filas do Azure e as filas do Barramento de Serviço do Azure, dão suporte a uma propriedade de contagem de eliminação de filas que indica o número de vezes que uma mensagem foi lida da fila. Isto pode ser útil no processamento de mensagens repetidas e não processáveis. Para obter mais informações, veja Manual Básico de Mensagens Assíncronas e Padrões de Idempotência.
As tarefas em segundo plano têm de oferecer desempenho suficiente para se certificar de que não bloqueiam a aplicação ou provocam inconsistências devido à operação atrasada quando o sistema está sob carga. Normalmente, o desempenho é melhorado ao dimensionar as instâncias de computação que alojam as tarefas em segundo plano. Quando estiver a planear e a criar tarefas em segundo plano, considere os seguintes pontos sobre escalabilidade e desempenho:
O Azure dá suporte ao dimensionamento automático (dimensionamento e redimensionamento) com base na demanda e carga atuais ou em um cronograma predefinido, para implantações hospedadas de Aplicativos Web e Máquinas Virtuais. Utilize esta funcionalidade para garantir que a aplicação completa tem capacidades suficientes de desempenho e minimiza os custos do 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 juntas 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 capacidades 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 tempo de execução.
Simplesmente dimensionar os recursos de computação pode não ser suficiente para evitar a perda de desempenho sob carga. Também poderá precisar de aumentar as filas de armazenamento e outros recursos para impedir que um ponto único do processamento geral da cadeia se torne um estrangulamento. Além disso, considere outras limitações, como o débito máximo de armazenamento e outros serviços que a aplicação e as tarefas em segundo plano dependem.
As tarefas em segundo plano têm de ser criadas para dimensionamento. Por exemplo, têm de ser capazes de detetar dinamicamente o número de filas de armazenamento em utilização para escutar ou enviar mensagens para a fila adequada.
Por predefinição, o WebJobs dimensiona com a instância das Aplicações Web do Azure associada. No entanto, se pretender que um WebJob seja executado como uma única instância, pode criar um ficheiro Settings.job que contém os dados JSON { "is_singleton": true }. Isto força o Azure a executar apenas uma instância do WebJob, mesmo se existirem várias instâncias da aplicação Web associada. Isto pode ser uma técnica útil para tarefas agendadas que têm de ser executadas como uma única instância.
evento
17/03, 23 - 21/03, 23
Junte-se à série meetup para criar soluções de IA escaláveis com base em casos de uso do mundo real com outros desenvolvedores e especialistas.
Registe-se agora