Cada algoritmo clássico parte de uma suposição sobre o vService que atende. Round-robin assume que os backends são intercambiáveis. Least-connections assume que a contagem de sessões se correlaciona com a carga do backend. Source-IP assume afinidade entre usuário e backend sem persistência explícita. Hashes de afinidade de cache assumem que a chave da requisição — URL, header ou sessão — é estável. Quando a suposição se sustenta, o algoritmo é a resposta certa.
Os casos mais difíceis são quando essas suposições deixam de valer: backends oscilam em desempenho durante o dia útil, gerações de hardware se misturam durante uma atualização gradual, a latência regional varia de requisição para requisição, ou a própria carga tem rajadas de consultas pesadas que não correspondem à contagem bruta de requisições. Nesses cenários, escolher o backend realmente mais rápido por requisição — ou usar um algoritmo de hash projetado para absorver mudanças de backend sem redistribuir tudo — é o que preserva a latência visível ao usuário.
A resposta certa é adequar o algoritmo à carga de trabalho — por vService, não globalmente.
Um vService no TR7 reúne o listener de frontend, regras de tráfego, verificações de integridade e o grupo de backends em um único objeto de configuração — mais abrangente do que o conceito clássico de pool que distribui esses elementos em lugares separados. Cada vService escolhe seu próprio algoritmo em um menu suspenso — sem reconstrução, sem reinicialização. Misture e combine em uma única instância TR7: round-robin no vService de ativos estáticos, Fastest+ no vService de API, Maglev hash no vService de camada de cache. O filtro por tipo de serviço acontece automaticamente; a interface exibe apenas os algoritmos válidos para o protocolo do vService.
A escolha do algoritmo vive no objeto vService, não na configuração global do ADC. Diferentes vServices executam algoritmos diferentes na mesma instância TR7.
A interface exibe apenas os algoritmos que fazem sentido para o protocolo do vService — vServices HTTP, TCP ou de camada de rede recebem cada um o subconjunto relevante, sem suposições do operador.
O algoritmo escolhe o backend para a primeira requisição; a persistência de sessão então fixa as requisições subsequentes do mesmo usuário. Ambas as camadas configuráveis de forma independente por vService.
Mude o algoritmo em um vService ativo e o tráfego muda para a nova lógica imediatamente. Sem reinicialização de serviço, sem necessidade de drenagem de conexões.
Todos os algoritmos clássicos, duas variantes modernas de consistent hash, um algoritmo de menor atraso, mais o motor proprietário Fastest+ do TR7. Todos disponíveis por vService — escolhidos em um menu suspenso, sem necessidade de código de configuração.
Distribuição uniforme pelo vService, ponderada ou não. O padrão para vServices uniformes onde cada backend tem capacidade idêntica.
Roteia para o backend com menor número de conexões abertas no momento. Altamente eficaz para sessões de longa duração onde a contagem de sessões se correlaciona com a carga do backend. A variante ponderada leva em conta diferenças de capacidade.
Sempre roteia para o primeiro backend listado com capacidade; cai para o próximo somente quando sobrecarregado. Útil para ordenação de backends quente-frio ou implantações graduais.
Seleção aleatória entre backends saudáveis. Sem estado, estatisticamente uniforme — útil quando o vService é grande e uniforme. Suporta random de potência de dois para seleção de menor carga com baixo overhead.
O mesmo IP de cliente sempre roteia para o mesmo backend. Útil para fluxos com estado quando a aplicação não gerencia persistência de sessão explícita.
Hash em um componente de URL — o comprimento da URL, o caminho URI ou um parâmetro de consulta específico (ex.: ?user_id). Roteia a mesma URL ou usuário ao mesmo backend para afinidade de cache.
Hash em um header HTTP personalizado. Útil para roteamento multi-tenant (header tenant-id), feature flagging ou cenários de testes A/B.
Lê o cookie de sessão RDP para seleção de backend. Útil para gateways RDP e farms de desktop remoto onde a afinidade de sessão é necessária.
Modo de hash moderno que minimiza a perturbação quando backends entram ou saem do vService — apenas uma pequena fração das chaves é redistribuída, não o vService inteiro. Ideal para camadas de cache onde a rotatividade de backends não deve invalidar todo o cache.
O algoritmo de consistent hashing do Google construído para balanceadores de carga de software em escala. Menor variância que o consistent hash clássico, determinístico entre réplicas. Excelente para serviços sem estado que precisam de atribuição previsível de backend.
Roteia para o backend com o menor tempo de espera esperado, levando em conta conexões ativas e peso por backend. Uma alternativa sensível à latência em relação ao least-connections quando as capacidades de backend diferem significativamente.
Roteia para o backend com o menor tempo de resposta recente. Uma opção mais simples e sensível à latência quando o tempo de resposta é o único sinal que importa.
O motor adaptativo proprietário do TR7 com 8 sinais. Combina tempo de resposta, tempo de conexão, profundidade de fila, sessões ativas, taxas de erro e mais em uma pontuação de rapidez por requisição. Veja a seção de detalhes abaixo.
A maioria dos algoritmos adaptativos monitora um único sinal — tempo de resposta ou contagem de conexões. Fastest+ amostra continuamente 8 sinais de desempenho independentes por backend e os combina em uma única pontuação de rapidez, calculada de forma atualizada para cada requisição recebida.
Latência média de resposta do backend, amostrada continuamente. O sinal principal — um backend que demora mais para responder cai no ranking imediatamente.
Quanto tempo leva para estabelecer uma conexão TCP/TLS. Um backend cujo tempo de conexão cresce está se aproximando da saturação, mesmo que seu tempo de resposta ainda pareça bom.
Tempo que as requisições passam na fila antes de chegar ao backend. O aumento do tempo de fila é o aviso mais precoce de que um backend não consegue acompanhar.
Sessões abertas no momento por backend. Roteamento ciente de capacidade sem o ruído dos totais históricos.
Requisições atualmente aguardando. Um backend com 0 na fila é preferido a um igualmente rápido com 50 esperando.
Conexões com falha recentes. Um backend que recusou 3 das últimas 10 tentativas cai no ranking antes que uma verificação de integridade o detecte.
Abortos de sessão iniciados pelo backend na janela recente. Captura o caso em que um backend está ativo mas falha no meio do processamento.
Utilização do pool de conexões — quão próximo da capacidade está o pool keep-alive de cada backend. Detecta esgotamento do pool antes que se torne visível ao usuário.
Backends idênticos, capacidade idêntica — round-robin mantém a matemática simples e a carga simétrica. Adicione random para vServices grandes e sem estado.
WebSockets, serviços de streaming, chamadas de vídeo — sessões ficam abertas por minutos ou horas. Least-connections ou SED rastreia a carga ativa muito melhor do que a contagem de requisições.
A rotatividade de backends não deve invalidar todo o cache. Consistent hash ou Maglev redistribui apenas uma pequena fração das chaves quando backends mudam.
Hardware misto, implantações graduais, variância de latência regional — Fastest+ pontua backends ao vivo para que o roteamento escolha o realmente mais rápido, não o teoricamente melhor.
Veja como o TR7 ADC permite definir o algoritmo por vService — e como o Fastest+ lida com as cargas de trabalho que os outros não conseguem.