Estilo de arquitetura Web-Fila-Trabalho

Azure App Service

Os componentes principais desta arquitetura são um front-end da Web que serve pedidos de clientes e uma função de trabalho que realiza tarefas com muitos recursos, fluxos de trabalho de execução longa ou tarefas de lote. O front-end da Web comunica com a função de trabalho através de uma fila de mensagens.

Logical diagram of Web-Queue-Worker architecture style.

Outros componentes que normalmente são incorporados nesta arquitetura:

  • Uma ou mais bases de dados.
  • Uma cache para armazenar os valores da base de dados para leituras rápidas.
  • CDN para servir conteúdo estático.
  • Serviços remotos, tais como o e-mail ou o serviço SMS. Muitas vezes, esses recursos são fornecidos por terceiros.
  • Fornecedor de identidade para a autenticação.

A função Web e a função de trabalho não têm estado. O estado da sessão pode ser armazenado numa cache distribuída. Qualquer trabalho de execução longa é realizado de modo assíncrono pela função de trabalho. A função de trabalho pode ser acionada por mensagens na fila ou executada com base numa agenda para o processamento em lotes. A função de trabalho é um componente opcional. Se não existirem operações de execução longa, a função de trabalho pode ser omitida.

O front-end pode ser uma API Web. No lado do cliente, a API Web pode ser utilizada por uma aplicação de página única que faz chamadas AJAX ou por uma aplicação cliente nativa.

Quando utilizar esta arquitetura

Normalmente, a arquitetura Web-Fila-Trabalho é implementada com os serviços de computação geridos, ou seja, o Serviço de Aplicações do Azure ou os Serviços Cloud do Azure.

Considere este estilo de arquitetura para:

  • Aplicações com um domínio relativamente simples.
  • Aplicações com alguns fluxos de trabalho de execução longa ou operações em lote.
  • Quando quiser utilizar serviços geridos, em vez da infraestrutura como um serviço (IaaS).

Benefícios

  • Arquitetura relativamente simples e fácil de compreender.
  • Facilidade de implementação e gestão.
  • Clara separação das preocupações.
  • O front-end é dissociado da função de trabalho através de mensagens assíncronas.
  • O front-end e a função de trabalho podem ser dimensionados de forma independente.

Desafios

  • Sem uma conceção cuidadosa, o front-end e a função de trabalho podem tornar-se componentes grandes e monolíticos difíceis de manter e atualizar.
  • Poderão existir dependências ocultas se o front-end e a função de trabalho partilharem 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-Fila-Trabalho no Serviço de Aplicações do Azure

Esta secção descreve uma arquitetura Web-Fila-Trabalho recomendada que utiliza o Serviço de Aplicações do Azure.

Physical diagram of Web-Queue-Worker architecture style.

Transfira um ficheiro do 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 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 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 o armazenamento, escolha as tecnologias de armazenamento que melhor se adequam às necessidades da aplicação. Poderá utilizar 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 têm de passar pela fila e pela função de trabalho para o armazenamento. O front-end da Web pode executar operações de leitura/escrita simples diretamente. As funções de trabalho foram concebidas para tarefas com muitos recursos ou fluxos de trabalho de execução longa. Em alguns casos, pode nem precisar de uma função de trabalho.

  • Utilize a funcionalidade de dimensionamento automático incorporado do Serviço de Aplicações para aumentar horizontalmente o número de instâncias de VM. Se a carga na aplicação seguir os padrões previsíveis, utilize o dimensionamento automático baseado numa agenda. Se a carga for imprevisível, utilize regras de dimensionamento automático baseado 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.

  • Utilize planos do Serviço de Aplicações separados para a produção e o teste. Caso contrário, se utilizar o mesmo plano para a produção e o teste, significa que os seus testes estão em execução nas VMs de produção.

  • Utilize blocos de implementação para gerir implementações. Esse método permite implantar uma versão atualizada em um slot de preparo e, em seguida, trocar para a nova versão. Também permite voltar para a versão anterior, caso tenha havido um problema com a atualização.