Compartilhar via

Estilo de arquitetura Web-Queue-Worker

Os principais componentes desta arquitetura são um front-end web que lida com solicitações de cliente e um worker que realiza 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.

Um diagrama lógico que mostra a arquitetura Web-Queue-Worker.

Os seguintes componentes geralmente são incorporados a essa arquitetura:

  • Um ou mais bancos de dados

  • Um cache para armazenar valores do banco de dados para leituras rápidas

  • Uma rede de distribuição de conteúdo para fornecer conteúdo estático

  • Serviços remotos, como email ou SMS (Serviço de Mensagem Curta), que os provedores de serviços que não são da Microsoft normalmente fornecem

  • Um provedor de identidade para autenticação

O servidor web e o worker são ambos sem estado, e o estado da sessão pode ser armazenado em um cache distribuído. O trabalhador executa trabalho de longa execução de forma assíncrona. As mensagens na fila podem iniciar o trabalhador, ou um agendamento pode executá-lo para processamento em lote. O trabalhador é opcional se o aplicativo não tiver operações de longa execução.

O front-end pode incluir uma API Web. Um aplicativo de página única pode consumir a API Web fazendo chamadas AJAX ou um aplicativo cliente nativo pode consumi-la diretamente.

Quando usar essa arquitetura

A arquitetura Web-Queue-Worker normalmente é implementada usando serviços de computação gerenciada, como o Azure App Service ou o Azure Kubernetes Service.

Considere essa arquitetura para os seguintes casos de uso:

  • Aplicativos que têm um domínio relativamente simples

  • Aplicativos que têm fluxos de trabalho de execução prolongada ou operações em lote

  • Cenários em que você prefere serviços gerenciados em vez de iaaS (infraestrutura como serviço)

Benefícios

  • Uma arquitetura simples e fácil de seguir

  • Implantação e gerenciamento com esforço mínimo

  • Separação clara de responsabilidades

  • Desacoplamento do front-end e do trabalho por meio de mensagens assíncronas

  • Dimensionamento independente do frontend e do trabalhador

Desafios

  • Sem um design cuidadoso, o front-end e o worker podem se tornar grandes componentes monolíticos que são difíceis de manter e atualizar.

  • Se o front-end e o worker compartilharem esquemas de dados ou módulos de código, poderá haver dependências ocultas.

  • O front-end da web pode falhar depois de persistir no banco de dados, mas antes de enviar mensagens para a fila, o que causa problemas de consistência porque o worker não executa sua parte da lógica. Para atenuar esse problema, você pode usar técnicas como o padrão de Caixa de Saída Transacional, que exigem o roteamento de mensagens de saída para o primeiro loop de volta por meio de uma fila separada. A biblioteca de Sessão Transacional do NServiceBus dá suporte a essa técnica.

Práticas recomendadas

Web-Queue-Worker no Serviço de Aplicações

Esta seção descreve uma arquitetura Web-Queue-Worker recomendada que usa App Service.

Diagrama que mostra a arquiteturaQueue-Worker Web.

Baixe um arquivo do Visio dessa arquitetura.

Workflow

  • O front-end é implementado como um aplicativo Web do Serviço de Aplicativo e o trabalho é implementado como um aplicativo do Azure Functions . O aplicativo Web e o aplicativo Functions estão associados a um plano do Serviço de Aplicativo que fornece as instâncias da VM (máquina virtual).

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

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

  • A Rede de Distribuição de Conteúdo do Azure é usada para armazenar em cache conteúdo estático, como imagens, CSS ou HTML.

  • Para armazenamento, escolha as tecnologias que melhor atendem às necessidades do aplicativo. Essa abordagem, conhecida como persistência poliglota, usa várias tecnologias de armazenamento no mesmo sistema para atender a requisitos diferentes. 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 aplicativo web zona-redundante e altamente disponível na linha de base e desenvolva aplicativos empresariais orientados por mensagens com o NServiceBus e o Service Bus.

Outras considerações

  • Nem todas as transações devem passar pela fila e trabalhar até o armazenamento. O front-end da Web pode fazer operações simples de leitura e 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.

  • Utilize o recurso de dimensionamento automático interno da plataforma de computação para escalar o número de instâncias. 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 o dimensionamento automático baseado em métricas.

  • Considere colocar o aplicativo Web e o aplicativo Functions em planos separados do Serviço de Aplicativo para que eles possam ser dimensionados de forma independente.

  • Use planos separados do Serviço de Aplicativo para produção e teste.

  • Utilize slots de implantação para gerenciar implantações. Esse método permite implantar uma versão atualizada em um slot de teste 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 durante a atualização.

  • Last updated on