Compartir a través de

Estrategias para controlar errores parciales

Sugerencia

Este contenido es un extracto del libro electrónico, ".NET Microservices Architecture for Containerized .NET Applications" (Arquitectura de microservicios de .NET para aplicaciones de .NET contenedorizadas), disponible en Documentación de .NET o como un PDF descargable y gratuito que se puede leer sin conexión.

Descargar PDF

Miniatura de la portada del libro electrónico 'Arquitectura de microservicios de .NET para aplicaciones .NET contenedorizadas'.

Para tratar los errores parciales, use una de las estrategias que se describen aquí.

Use la comunicación asincrónica (por ejemplo, comunicación basada en mensajes) en microservicios internos. Es muy recomendable no crear cadenas largas de llamadas HTTP sincrónicas en los microservicios internos, ya que ese diseño incorrecto se convertirá finalmente en la causa principal de interrupciones incorrectas. Por el contrario, excepto para las comunicaciones front-end entre las aplicaciones cliente y el primer nivel de microservicios o puertas de enlace de API específicas, se recomienda usar solo la comunicación asincrónica (basada en mensajes) una vez pasado el ciclo inicial de solicitud/respuesta, en los microservicios internos. La coherencia final y las arquitecturas controladas por eventos ayudarán a minimizar los efectos de onda. Estos enfoques aplican un mayor nivel de autonomía de microservicios y, por tanto, impiden el problema que se indica aquí.

Usar reintentos con retroceso exponencial. Esta técnica ayuda a evitar errores cortos e intermitentes realizando reintentos de llamada un número determinado de veces, en caso de que el servicio no estuviera disponible solo durante un breve tiempo. Esto puede producirse debido a problemas de red intermitentes o cuando un microservicio o contenedor se mueve a un nodo diferente de un clúster. Pero si estos intentos no se diseñan correctamente con interruptores, pueden agravar el efecto dominó e incluso pueden llegar a producir un ataque por denegación de servicio (DoS).

Solucionar los tiempos de expiración de red. En general, los clientes deben diseñarse para que no se bloqueen indefinidamente y para que usen siempre los tiempos de expiración cuando esperen una respuesta. El uso de tiempos de espera garantiza que los recursos nunca estén vinculados indefinidamente.

Utiliza el patrón Circuit Breaker. En este enfoque, el proceso de cliente realiza un seguimiento del número de solicitudes con error. Si la tasa de errores supera el límite establecido, se activa un "interruptor" para que los intentos adicionales fallen de inmediato. (Si se produce un error en un gran número de solicitudes, esto sugiere que el servicio no está disponible y que el envío de solicitudes no tiene sentido). Después de un período de tiempo de espera, el cliente debe intentarlo de nuevo y, si las nuevas solicitudes se realizan correctamente, cierre el disyuntor.

Proporcione alternativas. En este enfoque, el proceso de cliente realiza la lógica de reserva cuando se produce un error en una solicitud, como devolver datos almacenados en caché o un valor predeterminado. Se trata de un enfoque adecuado para las consultas y es más complejo para las actualizaciones o comandos.

Limite el número de solicitudes en cola. Los clientes también deben imponer un límite superior en el número de solicitudes pendientes que un microservicio de cliente puede enviar a un servicio determinado. Si se ha alcanzado el límite, es probable que no tenga sentido realizar solicitudes adicionales y esos intentos deben producir un error inmediatamente. En cuanto a la implementación, la directiva Aislamiento compartimentado de Polly se puede usar para cumplir este requisito. Este enfoque es básicamente una limitación en paralelo con SemaphoreSlim como implementación. También admite una "cola" fuera de la mampara. Puede perder proactivamente una carga excesiva incluso antes de la ejecución (por ejemplo, porque se considera que ha llegado al límite de su capacidad). Esto hace que su respuesta a determinados escenarios de error sea más rápida que la de un disyuntor, ya que este espera a los fallos. El objeto BulkheadPolicy de Polly expone hasta qué punto están llenos el espacio limitado por la mampara y la cola, y ofrece eventos sobre desbordamiento para que también se puedan utilizar para administrar un escalado horizontal automatizado.

Recursos adicionales

Siguiente anterior