Editar

Compartilhar via

Estilo de arquitetura de trabalho de fila da Web

Serviço de aplicativo do Azure

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

Logical diagram of Web-Queue-Worker architecture style.

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

  • Um ou mais bancos de dados.
  • Um cache para armazenar valores do banco de dados para leituras rápidas.
  • CDN para atender a 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 sem estado. O estado de sessão pode ser armazenado em um cache distribuído. Qualquer trabalho de longa execução é feito assincronamente pela função de trabalho. A função de trabalho pode ser acionada por mensagens na fila ou executada em um agendamento de processamento em lotes. A função de trabalho é um componente opcional. Se não houver nenhuma operação de longa execução, o trabalho pode ser omitido.

O front-end pode consistir em uma API da Web. Da parte 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 essa arquitetura

A arquitetura de trabalho de fila da Web geralmente é implementada usando serviços de computação gerenciados, tanto o Serviço de Aplicativo do Azure ou Serviços de Nuvem do Azure.

Considere esse estilo de arquitetura para:

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

Benefícios

  • Arquitetura relativamente simples e fácil de entender.
  • Fácil de implantar e gerenciar.
  • Clara separação de preocupações.
  • O front-end é separado do trabalho usando o sistema de mensagens assíncrono.
  • O front-end e o trabalho podem ser dimensionado independentemente.

Desafios

  • Sem um design cuidadoso, O front-end e o trabalho podem facilmente se tornar componentes grandes e monolíticos difíceis de serem mantidos e atualizados.
  • Pode haver dependências ocultas se o front-end e o trabalho 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 reduzir esse problema, mas exigem alterar o roteamento de mensagens de saída para primeiro "loop back" por meio de uma fila separada. Uma biblioteca que fornece suporte para essa técnica é a NServiceBus Transactional Session.

Práticas recomendadas

Trabalho de fila da Web no Serviço de Aplicativo do Azure

Esta seção descreve uma arquitetura recomendada de trabalho de fila da Web que usa Serviço de Aplicativo do Azure.

Physical diagram of Web-Queue-Worker architecture style.

Baixe um Arquivo Visio dessa arquitetura.

Workflow

  • O front-end é implementado como um aplicativo Web do Serviço de Aplicativo do Azure. Já o trabalhador é implementado como um aplicativo do Azure Functions. O aplicativo Web e o aplicativo de funções são associados a um Plano do Serviço de Aplicativo que fornece as instâncias de VM.

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

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

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

  • Para o 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 do 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 deve passar pela fila e pelo trabalho para o armazenamento. O front-end da Web pode executar diretamente operações simples de leitura/gravação. Os trabalhos são projetados para tarefas de uso intensivo de recursos ou fluxos de trabalho de longa execução. Em alguns casos, talvez não seja preciso de nenhum trabalho.

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

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

  • Use planos de Serviço de Aplicativo separados 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 em execução 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 depois trocar pela nova versão. Também permite que você troque para a versão anterior, caso tenha havido um problema com a atualização.