Novedades en API7 Enterprise 3.2.9: Configuración mejorada de Health Check

Introducción a las nuevas funciones de verificación de salud

En la versión 3.2.9 de API7 Enterprise, se ha optimizado completamente la experiencia de interacción de configuración para las verificaciones de salud.

1. Los elementos de configuración que antes estaban dispersos se han agrupado lógicamente, como los ajustes de las sondas y los criterios para determinar nodos saludables y no saludables, haciéndolos más estructurados.

2. Algunos nombres de elementos de configuración abstractos se han transformado en expresiones más intuitivas y semánticas, permitiendo a los usuarios ingresar directamente los parámetros relevantes a través de un formato de relleno, lo que facilita una comprensión más clara de los efectos prácticos de las configuraciones.

3. Durante la configuración de los nodos upstream y los procesos de verificación de salud, se han añadido más mensajes de ayuda para asistir a los usuarios en la comprensión de la conexión inherente entre los nodos upstream y las verificaciones de salud, facilitando así la finalización más sencilla de las tareas de configuración.

Conceptos básicos de las verificaciones de salud

En API7 Enterprise, la configuración de prioridad de los nodos upstream está estrechamente vinculada a los mecanismos de balanceo de carga y verificaciones de salud. Cuando los usuarios configuran múltiples nodos upstream con diferentes prioridades para el gateway, este prioriza los nodos de mayor prioridad durante el balanceo de carga. Esto significa que, mientras los nodos de mayor prioridad permanezcan saludables, el gateway continuará enrutando el tráfico hacia estos nodos.

Solo cuando todos los nodos de mayor prioridad se consideren no disponibles debido a fallos en las verificaciones de salud, el gateway degradará automáticamente, redirigiendo el tráfico a los nodos upstream de la siguiente prioridad más alta. Este diseño asegura un uso eficiente del tráfico y una alta disponibilidad del sistema.

Es importante destacar que, si se configuran múltiples niveles de prioridad de nodos upstream en el servicio pero se desactiva la función de verificación de salud, todas las solicitudes de los clientes siempre se enrutarán a los nodos de mayor prioridad, independientemente de su estado de salud real.

Métodos de configuración para las verificaciones de salud

Configuración de la sonda

Una sonda se utiliza para detectar la vivacidad y el estado del servicio de los nodos upstream. En APISIX, la sonda actúa como un "inspector" que regularmente verifica si el servicio upstream está funcionando correctamente. Si detecta algún problema o si el servicio está "no disponible", informa a APISIX: "Este servicio no está disponible actualmente, así que abstente de enviar solicitudes aquí". Este proceso de "verificación" se realiza a través de las sondas.

La sonda incluye principalmente los siguientes elementos de configuración:

• Esquema de la sonda: El tipo de protocolo utilizado por la sonda de verificación de salud, que soporta TCP, HTTP y HTTPS.

• Concurrencia: Este elemento de configuración permite establecer el número de solicitudes concurrentes de verificación de salud. En otras palabras, es el número de veces que deseas "verificar" simultáneamente la capacidad de respuesta de los servicios upstream. Ajustando la concurrencia, puedes simular posibles solicitudes concurrentes en escenarios reales, evaluando mejor el rendimiento y la estabilidad de los servicios upstream.

• Host: Especifica la dirección del servidor upstream que se va a verificar. Es como determinar a qué "casa" se va a "llamar a la puerta".

• Puerto: El número de puerto del servicio upstream. Es como saber a qué puerta llamar durante la sonda.

• Ruta: Si estás utilizando una sonda HTTP, este elemento de configuración especifica la ruta URL que deseas acceder. Es como indicarle a la sonda que verifique la habitación exacta una vez dentro.

Criterios para determinar nodos saludables

En cuanto a la determinación de nodos saludables, el sistema verifica regularmente los nodos previamente marcados como no saludables en el intervalo establecido por el usuario (en segundos) para asegurar la detección oportuna y el manejo adecuado de cualquier anomalía transitoria en los nodos.

Si la sonda utiliza el protocolo TCP, el nodo se considera saludable después de que la sonda se conecte exitosamente al nodo upstream el número de veces establecido por el usuario.

Si la sonda utiliza el protocolo HTTP/HTTPS, el sistema considera el nodo saludable solo cuando recibe continuamente solicitudes de sonda con códigos de estado específicos (como 200 y 302) del nodo. Esto significa que el nodo se considera en funcionamiento correcto solo cuando devuelve continuamente estos códigos de estado específicos.

Criterios para determinar nodos no saludables

En cuanto a la determinación de nodos no saludables, el método de configuración es similar al de determinar nodos saludables. El sistema verifica regularmente los nodos marcados como saludables en el intervalo establecido por el usuario. Una vez que estos nodos cumplen las condiciones preestablecidas de no saludabilidad, se reclasifican como no saludables.

Ligeramente diferente de la determinación de nodos saludables, se añade un elemento de configuración adicional, la verificación de solicitudes del cliente, durante el proceso de determinación de nodos no saludables. Cuando esta función está habilitada, el gateway no solo depende de los resultados de la inspección de la sonda, sino que también observa y analiza profundamente las solicitudes de los clientes y las respuestas reales de los servicios upstream. Basándose en estos datos y en los criterios de juicio definidos por el usuario, el gateway puede evaluar con mayor precisión el estado de funcionamiento de los servicios upstream.

Mejores prácticas para las verificaciones de salud

Selección del tipo de sonda adecuado

• Sonda TCP: Adecuada para escenarios que solo requieren confirmar si el puerto del servicio está abierto y accesible. Por ejemplo, un servicio de base de datos puede solo necesitar una sonda TCP para confirmar la apertura del puerto.

• Sonda HTTP/HTTPS: Más adecuada para escenarios que requieren verificar no solo que la conexión de red es normal, sino también que el servicio puede manejar correctamente las solicitudes. Por ejemplo, para un servidor web o un servicio API, necesitamos asegurarnos de que no solo puede recibir conexiones, sino también devolver páginas o datos correctos.

Configuración razonable de los parámetros de verificación de salud

Al configurar las verificaciones de salud, presta atención a varios parámetros clave:

• Intervalo de verificación: No debe ser demasiado corto para evitar sobrecargas innecesarias ni demasiado largo para evitar respuestas lentas en caso de problemas. Por ejemplo, para un sitio web de comercio electrónico con alto tráfico, verificar cada 30 segundos es una elección relativamente razonable. Este intervalo no consume excesivamente los recursos del sistema ni retrasa la detección y manejo de problemas en el sitio.

  Por supuesto, este intervalo no es absoluto y debe ajustarse según la situación real del sitio. Por ejemplo, si el sitio experimenta fluctuaciones significativas en el tráfico o aumentos de tráfico durante períodos específicos (como durante campañas promocionales), puede ser necesario ajustar el intervalo de verificación para adaptarse a estos cambios.

• Tiempo de espera: El tiempo que la sonda espera una respuesta del servicio. Si el servicio no responde dentro de este tiempo, la sonda considera el servicio no saludable. Este valor debe establecerse según el tiempo de respuesta real del servicio.

• Número de reintentos: El número de veces que la sonda intenta conectarse antes de determinar que el servicio no es saludable. Este valor debe ser moderado para evitar juicios erróneos.

Ajuste de estrategias basadas en el negocio

Las estrategias de verificación de salud deben ajustarse según la situación real del negocio. Si un servicio típicamente experimenta cargas altas durante períodos específicos, los intervalos de verificación de salud pueden aumentarse o reducirse el número de reintentos durante estos períodos para evitar presión adicional sobre el servicio.

Habilitación de la verificación de solicitudes del cliente según corresponda

La verificación de solicitudes del cliente puede determinar efectivamente el estado del servicio basándose en solicitudes reales del negocio, especialmente para identificar problemas estrechamente relacionados con la lógica del negocio. Sin embargo, puede no ser adecuada para todos los escenarios de negocio.

1. Servicios de bajo tráfico: Si el tráfico del servicio es bajo, las verificaciones de salud pasivas basadas en solicitudes del cliente pueden no proporcionar suficientes puntos de datos para evaluar con precisión el estado del servicio. En tales casos, depender de verificaciones activas de sondas puede ser más confiable.

2. Consideraciones de rendimiento en entornos de alta concurrencia: Las verificaciones de salud pasivas requieren el monitoreo y procesamiento de cada solicitud del cliente, lo que puede aumentar la sobrecarga de rendimiento en entornos de alta concurrencia. Si el rendimiento es una preocupación principal y el servicio ha sido adecuadamente monitoreado a través de otros medios, las verificaciones de salud pasivas pueden considerarse para su cierre.

3. Existencia de otros sistemas de monitoreo: Si en la empresa ya se han desplegado sistemas de monitoreo maduros, capaces de capturar y analizar el estado del servicio en tiempo real, las verificaciones de salud pasivas pueden no ser necesarias para evitar redundancia de datos y complejidad adicional.

Conclusión

Las verificaciones de salud son un aspecto crucial para garantizar la alta disponibilidad de los gateways API. En la versión 3.2.9 de API7 Enterprise, hemos optimizado completamente la configuración interactiva de las verificaciones de salud, simplificando las operaciones y mejorando la experiencia del usuario.

Al configurar adecuadamente las sondas, establecer criterios para nodos saludables y no saludables, y ajustar las estrategias según las necesidades reales del negocio, los usuarios pueden monitorear más efectivamente el estado de los servicios upstream, asegurando que el tráfico siempre se enrute a nodos saludables. Esto no solo mejora la estabilidad y disponibilidad del sistema, sino que también asegura que las solicitudes de los usuarios reciban respuestas oportunas y precisas.