El descubrimiento en los microservicios

Los microservicios, ganan cada día más protagonismo ante la creciente necesidad de ofrecer soluciones cada vez más óptimas y escalables. El crecimiento de los datos en los últimos años ha sido como nunca antes, según el IDC se espera para el 2025 un crecimiento de hasta 175 zettabytes, es un número inmenso.

Para ser un poco más claros y usando términos más comunes, mil megabytes (MB) equivalen a 1 gigabyte (GB); mil gigabytes equivalen a 1 terabyte (TB); milterabytes equivalen a un petabyte (PT), mil petabytes equivalen a 1 exabyte (EB) y mil exabytes (EB) equivalen a 1 zettabyte (ZB).

Sin duda manejar datos a esta tasa de crecimiento con aplicaciones monolíticas es insostenible manteniendo niveles aceptables de calidad de servicio.

Los microservicios entonces se están imponiendo como una solución para desacoplar los complejos monolitos.

El patrón de descubrimiento

Entre los grandes retos de los microservicios, al poder estar segregados su despliegue, radica en encontrar mecanismos que permitan “estén donde estén” cada uno, saber donde localizarlos para usarlos, sin necesidad de tener manualmente guardada sus direcciones, dominios o puertos específicos en donde se ejecutan.

Como se ha expuesto antes, en un entorno de microservicios lo más común es que existan diversas instancias de APIs ejecutándose en diferentes direcciones. En entornos más complejos de alta demanda puede darse el caso en que se levanten de forma automática nuevas instancias, este es un problema complejo que enfrenta el diseño de la arquitectura de microservicios.

El patrón de descubrimiento de servicios ayuda a solventar este problema, dando una solución para identificar en qué lugar está cada uno de los microservicios, conocer sus direcciones y las rutas de acceso hacia ellos. Un ejemplo concreto de uso de los datos registrados es cuando un sistema consulta el API Gateway, en este momento el API Gateway puede tener dos formas de configuración de las rutas (estáticas o basadas en un identificador/nombre del servicio).

El segundo caso es el más usual y el identificador lo conoce el servidor de descubrimiento, entonces al hacer la petición al Gateway este último pregunta al servidor de registro cual es la dirección para el identificador al que está asociada la petición del usuario, y con esa dirección el Gateway enruta la petición; esto brinda gran flexibilidad, porque los microservicios finales pueden moverse libremente en diferentes direcciones sin necesidad de realizar cambios de configuración en otros sistemas que los usan.

El patrón tiene dos enfoques de descubrimiento:

Del lado del cliente: Es cuando el servicio es quien le indica al servidor de descubrimiento donde está, los servicios se registran y notifican cada cierto tiempo que están disponibles y operativos. En este enfoque los clientes deben tener una lógica implementada que les indique donde está el discovery-server y los pasos para registrarse en el mismo. 

Del lado del servidor: Es el caso contrario, el servidor descubre y registra los clientes, en este enfoque participa un tercero, un componente llamado Router, los clientes saben donde esta el router, le comunican al router donde ellos están y el router le indica al servidor de registro donde esta el cliente para que el servidor le de seguimiento. Si bien este enfoque no requiere que los clientes implementen la lógica para registrarse en el servidor de registro se introduce un nuevo componente (el Router) que requiere estar disponibilizado, lo que añade mayor complejidad a la infraestructura. Un ejemplo de este tipo de esquema de registro es AWS Elastic Load Balancer (ELB)

Cuando usarlo:

El descubrimiento es una parte esencial de una arquitectura de microservicios, a medida que crece la granja de microservicios la necesidad de su uso crece también para lograr un producto con alto grado de mantenibilidad. Siempre que se vaya a implementar microservicios debe usarse un servidor de registro/descubrimiento, el enfoque a emplear dependerá del entorno cloud en el que se va a realizar el despliegue.

Software recomendado: Spring Cloud Eureka (por Netflix OSS), Hashicorp Consul, Apache Zookeeper.

Hemos usado con resultados muy positivos a Spring Cloud Eureka y lo recomendamos para entornos productivos.

Si te ha gustado el artículo, puedes invitarme a un café 🙂