Proxy para microservicios con Spring Cloud Netflix y Zuul

Escrito por picodotdev el .
java planeta-codigo programacion
Comentarios

Spring
Java

Teniendo una buen número de microservicios con múltiples instancias ofreciendo cada uno una API y en una ubicación diferente para simplificar la visión de los que actúen clientes de los microservicios se puede utilizar un proxy. Con un proxy es posible centralizar todas las peticiones, que sea éste el encargado de conocer la ubicación de todas las instancias de los microservicios y de hacer la llamada allí donde se encuentre cada una de ellas.

Entre las varias funcionalidades que proporcionar el proyecto Spring Cloud Netflix es esta de proxy mediante Zuul. Para hacer de proxy Zuul necesita tener una correspondencia entre URLs y servicios que realmente proporcionan la funcionalidad, una forma que tiene Zuul de conocer la ubicación de las instancias es utilizando el servicio de registro y descubrimiento Eureka. Además, Zuul como cliente de los microservicios posee la funcionalidad de Hystrix que implementa el patrón circuit breaker para tolerancia a fallos, Ribbon para hacer balanceo de carga entre varias instancias de los microservicios a nivel de servidor además de reintentos cuando una instancia falla.

En el ejemplo que he utilizado para esta serie de artículos sobre Spring Cloud hay un servicio que por defecto se inicia en el puerto 8080 y ofrece un endpoint / que devuelve un mensaje. Para crear un microservicio proxy con Zuul hay que crear una aplicación Spring Boot anotar la clase principal con la anotación @EnableZuulProxy y proporcionar la configuración para la correspondencia de rutas y microservicios, además de las propiedades para hacer reintentos en caso de que un microservicio falle y de timeouts en caso de que se comporte no como se espera en cuanto tiempos de respuesta.

Se puede establecer un tiempo máximo para establecer la conexión, de tiempo de petición, el número de reintentos en la misma instancia si falla o en otro número de instancias, el número máximo de conexiones y el número máximo de conexiones al mismo host. Todas ellas definibles en cada servicio de forma individual bajo las propiedades hystrix.command.service y service.ribbon donde service es el identificativo del servicio. Las rutas se indican bajo la propiedad zuul.routes con la relación identificativo del servicio y path.

Dado que Zuul es un proxy para múltiples instancias de microservicios a cada microservicio hay que darle una ruta, cuando Zuul realiza la llamada a una instancia del microservicio se encarga de omitirla. En el ejemplo, la ruta en Zuul /service/** está asociada al microservicio service pero el servicio service ofrece su endpoint en /, Zuul se encarga de omitir la parte de la ruta para el proxy y hace la llamada a la ruta / como espera el microservicio.

Lógicamente los clientes deben contactar con el proxy en vez de con el microservicio directamente. Arrancado el servicio de descubrimiento y registro Eureka, el servidor de configuración de Spring Cloud, dos instancias del servicio y el proxy con Zuul haciendo las llamadas al proxy se observa que se obtiene el resultado del microservicio. Como en el ejemplo hay varias instancias del servicio Zuul realiza balanceo de carga entre ellas con Ribbon utilizando la política round-robin y el mensaje es diferente en cada una de las respuestas según la instancia invocada. Con Zuul además se consigue balanceo de carga a nivel de servidor que Ribbon solo ofrece a nivel de cliente.

Las URLs del servicio en el microservicio y en el proxy son.

El cliente de ejemplo realiza peticiones al proxy, en la salida se muestra el resultado del balanceo de carga cuando hay varias instancias, cuando se añade una nueva instancia entra a formar parte del balanceo de carga. Otro beneficio de Zuul es que ofrece la funcionalidad de reintentos de modo que si una instancia de un servicio falla la petición se reintenta en otra. En el artículo Balanceo de carga y resilencia en un microservicio con Spring Cloud Netflix y Ribbon usando solo Ribbon se observaba que cuando una instancia falla se le siguen haciendo peticiones hasta que la lista de instancias del servicio en Eureka se actualiza quitando la fallida, con Hystrix se obtiene la respuesta fallback pero no se evita completamente el error. Zuul puede ocultar el error provocado por una instancia que falla reintentado la petición en la misma nuevamente, en otra u otras instancias según se configure. El comportamiento con Zuul cuando una instancia falla se puede comparar con el comportamiento incluido en el artículo anterior usando en el cliente los microservicios directamente.

Zuul además es capaz de proporciona otras muchas funcionalidades como:

  • Autenticación
  • Seguridad
  • Recolección de métricas y monitorización
  • Pruebas de carga
  • Pruebas de verificación o canary testing
  • Enrutado dinámico
  • Migración de servicio
  • Abandono de carga o load shedding
  • Manejo de respuesta estática
  • Gestión de tráfico active/active

El código fuente completo del ejemplo puedes descargarlo del repositorio de ejemplos de Blog Bitix alojado en GitHub y probarlo en tu equipo ejecutando el comando ./gradlew-run.sh.