Apache Camel y Hystrix: Como mejorar la resiliencia en microservicios

Hoy vamos uno de los patrones para mejorar la resiliencia de los micro servicios. En este caso concreto, será el patrón Circuit Breaker. Y podremos verlo aplicado a un micro servicio con Apache Camel a través de Hystrix. 

Como siempre empezaremos con un poco de teoría. Vamos a explicar que es el patrón Circuit Breaker y cual es su funcionalidad. Este patrón se basa en la idea de que algunas intercomunicaciones dentro del micro servicio pueden fallar. Pero al seguir funcionando la lógica normal, se pierde tiempo y recursos en hacer llamadas que posiblemente sean infructuosas. La idea del patrón es monitorizar el servicio externo al que vamos a invocar, para en caso de cualquier error, redirigir el flujo a otro servicio o lógica de negocio que nos haga mantener a nuestro micro servicio operativo y con baja latencia. 

Este patrón basa su funcionamiento en el control de estados del propio circuito. Contando con tres estados diferentes:

• Cerrado: Circuito operativo, todo funciona correctamente.
• Abierto: Circuito defectuoso. Se redirige el flujo hacia otro lado, permitiendo la perdida de recursos y seguir ofreciendo servicio. 
• Semi-abierto: Estado intermedio que se encargará de comprobar si el servicio externo se encuentra o no disponible y si mantiene el circuito abierto o lo cierra. 

Resumiendo mucho, el patrón circuit breaker actuará como un proxy que nos permitirá comprobar si el servicio externo se encuentra funcionando antes de realizar la llamada a dicho sistema, para poder ahorrarnos recursos y tiempo. 

Dentro de Apache Camel, hay tres implementaciones para llevar a cabo dicho patrón. Estas son:

• Hystrix: Librería de Netflix sobre la que basaremos el ejemplo. Actualmente (05/2021) ya no se encuentra en desarrollo y si en estado de mantenimiento. 
• Resilience4j: Librería basada en Hystrix y orientada a la implementación de varios patrones para la implementación de la resiliencia.
• MicroProfile Fault Tolerance: Librería de la fundación Eclipse para la implementación de patrones de resiliencia. 

Por tanto el uso a nivel de código del patrón Circuit Breaker será igual independientemente de la librería que seleccionemos para su implementación. Lo único que cambiará será librería que indiquemos como dependencia y la configuración de la misma. 

<dependency>
	<groupId>org.apache.camel.springboot</groupId>
	<artifactId>camel-hystrix-starter</artifactId>
</dependency>

Para el caso de Hystrix hay hasta 31 opciones de configuración que podemos introducir en el fichero de configuración de la aplicación de Apache Camel: application.properties. 

Para nuestro ejemplo modificaremos algunas opciones. De esta forma no tendremos que hacer tantas invocaciones para apreciar el funcionamiento del patrón Circuit Breaker. Estas opciones son: 

• circuitBreakerErrorThresholdPercentage: Porcentaje de error a partir del cual considera el circuito abierto y no acepta invocaciones.
• circuitBreakerSleepWindowInMilliseconds: Tiempo a pasar antes de volver a aceptar peticiones.
• metricsRollingStatisticalWindowInMilliseconds: Tiempo de duracion de las métricas asociadas.
• circuitBreakerRequestVolumeThreshold: Número mínimo de request a existir durante la duración de las métricas. Si no se alcanza este número mínimo de invocaciones no se considerará el circuito abierto, independientemente del porcentaje de error.  

Como hemos hecho referencia en el punto anterior, hay otro punto a destacar. Este son las métricas asociadas a la ejecución de nuestro micro servicio. En función a estas métricas y los valores de configuración, se decidirá el estado del circuito y como se debe actuar. 

Si utilizamos Spring en nuestra aplicación de Apache Camel, podemos acceder a esas métricas fácilmente a través de la URL /hystrix.stream.

Ahora pasaremos al primer ejemplo. Para llevarlo a cabo nos basaremos en ejemplos que hemos realizado anteriormente y que puedes ver aquí. En este ejemplo, invocaremos a una BBDD (la cual levantaremos con docker-compose). En función de si la BBDD se encuentra operativa o no, devolveremos uno u otro resultado. En el caso de que no hay BBDD, simplemente devolveremos un conjunto vacío. 

A través del método circuitBreaker indicaremos que vamos a implementar dicho patrón. Seguidamente podemos indicar si vamos a utilizar alguna configuración, en caso de que no indiquemos ninguna será utilizada la de por defecto. Debemos indicar una ruta a la que redirigir la llamada, que será la de nuestro servicio externo, en este caso la BBDD. Y debemos indicar que vamos a hacer en caso de error, para este caso enviaremos siempre el mismo resultado, lo cual podemos indicarlo a través del método onFallback. Y por último indicar que se termina la lógica asociada al circuit breaker. 

@Component
public class BookHystrixRouter extends RouteBuilder {
    @Override
    public void configure() throws Exception {
	restConfiguration().component("servlet").bindingMode(RestBindingMode.json_xml);

	rest().get("hystrix/sql").produces(MediaType.APPLICATION_JSON_VALUE)

		.route().circuitBreaker().id("hystrix/sql")
		.to("sql:{{sql.selectAll}}").onFallback()

		.setBody(bodyAs(ArrayList.class)).endCircuitBreaker()
		.log("--- SQL select all books---");
    }
}

Si levantamos el docker-compose, la aplicación y realizamos invocaciones a la siguiente URL, podremos ver como obtenemos de forma correcta todos los libros de la BBDD.

curl --location --request GET 'http://localhost:9090/hystrix/sql'

Una vez arrancada la aplicación, podemos acceder al Portainer, a través de la URL http://localhost:9000, y parar el contenedor de MySQL. En ese momento podremos volver a invocar a la aplicación y ver como las llamadas devuelven un conjunto vacío de elementos. 

El método onFallback nos permite responder un mensaje de forma inmediata, pero si lo que queremos hacer es reenviar la llamada a otro servicio externo para ello deberemos utilizar el método onFallbackViaNetwork. 

En el siguiente ejemplo que invoca a un Wiremock podremos comprobar esta segunda invocación. Además también nos permitirá visualizar a través de la consola del Wiremock si cuando el circuito se encuentra abierto, se sigue invocando o no al primer servicio. Aspecto que nos era más difícil de verificar con el contenedor de MySQL. 

Por ello crearemos un mapping para Wiremock que responda al path /book con la misma respuesta que devuelve la BBDD. Y nuestro ejemplo intentará invocar al path /fail, que al no existir siempre fallará y posteriormente invocará a /book. 

rest().get("hystrix/fail").produces(MediaType.APPLICATION_JSON_VALUE).route()

	.circuitBreaker().id("hystrix/fail")

	.toD("http://localhost:57001/fail?bridgeEndpoint=true").onFallbackViaNetwork()

	.toD("http://localhost:57001/book?bridgeEndpoint=true").end().unmarshal().json()
	.log("--- Wiremock select all books---");

Si invocamos al servicio y a la misma vez consultamos la consola del Wiremock, podremos ver como primero llama a un servicio y luego al otro. Devolviéndonos nuestro microservicio un listado de libros, como hacía el método anterior. 

curl --location --request GET 'http://localhost:9090/hystrix/fail'

Y en base a la configuración anteriormente indicada, si realizamos un conjunto elevado de llamadas. Podremos visualizar en la consola de Wiremock, como cuando el circuito se encuentra abierto, no se realizan llamadas al primer servicio. 

Por último indicar, que en versiones anteriores de Spring existía la dependencia spring-cloud-starter-hystrix-dashboard que generaba un dashboard para la visualización de las métricas de Hystrix. Pero la cual no es compatible con las versiones actuales de Spring y utilizadas en este ejemplo. En vez de usar esa librería, utilizaremos una imagen de docker llamada mlabouardy/hystrix-dashboard que nos permitirá acceder a dicho dashboard.  

Para ello debemos arrancar la imagen en el puerto 8080 y acceder a la URL: http://localhost:8080/hystrix. El siguiente paso será indicar la URL donde Hystrix esta mostrando las métricas. Hay que tener en cuenta, que si la aplicación de Apache Camel no esta siendo lanzada a través de una imagen en la misma red que la del dashboard deberemos indicar la URL de la siguiente forma en sistemas Windows o Mac: http://host.docker.internal:9090/hystrix.stream. A continuación un ejemplo de como se pueden visualizar dichas métricas con la ayuda de esta imagen:

Esto es todo, amigos. Ya hemos aprendido un poco más sobre resiliencia orientado a micro servicios y como hacerlo funcionar fácilmente en nuestra aplicación de Apache Camel. Si quieres acceso al código, lo tienes aquí.