10 Patrones Comunes de Diseño de Resiliencia de API con API Gateway
November 1, 2023
La resiliencia de las API se trata de construir API robustas que puedan resistir una variedad de desafíos, asegurando que sigan funcionando de manera efectiva. Los API Gateways juegan un papel clave en esto, actuando como el punto de entrada para las solicitudes externas y gestionando la comunicación entre diferentes servicios al tener en cuenta patrones comunes de resiliencia de API. Uno de los API Gateways de código abierto más populares, Apache APISIX, ofrece una variedad de características para mejorar la resiliencia y robustez de las API. En este artículo, exploraremos 10 patrones comunes de diseño de resiliencia de API y cómo se pueden implementar utilizando APISIX.
Aquí está la lista de los 10 patrones de resiliencia de API:
- Limitación de tasa.
- Reintento.
- Tiempo de espera.
- Respuesta de respaldo.
- Caché.
- Redundancia.
- Verificaciones de salud.
- Cortocircuito.
- Compartimentación.
- Inyección de fallos.
¿Qué es la resiliencia de las API?
La resiliencia de las API se refiere a la capacidad de una API para realizar sus funciones previstas de manera consistente y confiable, incluso frente a errores, tráfico elevado o condiciones inesperadas. No se trata de evitar fallos, sino de aceptar el hecho de que los fallos ocurrirán y responder a ellos de una manera que evite tiempos de inactividad o pérdida de datos. El objetivo de la resiliencia es devolver la aplicación a un estado de funcionamiento completo después de un fallo. Las API resilientes están diseñadas para manejar fallos de manera elegante, ya sea que esos fallos se originen dentro de la API misma, de servicios dependientes o debido a factores externos como problemas de red o latencia, incompatibilidad de versiones de API y otros problemas que puedan surgir debido a cambios en el entorno o comportamientos inesperados de los usuarios.
¿Por qué la resiliencia de las API en el API Gateway?
Muchos marcos de desarrollo de software existentes incluyen un conjunto de prácticas y patrones diseñados para garantizar que las API sigan estando disponibles, sean receptivas y precisas. Sin embargo, implementar la resiliencia de las API a nivel del API Gateway, en lugar de en servicios individuales o en otro lugar del sistema, ofrece varias ventajas estratégicas.
1. Control centralizado: El API Gateway sirve como un punto de entrada central para todas las solicitudes de API, proporcionando una oportunidad única para gestionar y aplicar patrones de resiliencia en todos los servicios de manera unificada. Esta centralización simplifica la implementación y el mantenimiento de las características de resiliencia.
2. Consistencia: Al manejar la resiliencia en el API Gateway, se asegura un enfoque consistente para manejar fallos, limitación de tasa, tiempos de espera y otras estrategias de resiliencia en todos los servicios. Esta consistencia es crucial para mantener un comportamiento del sistema confiable y predecible.
3. Reducción de la complejidad: Implementar características de resiliencia en cada microservicio puede llevar a un esfuerzo duplicado y a un aumento de la complejidad. El API Gateway abstrae estas preocupaciones, permitiendo que los desarrolladores de servicios se concentren en la lógica de negocio en lugar de en manejar la resiliencia.
4. Mejor utilización de recursos: El API Gateway puede gestionar eficientemente los recursos y distribuir el tráfico, asegurando que ningún servicio individual se vea abrumado. Este equilibrio de carga contribuye a la resiliencia general del sistema.
5. Monitoreo y registro más fáciles: Tener un único punto por el que fluye todo el tráfico de API facilita el monitoreo de la salud de los servicios y el registro de cualquier problema. Esta vista centralizada es invaluable para identificar y responder rápidamente a los problemas.
6. Seguridad simplificada: Medidas de seguridad como autenticación, autorización y cifrado pueden aplicarse de manera consistente en el API Gateway, asegurando que todos los servicios estén protegidos sin la necesidad de configuraciones redundantes.
7. Rendimiento mejorado: El API Gateway puede implementar caché y agregación de respuestas, reduciendo el número de llamadas a los servicios backend y mejorando el rendimiento general del sistema.
8. Degradación elegante: En caso de un fallo en un servicio, el API Gateway puede redirigir el tráfico o proporcionar respuestas de respaldo, asegurando que el sistema se degrade de manera elegante y continúe proporcionando funcionalidad.
9. Recuperación más rápida: La naturaleza centralizada del API Gateway permite una implementación más rápida de correcciones y actualizaciones, asegurando que el sistema pueda ser restaurado rápidamente a su funcionalidad completa después de un fallo.
10. Interacción simplificada con el cliente: Los clientes solo necesitan interactuar con el API Gateway, que proporciona una interfaz consistente y confiable, abstraiendo la complejidad de los microservicios subyacentes.
Desde un punto de vista de desarrollo, el enfoque del API Gateway también reduce el tiempo para implementar patrones de resiliencia comúnmente utilizados. Descubramos cada patrón en el ejemplo de la comunicación entre servicios en una aplicación típica de conferencias y entendamos cómo habilitarlos.
Esta publicación se centra principalmente en la parte teórica y proporciona referencias a la documentación relevante. Los desarrolladores pueden implementar estos patrones consultando cada enlace y siguiendo las guías proporcionadas. Con APISIX, es posible configurar estos patrones de diseño utilizando la Admin API, un archivo YAML estático o el APISIX Dashboard.
1. Limitación de tasa
Como su nombre lo indica, la limitación de tasa controla el número de solicitudes que un cliente puede hacer en un período de tiempo determinado. APISIX ofrece un plugin limit-req para configurar la limitación de tasa. Este plugin permite definir reglas basadas en las propiedades de las solicitudes individuales (demasiadas de un usuario, aplicación cliente o ubicación) para limitar las solicitudes, asegurando que su API no se vea abrumada por demasiadas solicitudes.
La política de limitación de tasa también se puede utilizar para limitar el acceso a usuarios no autorizados. Consulte la guía para ver cómo usar el plugin para la limitación de tasa.
2. Reintento
El patrón de reintento implica reintentar automáticamente una solicitud de API si falla. Con APISIX, puede configurar el mecanismo de reintento para un objeto Upstream para especificar el número de reintentos y las condiciones bajo las cuales se debe intentar un reintento.
Al configurar el upstream con propiedades de reintento, APISIX envía solicitudes de reintento automático al servicio backend Attendee si la solicitud anterior se agotó el tiempo de espera o falló debido a un problema de red.
3. Tiempo de espera
Establecer un tiempo de espera asegura que una solicitud no se quede colgada indefinidamente si el servicio backend no responde. APISIX le permite configurar tiempos de espera para sus API en la misma configuración del objeto Upstream, asegurando que las solicitudes se terminen si tardan demasiado en responder.
En caso de que el servicio de asistente responda lentamente, APISIX puede aplicar un patrón de fallo rápido y responder rápidamente a la solicitud de la aplicación cliente para mejorar la capacidad de respuesta del sistema en general.
4. Respuesta de respaldo
Un patrón de respuesta de respaldo proporciona una respuesta predeterminada cuando un servicio no está disponible. APISIX le permite definir las prioridades del upstream cuando el punto final principal falla, el API Gateway puede redirigir el tráfico a un servicio secundario o devolver una respuesta predefinida utilizando un plugin response-rewrite en caso de fallos del servicio como HTTP 500.
O puede usar el plugin proxy-cache para almacenar en caché las respuestas y servirlas cuando el backend esté caído. Por ejemplo, la aplicación móvil muestra una lista de asistentes a la conferencia almacenada en caché cuando el servicio de asistente está caído.
5. Caché
El almacenamiento en caché de respuestas puede reducir significativamente la carga en sus servicios backend. APISIX ofrece un plugin proxy-cache que le permite almacenar en caché las respuestas y servirlas directamente desde el API Gateway, reduciendo la latencia y mejorando el rendimiento.
Consulte el tutorial Cache API responses para aprender cómo usar el plugin proxy-cache.
6. Redundancia
Cada API Gateway proporciona una característica común como el Balanceo de carga que distribuye las solicitudes de API entrantes entre múltiples servicios backend (nodos o instancias). Tener instancias redundantes hace que el sistema sea más robusto frente a esos eventos irregulares. APISIX admite varios algoritmos para el balanceo de carga, como round-robin, menos conexiones y hash consistente.
En el caso del servicio de asistente, puede iniciar dos instancias y si el servidor A falla, las solicitudes pueden ser atendidas por el segundo servidor.
7. Verificaciones de salud
La verificación de salud es un mecanismo que determina si los servicios upstream están saludables o no según su capacidad de respuesta. APISIX identifica si el servicio está disponible o no utilizando verificaciones de salud activas del upstream. Con las verificaciones de salud habilitadas, APISIX solo reenviará solicitudes a los servicios upstream que se consideren saludables, y no reenviará solicitudes a los servicios que se consideren no saludables.
Para verificar la salud de la API periódicamente, APISIX necesita una ruta HTTP del punto final de salud del servicio upstream. Por lo tanto, primero debe agregar el punto final /health para el servicio de asistente.
8. Cortocircuito
El patrón de cortocircuito evita que un sistema haga llamadas a un servicio que probablemente falle, protegiendo así al sistema de fallos en cascada. APISIX proporciona dos opciones para implementar la funcionalidad de cortocircuito: Usar un plugin api-breaker en una configuración de Ruta o habilitar verificaciones de salud pasivas del upstream. Ambas formas manejan fallos y evitan que los servicios upstream realicen intentos de reintento constantes si el servicio falla o funciona lentamente.
APISIX monitorea el número de fallos recientes que han ocurrido y utiliza esta información para decidir si permitir que la operación continúe o simplemente devolver una excepción de inmediato.
9. Compartimentación
El patrón de compartimentación aísla elementos dentro de una aplicación, asegurando que si una parte del sistema falla o está bajo carga pesada, las otras partes del sistema continúen funcionando. Para asegurar que el tráfico pesado o los problemas en las operaciones de lectura del servicio de asistente no afecten la disponibilidad y el rendimiento de las operaciones de escritura en el servicio de asistente, puede implementar el patrón de compartimentación utilizando APISIX.
Crea puntos finales de ruta separados en el API Gateway para dos nodos upstream para que todas las solicitudes de escritura se reenvíen al Servicio A y todas las solicitudes de lectura al Servicio B.
10. Pruebas de caos
Las pruebas de caos pueden ayudar a garantizar que una API sea resiliente en entornos de producción. Utilizándolas, puede evaluar y fortalecer la resiliencia de su aplicación o microservicios API frente a varios tipos de fallos, mejorando la confiabilidad. Este método permite la introducción intencional de retrasos y la terminación forzada de solicitudes con códigos de error designados, facilitando la simulación de varios escenarios adversos, incluyendo interrupciones del servicio, demanda excesiva del servicio, retrasos significativos en la red y segmentación de la red.
El Plugin de Inyección de Fallos de APISIX también ofrece el mismo mecanismo para simular varios escenarios de fallos como errores o retrasos en el servicio de asistente para probar cómo reacciona la aplicación cliente a ellos.
Conclusión
En esta publicación de blog, revisamos 10 patrones comunes de diseño de resiliencia de API, demostrando cómo implementarlos de manera efectiva utilizando APISIX. Al centralizar las estrategias de resiliencia a nivel del API Gateway, las organizaciones pueden lograr una gestión consistente, simplificada y eficiente del tráfico de API y el manejo de errores.