Editar

Compartilhar via


Estilo de arquitetura de N camadas

Armazenamento do Azure
Serviços de nuvem do Azure
Máquinas Virtuais do Azure

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

diagrama lógico de um estilo de arquitetura de N camadas

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

As camadas são fisicamente separadas, em execução em computadores separados. Contratualmente, a camada pode fazer com que seus modelos de comunicação sejam estritos ou relaxados. No modelo estrito, uma solicitação deve passar por camadas adjacentes, uma por uma, e não pode ignorar nenhuma camada no meio. Por exemplo, do firewall do aplicativo Web para a camada da Web, em seguida, para a camada intermediária 1 e assim por diante. Por outro lado, na abordagem descontraída, a solicitação poderá ignorar algumas camadas se for necessário. A abordagem estrita tem mais latência e sobrecarga, e a abordagem relaxada tem mais acoplamentos e, posteriormente, é mais difícil mudar. Um sistema pode usar uma abordagem híbrida: ter camadas relaxadas e estritas 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 poderá criar tráfego de rede desnecessário, se uma camada simplesmente passar solicitações para a próxima camada.

Quando usar essa arquitetura

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

Considere uma arquitetura de N camadas para:

  • Aplicativos Web simples.
  • Um bom ponto de partida quando os requisitos de arquitetura ainda não estão claros.
  • Migrar um aplicativo local para o Azure com refatoração mínima.
  • Desenvolvimento unificado de aplicativos locais e de nuvem.

Arquiteturas de N camadas são muito comuns em aplicativos locais tradicionais, portanto, é um ajuste natural para migrar cargas de trabalho existentes para o Azure.

Benefícios

  • Portabilidade entre a nuvem e o local e entre plataformas de nuvem.
  • Menos curva de aprendizado para a maioria dos desenvolvedores.
  • Custo relativamente baixo ao não rearquitecar a solução
  • Evolução natural do modelo de aplicativo tradicional.
  • Abrir para 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 de rede em um sistema grande.
  • Os fluxos de usuário e dados normalmente se estendem por várias camadas, adicionando complexidade a preocupações como teste e observabilidade.

Práticas recomendadas

  • Use o dimensionamento automático para lidar com as alterações na carga. Consulte práticas recomendadas de dimensionamento automático.
  • Use de mensagens assíncronas para desacoplar camadas.
  • Armazenar dados semárticos 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 WAF (firewall de aplicativo Web) 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 das camadas intermediárias.

Arquitetura de N camadas em máquinas virtuais

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

diagrama físico de uma arquitetura de N camadas

Cada camada consiste em duas ou mais VMs, colocadas em um conjunto de disponibilidade ou conjunto de dimensionamento de máquinas virtuais. Várias VMs fornecem resiliência caso uma VM falhe. 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 roteamento de tabelas a camadas individuais.

As camadas web e de negócios são sem estado. Qualquer VM pode lidar com qualquer solicitação para essa camada. A camada de dados deve consistir em um banco de dados replicado. Para o Windows, recomendamos o SQL Server, usando grupos de disponibilidade Always On para alta disponibilidade. Para Linux, escolha um banco de dados que dê suporte à replicação, como o 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 o acesso da camada de negócios.

Nota

A camada rotulada "Camada de Negócios" em nosso diagrama de referência é um moniker para a camada lógica de negócios. Da mesma forma, também chamamos a camada de apresentação de "Camada da Web". Em nosso exemplo, este é um aplicativo Web, embora arquiteturas de várias camadas também possam ser usadas para outras topologias (como aplicativos da área de trabalho). Nomeie suas camadas como o que funciona melhor para sua equipe para comunicar a intenção dessa camada lógica e/ou física em seu aplicativo – você pode até mesmo expressar essa nomenclatura em recursos que você escolhe para representar essa camada (por exemplo, vmss-appName-business-layer).

Considerações adicionais

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

  • As camadas são o limite de escalabilidade, confiabilidade e segurança. Considere ter camadas separadas para serviços com requisitos diferentes nessas áreas.

  • Use conjuntos de dimensionamento de máquinas virtuais para de dimensionamento automático.

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

  • Para maior segurança, coloque uma rede DMZ na frente do aplicativo. O DMZ inclui NVAs (dispositivos virtuais de rede) que implementam funcionalidades de segurança, como firewalls e inspeção de pacotes. Para obter mais informações, consulte arquitetura de referência DMZ de rede.

  • 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 de RDP ou SSH a VMs que estão executando o código do aplicativo. Em vez disso, os operadores devem fazer logon em um jumpbox, também chamado de host de bastião. Essa é 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 somente 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 o Azure ExpressRoute. Para obter mais informações, consulte arquitetura de referência de rede híbrida.

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

  • Se você precisar de maior disponibilidade do que o SLA do Azure para VMs fornece, 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 do Linux em várias regiões.