Estilo de arquitetura de N camadas

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

As camadas são uma maneira de separar responsabilidades e gerenciar dependências. Cada camada tem uma responsabilidade específica. Uma camada superior pode usar serviços em uma camada inferior, mas não o contrário.

Os níveis são fisicamente separados, funcionando em máquinas separadas. Contratualmente, o nível pode ter seus modelos de comunicação rigorosos ou relaxados. 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, do firewall do aplicativo Web para a camada da Web, depois para a camada intermediária 1 e assim por diante. Em contrapartida, na abordagem descontraída, o pedido pode saltar alguns níveis, se necessário. A abordagem estrita tem mais latência e sobrecarga, e a abordagem relaxada tem mais acoplamentos e, posteriormente, é mais difícil de mudar. Um sistema pode usar uma abordagem híbrida: ter níveis relaxados e rigorosos quando necessário.

Uma camada pode chamar para outra camada diretamente ou usar padrões de mensagens assíncronas por meio de uma fila de mensagens. Embora cada camada possa ser hospedada em sua própria camada, isso não é necessário. Várias camadas podem ser hospedadas na mesma camada. A separação física das camadas melhora a escalabilidade e a resiliência, mas também adiciona latência da comunicação de rede adicional.

Um aplicativo tradicional de três camadas tem uma camada de apresentação, uma camada intermediária e uma camada de banco de dados. A camada intermediária é opcional. Aplicativos mais complexos podem ter mais de três camadas. O diagrama acima mostra um aplicativo com duas camadas intermediárias, encapsulando 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.
• Em uma arquitetura de camada aberta, uma camada pode chamar qualquer uma das camadas abaixo dela.

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

Quando usar esta arquitetura

As arquiteturas de N camadas são normalmente implementadas como aplicativos de infraestrutura como serviço (IaaS), com cada camada sendo executada em um conjunto separado de VMs. No entanto, um aplicativo de N camadas não precisa ser IaaS puro. Muitas vezes, é vantajoso usar serviços gerenciados para algumas partes da arquitetura, particularmente cache, mensagens e armazenamento de dados.

Considere uma arquitetura de N camadas para:

• Aplicações web simples.
• Um bom ponto de partida quando os requisitos arquitetônicos ainda não estão claros.
• Migrar um aplicativo local para o Azure com refatoração mínima.
• Desenvolvimento unificado de aplicações on-premises e cloud.

As arquiteturas de N camadas são muito comuns em aplicativos locais tradicionais, portanto, é uma opção natural para migrar cargas de trabalho existentes para o Azure.

Benefícios

• Portabilidade entre nuvem e local e entre plataformas de nuvem.
• Menos curva de aprendizado para a maioria dos desenvolvedores.
• Custo relativamente baixo por não rearquitetar a solução
• Evolução natural do modelo de aplicação tradicional.
• Aberto a ambiente heterogêneo (Windows/Linux)

Desafios

• É fácil acabar com uma camada intermediária que apenas faz operações CRUD no banco de dados, adicionando latência extra sem fazer nenhum trabalho útil.
• O design monolítico impede a implantação independente de recursos.
• Gerenciar um aplicativo IaaS é mais trabalhoso do que um aplicativo que usa apenas serviços gerenciados.
• Pode ser difícil gerenciar a segurança da rede em um sistema grande.
• Os fluxos de usuários e dados normalmente abrangem várias camadas, adicionando complexidade a preocupações como testes e observabilidade.

Melhores práticas

• Use o dimensionamento automático para lidar com alterações na carga. Consulte Práticas recomendadas de dimensionamento automático.
• Use de mensagens assíncronas para desacoplar camadas.
• Armazenar dados semiestáticos em cache. 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.
• Coloque um firewall de aplicativo Web (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 da(s) camada(s) intermediária(s).

Arquitetura de N camadas em máquinas virtuais

Esta seção descreve uma arquitetura de N camadas recomendada em execução em VMs.

Cada camada consiste em duas ou mais VMs, colocadas em um conjunto de disponibilidade ou conjunto de escala de máquina virtual. Várias VMs fornecem resiliência no caso de uma VM falhar. Os balanceadores de carga são usados para distribuir solicitações entre as VMs em uma camada. Uma camada pode ser dimensionada 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. Isso 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. Para Windows, recomendamos o SQL Server, usando 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.

Considerações adicionais

• As arquiteturas de N camadas não estão restritas a três camadas. Para aplicações mais complexas, é comum ter mais camadas. Nesse caso, considere o uso do roteamento de camada 7 para rotear solicitações para uma camada específica.

• Os níveis são o limite de 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 .

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

• Para maior segurança, coloque uma DMZ de rede na frente do aplicativo. A DMZ 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 Network DMZ reference architecture.

• Para alta disponibilidade, coloque dois ou mais NVAs em um conjunto de disponibilidade, com um balanceador de carga externo para distribuir solicitações da Internet entre as instâncias. Para obter mais informações, consulte Implantar dispositivos virtuais de rede altamente disponíveis.

• Não permita acesso direto RDP ou SSH a VMs que estejam executando código de aplicativo. Em vez disso, os operadores devem fazer login em um jumpbox, também chamado de bastion host. Esta é uma VM na rede que os administradores usam para se conectar às outras VMs. O jumpbox tem um grupo de segurança de rede que permite RDP ou SSH apenas a partir de endereços IP públicos aprovados.

• Você pode estender 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.

• Se sua organização usa o Ative Directory para gerenciar a identidade, convém estender seu ambiente do Ative Directory para a VNet do Azure. Para obter mais informações, consulte Arquitetura de referência de gerenciamento de identidades.

• Se você precisar de uma disponibilidade maior do que a fornecida pelo SLA do Azure para VMs, replique o aplicativo em duas regiões e use o Gerenciador de Tráfego do Azure para failover. Para obter mais informações, consulte Executar VMs Linux em várias regiões.

Recursos relacionados

• aplicativo de N camadas com Apache Cassandra
• [Aplicativo de N camadas do Windows no Azure com SQL Server][n-tier-windows-SQL]
• módulo Microsoft Learn: visite o estilo de arquitetura de N camadas
• Azure Bastion
• Mais informações sobre mensagens em um estilo de arquitetura N camadas no Azure