estilo de arquitetura Web-Queue-Worker

Os componentes centrais desta arquitetura são uma interface web que gere pedidos de clientes e um trabalhador que realiza tarefas intensivas em recursos, fluxos de trabalho de longa duração ou trabalhos em lote. A interface web comunica com o trabalhador através de uma fila de mensagens.

Os seguintes componentes são normalmente incorporados nesta arquitetura:

• Uma ou mais bases de dados

• Uma cache para armazenar valores da base de dados para leituras rápidas

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

• Serviços remotos, como email ou Short Message Service (SMS), que normalmente fornecem fornecedores de serviços não Microsoft

• Um fornecedor de identidade para autenticação

A web e o worker são ambos sem estado, e o estado da sessão pode ser armazenado numa cache distribuída. O trabalhador gere trabalhos de longa duração de forma assíncrona. Mensagens na fila podem iniciar o trabalhador, ou um horário pode executá-lo para processamento em lote. O worker é opcional se a aplicação não tiver operações de longa duração.

A interface pode incluir uma API web. Uma aplicação de página única pode consumir a API web através de chamadas AJAX, ou uma aplicação cliente nativa pode consumi-la diretamente.

Quando usar esta arquitetura

A arquitetura Web-Queue-Worker é tipicamente implementada utilizando serviços de computação gerida como Azure App Service ou Azure Kubernetes Service.

Considere esta arquitetura para os seguintes casos de uso:

• Aplicações que têm um domínio relativamente simples

• Aplicações que têm fluxos de trabalho de longa duração ou operações em lote

• Cenários em que prefere serviços geridos em vez de infraestrutura como serviço (IaaS)

Benefícios

• Uma arquitetura simples e fácil de seguir

• Implementação e gestão com esforço mínimo

• Separação clara de responsabilidades

• Desacoplamento do front-end e do worker através de mensagens assíncronas

• Escalonamento independente da frente e do operador

Desafios

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

• Se a interface e o trabalhador partilharem esquemas de dados ou módulos de código, podem existir dependências ocultas.

• A interface web pode falhar depois de persistir na base de dados mas antes de enviar mensagens para a fila, o que causa problemas de consistência porque o trabalhador não cumpre a sua parte da lógica. Para mitigar este problema, pode usar técnicas como o padrão Transactional Outbox, que exige que as mensagens de saída passem primeiro por uma fila separada. A biblioteca NServiceBus Transactional Session suporta esta técnica.

Melhores práticas

• Expõe uma API bem desenhada ao cliente. Para mais informações, consulte as melhores práticas de design de APIs.

• Escala automaticamente para lidar com alterações de carga. Para obter mais informações, consulte Práticas recomendadas de dimensionamento automático.

• Armazenar em cache dados semiestáticos. Para obter mais informações, consulte Práticas recomendadas de cache.

• Use uma rede de distribuição de conteúdos para alojar conteúdos estáticos. Para mais informações, consulte as melhores práticas para redes de distribuição de conteúdos.

• Utilize persistência poliglota quando apropriado. Para mais informações, consulte Compreender modelos de dados.

• Particione os dados para melhorar a escalabilidade, reduzir a contenção e otimizar o desempenho. Para mais informações, consulte as melhores práticas de particionamento de dados.

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

Esta secção descreve uma arquitetura recomendada de Web-Queue-Worker que utiliza o App Service.

Diagrama de arquitetura que mostra os utilizadores que acedem a aplicações web através do Azure CDN para entrega de conteúdo estático. O tráfego flui para as aplicações web App Service que lidam com pedidos de utilizadores e enviam mensagens para as filas do Azure Service Bus ou Azure Storage. Os trabalhadores do Azure Functions processam mensagens das filas para tratar de tarefas que consomem muitos recursos. O sistema inclui Azure Managed Redis para acesso a dados em estado de sessão e baixa latência, Azure Blob Storage para armazenamento de ficheiros e documentos, e armazenamento de dados poliglotas com Azure SQL Database e Azure Cosmos DB. As aplicações web e as Funções funcionam ambas em planos de App Service para infraestrutura de computação.

Descarregue um ficheiro Visio desta arquitetura.

Workflow

• A interface frontal é implementada como uma aplicação web Serviço de Aplicações, e o worker é implementado como uma aplicação Azure Functions. A aplicação web e a aplicação Functions estão ambas associadas a um plano de Serviços de Aplicações que fornece as instâncias da máquina virtual (VM).

• Pode usar filas do Azure Service Bus ou filas do Azure Storage para a fila de mensagens. O diagrama anterior utiliza uma fila de armazenamento.

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

• A Azure Content Delivery Network é usada para armazenar em cache conteúdos estáticos como imagens, CSS ou HTML.

• Para armazenamento, escolha tecnologias que melhor se adaptem às necessidades da sua aplicação. Esta abordagem, conhecida como persistência poliglota, utiliza múltiplas tecnologias de armazenamento no mesmo sistema para satisfazer diferentes requisitos. Para ilustrar esta ideia, o diagrama mostra tanto Azure SQL Database como Azure Cosmos DB.

Para mais informações, consulte Baseline aplicação web altamente disponível por redundância de zona e Construir aplicações empresariais orientadas por mensagens com NServiceBus e Service Bus.

Outras considerações

• Nem todas as transações precisam passar pela fila e pelo processo de trabalho até o armazenamento. A interface web pode fazer operações simples de leitura e escrita diretamente. Os trabalhadores são concebidos para tarefas intensivas em recursos ou fluxos de trabalho de longa duração. Em alguns casos, pode nem precisar de um trabalhador.

• Use a funcionalidade de autoescala incorporada da sua plataforma de computação para escalar o número de instâncias. Se a carga na aplicação seguir padrões previsíveis, use o autoescalonamento baseado em agendamento. Se a carga for imprevisível, use dimensionamento automático baseado em métricas.

• Considere colocar a aplicação web e a aplicação Functions em planos de App Service separados para que possam escalar de forma independente.

• Use planos de App Service separados para produção e testes.

• Utilize os slots de implementação para gerir as implementações. Este método permite-te implementar uma versão atualizada num slot de staging e depois trocar para a nova versão. Também permite voltar à versão anterior se houver algum problema durante a atualização.

Recurso relacionado

• Queue-Based Padrão de nivelamento de carga