Si encuentras algún fallo en tu código o trabajo, recuerda probar siempre en un ambiente de testing antes aplicar el código al proyecto final.
Solución:
General
En general, el objetivo del patrón de mamparo es evitar fallas en una parte de un sistema para desmantelar todo el sistema. El término proviene de los barcos en los que un barco se divide en compartimentos estancos separados para evitar que una sola brecha en el casco inunde todo el barco; solo inundará un mamparo.
Las implementaciones del patrón de mamparo pueden tomar muchas formas según el tipo de fallas de las que desee proteger el sistema. Solo discutiré el tipo de fallas que maneja Hystrix en esta respuesta.
Creo que el patrón de mamparo fue popularizado por el libro. ¡Liberarlo! por Michael T. Nygard.
Qué resuelve Hystrix
La implementación del mamparo en Hystrix limita el número de llamadas simultáneas a un componente. De esta manera, la cantidad de recursos (normalmente subprocesos) que esperan una respuesta del componente es limitada.
Suponga que tiene una aplicación multiproceso basada en solicitudes (por ejemplo, una aplicación web típica) que utiliza tres componentes diferentes, A, B, y C. Si se solicita al componente C comienza a colgarse, eventualmente todos los subprocesos de manejo de solicitudes se quedarán esperando una respuesta de C. Esto haría que la aplicación no responda por completo. Si las solicitudes a C se maneja lentamente, tenemos un problema similar si la carga es lo suficientemente alta.
La implementación de Hystrix del patrón de mamparo limita la cantidad de llamadas simultáneas a un componente y habría salvado la aplicación en este caso. Supongamos que tenemos 30 subprocesos de manejo de solicitudes y hay un límite de 10 llamadas simultáneas a C. Entonces, como máximo, 10 subprocesos de manejo de solicitudes pueden colgarse al llamar C, los otros 20 subprocesos aún pueden manejar solicitudes y usar componentes A y B.
Los enfoques de Hystrix
Hystrix tiene dos enfoques diferentes para el mamparo, el aislamiento de subprocesos y el aislamiento de semáforos.
Aislamiento de subprocesos
El enfoque estándar es entregar todas las solicitudes al componente C a un grupo de subprocesos separado con un número fijo de subprocesos y ninguna (o una pequeña) cola de solicitudes.
Aislamiento de semáforo
El otro enfoque es hacer que todas las personas que llaman adquieran un permiso (con 0 tiempo de espera) antes de que se soliciten. C. Si no se puede adquirir un permiso desde el semáforo, llama a C no se traspasan.
diferencias
La ventaja del enfoque del grupo de subprocesos es que las solicitudes que se pasan a C se puede agotar el tiempo de espera, algo que no es posible cuando se utilizan semáforos.
Aquí hay un buen ejemplo con una explicación del tiempo de ejecución para el mamparo en Resilience4j que está inspirado en Netflix Hystrix.
Las configuraciones de ejemplo a continuación pueden dar cierta claridad de uso.
Configuraciones de ejemplo: permite un máximo de 5 llamadas simultáneas en un momento dado. Mantenga otras llamadas en espera hasta que finalice una de las 5 concurrentes en proceso o hasta un máximo de 2 segundos.
La idea es no sobrecargar ningún sistema con más carga de la que puede consumir. Si la carga entrante es mayor que el consumo, espere un tiempo razonable o simplemente se agote el tiempo de espera y busque una ruta alternativa.
Te mostramos las comentarios y valoraciones de los usuarios
Si para ti ha sido útil este artículo, te agradeceríamos que lo compartas con el resto entusiastas de la programación y nos ayudes a extender esta información.