Compartir a través de


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.

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

En sistemas distribuidos, como las aplicaciones basadas en microservicios, existe un riesgo de error parcial. Por ejemplo, un único microservicio o contenedor puede producir un error o no estar disponible para responder durante un breve tiempo, o una sola máquina virtual o servidor puede bloquearse. Dado que los clientes y los servicios son procesos independientes, es posible que un servicio no pueda responder de forma oportuna a la solicitud de un cliente. Es posible que el servicio se sobrecargue y responda muy lentamente a las solicitudes o que simplemente no sea accesible durante un breve tiempo debido a problemas de red.

Por ejemplo, considere la página de detalles del pedido de la aplicación de ejemplo eShopOnContainers. Si el microservicio de ordenación no responde cuando el usuario intenta enviar un pedido, una implementación incorrecta del proceso de cliente (la aplicación web MVC), por ejemplo, si el código de cliente usara RPCs sincrónicas sin tiempo de espera, bloquearía los subprocesos indefinidamente esperando una respuesta. Además de crear una mala experiencia del usuario, cada espera que no responde consume o bloquea un subproceso, y los subprocesos son extremadamente valiosos en aplicaciones altamente escalables. Si hay muchos subprocesos bloqueados, eventualmente el tiempo de ejecución de la aplicación puede quedarse sin subprocesos. En ese caso, la aplicación puede dejar de responder globalmente en lugar de simplemente no responder parcialmente, como se muestra en la figura 8-1.

Diagrama que muestra errores parciales.

Figura 8-1. Errores parciales debido a dependencias que afectan a la disponibilidad del subproceso de servicio

En una aplicación basada en microservicios de gran tamaño, se puede amplificar cualquier error parcial, especialmente si la mayoría de la interacción interna de microservicios se basa en llamadas HTTP sincrónicas (que se considera un antipatrón). Piense en un sistema que recibe millones de llamadas entrantes al día. Si el sistema tiene un diseño incorrecto basado en cadenas largas de llamadas HTTP sincrónicas, estas llamadas entrantes podrían dar lugar a muchos más millones de llamadas salientes (supongamos una relación de 1:4) a docenas de microservicios internos como dependencias sincrónicas. Esta situación se muestra en la figura 8-2, especialmente la dependencia 3, que inicia una cadena, llamando a dependency #4, que luego llama a #5.

Diagrama que muestra varias dependencias distribuidas.

Figura 8-2. El impacto de tener un diseño incorrecto que incluye cadenas largas de solicitudes HTTP

Se garantiza un error intermitente en un sistema distribuido y basado en la nube, incluso si cada dependencia tiene una excelente disponibilidad. Es un hecho que debes tener en cuenta.

Si no diseña ni implementa técnicas para asegurar la tolerancia a errores, incluso se pueden magnificar los pequeños tiempos de inactividad. Por ejemplo, 50 dependencias cada una con 99,99% de disponibilidad daría como resultado varias horas de tiempo de inactividad cada mes debido a este efecto de onda. Cuando se produce un error en una dependencia de microservicio al controlar un gran volumen de solicitudes, ese error puede saturar rápidamente todos los subprocesos de solicitud disponibles en cada servicio y bloquear toda la aplicación.

Diagrama que muestra un error parcial amplificado en microservicios.

Figura 8-3. Error parcial amplificado por microservicios con cadenas largas de llamadas HTTP sincrónicas

Para minimizar este problema, en la sección Integración asincrónica de microservicios exige la autonomía del microservicio, esta guía le anima a usar la comunicación asincrónica entre los microservicios internos.

Además, es esencial diseñar los microservicios y las aplicaciones cliente para controlar errores parciales, es decir, crear microservicios resistentes y aplicaciones cliente.