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 texto [dividido en dos posts, puedes acceder a la segunda parte desde aquí] 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

MicroS3 Eureka 1Configuración avanzada y metadatos
La configuración que se puede ver en la anterior imagen 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.

Existe otra propiedad interesante que nos permite definir el estado inicial que será transmitido a Eureka en la primera notificación para el registro. Se trata de eureka.instance.initialStatus que en nuestro caso hemos definido con el valor UNKNOWN. De esta forma podemos registrar microservicios sin ponerlos inmediatamente disponibles utilizando los diferentes estados (se analizan en profundidad más adelante). En la siguiente captura del dashboard de Eureka podemos ver cómo efectivamente nuestro microservicio se registra con dicho estado: MicroS3 Eureka 2Eureka 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.

La lista de propiedades que se pueden configurar se pueden consultar en las clases org.springframework.cloud.netflix.eureka.EurekaInstanceConfigBean y org.springframework.cloud.netflix.eureka.EurekaClientConfigBean. A continuación podemos ver cómo queda el fichero de configuración de nuestro microservicio security al configurar algunas de estas propiedades: MicroS3 Eureka 3Podremos comprobar los datos de los microservicios registrados por Eureka en http://localhost:8761/eureka/apps. También podemos ver los datos de un microservicio concreto añadiendo /{nombre de microservicio} al final de la anterior URL, en nuestro caso http://localhost:8761/eureka/apps/security. La siguiente imagen muestra los datos en el registro para la configuración correspondiente a la anterior dada: MicroS3 Eureka 4Como 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.

Éste 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.

La siguiente captura muestra una implementación que se ha realizado para las pruebas. Su funcionamiento consiste en ir retornando un estado diferente cada vez que sea consultada (cada 30 segundos), y una vez retornados todos volver siempre al estado ‘UP’: MicroS3 Eureka 5A continuación se pueden ver dos capturas que reflejan estos cambios de estado del microservicio:  MicroS3 Eureka 6Esta 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…

 

Abraham Rodríguez actualmente desarrolla funciones de ingeniero backend J2EE en Paradigma donde ya ha realizado diversos proyectos enfocados a arquitecturas de microservicios. Especializado en sistemas Cloud, ha trabajado con AWS y Openshift y es Certified Google Cloud Platform Developer. Cuenta con experiencia en diversos sectores como banca, telefonía, puntocom... Y es un gran defensor de las metodologías ágiles y el software libre."

Ver toda la actividad de José Abraham Rodríguez López

Recibe más artículos como este

Recibirás un email por cada nuevo artículo.. Acepto los términos legales

Posts relacionados

3 comentarios

  1. […] el post anterior se comenzó explicando posibles configuraciones del servidor y cliente Eureka, que rematamos en […]

  2. […] se ha mencionado en un post anterior sobre Eureka, la zona de un microservicio se define con la propiedad […]

  3. […] 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 […]

Escribe un comentario