Previamente, en posts anteriores hemos identificado los componentes clave de la arquitectura de microservicios de Spring Cloud y Netflix y hemos profundizado en las posibilidades que Eureka como microservicio de descubrimiento nos proporciona. En este post analizaremos a fondo Ribbon, la librería encargadade realizar el balanceo de carga en cliente.

Eureka se adorna con la cinta de Ribbon

Como hemos hecho en entradas anteriores, analizaremos Ribbon integrado con Eureka para el hallazgo de las instancias que componen un microservicio, conformando así una arquitectura de microservicios como la mencionada.

Configuración inicial y funcionamiento

En este primer apartado vamos a ejemplificar una configuración y funcionamiento sencilla de Ribbon. Para ello contaremos con dos microservicios funcionales con un total de tres instancias:

MicroS4 1 390

Cuando desde customer-backend se desee realizar una petición a security lo que ocurrirá será lo siguiente:

  1. Ribbon en cuanto recibe una petición a un sistema externo solicitará a Eureka el registro de microservicios (en la práctica esta consulta no se realiza ya que customer-backend al ser un eureka-client dispondrá de una caché local con el registro que se actualiza cada 30 segundos; este es el comportamiento por defecto).
  2. Ribbon con la información del registro disponible utiliza su balanceador y reglas de balanceo para decidir a qué instancia de security enviar la petición.

Configurar Ribbon es realmente sencillo si estamos trabajando con spring-boot y spring-cloud-netflix. Al añadir la dependencia de spring-cloud-starter-eureka esta incluirá las librerías de Ribbon. A continuación se muestra la dependencia de Eureka:

MicroS4 2

Y si navegamos por los poms del spring-cloud-starter-eureka podremos ver que incluye las siguientes dependencias de Ribbon:

MicroS4 3

Una vez incluidas las dependencias en nuestro proyecto, solo deberemos inyectarnos la instancia de RestTemplate. Durante su configuración en la clase LoadBalancerAutoConfiguration se creará una instancia de RestTemplate a la que le setea un RibbonLoadBalancerClient como interceptor, de forma que todas las peticiones realizadas con el RestTemplate pasarán por él. RibbonLoadBalancerClient se encargará de utilizar el balanceador configurado para obtener la instancia final a la que se enviará la petición.

MicroS4 4

En este caso podemos ver cómo se indica el nombre del microservicio security directamente. RibbonLoadBalancerClient como interceptor será el encargado de reconstruir la URL sustituyendo el nombre del microservicio por la instancia concreta que se haya seleccionado para esta petición. Además se encargará de recoger las estadísticas sobre la ejecución de las peticiones.

Arquitectura de Ribbon

Ribbon utiliza básicamente dos elementos a la hora de decidir cuál será la instancia a la que finalmente derivará la petición, estos dos elementos son los balanceadores (con sus filtros asociados) y las reglas.

Así, en primer lugar Ribbon utilizará un balanceador y filtros para descartar una serie de instancias del microservicio a invocar, en base a diversos criterios: que las instancias estén caídas, que estén en una zona con una alta carga de peticiones…

Una vez pasada esta primera etapa quedarán una serie de instancias que son las que cumplen las condiciones implementadas en los filtros, y ahí entrarán en juego las reglas de balanceo para determinar a cual de esas instancias enviar la petición.

Ribbon dispone de diferentes filtros y reglas así como la posibilidad de implementar los que deseemos, cosa que haremos en las siguientes secciones.

Cuéntanos qué te parece.

Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.

Suscríbete