Balanceamento de carga: tráfego e resiliência

Objetivos e percurso

Percurso técnico com 120 decisões originais PT-PT/EN. Mantém os vinte grupos NGINX anteriores e acrescenta doze grupos reais de afinidade, mudança de membros, estado local e prazo de encerramento do worker. Código completo e ficha proposta de go/no-go e handover em inglês. Execução NGINX 1.30.5/Python 3.13.1 com um worker e backends HTTP sintéticos em loopback. Avaliação interna de 62 decisões em 130 minutos. A cópia de estado é didática e o handler continua deliberadamente após desligação; não se demonstra replicação durável, cancelamento de negócio, carga representativa ou comportamento de outras plataformas.

Para quem: Equipas APS L2/L3, administradores de middleware, equipas de plataforma e gestores técnicos.

Pré-requisitos: Noções de TCP/IP, HTTP/HTTPS e TLS; os casos fornecem os limites e observações necessários.

730 minutos de estudo estimados

• Identifica o que o balanceador vê e que dependências continuam no percurso.
• Escolhe sinais de distribuição e distingue persistência de recuperação de dados.
• Define o que cada check demonstra e a consequência de falhar.
• Controla repetição, duração, concorrência e confiança nos metadados recebidos.
• Calcula margem após falhas e reconhece amplificação de carga.
• Valida tráfego real e coordena conclusão de pedidos durante mudanças.
• Reconstrói o percurso de um pedido e distingue sucesso recuperado, exclusão temporária e risco de repetição.
• Demonstra a mudança aplicada sem perder pedidos em curso e distingue validação, ativação e aceitação funcional.
• Compara algoritmos com pedidos em curso e observa limites de ligações, uso do backup e retoma após libertar capacidade.
• Observa exclusão e reentrada, distingue retry de falha contabilizada e valida se o check representa a aplicação pretendida.
• Experimenta hash consistente com membros que mudam e distingue estabilidade de encaminhamento, presença de estado e recuperação funcional.
• Observa um reload com pedido pendente, identifica o efeito do prazo de encerramento e prepara decisões de reconciliação e handover para RUN.

Módulos

1. Encaminhamento e fronteiras TLS
2. Algoritmos, afinidade e estado
3. Health checks e prontidão
4. Retries, limites e origem do cliente
5. Capacidade e falhas em cascata
6. Retirada, release e operação
7. Tentativas e saúde passiva com NGINX
8. Reload, retirada e evidência de mudança
9. Concorrência, seleção e limites
10. Falha passiva, reentrada e prontidão
11. Afinidade, membros e continuidade do estado
12. Drain, prazos e resultados incertos

Continua a aprender

Avaliações técnicas

• HTTP / HTTPS
• TLS e certificados
• Middleware
• Suporte de aplicações em produção

Referências e versão

DR load balancing 2026-09; selected NGINX, HAProxy 3.2, Kubernetes and AWS ALB behavior

• NGINX HTTP load-balancing methods · 2026-09-30
• NGINX upstream hashing and membership · 2026-10-04
• NGINX transport-stream upstreams · 2026-09-30
• NGINX trusted client-address replacement · 2026-09-30
• HAProxy 3.2 configuration manual · 2026-09-30
• Kubernetes startup, liveness and readiness probes · 2026-09-30
• Kubernetes pod termination and endpoint conditions · 2026-09-30
• NGINX TLS ClientHello preread · 2026-09-30
• NGINX active upstream health checks · 2026-09-30
• AWS ALB target connections · 2026-09-30
• AWS ALB health and fail-open behavior · 2026-09-30
• Google SRE datacenter load balancing · 2026-09-30
• Google SRE handling overload · 2026-09-30
• AWS ALB algorithms and deregistration · 2026-09-30
• NGINX upstream request controls · 2026-10-04
• NGINX request processing · 2026-10-04
• HTTP Semantics · 2026-10-02
• Controlling NGINX · 2026-10-04
• NGINX command-line parameters · 2026-10-02
• NGINX access logging · 2026-10-04
• Building NGINX from sources · 2026-10-02
• NGINX downloads · 2026-10-02
• NGINX worker shutdown deadline · 2026-10-04