Saltar al contenido

¿Qué es el patrón Bulkhead utilizado por Hystrix?

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.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *