Respuestas:
En general, el objetivo del patrón de mamparo es evitar fallas en una parte de un sistema para detener todo el sistema. El término proviene de barcos donde 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 dependiendo del 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 Release It! por Michael T. Nygard.
La implementación de mamparo en Hystrix limita el número de llamadas simultáneas a un componente . De esta forma, el número de recursos (normalmente subprocesos) que esperan una respuesta del componente es limitado.
Suponga que tiene una basada, aplicaciones multihilo (por ejemplo, una aplicación web típica) solicitar que utiliza tres componentes diferentes, A , B , y C . Si las solicitudes a componente C empieza a colgar, con el tiempo todos los gastos de envío de solicitud de hilos colgarán en la espera de una respuesta de C . Esto haría que la aplicación no respondiera por completo. Si las solicitudes a C se manejan lentamente, tenemos un problema similar si la carga es lo suficientemente alta.
La implementación de Hystrix del patrón de mamparo limita el número de llamadas simultáneas a un componente y habría salvado la aplicación en este caso. Asumamos que tenemos 30 hilos solicitud de manipulación y hay un límite de 10 llamadas simultáneas a C . Luego, en la mayoría de los hilos de manipulación 10 solicitud puede colgar al llamar C , los otros 20 hilos todavía pueden manejar las solicitudes y componentes de uso A y B .
Hystrix 'tiene dos enfoques diferentes para el mamparo, aislamiento de subprocesos y aislamiento de semáforos.
El enfoque estándar es transferir todas las solicitudes al componente C a un grupo de subprocesos separado con un número fijo de subprocesos y ninguna cola de solicitudes (o una pequeña).
El otro enfoque es tener todas las personas que llaman a adquirir un permiso (con 0 tiempo de espera) antes de peticiones a C . Si no se puede obtener un permiso del semáforo, las llamadas a C no se transfieren.
La ventaja del enfoque del grupo de subprocesos es que las solicitudes que se pasan a C pueden agotar el tiempo de espera, algo que no es posible cuando se usan 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 siguientes configuraciones de ejemplo pueden proporcionar cierta claridad de uso.
Configuraciones de ejemplo: Permita un máximo de 5 llamadas simultáneas en un momento dado. Mantenga otras llamadas esperando hasta que finalice una de las 5 llamadas simultáneas en proceso o hasta un máximo de 2 segundos.
La idea es no cargar 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 agote el tiempo de espera y busque una ruta alternativa.