Estilo de arquitetura Web-Queue-Worker

Essa arquitetura tem dois componentes principais. Um front-end da Web lida com solicitações de clientes e um worker 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.

Essa arquitetura normalmente usa os seguintes componentes:

• 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 front-end da web e o worker são ambos stateless (sem estado). Você pode armazenar o estado da sessão em um cache distribuído. O trabalhador executa trabalho de longa execução de forma assíncrona. Você pode acionar o worker usando mensagens da fila ou executá-lo em um agendamento 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 solicitações HTTP assíncronas ou um aplicativo cliente nativo pode consumi-la diretamente.

Quando usar essa arquitetura

Para implementar a arquiteturaQueue-Worker Web, você normalmente usa serviços de computação gerenciada, como o Serviço de Aplicativo do Azure, o AKS (Serviço de Kubernetes do Azure) ou os Aplicativos de Contêiner do Azure.

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

• Arquitetura simples que é fácil de entender

• Implantação e gerenciamento simples

• Clara separação de responsabilidades entre o front-end e o worker

• Mensagens assíncronas que desacoplam o front-end do worker

• Capacidade de escalar o front-end e o worker independentemente

Desafios

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

• Esquemas de dados compartilhados ou módulos de código entre o front-end e o trabalhador podem criar dependências ocultas.

• O front-end da web pode falhar após gravar no banco de dados, mas antes de enviar uma mensagem para a fila. Essa falha causa problemas de consistência porque o trabalhador nunca processa sua parte da lógica. Para resolver esse problema, use técnicas como o padrão de Caixa de Saída Transacional, que encaminha as mensagens de saída por meio de uma fila separada primeiro. A biblioteca de Sessão Transacional do NServiceBus dá suporte a essa abordagem.

Práticas recomendadas

• Exponha uma API bem projetada ao cliente. Para obter mais informações, consulte as práticas recomendadas de design da API.

• Escalabilidade automática para lidar com mudanças na carga. Para obter mais informações, consulte as práticas recomendadas de dimensionamento automático.

• Armazenar dados semárticos em cache. Para obter mais informações, consulte as práticas recomendadas de cache.

• Use uma rede de distribuição de conteúdo para hospedar conteúdo estático. Para obter mais informações, consulte as práticas recomendadas da rede de distribuição de conteúdo.

• Utilize a persistência poliglota quando apropriado. Para obter mais informações, consulte Noções básicas sobre modelos de dados.

• Dados de partição para melhorar a escalabilidade, reduzir a contenção e otimizar o desempenho. Para obter mais informações, consulte Projetar uma estratégia de particionamento de dados.

Web-Queue-Worker no Serviço de Aplicativo

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

Baixe um arquivo do Visio dessa arquitetura.

Workflow

• Um aplicativo Web do Serviço de Aplicativo serve como front-end e um aplicativo do Azure Functions serve como worker. Ambos os componentes são executados em um plano do App Service.

• As filas de mensagens utilizam o Barramento de Serviço do Azure ou as filas de Armazenamento do Azure. O diagrama anterior mostra 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 armazena em cache conteúdo estático, como imagens, CSS e HTML.

• Para armazenamento, escolha as tecnologias que melhor atendem às necessidades do aplicativo. Essa abordagem, conhecida como persistência poliglota, combina várias tecnologias de armazenamento em um sistema para atender a requisitos diferentes. O diagrama anterior demonstra essa abordagem usando o Banco de Dados SQL do Azure e o Azure Cosmos DB.

Para obter mais informações, consulte Aplicativo Web básico altamente disponível e com redundância de zona e Crie aplicativos de negócios orientados por mensagens usando o NServiceBus e o Barramento de Serviço.

Outras considerações

• Nem toda transação precisa passar pela fila e pelo worker para o armazenamento. O front-end da Web pode lidar diretamente com operações simples de leitura e gravação. Reserve trabalhadores para tarefas com uso intensivo de recursos ou fluxos de trabalho de execução longa. Se o aplicativo não tiver essas tarefas, talvez você não precise de um trabalho.

• Use o recurso de autoscaling integrado da plataforma de computação para escalar as instâncias. Se a carga 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 ambientes de produção e teste.

• Use slots de implantação para gerenciar implantações em planos de Serviço de Aplicativo. Implante uma versão atualizada em um slot de preparo e, em seguida, alterne para a nova versão. Se ocorrerem problemas, alterne de volta para a versão anterior.

Recurso relacionado

• Padrão de nivelamento de carga baseado em fila