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 7

Como se puede ver se han definido dos perfiles:

Cosas importantes a destacar de la configuración:

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 8

De la misma forma en el nodo 2 podemos ver cómo se identifica al nodo 1 como réplica:

MicroS3 Eureka 9

A 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 10

En 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 11

La 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:

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.

Cuéntanos qué te parece.

Enviar.

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.