Bulkhead, el patrón para cuidar los µservicios

El diseño de los microservicios debe lograr una arquitectura desacoplada y que los errores / problemas de un sistema afecten lo menos posible a otros.

El patrón de mamparos (bulkhead en inglés), tiene como objetivo aumentar la resistencia del sistema con un diseño de microservicios enfocado a ello.

Un microservicio puede tener múltiples consumidores, o puede darse el escenario en que la carga posible que soporte un microservicio sea menor que el total que un servicio superior le pueda solicitar.

El esquema de funcionamiento de una aplicación autocontenida en un servidor web que recibe solicitudes HTTP y debe llamar a otra, normalmente se basa en realizar tantas llamadas al servicio de abajo como sean necesarias para completar su trabajo.

Veamos el siguiente gráfico.

En el escenario anterior, puede ocurrir que el MS2 demore en realizar sus operaciones y/o llegue a un estado de ocupado (HTTP 502); ante la llegada de más peticiones que demandan acceder a MS2 se destinarán más hilos en MS1. Cuando los recursos de MS1 se terminen tratando de atender a MS2 (que está no disponible) se provocará un fallo en MS1.

Si retomamos la figura anterior MS1 realizaba operaciones sobre MS2 y MS3, pero al destinar recursos que quedaban ocupados por MS2 se produjo un fallo escalonado cuando pudo haberse evitado siguiendo una estrategia de diseño centrada en el patrón bulkhead.

Patrón bulkhead

Bulkhead aumenta la resistencia, evitando que fallos en un servicio/instancia produzcan la caída total del sistema.

Bulkhead propone separar en grupos (pools) el número de recursos que se dedican para llamar a una instancia de servicio, si el servicio llamado falla no se destinarán recursos innecesarios, evitando la falla en cascada del sistema.

Libro: Patrones para la implementación de una arquitectura basada microservicios

La implementación de bulkhead, desde el punto de vista gráfico puede verse como se muestra a continuación.

Cuando se diseña un sistema que usa sistemas subyacentes debe tenerse en cuenta aplicar Bulkhead, ello es aplicable a conexiones a bases de datos, llamadas servicio → servicio, y cualquier otro tipo de comunicación que pueda tener lugar.

Bulkhead se complementa con otros patrones de resiliencia como Retry, Circuit Breaker, Rate Limiter y Timeout limiter.

Particularmente Bulkhead puede ser implementado en las llamadas servicio → servicio de forma sencilla en Java usando Hystrix (implementación del patrón Circuit Breaker); se define un HystrixCommand en el que se define un pool que permite indicar la cantidad de hilos que pueden estar en ejecución, el número de llamadas a encolar, y otro grupo de configuraciones que no detallaremos acá.

Otra tecnología Java que permite esta implementación de forma sencilla es Resilience4j, de la que estaremos posteando más adelante.

En cuanto a las tecnologías de conexión a bases de datos puede usarse, en el lenguaje Java por ejemplo: HickariCP y C3P0.

¿Cuándo usar este patrón?

Este patrón debe emplearse en los siguientes escenarios:

  • En los consumidores críticos del sistema (mayor demanda) para una mejor protección.
  • En consumidores que tengan que acceder a múltiples servicios backend, especialmente si alguno de los servicios inferiores tiene probabilidades de fallo.
  • En sistema que acceden a sistemas legados y/o APIs de terceros que son particularmente sensibles a fallos o cuyo funcionamiento no depende directamente del equipo de desarrollo

Espero te sea útil el artículo, implementa Bulkhead y construye sistemas más resistentes.

5 comentarios en «Bulkhead, el patrón para cuidar los µservicios»

  • el 12 de junio de 2020 a las 04:58
    Enlace permanente

    Interesante, tema. Con las arquitecturas en microservicios surgen un grupo de temas como este, que en ocaciones no visualizamos hasta que se produce un problema.
    Aprovecho la oportunidad para comentarte si puedes exponer tu experiencia sobre la seguridad en los microservicios. Ahora mismo estoy buscando una estrategia para una solución que estamos diseñando. Busco una solución que me permita propagar el contexto de seguridad. Saludos

    Respuesta
  • el 12 de junio de 2020 a las 17:00
    Enlace permanente

    Hola Rolando, que tal estas, gracias por seguir el blog ! Prepararemos una entrada del tema, pero en realidad lo hemos hecho con Oauth2, y en ocasiones lo que hacemos es en el EDGE (Zuul) verificamos algunas cuestiones de seguridad.

    Ahora tenemos próximamente otro tema de resiliencia pre-preparado (resilience4j), luego trataremos seguridad.

    Respuesta
    • el 13 de junio de 2020 a las 00:51
      Enlace permanente

      Excelente, basicamente estoy viendo Zuul y la implementación que ofrece el equipo de jhipster para la seguridad. Saludos

      Respuesta
      • el 13 de junio de 2020 a las 03:36
        Enlace permanente

        Esa es buena Rolando, aprendí mucho viendo código de jhipster. Gracias Yoandy, he adquirido tu libro, he aprendido pila, me gusto mucho como abordas la transaccionalidad.

        Respuesta
  • Pingback: Resilience4j, tolerancia a fallos completa - Tech Blog - SACAViX

Deja una respuesta

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

SACAViX Tech