Nas abordagens tradicionais de balanceamento de carga, a escolha do algoritmo costuma ser reduzida a uma lista de uma única variável: distribuir em sequência, enviar para o menor número de conexões, fixar pelo endereço de origem ou usar peso. Esse modelo pode parecer suficiente sob tráfego normal; mas, quando começa uma campanha, uma explosão de API, tráfego de streaming ou um pico súbito de usuários, fica fraco para decidir sozinho.
Por exemplo, se dois backends apresentam o mesmo tempo de resposta e o sistema não tem como fazer uma segunda comparação, o tráfego se distribui de forma aleatória. Pode ser escolhido um serviço que parece ter baixo tempo de resposta mas com a fila cheia; um serviço com poucas conexões aparentes mas que começou a produzir erros ainda pode permanecer como candidato.
Essa indecisão afeta especialmente os valores de latência de cauda. Enquanto o tempo médio de resposta parece aceitável, a experiência do usuário pode se degradar nos percentis altos. Quando também não se leva em conta a latência adicionada pelos controles de segurança, controle de acesso ou camada de aplicação, candidatos que parecem rápidos mas que se comportam de fato como lentos podem se destacar.
O modelo correto deve ler os sinais de serviço ao vivo no momento da decisão e eliminar automaticamente os candidatos não saudáveis ou em modo de manutenção. Se a afinidade de sessão estiver ativa, não deve quebrar o vínculo de usuário existente; deve escolher o serviço mais adequado apenas para as requisições livres.
Esse é o problema fundamental que o Fastest+ Routing resolve: vincular a decisão de balanceamento de carga não a um único rótulo, mas ao comportamento de serviço em tempo real e em dois estágios.
O TR7 aborda o Fastest+ Routing com leitura de sinais ao vivo, pontuação em dois níveis, consciência de saúde e configuração baseada em interface.
A lógica de decisão roda embutida no data plane e lê as estatísticas de serviço ao vivo em cada requisição HTTP ou TCP. O serviço escolhido é gravado na variável de roteamento e o tráfego avança conforme essa decisão. O operador obtém uma seleção dinâmica por requisição sem escrever código personalizado.
No primeiro estágio, os serviços com o melhor valor no sinal primário são incluídos na lista de candidatos. Se vários serviços compartilham a mesma pontuação, no segundo estágio entra em ação o sinal secundário. Assim, decisões práticas como "se o tempo de resposta for o mesmo, escolha aquele com a fila mais vazia" são aplicadas dentro de um único algoritmo.
Os serviços em modo de manutenção ou com status de saúde inadequado não são incluídos na lista de candidatos. Se a afinidade de sessão dinâmica estiver ativa, a seleção Fastest+ é ignorada e o vínculo de sessão existente é preservado. Essa abordagem otimiza o desempenho sem quebrar as sessões do usuário.
O operador apenas escolhe os sinais de decisão primário e secundário. O sistema gera automaticamente as linhas de roteamento necessárias durante a fase de geração da configuração. A lógica de decisão complexa se transforma em uma escolha de política simples para a operação diária.
O Fastest+ Routing oferece capacidades avançadas de roteamento que avaliam em conjunto desempenho ao vivo, saúde e vínculo de sessão entre os backends.
Quando um novo melhor valor é encontrado no sinal de decisão primário, a lista de candidatos é zerada; os serviços que compartilham o mesmo valor são adicionados à lista. No segundo estágio, esses candidatos são novamente restringidos conforme o sinal secundário. Na configuração padrão, o Fastest+ prefere, entre os candidatos de baixo tempo de resposta, o serviço com menor carga instantânea de sessão. Assim, entre os serviços que parecem rápidos, prefere-se aquele com menor carga.
O operador escolhe dois sinais de decisão para o Fastest+: tempo médio de resposta, tempo de estabelecimento de conexão, tempo de espera na fila, carga instantânea de sessão, densidade instantânea de fila, erros de conexão, densidade de erros de cliente, densidade de erros de servidor, quedas originadas no serviço ou capacidade de conexão utilizada. Esses sinais são vinculados internamente aos contadores de serviço ao vivo relevantes; o usuário não lida com nomes brutos de métricas. Assim, o tráfego pode ser encaminhado não apenas ao serviço que "parece rápido", mas ao backend que naquele momento está mais saudável, mais vazio ou produzindo menos erros.
Em pools de serviço que não precisam de uma segunda comparação, o modo de sinal único pode ser usado. Nesse modo, a decisão é tomada apenas pelo melhor valor do sinal primário escolhido. Para grupos de serviço mais simples, não é adicionada profundidade de decisão desnecessária. O operador pode gerenciar tanto o modo de sinal único quanto o de sinal duplo pela mesma interface.
Se um backend estiver em modo de manutenção ou com status de saúde inadequado, ele não entra na lista de candidatos. Esse comportamento está embutido no algoritmo; não requer regras manuais, listas de controle de acesso adicionais ou intervenção operacional. Manutenção planejada, separação de serviço problemático e remoção temporária de serviço refletem automaticamente na decisão de tráfego. Assim, o sistema escolhe apenas entre os candidatos adequados.
Quando as condições de afinidade de sessão se formam, a seleção Fastest+ é desativada. A requisição é encaminhada ao serviço determinado pela lógica de sessão persistente existente. A condição de roteamento gerada é configurada de forma transparente pelo sistema. Assim, a otimização de desempenho não se sobrepõe à continuidade da sessão do usuário.
O Fastest+ pode rodar tanto na fase de requisição HTTP quanto na fase de inspeção de conteúdo TCP. Em serviços TCP, a janela de inspeção necessária para a decisão é criada automaticamente. Assim, o tráfego da camada de aplicação e os serviços baseados em TCP são tratados no mesmo modelo de gerenciamento. O operador não precisa aprender lógicas de produto diferentes conforme o tipo de serviço.
Quando a afinidade dinâmica é usada, o Fastest+ roda apenas para os clientes que ainda não têm uma sessão fixada. Enquanto as sessões existentes são preservadas, as requisições novas ou livres são distribuídas conforme os sinais ao vivo. Esse modelo oferece uma abordagem equilibrada tanto em termos de continuidade do usuário quanto de uso instantâneo da capacidade. Ajuda especialmente a usar o pool de serviço de forma mais eficiente sob tráfego intenso e flutuante.
Se nenhum backend adequado for encontrado no processo de decisão, a decisão de roteamento personalizada fica vazia. Nesse caso, entra em ação o comportamento padrão de balanceamento de carga. Quando o sistema não consegue produzir uma decisão de roteamento personalizada, em vez de descartar o tráfego, ele retorna ao comportamento padrão conhecido. Essa lógica de retorno reduz os riscos operacionais.
O Fastest+ Routing foi projetado não apenas como uma escolha de algoritmo, mas em conjunto com comportamentos de alta disponibilidade, visibilidade, recarga e integração.
A lógica de decisão é carregada na inicialização do serviço e definida como duas ações distintas: de sinal único e de sinal duplo. A ação de sinal único trabalha com uma entrada de decisão, e a de sinal duplo com duas entradas de decisão. As ações podem ser usadas nas fases de requisição HTTP e TCP.
As estatísticas de serviço são lidas de uma tabela em memória; não são necessários soquetes adicionais, leitura de arquivo ou consulta externa. O processo de decisão faz uma varredura linear conforme o número de serviços. Essa estrutura mantém a decisão de roteamento próxima do data plane mesmo em pools com grande número de backends.
Em uma configuração de alta disponibilidade de dois nodes, cada node roda o mesmo algoritmo de forma independente. Como os sinais ao vivo são avaliados localmente no node, após o failover o novo node ativo continua a decidir com as estatísticas que ele próprio observa. Não se cria dependência de um repositório de pontuação compartilhado externo.
O backend escolhido é mantido na variável de roteamento e pode ser adicionado ao formato de log. Assim, é possível investigar retroativamente qual requisição foi encaminhada a qual serviço. As equipes de operação podem ver as decisões de tráfego não apenas como resultado, mas como um rastro de roteamento rastreável.
Durante uma recarga suave, o contexto de decisão é recarregado e o algoritmo começa com um novo estado de memória. Como a observação de tempo de resposta passado não é transferida, nas primeiras requisições as decisões se baseiam nos dados instantâneos atuais. A possibilidade de aplicar mudanças de configuração sem reiniciar o pool reduz a interrupção operacional.
Quando a camada WAAP bloqueia uma requisição, o Fastest+ não é chamado; assim, não se faz uma seleção de serviço desnecessária. O Fastest+ vale apenas para pools de serviço HTTP e TCP. Em serviços Layer 4, são usadas as opções de algoritmo Layer 4 da plataforma.
Em períodos de vendas intensas, muitos backends recebem tráfego ao mesmo tempo. O Fastest+ avalia em conjunto sinais como tempo de resposta e densidade de fila, evitando que serviços rápidos mas com a fila cheia se destaquem desnecessariamente. O resultado é um uso de serviço mais equilibrado e uma experiência de usuário mais controlada.
Nas camadas de API financeira, apenas a resposta rápida não basta; o comportamento de geração de erros também deve fazer parte da decisão. O Fastest+ pode priorizar serviços com baixa densidade de erros de servidor e, em caso de empate, levar em conta a carga instantânea de sessão. Essa estrutura proporciona uma distribuição mais consciente no tráfego de API crítico.
No tráfego de streaming e mídia, o node menos carregado nem sempre oferece a melhor experiência de usuário. O Fastest+ avalia em conjunto o uso atual de conexão e o comportamento de resposta combinando capacidade de conexão utilizada e tempo de resposta. Assim, faz-se uma partilha de tráfego mais precisa entre os serviços de borda.
Em estruturas multitenant, o grupo de serviço de cada tenant pode apresentar comportamento diferente. O Fastest+ pode preferir os serviços que operam de forma mais estável com sinais como quedas originadas no serviço e tempo de estabelecimento de conexão. Essa abordagem torna a qualidade de serviço por tenant mais gerenciável.
Distribuição de tráfego em dois estágios com sinais ao vivo, configurada sem escrever código. Vamos guiá-lo em uma configuração ao vivo sobre os seus próprios serviços.