Diagrama de arquitetura em três camadas: apresentação, aplicação e dados

A arquitetura em três camadas é o formato que a maioria das aplicações web ainda tem por baixo dos panos: algo que serve a interface do usuário, algo que executa a lógica de negócio e algo que armazena os dados. Ela é antiga, é sem graça e é o ponto de partida certo para a maioria dos sistemas, porque cada camada pode escalar e ser protegida de forma independente.

Este artigo explica as três camadas, mostra como elas se traduzem numa rede de nuvem com sub-redes e security groups, e desenha um deploy típico na AWS em duas zonas de disponibilidade. A mesma estrutura funciona em qualquer nuvem.

As três camadas

A regra que faz disso uma arquitetura, e não só três caixas: cada camada só conversa com a vizinha. O navegador nunca alcança o banco de dados, e a camada de apresentação nunca executa SQL.

A AWS descreve o padrão na sua visão geral da arquitetura em três camadas, incluindo variantes serverless em que funções substituem os servidores de aplicação.

Mapeando as camadas na rede

As camadas viram fronteiras reais quando vivem em sub-redes diferentes, com rotas diferentes:

• Sub-redes públicas contêm só o que precisa ser acessível pela internet: o load balancer e os NAT gateways.
• Sub-redes privadas de aplicação contêm os servidores de aplicação. Eles podem sair para a internet via NAT para atualizações e APIs, mas nada os alcança de fora a não ser pelo load balancer.
• Sub-redes privadas de dados contêm bancos de dados e caches, sem nenhuma rota para a internet.

Os security groups então permitem só o tráfego da vizinha: o banco aceita a porta 5432 apenas do security group da camada de aplicação, não de uma faixa de IPs. Referenciar grupos em vez de endereços mantém as regras corretas enquanto instâncias vêm e vão.

Alta disponibilidade entre zonas

Rode cada camada em pelo menos duas zonas de disponibilidade:

• O load balancer abrange várias zonas por design.
• Os servidores de aplicação rodam num grupo de autoscaling com instâncias em cada zona. Se uma zona cai, as outras assumem o tráfego e o grupo repõe a capacidade.
• O banco de dados roda com um standby síncrono em outra zona. Com o Amazon RDS Multi-AZ, o failover para o standby é automático e o nome do endpoint continua o mesmo.

Mantenha a camada de aplicação sem estado, para que qualquer instância atenda qualquer requisição: sessões vão para um cache compartilhado ou para o banco, uploads para o armazenamento de objetos, e nada importante fica no disco de uma instância. Teste encerrando um servidor de aplicação aleatório em horário comercial; se os usuários perceberem, ainda tem estado escondido nas instâncias.

Escalando cada camada

As camadas escalam de formas diferentes, e é por isso que vale mantê-las separadas:

• Apresentação: uma CDN absorve a maior parte do tráfego estático. Os headers de cache decidem quanto.
• Aplicação: adicione instâncias. Escale por número de requisições ou por CPU, e mantenha rápida a inicialização das instâncias.
• Dados: a mais difícil. Escale verticalmente primeiro, adicione réplicas de leitura para cargas dominadas por leitura, um cache para chaves quentes, e deixe o sharding como último recurso.

Uma requisição pelas camadas

Siga um usuário carregando o histórico de pedidos:

1. O DNS retorna o endereço da CDN. O navegador pede a página; HTML, scripts e imagens vêm do cache da CDN ou do bucket estático por trás dela.
2. A página chama GET /api/orders. A CDN encaminha os caminhos dinâmicos ao load balancer, que termina o TLS e escolhe um servidor de aplicação saudável em qualquer uma das zonas.
3. O servidor de aplicação lê a sessão no cache, confere se o usuário está logado e consulta os pedidos no banco primário.
4. A resposta volta pelo load balancer e pela CDN, que não a coloca em cache porque a resposta é privada.

Cada salto cruza uma única fronteira de camada, e cada fronteira tem exatamente um ponto de entrada permitido. É isso que torna o design fácil de entender e de proteger.

Custos e dimensionamento

A camada de dados costuma dominar a conta e é a mais difícil de reduzir depois, então dimensione-a com base em medições, não em palpites. A camada de aplicação é a mais fácil de ajustar: comece pequeno, escale pela carga real e deixe o autoscaling cuidar dos picos. NAT gateways e tráfego entre zonas são os itens que surpreendem; mantenha o tráfego mais falante dentro de uma zona sempre que der, e use endpoints de VPC para o armazenamento de objetos, para que os servidores de aplicação não paguem NAT a cada upload.

O diagrama de arquitetura

Como ler:

• Topo: os usuários resolvem o DNS e se conectam à CDN, que serve arquivos estáticos de um bucket e encaminha as requisições dinâmicas.
• Camada de apresentação: o application load balancer é o único componente nas sub-redes públicas.
• Camada de aplicação: os servidores de aplicação nas zonas A e B ficam em sub-redes privadas e só recebem tráfego do load balancer.
• Camada de dados: o banco primário na zona A replica de forma síncrona para um standby na zona B; os servidores de aplicação também usam um cache de sessões. Essa camada não tem rota para a internet.
• O bloco Markdown lista as regras dos security groups, que são o que de fato impõe as camadas.

Erros comuns

• Bancos em sub-redes públicas, "temporariamente", para uma consulta rápida de um notebook. Use um bastion ou uma ferramenta de sessão gerenciada no lugar.
• Security groups que liberam uma faixa CIDR inteira entre camadas em vez de referenciar o grupo da vizinha.
• Estado nos servidores de aplicação: sessões em memória, uploads no disco local. O autoscaling e o failover então perdem dados.
• Uma única zona de disponibilidade para o banco para economizar, com a camada de aplicação espalhada por três.
• Pular a CDN e servir cada imagem a partir dos servidores de aplicação.
• Nenhum caminho de health check nos servidores de aplicação, e o load balancer continua mandando tráfego para instâncias que não alcançam o banco.

Quando três camadas não bastam

Três camadas descrevem uma aplicação. Quando um sistema cresce para vários serviços, cada serviço muitas vezes mantém o próprio formato de três camadas, e o diagrama sobe um nível para mostrar como os serviços conversam entre si. O diagrama de arquitetura de microsserviços cobre esse passo. Para os detalhes de rede, veja o diagrama de VPC da AWS e, para mais de uma região, o diagrama de arquitetura multirregião na AWS.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Adicione uma Pessoa do pack Modelo C4, um DNS do pack Rede, e uma CDN e um nó Armazenamento de objetos do pack Nuvem.
3. Adicione uma VPC do pack Rede e, dentro dela, três nós Moldura do pack Básico, um por camada.
4. Adicione um Balanceador de carga na nuvem à camada de apresentação, dois nós Instância de computação à camada de aplicação, e dois nós Banco de dados gerenciado mais Redis do pack Dados à camada de dados.
5. Conecte cada camada só à vizinha e adicione um bloco Markdown do pack Básico com as regras dos security groups. Se a sua infraestrutura já existe em Terraform, a ferramenta de Terraform para diagrama gera um primeiro rascunho.

O exemplo usa 15 nós de diagrama e fica dentro do plano Free.

Perguntas frequentes

Quais são as três camadas de uma arquitetura em três camadas? Apresentação (a interface do usuário e o ponto de entrada), aplicação (lógica de negócio e APIs) e dados (bancos de dados, caches e armazenamento).

A arquitetura em três camadas está ultrapassada? Não. É o formato padrão para aplicações web. Microsserviços e sistemas serverless continuam tendo as mesmas três responsabilidades, muitas vezes por serviço.

Qual a diferença entre tiers e layers numa arquitetura em três camadas? Layers são uma divisão lógica dentro do código; tiers são uma divisão física entre máquinas ou serviços separados, com fronteiras de rede entre eles.

O banco de dados deve ficar numa sub-rede pública? Não. Mantenha-o em sub-redes privadas sem rota para a internet, acessível só a partir do security group da camada de aplicação.

Como deixo uma aplicação em três camadas altamente disponível? Rode cada camada em pelo menos duas zonas de disponibilidade, mantenha os servidores de aplicação sem estado e use um banco com standby automático em outra zona.

Comece grátis — um assento, sem cartão de crédito.