En los enfoques tradicionales de balanceo de carga, la elección del algoritmo suele reducirse a una lista de una sola variable: distribuir por turnos, enviar al de menos conexiones, fijar según la dirección de origen o usar pesos. Este modelo puede parecer suficiente bajo tráfico normal; pero cuando comienza una campaña, una explosión de API, tráfico de streaming o una densidad repentina de usuarios, decidir por sí solo resulta débil.
Por ejemplo, si dos backends dan el mismo tiempo de respuesta y el sistema no tiene forma de hacer una segunda comparación, el tráfico se distribuye de forma arbitraria. Puede elegirse un servicio que parece de bajo tiempo de respuesta pero con la cola llena; un servicio que parece tener pocas conexiones pero que ha empezado a producir errores puede seguir siendo candidato.
Esta indecisión afecta especialmente a los valores de latencia extremos. Mientras el tiempo medio de respuesta parece aceptable, la experiencia de usuario puede degradarse en los percentiles altos. Cuando tampoco se tiene en cuenta la latencia que añaden los controles de seguridad, de control de acceso o de la capa de aplicación, pueden destacar candidatos que parecen rápidos pero que de hecho se comportan despacio.
El modelo correcto debe leer las señales de servicio en vivo en el momento de la decisión y eliminar automáticamente a los candidatos no aptos o en modo de mantenimiento. Si la afinidad de sesión está activa, no debe romper el vínculo del usuario existente; solo debe elegir el servicio más adecuado en las peticiones libres.
Ese es el problema fundamental que resuelve Fastest+ Routing: vincular la decisión de balanceo de carga no a una sola etiqueta, sino al comportamiento de servicio en tiempo real y en dos etapas.
TR7 aborda Fastest+ Routing con lectura de señales en vivo, puntuación en dos niveles, conciencia de salud y configuración basada en la interfaz.
La lógica de decisión se ejecuta integrada en el plano de datos y lee las estadísticas de servicio en vivo en cada petición HTTP o TCP. El servicio elegido se escribe en la variable de enrutamiento y el tráfico avanza según esa decisión. El operador obtiene una selección dinámica por petición sin escribir código personalizado.
En la primera etapa, los servicios con el mejor valor en la señal primaria se incorporan a la lista de candidatos. Si varios servicios comparten la misma puntuación, en la segunda etapa entra en juego la señal secundaria. Así, decisiones prácticas como "si el tiempo de respuesta es igual, elige el que tiene la cola más libre" se aplican dentro de un solo algoritmo.
Los servicios en modo de mantenimiento o con un estado de salud no apto no se incorporan a la lista de candidatos. Si la afinidad de sesión dinámica está activa, se omite la selección Fastest+ y se conserva el vínculo de sesión existente. Este enfoque optimiza el rendimiento sin romper las sesiones de usuario.
El operador solo elige la señal de decisión primaria y secundaria. El sistema crea automáticamente las líneas de enrutamiento necesarias en la fase de generación de configuración. La lógica de decisión compleja se convierte en una simple elección de política para la operación diaria.
Fastest+ Routing ofrece capacidades avanzadas de enrutamiento que evalúan juntos el rendimiento en vivo, la salud y el vínculo de sesión entre los backends.
Cuando se encuentra un nuevo mejor valor en la señal de decisión primaria, la lista de candidatos se reinicia; los servicios que comparten el mismo valor se añaden a la lista. En la segunda etapa, esos candidatos se acotan de nuevo según la señal secundaria. En la configuración por defecto, Fastest+ prefiere, entre los candidatos de bajo tiempo de respuesta, el servicio con menor carga instantánea de sesión. Así, entre los servicios que parecen rápidos se prefiere el de menor carga.
El operador elige dos señales de decisión para Fastest+: tiempo medio de respuesta, tiempo de establecimiento de conexión, tiempo de espera en cola, carga instantánea de sesión, densidad instantánea de cola, errores de conexión, densidad de errores de cliente, densidad de errores de servidor, cortes originados en el servicio o capacidad de conexión utilizada. Estas señales se vinculan internamente a los contadores de servicio en vivo correspondientes; el usuario no lidia con nombres de métricas en bruto. Así, el tráfico puede enrutarse no solo al servicio que "parece rápido", sino al backend que en ese momento está más sano, más libre o produce menos errores.
En los pools de servicio donde no hace falta una segunda comparación, puede usarse el modo de señal única. En este modo la decisión se toma solo según el mejor valor de la señal primaria elegida. Para grupos de servicio más simples no se añade una profundidad de decisión innecesaria. El operador puede gestionar tanto el modo de señal única como el de doble señal desde la misma interfaz.
Si un backend está en modo de mantenimiento o su estado de salud no es apto, no entra en la lista de candidatos. Este comportamiento está integrado dentro del algoritmo; no requiere además regla manual, lista de control de acceso adicional ni intervención operativa. El mantenimiento planificado, la separación de un servicio problemático y la retirada temporal de un servicio se reflejan automáticamente en la decisión de tráfico. Así el sistema elige solo entre candidatos aptos.
Cuando se dan las condiciones de afinidad de sesión, la selección Fastest+ queda deshabilitada. La petición se enruta al servicio determinado por la lógica de sesión adhesiva existente. La condición de enrutamiento generada la configura el sistema de forma transparente. Así, la optimización de rendimiento no se antepone a la continuidad de la sesión del usuario.
Fastest+ puede ejecutarse tanto en la fase de petición HTTP como en la fase de inspección de contenido TCP. En los servicios TCP, la ventana de inspección necesaria para la decisión se crea automáticamente. Así, el tráfico de la capa de aplicación y los servicios basados en TCP se tratan en el mismo modelo de gestión. El operador no tiene que aprender lógicas de producto diferentes según el tipo de servicio.
Cuando se usa la adhesividad dinámica, Fastest+ se ejecuta solo para los clientes que aún no tienen una sesión fijada. Mientras se conservan las sesiones existentes, las peticiones nuevas o libres se distribuyen según las señales en vivo. Este modelo ofrece un enfoque equilibrado tanto para la continuidad del usuario como para el uso instantáneo de la capacidad. Especialmente bajo tráfico intenso y fluctuante, ayuda a usar el pool de servicios de forma más eficiente.
Si en el proceso de decisión no se encuentra un backend adecuado, la decisión de enrutamiento especial queda vacía. En ese caso entra en juego el comportamiento de balanceo de carga por defecto. Cuando el sistema no puede producir una decisión de enrutamiento especial, en lugar de desperdiciar el tráfico, vuelve al comportamiento por defecto conocido. Esta lógica de retorno reduce los riesgos operativos.
Fastest+ Routing no es solo una elección de algoritmo; está diseñado junto con comportamientos de alta disponibilidad, visibilidad, recarga e integración.
La lógica de decisión se carga al inicio del servicio y se define como dos acciones separadas: de señal única y de doble señal. La acción de señal única funciona con una entrada de decisión, y la de doble señal con dos entradas de decisión. Las acciones pueden usarse en las fases de petición HTTP y TCP.
Las estadísticas de servicio se leen de una tabla en memoria; no se requiere socket adicional, lectura de archivo ni consulta externa. El proceso de decisión realiza un recorrido lineal según el número de servicios. Esta estructura mantiene la decisión de enrutamiento cerca del plano de datos incluso en pools con muchos backends.
En una instalación de alta disponibilidad de dos nodos, cada nodo ejecuta el mismo algoritmo de forma independiente. Como las señales en vivo se evalúan localmente en el nodo, tras el failover el nuevo nodo activo sigue decidiendo con las estadísticas que él mismo observa. No se crea dependencia de un almacén de puntuación compartido externo.
El backend elegido se mantiene en la variable de enrutamiento y puede añadirse al formato de log. Así puede investigarse retrospectivamente a qué servicio se enrutó cada petición. Los equipos de operación pueden ver las decisiones de tráfico no solo como resultado, sino como un rastro de enrutamiento rastreable.
Durante una recarga suave, el contexto de decisión se recarga y el algoritmo arranca con un nuevo estado de memoria. Como no se transfiere la observación pasada del tiempo de respuesta, en las primeras peticiones las decisiones se basan en los datos instantáneos actuales. Que los cambios de configuración puedan aplicarse sin reiniciar el pool reduce la interrupción operativa.
Cuando la capa WAAP bloquea una petición, no se invoca Fastest+; así no se realiza una selección de servicio innecesaria. Fastest+ solo es válido en los pools de servicio HTTP y TCP. En los servicios Layer 4 se usan las opciones de algoritmo Layer 4 de la plataforma.
En los periodos de venta intensa, muchos backends reciben tráfico al mismo tiempo. Fastest+ evalúa juntas señales como el tiempo de respuesta y la densidad de cola, evitando que los servicios rápidos pero con la cola llena destaquen sin necesidad. El resultado es un uso de servicio más equilibrado y una experiencia de usuario más controlada.
En las capas de API financieras no basta solo con una respuesta rápida; el comportamiento de producción de errores también debe ser parte de la decisión. Fastest+ puede anteponer los servicios con baja densidad de errores de servidor y, en caso de empate, tener en cuenta la carga instantánea de sesión. Esta estructura proporciona una distribución más consciente en el tráfico de API crítico.
En el tráfico de streaming y medios, el nodo menos cargado no siempre da la mejor experiencia de usuario. Fastest+ evalúa juntos, con la combinación de capacidad de conexión utilizada y tiempo de respuesta, tanto el uso de conexión actual como el comportamiento de respuesta. Así se hace un reparto de tráfico más preciso entre los servicios de borde.
En las estructuras multi-tenant, el grupo de servicio de cada tenant puede comportarse de forma distinta. Fastest+ puede preferir los servicios que funcionan de forma más estable con señales como los cortes originados en el servicio y el tiempo de establecimiento de conexión. Este enfoque hace más gestionable la calidad de servicio por tenant.
Distribución de tráfico en dos etapas con señales en vivo, configurada sin escribir código. Recorrámosla en una instalación en vivo sobre sus propios servicios.