Eureka: Registro de microservicios (1/2).

En artículos anteriores se han identificado los principales componentes de la arquitectura de microservicios de Spring Cloud enumerando las ventajas que cada uno aporta (El 'who is who'). En el siguiente post, y otros que se publicarán próximamente, se pretende profundizar en dichas ventajas metiéndonos en harina con uno de los componentes: Eureka. Para ello se han configurado y probado las diferentes funcionalidades que se pueden ver a continuación.

Configuración básica

Se ha partido de una configuración básica en la que se dispone de lo siguiente:

• Un servidor Eureka ejecutándose como standalone
• Un microservicio llamado security que será el eureka client

Configuración avanzada y metadatos

La configuración nos proporciona lo necesario (más algún pequeño añadido) para ejecutar nuestro servidor Eureka y que el microservicio security se registre en él.

En esta sección vamos a profundizar en configuración adicional, que nos permite personalizar nuestro microservicio security.

Además de la información típica (nombre, IP, estado ...) Eureka almacena en su registro información adicional sobre cada microservicio. Por ejemplo, existen dos propiedades para definir el path del endpoint de estado y el path del endpoint de información.

Estos endpoints sirven para que otros microservicios puedan recuperar el estado del microservicio e información adicional sobre el mismo respectivamente.

Eureka configura por defecto estas propiedades con los valores ‘/info’ y ‘/health’ aunque nuestra aplicación no los implemente.

Estos valores se pueden sobreescribir con las propiedades eureka.instance.statusPageUrlPath y eureka.instance.healthCheckUrlPath. En nuestro caso hemos definido los valores ‘/my_info’ y ‘/my_health’.

Otras propiedades relevantes son las referentes al http seguro. Aunque éste está habilitado por defecto en Eureka, será necesario configurar dos properties explícitamente:
eureka.instance.nonSecurePortEnabled=false y eureka.instance.securePortEnabled=true para que se trabaje con la conexión segura.

Esto hará que Eureka publique la información de la instancia mostrando preferencia por la conexión segura.

Eureka nos permite así mismo proporcionarle información adicional como metadatos. Para ello, dispone de la propiedad eureka.instance.metadataMap. En nuestro caso hemos añadido dos propiedades al mapa de metadatos: ‘appOwner=abraham’ y ‘description=eureka tutorial’.

También hemos añadido otra propiedad eureka.instance.virtualHostName con el valor myOtherHostName.

Como se puede observar, tanto el status como el overriddenstatus tienen el valor UNKNOWN. También se puede ver que se han incluido nuestros datos en la sección metadata, así como actualizado las URL para statusPageUrl y healthCheckUrl y el vipAddress.

Gestión del estado

El registro de los microservicios se realiza por medio de notificaciones llamadas heartbeat que se realizan cada 30 segundos.

Cada microservicio deberá enviar una notificación al Eureka Server cada 30 segundos para que éste sepa que el microservicio sigue activo. Si el servidor no recibe una notificación después de 90 segundos eliminará al microservicio del registro.

Este es el comportamiento por defecto, pero nuestro microservicio podría querer notificar diferentes estados más allá de estos dos. Podríamos querer que nuestro microservicio se registrase como no disponible para que no se le derivaran peticiones durante un periodo de tiempo, por ejemplo para realizar tareas de mantenimiento, pruebas...

Para esta finalidad Eureka soporta cinco estados diferentes: OUT_OF_SERVICE, DOWN, STARTING, UNKNOWN y UP.

Nosotros mismos podemos gestionar el estado devuelto por nuestro microservicio implementando la interfaz com.netflix.appinfo.HealthCheckHandler. Deberemos habilitar también esta opción en nuestra configuración, para ello añadiremos la propiedad eureka.client.healthcheck.enabled=true.

Esta funcionalidad nos abre la puerta a controlar dinámicamente el estado de nuestro microservicio. Podríamos definir un método REST securizado para cambiarlo, o recuperarlo de una base de datos, o de una caché, incluso podríamos definirlo como una propiedad de configuración y cambiarla en caliente gracias a cloud-config.

Esto nos proporciona una serie de ventajas:

• La previamente mencionada posibilidad de eliminar el microservicio de la lista de disponibles para realizar tareas de mantenimiento o pruebas sobre él sin tener que parar ni el microservicio ni el servidor de Eureka.
• Podemos desplegar una nueva versión del microservicio con un estado no disponible de forma que no se le derive tráfico y cuando decidamos, hacer el ‘switch’ (cambiando la disponibilidad de la versión actual a la nueva) sin que el sistema ni el usuario lo noten. Es más, en caso de problemas con la nueva versión podríamos deshacer el proceso volviendo a la anterior en cuestión de segundos.
• Podemos derivar peticiones durante pequeños periodos de tiempo a una instancia para probar una nueva versión, depurar un error, realizar pruebas de carga...