Eureka: Registro de microservicios (2/2)

En el post anterior se comenzó explicando posibles configuraciones del servidor y cliente Eureka, que rematamos en esta segunda y última parte con la configuración de un cluster de servidores.

Eureka Peer Cluster

En la configuración hasta ahora mostrada del servidor Eureka en modo ‘standalone’, éste consta de una única instancia que combinada con el uso de las dos cachés (de cliente y servidor) añaden fiabilidad y resistencia a fallos al sistema, pero no toda la necesaria teniendo en cuenta que Eureka es la pieza central de nuestro ecosistema de microservicios.

Por ello Eureka puede ser configurado como un cluster de instancias peer aumentando así la fiabilidad y resistencia a fallos. Estas instancias se registrarán las unas en las otras durante el arranque e intercambiarán la información del registro entre ellas.

Aclaración: Eureka distingue las diferentes instancias de un mismo microservicio (o de sí mismo como servidor) en base al hostname en el que se ejecuta cada instancia. Al hacer la prueba en local, si levantamos dos instancias de un microservicio, aunque el servidor reciba heartbeat de las dos, entenderá que se trata de una única por tener el mismo nombre y hostname. Esto es el comportamiento normal, ya que las instancias de cualquier microservicio no deberían ejecutarse en la misma máquina (ya sea virtual o física). Por tanto, para poder realizar esta prueba en local, deberemos editar nuestro fichero de hosts para definir un nuevo hostname para nuestra máquina, en este caso hemos utilizado demo.eureka.com. Otra forma de hacerlo sería utilizar Docker para cada una de las instancias.

Como tenemos un único proyecto con el servidor Eureka nos apoyaremos en los perfiles de Spring para definir la configuración de las dos instancias del servidor y arrancaremos cada una con un perfil. En la siguiente imagen se puede ver la nueva configuración de nuestro servidor Eureka:MicroS3 Eureka 7Como se puede ver se han definido dos perfiles:

  • ⦁ Node1: se ejecutará en el puerto 8761 y no tiene definido nombre de máquina (como hemos visto en previas capturas del dashboard de Eureka utilizará abraham-laptop como nombre de máquina)
  • ⦁ Node2: se ejecutará en el puerto 8762 y utilizará como hostname demo.eureka.com (propiedad eureka.instance.hostname)

Cosas importantes a destacar de la configuración:

  • ⦁ Los dos microservicios tienen el mismo nombre eureka-server y al tener hostnames diferentes se identificarán como dos instancias del mismo microservicio.
  • ⦁ Los dos microservicios aún siendo servidores Eureka, también son clientes Eureka y se registrarán en sí mismo y en el otro nodo y recuperarán el registro (propiedades eureka.client.XXX).
  • ⦁ Propiedad eureka.instance.leaseRenewalIntervalSeconds: el proceso de registro de un microservicio puede implicar un tiempo considerable ya que éste no estará disponible para que otros lo descubran hasta que las cachés de los clientes, servidor e instancia estén sincronizadas, lo que puede requerir tres heartbeats. Esta propiedad permite indicar cada cuantos segundos se envían los heartbeats en lugar de los 30 por defecto, reduciendo así el tiempo necesario para el proceso de registro.
  • ⦁ Propiedad eureka.server.enableSelfPreservation es explicada en más detalle en la siguiente sección del artículo.

En la siguiente captura del dashboard del nodo 1 podemos ver como hay dos instancias disponibles (con hostnames demo.eureka.com y abraham-laptop) y cómo se identifica al nodo 2 (http://demo.eureka.com:8762/eureka) como réplica (secciones General Info y DS Replicas):MicroS3 Eureka 8De la misma forma en el nodo 2 podemos ver cómo se identifica al nodo 1 como réplica:MicroS3 Eureka 9A continuación levantaremos la instancia del microservicio security. Durante su arranque ésta se registrará en el nodo 1, que es el que tiene configurado (sección configuración básica). En el momento que el nodo 1 sincronice su registro con el nodo 2, el microservicio aparecerá también disponible en dicho nodo, como se puede ver en la siguiente captura del dashboard del nodo 2:MicroS3 Eureka 10En esta situación podría parecer que todo se ha ejecutado de la forma correcta. Nada más lejos de la realidad. Según la configuración actual, el microservicio security solo enviará heartbeats al nodo 1, por lo que si éste se cayera por el motivo que fuera, no podríamos tener constancia de la existencia de security.

En esta situación security seguiría intentando enviar heartbeats al nodo caído, por lo que nadie los recibiría. El nodo 2, tras 90 segundos sin recibir ningún heartbeat, eliminará a security del registro quedando completamente aislado del resto de microservicios. Esta situación se puede ver en el dashboard del nodo 2, 90 segundos después de que parásemos el nodo 1, como muestra la siguiente captura:MicroS3 Eureka 11La forma correcta es por tanto incluir todos los nodos de Eureka Server en la configuración de security (eureka.client.serviceUrl.defaultZone=http://abraham-laptop:8761/eureka/,http://demo.eureka.com:8762/eureka).

…y más a fondo
Ya hemos visto unos cuantos conceptos avanzados sobre Eureka, pero para aquellos que todavía estén sedientos de más, esta sección aglutina algunos detalles adicionales sobre el funcionamiento de Eureka:

  • ⦁ Los clientes Eureka utilizan una caché para almacenar el registro de forma que no tienen que solicitarlo al servidor cada vez que necesitan invocar a otro microservicio. Esta información se actualiza cada 30 segundos con cada heartbeat.
  • ⦁ Durante su parada, una instancia de microservicio enviará al servidor una notificación de apagado, de forma que Eureka eliminará dicha instancia del registro.
  • ⦁ Se pueden añadir tantos peers como se desee siempre y cuando estén todos conectados entre sí por al menos un punto, de forma que puedan sincronizar sus registros. Si los peers no pudiesen comunicarse podríamos llegar a una situación ‘split-brain’ donde cada uno tiene registro de un conjunto de microservicios diferentes.
  • ⦁ Cuando se arranca una nueva instancia peer esta intenta recuperar la información de registro de un nodo vecino, y en caso de no ser posible intentará con todos los demás.
  • ⦁ Si en cualquier momento la tasa de notificaciones cae por debajo de un determinado valor (85% durante 15 minutos) el servidor parará de eliminar instancias del registro. Esto es conocido como el modo self-preservation y es utilizado para proteger el registro ante situaciones donde pueda existir una partición de red entre diferentes instancias de Eureka Server. Así mismo, esto puede provocar que se recuperen instancias de microservicios que ya no existen, por tanto los microservicios deben implementarse teniendo en cuenta posibles fallos debido a dicha situación.

Conclusiones
Eureka es una herramienta, aunque relativamente joven, madura. Diseñada para trabajar en entornos distribuidos con alta disponibilidad y tolerancia a fallos. Dispone de una gran cantidad de opciones de personalización, sin tener en cuenta la posibilidad de extender o sobreescribir funcionalidades. Lo exquisitamente bien diseñada que está y todas las posibilidades que ofrece nos hace pensar en cómo hemos podido trabajar sin Eureka hasta ahora.

 

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

8 comentarios

  1. […] [Fin de la primera parte. Puedes acceder directamente a la segunda parte del artículo aquí] […]

  2. […] El servidor Eureka para registro de microservicios, a fondo (2/2) […]

  3. […] El servidor Eureka para registro de microservicios, a fondo (2/2) […]

  4. Jesús dice:

    Gracias por el aporte.

    Tengo una duda acerca del uso de Eureka con el servidor de configuración. Cada 5 minutos exactos, Eureka devuelve el siguiente log ‘Resolving eureka endpoints via configuration’, ¿se supone que se va actualizando con el registro de configuración?¿No lo hace únicamente al principio?

    Gracias por ayudar a los que estamos empezando!

    Un saludo.

    • Abraham dice:

      Buenas Jesús

      Este mensaje que envía Eureka, no es muy representativo y puede llevar a confusión. No es que recupere la configuración del servidor de configuración (de hecho si arrancas solo el servidor Eureka verás que también saca ese mensaje).

      Si ves la paquetería, ese mensaje corresponde a la clase com.netflix.discovery.shared.resolver.aws.ConfigClusterResolver que se encuentra en el artefacto eureka-client (si recuerdas nuestro servidor eureka es también un cliente eureka) por lo tanto es el cliente de eureka cargando el listado de endpoints del eureka server. De hecho si te fijas ese mensaje también lo saca cualquier microservicio que sea un cliente Eureka

      Espero que te ayude

      Saludos

      • Jesús dice:

        Muchas gracias Abraham,

        me despisté en la búsqueda del artefacto y pensaba que se producía a partir de Config Server (como bien dices, veía que todos los microservicios tenían el mismo log) ya que todas las aplicaciones arrancan a partir del configurador y le veía como único punto en común (no recordaba que Eureka Server era también Eureka Client).

        Me ha ayudado a comprender de mejor manera todo los entresijos de Eureka, Muchas gracias!

        Un saludo.

  5. Jaider dice:

    Excelente post, me ha creado una duda sobre los servidores de Eureka en cluster, veo que manualmente es necesario agregar en el registro el servidor que esta clusterizado en cada Eureka server, si por alguna situación extrema es necesario levantar mas cluster de Eureka, como hacemos este registro dinamicamente, igual para los microservicios.

    Gracias

    • Abraham dice:

      Buenas Jaider
      A día de hoy que yo sepa, no es posible añadir nuevas instancias al cluster de eureka en caliente. Es necesario, como incidas, agregar la nueva instancia al registro del cluster. Además esto hay que hacerlo para todas las instancias de todos los microservicios, no solo para los de eureka. Por lo que a efectos prácticos necesitarás un reinicio completo de todo el entorno

Escribe un comentario