Microservicios Spring Cloud: Hystrix, Ribbon y Zuul.

Como continuación del anterior post dedicado a los nuevos microservicios que tan bien trabajan en los filter bubbles de Netflix, rematamos este who is who con estos "nuevos chicos en el barrio".

Hystrix

¿Qué es?

Hystrix es una librería que implemente el patrón CircuitBreaker. Hystrix nos permite gestionar las interacciones entre servicios en sistemas distribuidos añadiendo lógica de latencia y tolerancia a fallos.

Su finalidad es mejorar la fiabilidad global del sistema, para ello Hystrix aísla los puntos de acceso de los microservicios, impidiendo así los fallos en cascada a través de los diferentes componentes de la aplicación, proporcionando alternativas de “fallback”, gestionando timeouts, pools de hilos…

¿Cómo funciona?

Hystrix encapsula las peticiones a sistemas “externos” para gestionar diversos aspectos de éstas tales como: timeouts, estadísticas de éxito y fallo, semáforos, lógica de gestión de error, propagación de errores en cascada...

Así por ejemplo si una petición a un servicio alcanza un cierto límite (20 fallos en 5 segundos por defecto), Hystrix abrirá el circuito de forma que no se realizarán más peticiones a dicho servicio, lo que impedirá la propagación de los errores en cascada.

¿Qué aporta?

• Encapsula las peticiones a sistemas “externos” y las ejecuta dentro de un hilo separado. Esto es un ejemplo del “command pattern”.
• Se encarga de cancelar las peticiones que exceden el timeout que se les haya definido.
• Gestiona semáforos / pools de hilos para cada petición a sistema “externo”, de forma que si no hay hilos disponibles la petición será rechazada en lugar de encolada previniendo así esperas innecesarias (“failing fast instead of queueing”).
• Gestiona la propagación de errores en cascada.
• Mide estadísticas de peticiones exitosas, fallidas, timeouts…
• Gestiona las peticiones para que en caso de que un sistema externo exceda una cuota de error definida no se le deriven más peticiones.
• Gestiona la ejecución del “fallback” en caso de error en una petición para proteger al usuario del fallo.
• Proporciona un dashboard que integra las métricas capturadas donde se pueden observar número de peticiones exitosas, fallidas, timeouts, número de hilos, número de hosts, percentiles de tiempos de respuesta… en tiempo real de cada una de las peticiones gestionadas por Hystrix. Estas métricas en tiempo real nos permiten optimizar el “time­-to­-discovery” en caso de fallos.
• El flujo de datos de métricas generado por Hystrix puede ser interpretado por Turbine para agregar en un único dashboard las peticiones gestionadas por Hystrix de todos los microservicios de nuestro ecosistema.

Ribbon

¿Qué es?

Ribbon es una librería diseñada para la comunicación entre procesos en la nube que realiza balanceo de carga en el lado cliente. Cada uno de los balanceadores es parte de un conjunto de componentes que trabajan juntos para comunicarse con un servidor remoto bajo demanda.

Uno de los puntos clave de Ribbon es la posibilidad de integrarse con Eureka para el descubrimiento de las diferentes instancias de las que dispone un microservicio. Aunque Ribbon puede trabajar de forma autónoma, en este artículo nos centraremos en su funcionamiento integrado con Eureka.

¿Cómo funciona?

Cuando necesitamos invocar un microservicio, en primera instancia definiremos nuestra petición a dicho microservicio identificándolo por el nombre con el que se registra en Eureka. No será necesario pues identificar una instancia concreta del microservicio, ni la máquina en la que se encuentra, su IP o puerto.

Ribbon utilizará el nombre de microservicio que hemos indicado y consultará el registro de Eureka para recuperar cuantas instancias hay de ese microservicio y en qué máquinas se encuentran.

Con dicha información Ribbon ejecutará el algoritmo de balanceo de carga que tenga definido (Round Robin por defecto) para determinar a qué instancia del microservicio invocar.

Una vez decidida que instancia invocar, Ribbon encapsulará la petición dentro de un “Hystrix Command” y la realizará. La gestión de la petición será entonces realizada por Hystrix.

¿Qué aporta?

• Abstracción del número de instancias existentes, cuál es la invocada y su localización: al invocar a un microservicio por nombre no necesitamos saber el número de instancias disponibles, a cual de ellas estamos invocando ni la localización (IP o nombre de máquina) de la máquina en la que se está ejecutando.
• Dispone de diferentes implementaciones de algoritmos de balanceo: round robin, basados en tiempo de respuesta, aleatorios… además permite implementar tu propio algoritmo.
• Gestión de zonas: en entornos cloud (como AWS) Ribbon es capaz de distinguir diversas zonas, pudiendo ser configurado para invocar solo a los microservicios de su misma zona reduciendo así los costes de red y disminuyendo los tiempos de respuesta. Además puede detectar la salud de las instancias de la zona y dinámicamente evitar la zona “más problemática”.
• Gracias a su integración con Eureka puede detectar que instancias de microservicios están caídas y no derivarles peticiones.
• Permite configurar la realización de reintentos en las peticiones de forma automática en caso de fallo, así como indicar timeouts.
• Permite realizar peticiones de “warm up” para que los microservicios estén disponibles cuando las peticiones reales comiencen.
• Se integra con Hystrix para encapsular sus peticiones en un “Hystrix Command”, lo que nos aporta las ventajas propias de Hystrix.

Zuul

¿Qué es?

Zuul es un “edge service” que permite enrutado dinámico, balanceo de carga, monitorización y securización de peticiones. A efectos prácticos Zuul es un servidor compuesto por filtros, cada uno de los cuales está enfocado a una funcionalidad como pueden ser las anteriormente mencionadas.

¿Cómo funciona?

En una arquitectura de microservicios normalmente Zuul será configurado como el punto de entrada al ecosistema de microservicios y será el encargado de enrutar, balancear, securizar… las peticiones que reciban los microservicios.

Cada petición enviada a Zuul pasará por los filtros que lo componen que en función de las características de la petición pueden por ejemplo rechazarla por motivos de seguridad, registrarla con finalidades de monitorización, enrutarla a una determinada instancia de un microservicio… según los filtros configurados o los que nosotros mismos hayamos implementado.

Por defecto, Zuul utiliza Ribbon para localizar a través de Eureka las instancias de microservicio a la que derivar las peticiones que ejecutará dentro de un “Hystrix Command”, integrando así todos los componentes de la arquitectura y aprovechando todas la ventajas que proporciona el ecosistema spring­cloud.

Zuul también nos permite configurar el enrutamiento a los microservicios a través de properties, de forma que un microservicio no tendrá que ser invocado necesariamente por el nombre con el que ha sido registrado en Eureka.

Sin embargo esta funcionalidad de enrutamiento no utiliza los otros elementos de la arquitectura como Ribbon o Hystrix.

¿Que aporta?

• Proporciona un sistema que puede reaccionar de forma rápida cambiando su comportamiento ante diferentes situaciones problemáticas: esto se consigue a través de los diferentes filtros de los que está compuesto Zuul.
• Proporciona una serie de filtros para gestionar diferentes situaciones: filtros de autenticación y seguridad, filtros de monitorización, filtros para enrutado dinámico, filtros para tests de carga, filtros para gestión de recursos o respuestas estáticas, filtros para la gestión de multiregión...
• Permite la implementación de filtros personalizados y la carga de estos en caliente, lo que permite reequilibrar carga, redirigir peticiones, cancelarlas… cambiando el comportamiento en tiempo real sin necesidad de reiniciar el servidor. Esto se consigue gracias a que Zuul es capaz de compilar y ejecutar filtros en caliente sin necesidad de parar la aplicación. Así pues, por ejemplo se podría implementar un filtro que a partir de determinado momento enrutase una pequeña cantidad de peticiones a una instancia de microservicio con una nueva versión para poder así probarla.
• Al pasar todas las peticiones al ecosistema de microservicios a través de Zuul éste puede encargarse de realizar tareas comunes como gestión de CORS, autenticación… que de esta forma no se tendrán que realizar luego en cada uno de los microservicios.

En el tintero quedan otros elementos clave de este tipo nuevo de arquitecturas como son la gestión de logs, gestión de despliegue, monitorización, contenedores… pero eso es ya cuestión de otras entradas.

A modo de conclusión

Como hemos visto, todos estos componentes están diseñados para integrarse entre sí, conformando una nueva arquitectura, con alta disponibilidad, tolerancia a fallos… Arquitectura que ha sido probada en un entorno tan complejo y exigente como al que Netflix se enfrenta cada día con miles de millones de peticiones.

Arquitectura que integra plenamente los conceptos y filosofía del Cloud Computing. Arquitectura que Pivotal ha decidido incluir en Spring. Sin duda todo esto ha jugado a su favor permitiéndole situarse como referente, a la vanguardia de la nueva ola de tecnologías que la nube nos trae.

Así que no lo perdáis de vista, porque vamos a oír hablar mucho de microservicios y de Spring Cloud.

Fuentes

1. Documentación de Spring Cloud Netflix
2. Wiki oficial del desarrollo de Eureka
3. Página oficial del desarrollo de Cloud­-config
4. Wiki oficial del desarrollo de Hystrix
5. Wiki oficial del desarrollo de Ribbon
6. Wiki oficial del desarrollo de Zuul
7. Wiki oficial del desarrollo de Turbine
8. Wiki oficial del desarrollo de Asgard
9. CircuitBreaker por Martin Fowler
10. Command Pattern
11. Scalable Microservices at Netflix. Challenges and Tools of the Trade por Shudir Tonse