Compartilhar via

Estilo de arquiteturaQueue-Worker Web

Serviço de aplicativo do Azure

Os principais componentes dessa arquitetura são um front-end da Web que atende a solicitações de cliente e um trabalho que executa tarefas com uso intensivo de recursos, fluxos de trabalho de execução longa ou trabalhos em lotes. O front-end da Web se comunica com o trabalhador por meio de uma fila de mensagens.

Diagrama lógico do estilo de arquiteturaQueue-Worker Web.

Outros componentes que normalmente são incorporados a essa arquitetura incluem:

  • Um ou mais bancos de dados.
  • Um cache para armazenar valores do banco de dados para leituras rápidas.
  • CDN para fornecer conteúdo estático
  • Serviços remotos, como email ou serviço de SMS. Geralmente, esses recursos são fornecidos por terceiros.
  • Provedor de identidade para autenticação.

A Web e o trabalho são ambos sem estado. O estado da sessão pode ser armazenado em um cache distribuído. Qualquer trabalho de longa execução é feito de forma assíncrona pelo trabalhador. O trabalho pode ser disparado por mensagens na fila ou executado em um agendamento para processamento em lote. O trabalho é um componente opcional. Se não houver operações de execução prolongada, o trabalho poderá ser omitido.

O front-end pode consistir em uma API Web. No lado do cliente, a API Web pode ser consumida por um aplicativo de página única que faz chamadas AJAX ou por um aplicativo cliente nativo.

Quando usar essa arquitetura

A arquitetura deQueue-Worker Web normalmente é implementada usando serviços de computação gerenciada, o Serviço de Aplicativo do Azure ou os Serviços de Nuvem do Azure.

Considere este estilo de arquitetura para:

  • Aplicativos com um domínio relativamente simples.
  • Aplicativos com alguns fluxos de trabalho de execução prolongada ou operações em lote.
  • Quando você deseja usar serviços gerenciados, em vez de iaaS (infraestrutura como serviço).

Benefícios

  • Arquitetura relativamente simples que é fácil de entender.
  • Fácil de implantar e gerenciar.
  • Separação clara de preocupações.
  • O front-end é dissociado do trabalho usando mensagens assíncronas.
  • O front-end e o trabalho podem ser dimensionados de forma independente.

Desafios

  • Sem um design cuidadoso, o front-end e o trabalho podem se tornar componentes grandes e monolíticos difíceis de manter e atualizar.
  • Pode haver dependências ocultas se o front-end e o worker compartilharem esquemas de dados ou módulos de código.
  • O front-end da Web pode funcionar mal depois de persistir com êxito no banco de dados, mas antes de emitir as mensagens para a fila. Isso pode resultar em possíveis problemas de consistência, pois o trabalhador não executará sua parte da lógica. Técnicas como o padrão de caixa de saída transacional podem ser usadas para ajudar a atenuar esse problema, mas exigem a alteração do roteamento de mensagens de saída para o primeiro "loop back" por meio de uma fila separada. Uma biblioteca que fornece suporte para essa técnica é a Sessão Transacional NServiceBus.

Práticas recomendadas

Web-Queue-Worker no Serviço de Aplicativo do Azure

Esta seção descreve uma arquitetura deQueue-Worker da Web recomendada que usa o Serviço de Aplicativo do Azure.

Diagrama físico do estilo de arquiteturaQueue-Worker Web.

Baixe um arquivo do Visio dessa arquitetura.

Fluxo de Trabalho

  • O front-end é implementado como um aplicativo Web do Serviço de Aplicativo do Azure e o trabalho é implementado como um aplicativo do Azure Functions . O aplicativo Web e o aplicativo de funções estão associados a um plano do Serviço de Aplicativo que fornece as instâncias da VM.

  • Você pode usar as filas do Barramento de Serviço do Azure ou do Armazenamento do Azure para a fila de mensagens. (O diagrama mostra uma fila do Armazenamento do Azure.)

  • O Cache do Azure para Redis armazena o estado da sessão e outros dados que precisam de acesso de baixa latência.

  • A CDN do Azure é usada para armazenar em cache conteúdo estático, como imagens, CSS ou HTML.

  • Para armazenamento, escolha as tecnologias de armazenamento que melhor atendem às necessidades do aplicativo. Você pode usar várias tecnologias de armazenamento (persistência poliglota). Para ilustrar essa ideia, o diagrama mostra o Banco de Dados SQL do Azure e o Azure Cosmos DB.

Para obter mais informações, consulte a arquitetura de referência de aplicativo Web do Serviço de Aplicativo e como criar aplicativos de negócios controlados por mensagens com o NServiceBus e o Barramento de Serviço do Azure.

Outras considerações

  • Nem toda transação precisa passar pela fila e trabalhar no armazenamento. O front-end da Web pode executar operações simples de leitura/gravação diretamente. Os trabalhadores são projetados para tarefas com uso intensivo de recursos ou fluxos de trabalho de execução longa. Em alguns casos, talvez você não precise de um trabalhador.

  • Use o recurso de dimensionamento automático interno do Serviço de Aplicativo para escalar horizontalmente o número de instâncias de VM. Se a carga no aplicativo seguir padrões previsíveis, use o dimensionamento automático baseado em agendamento. Se a carga for imprevisível, use regras de dimensionamento automático baseadas em métricas.

  • Considere colocar o aplicativo Web e o aplicativo de funções em planos separados do Serviço de Aplicativo. Dessa forma, eles podem ser dimensionados de forma independente.

  • Use planos separados do Serviço de Aplicativo para produção e teste. Caso contrário, se você usar o mesmo plano para produção e teste, isso significa que seus testes estão sendo executados em suas VMs de produção.

  • Use slots de implantação para gerenciar implantações. Esse método permite implantar uma versão atualizada em um slot de preparo e, em seguida, alternar para a nova versão. Ele também permite que você alterne de volta para a versão anterior, se houver um problema com a atualização.