Estilo de arquitetura de N camadas

Uma arquitetura de N camadas divide um aplicativo em camadas lógicas e camadas físicas.

O diagrama começa com um cliente, depois vai para um firewall de aplicativo da Web (WAF) e, em seguida, para a camada da Web. Da camada da Web, um fluxo vai para a camada intermediária 1 e outro fluxo vai para mensagens e, em seguida, para a camada intermediária 2. Da camada intermediária 1, um fluxo vai para o serviço remoto e outro fluxo vai para a camada de dados. Da camada intermediária 2, o fluxo vai para a camada de dados. A partir da camada de dados, ambos os fluxos se invertem através do cache e, em seguida, voltam para as camadas intermediárias 1 e 2, respectivamente.

As camadas separam responsabilidades e gerenciam dependências. Cada camada tem uma responsabilidade específica. Uma camada superior pode usar serviços em uma camada inferior, mas uma camada inferior não pode usar serviços em uma camada superior.

As camadas são fisicamente separadas e executadas em máquinas separadas. Contratualmente, o nível pode ter modelos de comunicação rigorosos ou descontraídos. No modelo estrito, uma solicitação deve passar por camadas adjacentes, uma a uma, e não pode pular nenhuma camada intermediária. Por exemplo, uma solicitação viaja do firewall de aplicativo Web (WAF) para a camada da Web, depois para a camada intermediária 1 e continua. Em contrapartida, a abordagem flexível permite que os pedidos saltem alguns níveis, se necessário. A abordagem estrita tem maior latência e sobrecarga. A abordagem relaxada tem mais acoplamentos, o que torna as mudanças mais difíceis. Você também pode combinar ambas as abordagens no mesmo sistema.

Uma camada pode chamar para outra camada diretamente ou usar padrões de mensagens assíncronas por meio de uma fila de mensagens. Você pode hospedar cada camada em sua própria camada, mas essa abordagem não é necessária. Você pode hospedar várias camadas no mesmo nível. A separação física de camadas melhora a escalabilidade e a resiliência, mas também adiciona latência da comunicação de rede extra.

Um aplicativo tradicional de três camadas tem uma camada de apresentação, uma camada intermediária opcional e uma camada de banco de dados. Aplicativos mais complexos podem ter mais de três camadas. O diagrama anterior mostra um aplicativo com duas camadas intermediárias que encapsulam diferentes áreas de funcionalidade.

Um aplicativo de N camadas pode ter uma arquitetura de camada fechada ou uma arquitetura de camada aberta :

• Em uma arquitetura de camada fechada, uma camada só pode chamar a próxima camada imediatamente para baixo.
• Numa arquitetura de camada aberta, uma camada pode chamar quaisquer camadas sob ela.

Uma arquitetura de camada fechada limita as dependências entre camadas. Mas essa arquitetura pode criar tráfego de rede desnecessário se uma camada apenas passar solicitações para a próxima camada.

Quando usar esta arquitetura

Considere uma arquitetura de N camadas para os seguintes cenários:

• Apoie os requisitos de arquitetura que ainda estão evoluindo.
• Migre um aplicativo local para o Azure com alterações mínimas.
• Desenvolva aplicativos que abrangem ambientes locais e em nuvem.

As arquiteturas de N camadas são comuns em sistemas locais tradicionais, o que as torna uma opção natural para a transição de cargas de trabalho existentes para o Azure.

Implemente arquiteturas de N camadas de forma eficaz usando serviços gerenciados que fornecem escalabilidade, confiabilidade e sobrecarga operacional reduzida ou máquinas virtuais (VMs). Essas cargas de trabalho geralmente se beneficiam do uso de soluções gerenciadas para componentes-chave, como cache, mensagens e armazenamento de dados.

Benefícios

• Portátil na nuvem e no local e entre plataformas na nuvem
• Requer menos curva de aprendizado para a maioria dos desenvolvedores
• Custa relativamente pouco por não rearquitetar a solução
• Segue uma evolução natural do modelo de aplicação tradicional
• Suporta ambientes mistos que incluem Windows e Linux

Desafios

• Uma camada intermediária pode executar apenas operações básicas de criação, leitura, atualização, exclusão (CRUD), o que adiciona latência e complexidade sem fornecer valor significativo.
• O design monolítico impede a implantação independente de recursos.
• Sistemas grandes podem dificultar a gestão da segurança da rede.
• As solicitações de usuários e os dados que passam por várias camadas dificultam o teste e o monitoramento.

Melhores práticas

• Use o dimensionamento automático para lidar com alterações na carga. Para obter mais informações, consulte Práticas recomendadas de dimensionamento automático.
• Use de mensagens assíncronas para desacoplar camadas.
• Armazene em cache dados que não são alterados com frequência. Para obter mais informações, consulte Práticas recomendadas de cache.
• Configure a camada de banco de dados para alta disponibilidade usando uma solução como grupos de disponibilidade Always On do SQL Server.
• Insira um WAF entre o front-end e a Internet.
• Coloque cada camada em sua própria sub-rede e use sub-redes como um limite de segurança.
• Restrinja o acesso à camada de dados permitindo solicitações somente de uma camada intermediária.

Arquitetura de N camadas em VMs

Esta seção descreve uma arquitetura de N camadas que é executada em VMs.

Observação

Use VMs para alojar uma arquitetura de N-camadas se planeia migrar uma aplicação existente para a Azure com refatoração mínima. Caso contrário, considere usar serviços gerenciados para implementar a arquitetura, como o Serviço de Aplicativo do Azure ou os Aplicativos de Contêiner do Azure.

O fluxo começa com a internet, que se conecta a um balanceador de carga que roteia o tráfego de entrada para dois dispositivos virtuais de rede (NVAs) localizados na rede de perímetro. Em seguida, o tráfego passa por outro balanceador de carga para alcançar várias VMs na camada da Web. Um terceiro balanceador de carga encaminha o tráfego da camada da Web para a camada de negócios, que inclui várias VMs. A camada de negócios se conecta por meio de um quarto balanceador de carga à camada de dados, que inclui um SQL Server primário e secundário. Para acesso administrativo seguro, o pessoal de DevOps usa o portal do Azure para se conectar a um host do Azure Bastion localizado na AzureBastionSubnet. A rede de perímetro, todas as camadas e a AzureBastionSubnet residem em uma rede virtual.

Cada camada consiste em um conjunto de escala de máquina virtual que tem duas ou mais VMs. Várias VMs fornecem resiliência se uma VM falhar. Os balanceadores de carga distribuem solicitações entre as VMs em uma camada. Você pode dimensionar uma camada horizontalmente adicionando mais VMs ao pool.

Cada camada também é colocada dentro de sua própria sub-rede, o que significa que seus endereços IP internos estão dentro do mesmo intervalo de endereços. Essa abordagem facilita a aplicação de regras de grupo de segurança de rede e tabelas de rotas a camadas individuais.

As camadas da Web e de negócios são apátridas. Qualquer VM pode lidar com qualquer solicitação para essa camada. A camada de dados deve consistir em um banco de dados replicado. Sempre que possível, use um banco de dados gerenciado, mas você também pode hospedar bancos de dados em bancos de dados hospedados por VMs. Para Windows, recomendamos o SQL Server com grupos de disponibilidade Always On para alta disponibilidade. Para Linux, escolha um banco de dados que suporte replicação, como Apache Cassandra.

Os grupos de segurança de rede restringem o acesso a cada camada. Por exemplo, a camada de banco de dados só permite acesso a partir da camada de negócios.

Observação

A camada rotulada Camada de negócios no diagrama de referência refere-se à camada de lógica de negócios. A camada de apresentação é rotulada como camada da Web. O exemplo mostra um aplicativo Web, mas você também pode usar arquiteturas de várias camadas para outras topologias, como aplicativos de área de trabalho. Use nomes claros e descritivos para cada camada que a sua equipa compreenda. Você também pode usar esses nomes em seus recursos do Azure, por exemplo, vmss-appname-business-tier.

Outras considerações

• As arquiteturas de N camadas não estão restritas a três camadas. Aplicativos mais complexos geralmente têm mais camadas. Nesse caso, considere o uso do roteamento de camada 7 para rotear solicitações para uma camada específica.

• As camadas criam limites para escalabilidade, confiabilidade e segurança. Considere a possibilidade de ter níveis separados para serviços com requisitos diferentes nessas áreas.

• Use conjuntos de dimensionamento de máquina virtual para de dimensionamento automático .

• Encontre locais na arquitetura onde você pode usar um serviço gerenciado sem refatoração significativa. Em particular, considere o armazenamento em cache, as mensagens, o armazenamento e os bancos de dados.

• Coloque uma rede de perímetro (também conhecida como DMZ,zona desmilitarizada e sub-rede filtrada) na frente do aplicativo para maior segurança. A rede de perímetro inclui dispositivos virtuais de rede (NVAs) que implementam funcionalidades de segurança, como firewalls e inspeção de pacotes. Para obter mais informações, consulte Implementar uma rede híbrida segura.

• Use dois ou mais NVAs em um conjunto de dimensionamento de máquina virtual, com um balanceador de carga externo para distribuir solicitações da Internet entre as instâncias para alta disponibilidade. Para obter mais informações, consulte Distribuir NVAs altamente disponíveis.

• Bloqueie o acesso direto ao protocolo RDP (Ambiente de Trabalho Remoto Protocol) ou ao Secure Shell (SSH) a VMs que executam o código do aplicativo. Em vez disso, use o Azure Bastion para se conectar com segurança a VMs por meio de endereços IP privados, que fornecem conectividade RDP e SSH. Para obter mais informações, consulte Visão geral do Bastião do Azure.

• Estenda a rede virtual do Azure para sua rede local usando uma VPN (rede virtual privada) site a site ou a Rota Expressa do Azure. Para obter mais informações, consulte Arquitetura de referência de rede híbrida.

Próximo passo

• Criar uma aplicação segura de N-camadas no App Service

Recurso relacionado

• Mensagem numa arquitetura de estilo N-tier no Azure