Si la semana pasada hablaba de que era importante tener sistemas estables para dormir tranquilos, hoy quiero mostrar una técnica no demasiado conocida pero bastante efectiva para aumentar la estabilidad de las aplicaciones: los disyuntores (circuit breakers).

Un disyuntor es un mecanismo capaz de abrir o cerrar un circuito eléctrico bajo determinadas circunstancias. Es lo que en España se conoce habitualmente como “automático” y es lo que “salta” cuando hay algún problema en la red eléctrica, por ejemplo cuando se intenta usar más potencia de la contratada o se conecta algún electrodoméstico defectuoso. Cuando “salta el automático”, se fuerza la apertura del circuito y se evita que los problemas se propaguen.

Cómo aplicar la idea al desarrollo de software

Cuando tenemos una aplicación que se integra con sistemas externos, estamos expuestos a que los fallos se propaguen de unos sistemas a otros, provocando reacciones en cadena cuyas consecuencias pueden ser bastante graves. Un disyuntor nos ayuda a evitar la propagación de errores de un sistema a otro, deteniendo así la reacción en cadena.

Un caso de uso típico para un disyuntor es controlar el acceso a un servidor externo.

Supongamos que tenemos un servidor que empieza a responder más despacio a las peticiones de los clientes. Al tardar más en atender cada petición, existe el riesgo de que se vayan acumulando peticiones, cada una de ellas introduciendo más carga en el servidor y amplificando el problema. Llegado un momento, el servidor puede llegar a caer por completo.

Desde el punto de vista del cliente, la situación no es mucho mejor. El servicio que recibe se va degradando paulatinamente hasta que se interrumpe totalmente. Además, se están consumiendo inutilmente recursos locales y esos recursos pueden ser limitados, como por ejemplo la batería en un teléfono móvil que se conecta a internet.

Funcionamiento de un Disyuntor

Un disyuntor nos permite minimizar problemas como el que acabo de contar. La forma más sencilla de entender un disyuntor es verlo como una máquina de estados:

• Cerrado: inicialmente, el disyuntor mantiene el circuito cerrado y permite que se realicen las operaciones, es decir, que se invoque al recurso externo. Cuando se producen N errores seguidos, se considera que el recurso externo no está accesible y se abre el circuito.
• Abierto: cuando el circuito está abierto, las llamadas al sistema remoto no se realizan, sino que fallan directamente. De esta forma se evita seguir cargando el sistema remoto y se evitan también costes locales (por ejemplo, el tiempo de espera antes de decidir que el sistema remoto no responde). Tras un tiempo prudencial, se pasa al estado Semi Abierto.
• Semi Abierto: en el estado Semi Abierto, la siguiente solicitud que se realice se enviará al sistema remoto para comprobar si ha vuelto a la vida. Si es así, el disyuntor pasa a estado Cerrado y vuelve a funcionar normalmente. Si no, vuelve a estado Abierto, iniciándose un nuevo periodo de espera.

Cómo implementarlo

La implementación de esto no es complicada y hay algunos ejemplos online de cómo implementar un disyuntor en C#. A la hora de implementarlo hay que tener en cuenta que normalmente el recurso externo que se está protegiendo con el disyuntor suele ser accedido desde varias hebras en el cliente, por lo que la implementación del disyuntor debe ser thread safe.

Normalmente se suele crear una implementación genérica, creando una clase que reciba un Action o un Func<T> e incorpore la lógica de apertura y cierre de circuito, pudiendo ser reutilizada con distintos servicios:

var service = new MyRemoteServiceProxy();
var breaker = new CircuitBreaker
{
    Timeout = TimeSpan.FromMinutes(2),
    ErrorThreshold = 5
};
var data = breaker.Get(() => service.GetDataFromRemoteServer());

Otra alternativa es utilizar decoradores sobre las clases que acceden a los servicios externos, o incluso emplear técnicas de AOP con interceptores como los que vimos hace poco.

En cualquier caso, lo recomendable es siempre aislar la lógica propia del disyuntor de la lógica de invocación al servicio que estamos controlando.

Conclusiones

Como todos los patrones de diseño, el disyuntor no es más que la formalización de soluciones aplicadas frecuentemente durante el desarrollo y seguramente lo hayas aplicado más de una vez sin darle nombre. La ventaja de formalizarlo es que permite reutilizar la solución en distintos contextos.

Es una técnica interesante y bonita por su simplicidad, y su uso nos permite proteger un sistema de fallos en sus colaboradores mejorando la estabilidad global.

Tener un sistema sólido no depende de un único factor, pero es la suma de muchos pequeños factores cómo este (y algunos no tan pequeños) la que hará que todo funcione o se caiga a las primeras de cambio.