Editar

Estilo de arquitetura de N camadas

Azure Storage
Azure Cloud Services
Azure Virtual Machines

Uma arquitetura de N camadas divide uma aplicação em camadas lógicas e camadas físicas.

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

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

As camadas estão separadas fisicamente e são executadas em computadores separados. Uma camada pode chamar para outra camada diretamente ou usar padrões de mensagens assíncronas por meio de uma fila de mensagens. Apesar de ser possível alojar cada camada na sua própria camada, tal não é necessário. É possível alojar várias camadas na mesma camada. A separação física das camadas não só melhora a escalabilidade e a resiliência, como também adiciona latência resultante da comunicação de rede adicional.

Uma aplicação de três camadas tradicional é composta por uma camada de apresentação, uma camada média e uma camada de base de dados. A camada média é opcional. As aplicações mais complexas podem ter mais de três camadas. O diagrama acima mostra uma aplicação com duas camadas médias, cada uma com diferentes áreas de funcionalidade encapsuladas.

Uma aplicação de N camadas pode ter uma arquitetura de camadas fechada ou uma arquitetura de camadas aberta:

  • Numa arquitetura de camadas fechada, uma camada só pode efetuar uma chamada para a camada seguinte imediatamente abaixo.
  • Numa arquitetura de camadas aberta, uma camada pode efetuar uma chamada para qualquer uma das camadas abaixo dela.

Uma arquitetura de camadas fechada limita as dependências entre camadas. No entanto, poderá criar tráfego de rede desnecessário, caso uma camada se limite a passar pedidos para a camada seguinte.

Quando utilizar esta arquitetura

Normalmente, as arquiteturas de N camadas são implementadas como aplicações de infraestrutura como um serviço (IaaS), em que cada camada é executada num conjunto de VMs separado. No entanto, uma aplicação de N camadas não precisa de ser uma IaaS pura. Muitas vezes, é vantajoso utilizar serviços geridos para algumas partes da arquitetura, em especial para a colocação em cache, as mensagens e o armazenamento de dados.

Considere utilizar uma arquitetura de N camadas para:

  • Aplicações Web simples.
  • Migrar uma aplicação no local para o Azure com refatorização mínima.
  • Desenvolvimento unificado de aplicações na cloud e no local.

As arquiteturas de N camadas são muito comuns nas tradicionais aplicações no local, pelo que constituem uma opção natural para migrar cargas de trabalho existentes para o Azure.

Benefícios

  • Portabilidade entre as vertentes cloud e no local e entre plataformas na cloud.
  • Curva de aprendizagem menos acentuada para a maior parte dos programadores.
  • Evolução natural face ao modelo de aplicação tradicional.
  • Recetividade a um ambiente heterogéneo (Windows/Linux)

Desafios

  • É fácil acabar por ficar com uma camada média que apenas executa operações CRUD na base de dados, adicionando latência extra sem que isso se traduza em trabalho útil.
  • A estrutura monolítica impede a implementação independente de funcionalidades.
  • A gestão de uma aplicação de IaaS envolve mais trabalho do que gerir uma aplicação que utiliza apenas serviços geridos.
  • Pode ser difícil gerir a segurança de rede num sistema de grandes dimensões.

Melhores práticas

  • Utilize o dimensionamento automático para processar alterações na carga. Veja Melhores práticas de dimensionamento automático.
  • Use mensagens assíncronas para desacoplar camadas.
  • Armazenar dados semiestáticos em cache. Veja Melhores práticas de colocação em 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 uma firewall de aplicações Web (WAF) entre o front-end e a Internet.
  • Coloque cada uma das camadas na sua própria sub-rede e utilize sub-redes como um limite de segurança.
  • Limite o acesso à camada de dados, ao permitir pedidos apenas a partir das camadas médias.

Arquitetura de N camadas em máquinas virtuais

Esta secção descreve uma arquitetura de N camadas recomendada em execução nas 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 escala de máquina virtual. A existência de várias VMs oferece resiliência em caso de falha de uma VMs. Os balanceadores de carga são utilizados para distribuir os pedidos entre as VMs de uma camada. Uma camada pode ser aumentada horizontalmente adicionando mais VMs ao conjunto.

Cada camada também é colocada dentro da sua própria sub-rede, o que significa que os respetivos endereços IP internos ficam abrangidos pelo 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 Web e de negócio não têm um estado específico. Qualquer VM pode processar qualquer pedido para essa camada. A camada de dados deve ser constituída por uma base de dados replicada. Para Windows, recomendamos o SQL Server, usando grupos de disponibilidade Always On para alta disponibilidade. Para o Linux, escolha uma base de dados que suporte a replicação, como o Apache Cassandra.

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

Nota

A camada rotulada como "Camada de negócios" em nosso diagrama de referência é um apelido para a camada de 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 de desktop). Nomeie suas camadas 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é expressar essa nomenclatura em recursos que escolher para representar essa camada (por exemplo, vmss-appName-business-layer).

Considerações adicionais

  • As arquiteturas de N camadas não estão limitadas a três camadas. Nas aplicações mais complexas, é comum existirem mais camadas. Nesse caso, considere utilizar um encaminhamento de 7 camadas para encaminhar pedidos para uma camada específica.

  • As camadas demarcam o limite ao nível da escalabilidade, fiabilidade e segurança. Considere ter camadas separadas para serviços com requisitos diferentes nessas áreas.

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

  • Procure pontos na arquitetura onde possa utilizar um serviço gerido sem incorrer numa refatorização significativa. Em concreto, analise a colocação em cache, o sistema de mensagens, o armazenamento e as bases de dados.

  • Para uma maior segurança, coloque uma rede de perímetro à frente da aplicação. A rede de perímetro inclui aplicações virtuais de rede (NVAs) que implementam funcionalidades de segurança, como firewalls e a inspeção de pacotes. Para obter mais informações, veja Arquitetura de referência de rede de perímetro.

  • Para obter elevada disponibilidade, coloque duas ou mais NVAs num conjunto de disponibilidade, com um balanceador de carga externo para distribuir os pedidos de Internet pelas instâncias. Para obter mais informações, consulte Implantar dispositivos virtuais de rede altamente disponíveis e este cenário de exemplo de alta disponibilidade e recuperação de desastres para aplicativos IaaS.

  • Não permita o acesso direto de RDP ou SSH às VMs que estejam a executar o código da aplicação. Em vez disso, os operadores devem iniciar sessão numa jumpbox, também denominada anfitrião de bastião. Trata-se de uma VM na rede que os administradores utilizam para ligar a 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.

  • Pode alargar a rede virtual do Azure à sua rede no local através de uma rede de VPNs ou do Azure ExpressRoute. Para obter mais informações, veja Arquitetura de referência de rede híbrida.

  • Se a sua organização utiliza o Active Directory para gerir a identidade, será conveniente alargar o ambiente do Active Directory à VNet do Azure. Para obter mais informações, veja Arquitetura de referência de gestão de identidades.

  • Se precisar de uma disponibilidade mais elevada do que a fornecida pelo SLA do Azure para VMs, replique a aplicação em duas regiões e utilize o Gestor de Tráfego do Azure para a ativação pós-falha. Para obter mais informações, veja Executar VMs do Windows em várias regiões ou Executar VMs do Linux em várias regiões.