Partilhar via

Estilo de arquiteturaQueue-Worker Web

Serviço de Aplicações do Azure

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

Diagrama lógico do estilo de arquitetura Web-Queue-Worker.

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

  • Uma ou mais bases 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 e-mail ou serviço de SMS. Muitas vezes, esses recursos são fornecidos por terceiros.
  • Provedor de identidade para autenticação.

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

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

Quando usar esta arquitetura

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

Considere este estilo de arquitetura para:

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

Benefícios

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

Desafios

  • Sem um design cuidadoso, o front-end e o trabalhador podem se tornar componentes grandes e monolíticos que são difíceis de manter e atualizar.
  • Pode haver dependências ocultas, se o front-end e o trabalhador 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 mitigar esse problema, mas exigem alterar o roteamento de mensagens de saída para primeiro "loop back" através de uma fila separada. Uma biblioteca que fornece suporte para essa técnica é a sessão transacional NServiceBus.

Melhores práticas

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 arquitetura Web-Queue-Worker.

Baixe um arquivo Visio desta arquitetura.

Fluxo de trabalho

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

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

  • O Cache Redis do Azure 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 se ajustam à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 do aplicativo Web do Serviço de Aplicativo e como criar aplicativos de negócios controlados por mensagem com o NServiceBus e o Azure Service Bus.

Outras considerações

  • Nem todas as transações precisam passar pela fila e trabalhar para o armazenamento. O front-end da Web pode executar operações simples de leitura/gravação diretamente. Os trabalhadores são projetados para tarefas que consomem muitos recursos ou fluxos de trabalho de longa execução. Em alguns casos, você pode não precisar de um trabalhador.

  • Use o recurso de dimensionamento automático interno do Serviço de Aplicativo para dimensionar 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ção 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, trocar para a nova versão. Ele também permite que você troque de volta para a versão anterior, se houver um problema com a atualização.