O que é um balanceador de carga em termos simples?

Um balanceador de carga é um componente que fica à frente de vários servidores e divide entre eles os pedidos recebidos. Assim nenhum servidor fica sobrecarregado, e se um falhar os outros continuam a servir, de modo que o site se mantém online e consegue lidar com mais tráfego do que uma só máquina conseguiria.

Qual é a diferença entre o balanceamento Layer 4 e Layer 7?

Um balanceador Layer 4 encaminha por IP e porta sem inspecionar o tráfego, o que é rápido e funciona para qualquer protocolo. Um balanceador Layer 7 compreende HTTP, por isso pode encaminhar por URL, nome de host ou cabeçalhos e terminar TLS. O Layer 7 é típico de apps web; o Layer 4 escolhe-se quando a velocidade bruta é o que mais importa.

Quais são os algoritmos de balanceamento de carga mais comuns?

Os mais comuns são round-robin (cada servidor à vez), least connections (o servidor com menos ligações ativas), IP hash (o mesmo cliente chega sempre ao mesmo servidor) e ponderado (os servidores mais potentes recebem mais tráfego). O round-robin é a escolha simples por defeito quando os servidores são parecidos.

Programação · Servidores · Redes

O que é um balanceador de carga?

Q: Qual é a diferença entre um balanceador de carga e um proxy reverso?

O balanceamento de carga é uma das tarefas que um proxy reverso pode fazer. Um proxy reverso é o conceito mais amplo de porta de entrada que pode encaminhar, fazer cache, terminar TLS e distribuir a carga. Um balanceador de carga é essa mesma porta de entrada focada em distribuir o tráfego pelos backends. Ferramentas como Nginx e HAProxy fazem ambas as coisas.

Por ColdwastAtualizado a 26 jun 20268 min de leitura#load-balancer#scaling#networking

Unidades de servidor montadas em rack num centro de dados — Um balanceador de carga fica à frente de vários servidores idênticos e divide entre eles os pedidos recebidos, para que nenhuma máquina carregue sozinha com todo o trabalho.

Um único servidor tem os seus limites. Quando o tráfego ultrapassa o que uma só máquina consegue servir — ou quando simplesmente não pode dar-se ao luxo de o site cair se essa máquina falhar — coloca várias cópias a correr e põe um balanceador de carga à frente delas. Este guia explica o que é um balanceador de carga, como decide para onde vai cada pedido e como se relaciona com o proxy reverso que talvez já conheça.

A ideia central: partilhar o trabalho

Um balanceador de carga é um componente que recebe os pedidos que chegam e os distribui por um pool de servidores backend — normalmente cópias idênticas da mesma app. Para o visitante há um só endereço; por trás, o balanceador reparte o tráfego discretamente para que nenhum servidor fique sobrecarregado. Resolve dois problemas de uma vez: a escala (lidar com mais tráfego do que uma só máquina conseguiria) e a disponibilidade (se um servidor morre, os outros continuam a servir).

Este segundo ponto é o que se subestima. Um balanceador de carga verifica continuamente se cada backend está saudável e deixa de enviar tráfego para os que param de responder. Um único servidor com problemas já não derruba o site inteiro — a sua quota de pedidos é simplesmente reencaminhada para os servidores saudáveis.

Como decide: os algoritmos de balanceamento

O balanceador de carga precisa de uma regra para escolher que servidor trata o próximo pedido. Os mais comuns são:

Round-robin — entregar cada novo pedido ao servidor seguinte, à vez. Simples e equilibrado quando os servidores são parecidos.
Least connections (menos ligações) — enviar o pedido para o servidor que tem neste momento menos ligações ativas. Melhor quando os pedidos variam no custo.
IP hash — escolher o servidor com base no IP do cliente, para que o mesmo visitante caia sempre no mesmo backend (útil para a persistência de sessão).
Ponderado (weighted) — dar aos servidores mais potentes uma quota maior de tráfego.

Um rack de servidores com luzes de estado acesas num centro de dados — Os health checks permitem ao balanceador contornar automaticamente um servidor em falha — as luzes ficam acesas mesmo quando uma máquina cai.

Layer 4 vs Layer 7

Os balanceadores de carga trabalham num de dois níveis. Um balanceador de Layer 4 (transporte) encaminha por endereço IP e porta sem olhar para dentro do tráfego — rápido e independente do protocolo. Um balanceador de Layer 7 (aplicação) compreende HTTP, por isso pode encaminhar por caminho de URL, nome de host ou cabeçalhos, terminar TLS e tomar decisões mais inteligentes. O Layer 7 é a escolha comum para apps web; o Layer 4 ganha quando a velocidade bruta importa mais do que um encaminhamento consciente do conteúdo.

Balanceador de carga vs proxy reverso

É a pergunta que baralha as pessoas. A resposta honesta: o balanceamento de carga é uma das tarefas que um proxy reverso pode fazer. Um proxy reverso é a ideia mais ampla — um servidor que fica à frente dos seus backends e pode encaminhar, fazer cache, terminar TLS e distribuir a carga. Um «balanceador de carga» é essa mesma porta de entrada focada na tarefa de distribuição. Na prática as ferramentas sobrepõem-se: Nginx, HAProxy e Caddy funcionam todos como balanceadores de carga, e um balanceador de carga na cloud é uma versão gerida do mesmo papel.

Onde correm os balanceadores de carga

Encontra-os em algumas formas. Os balanceadores de carga de software — Nginx, HAProxy, Traefik — correm num servidor que você controla. Os balanceadores de carga na cloud (AWS, Google Cloud, Azure) são serviços geridos que configura em vez de alojar. E em plataformas de contentores como Kubernetes, o balanceamento de carga vem integrado e espalha o tráfego pelos pods à medida que surgem e desaparecem. Use o que usar, vai querer mais do que um backend — normalmente uns quantos servidores a correr cópias idênticas da app.

Em resumo

Um balanceador de carga distribui os pedidos recebidos por vários servidores para que o sistema lide com mais tráfego e sobreviva à falha de um servidor. Escolhe um backend através de um algoritmo como round-robin ou least connections, verifica a saúde de cada servidor e pode trabalhar na camada de transporte (L4) ou de aplicação (L7). Veja-o como a tarefa de distribuição de um proxy reverso — a peça que transforma uma app numa só máquina num serviço que escala e se mantém online.