La llegada de nuevas arquitecturas como SOA o Microservicios han traído grandes ventajas, pero con ello, han surgido nuevas problemáticas que pocas veces se saben resolver con precisión, uno de estos casos, es identificar cuando un servicio ha dejado de funcionar para dejarle de enviar peticiones, pero por otro lado, identificar el fallo, reportarlo y hacer algo en consecuencia, por suerte, la patrón Circuit Breaker (Corto circuito) permite cortar la comunicación con un determinado servicio cuando se ha detectado que está fallado, evitando así, que el sistema continúe fallando.
Problemática
Uno de los problemas más común en arquitecturas distribuidas es que, algunos de los componentes comiencen a fallar, lo que esto puede implicas desde que dejemos de realizar ventas, hasta detener la operación por completo, por lo que tener un plan B en caso de que algo falle siempre es recomendable, sobre todo en proceso críticos.
En la práctica es común que cuando algo falla, simplemente le mostremos un error al usuario de que algo salió mal y que lo intente más tarde, pero que pasa que si eso que salió mal es precisamente una venta, ¿es acaso que estamos dispuestos a dejar pasar esa venta? Lo más seguro es que no, he intentaremos hacer lo posible por completarla, pero ¿cómo si el sistema está fallando?
Invocaciones condenadas a fallar
Ahora bien, si este componente está fallando, cual es el sentido se seguirle enviando peticiones, si ya sabemos de antemano que va a fallar, además, si ya está fallando, el enviarle más peticiones puede hacer que agrave la situación.
Imagina un servicio que está dejando de responder y nos arroja tiempo de espera agotado, este servidor puede que dejó de responder por una carga excesiva de peticiones, lo que está haciendo que responda muy lento. Ahora bien, si sabemos que el servicio está saturado, y le seguimos enviando peticiones, eventualmente lo terminaremos de rematar, lo que puede hacer que termine callándose. Entonces, si ya sabemos que el servicio va a fallar, ¿no sería más inteligente dejar de mandarle peticiones y ejecutar un plan B en lo que el servicio se repone?
Solución
El patrón Circuit Breaker es muy parecido a un fusible, el cual se funde para evitar que una descarga eléctrica afecte al circuito, con la única diferencia de que el software, este fusible se puede restaurar cuando el problema allá pasado. Esto puede resultar un poco confuso, pero analicemos cómo funciona el patrón con el siguiente diagrama:
Diagrama de secuencia del Circuit Breaker
Antes de explicar cómo funciona el diagrama, debemos de comprender que son y el rol que tiene cada uno de los componentes involucrados:
Supplier: representa el servicio de negocio remoto, el cual expone una serie de funcionalidad para ser consumida por el Client.
Client: representa al cliente que intenta consumir los servicios del Supplier, sin embargo, este lo hace por medio del Circuit Breaker.
Circuit Breaker: es el componente que se encarga de la comunicación con el Supplier, el cual, mantiene un registro del estado de salud del servicio que usará para abrir el circuito cuando detecte que el Supplier está fallando.
Conclusiones
Como hemos analizado, utilizar el patrón Circuit Breaker impide que inundemos nuestra aplicación con una gran cantidad de solicitudes que sabemos de antemano que van a fallar, por lo que, en lugar de eso, evitamos la llamada e incluso, podemos hacer una acción en consecuencia.
Este patrón es muy utilizado en procesos críticos, donde no podemos darnos el lujo de cancelar la operación y regresar un error al cliente, sino al contrario, tratamos de proporcionar el servicio, aunque tengamos de una forma diferente.
Acerca de este libro
Todo lo que acabas de ver en este artículo es solo una pequeña parte del libro Introducción a la arquitectura de software, el libro más completo en español sobre arquitectura de software, donde cubrimos los temas más importantes para convertirte en un arquitecto de software profesional.
¿Quieres convertirte en arquitecto de software pero no sabes cuál es el camino adecuando? o simplemente no sabes que guía estudiar para convertirte en arquitecto de software, te invito a que veas mi libro:
