En general, el objetivo del patrón de mamparo es evitar fallas en una parte de un sistema para derribar todo el sistema. El término proviene de los buques en los que un buque se divide en compartimentos estancos separados para evitar una brecha de un solo casco que inunde todo el buque; solo inundará un mamparo.
Las implementaciones del patrón de mamparo pueden adoptar 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.
Qué resuelve Hystrix
La implementación de mamparo en Hystrix limita el número de llamadas simultáneas a un componente. De esta manera, el número de recursos (típicamente subprocesos) que está esperando una respuesta del componente es limitado.
Suponga que tiene una aplicación multihilo basada en solicitudes (por ejemplo, una aplicación web típica) que utiliza tres componentes diferentes, A, B y C. Si las solicitudes al componente C comienzan a colgarse, eventualmente todos los subprocesos de manejo de solicitudes se colgarán en espera de una respuesta de C. Esto haría que la aplicación no respondiera por completo. Si las peticiones 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 guardado la aplicación en este caso. Supongamos que tenemos 30 subprocesos de manejo de solicitudes y que hay un límite de 10 llamadas simultáneas a C. Luego, como máximo, se pueden colgar 10 subprocesos de manejo de solicitudes al llamar a C, los otros 20 subprocesos aún pueden manejar solicitudes y usar los componentes A y B.
enfoques de Hystrix
Hystrix tiene dos enfoques diferentes para el mamparo, aislamiento de subprocesos y 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 sin (o una pequeña) cola de solicitudes.
Aislamiento de semáforos
El otro enfoque es hacer que todas las personas que llaman adquieran un permiso (con tiempo de espera 0) antes de las solicitudes a C. Si no se puede obtener un permiso del semáforo, las llamadas a C no se pasan.
Diferencias
La ventaja del enfoque de grupo de subprocesos es que las solicitudes que se pasan a C pueden agotarse, algo que no es posible cuando se usan semáforos.
