Trabajar con servicios es fácil, ya que nos permite exponer servicios de alto nivel que podemos fácilmente reutilizar y permite ejecutarlos con tecnologías interoperables, es decir que podemos ejecutarlas sin importar la tecnología en que estén echas, pero que pasa cuando estos servicios se van haciendo numerosos y cada vez es más complicado saber en dónde vive cada servicio o peor aún, en que puerto corren, sobre todo cuando el puerto y la IP en que se ejecuta es aleatorio.
Problemática
A medida que las empresas crecen, lo hace también la cantidad de servicios que se requieren para darle soporte a la operación, lo que provoca que cada vez sea más difícil saber exactamente en donde está cada servicio (IP, puerto), sumando a esto, es común que, para balancear la carga de trabajo, despleguemos múltiples instancias de un mismo componente, lo que hace que la cantidad de servicio publicados crezca de forma exponencial, dificultando aún más la administración de todos los servicios publicados.
Uno de los problemas más comunes cuando trabajamos con servicios, es que necesitamos saber forzosamente donde está cada servicio, y peor aún, necesitamos saber exactamente qué servicio apunta a desarrollo, cual a QA y cual producción, lo que va a haciendo que trabajar con servicios sea una tarea complicado, además, cada vez que agregamos una nueva instancia, es necesario modificar el balanceador de carga para registrar la nueva instancia.
Nuevas instancias de un mismo servicio
En la imagen anterior puedes ver más claramente este problema, donde tenemos una configuración de Nginx (Balanceado de cargas) donde están registradas 3 instancias de un Microservicio, sin embargo, cuando encendemos dos nuevas instancias, al balanceador de cargas no sabrá de sus existencia, por lo que tendremos que modificar la configuración del balanceador de cargar y reiniciarlo para que este tome la nueva configuración, lo cual no es para nada bueno en un arquitectura cloud, donde podemos estirar la nube para agregar o quitar instancias dinámicamente a medida que la carga de trabajo crece o disminuye, por lo que no podemos tener a una persona que esté registrando y eliminado los servidores en el balanceado de cargas.
Solución
El patrón Service Registry propone crear un servidor centralizado donde todos los servicios se registren al momento de encender, de esta forma, cada servicio le tendrá que enviar la dirección IP, el puerto en el que responde al servidor y finalmente, el identificador del servicio, que por lo general es un nombre alfanumérico que ayude a identificarlo, de esta forma, el servidor central o registro, sabrá exactamente dónde está cada servicio disponible.
Registro de servicios
Esto lo que provoca es que mediante el Service Registry sepamos exactamente qué servicios están disponibles y su ubicación física, ya que por lo general proporciona una interface gráfica que nos permite ver gráficamente todos los servicios activos.
Otra de las características de este patrón es que los servicios que se registren, deberán estar enviando constantemente una señal al registro, la cual le indica que los servicios siguen disponibles al pasar del tiempo. Ha esta señal se le conoce como heartbeat (latidos).
Mediante los latidos el Registro puede identificar qué servicios han dejado de funcionar, ya que, si deja de recibir los latidos, el Registro lo tomará como que ese servicio se ha caído, lo que puede disparar una alerta al administrador del sistema.
Heartbeat
Como podemos apreciar en la imagen, tenemos un par de servicios ya registrados, los cuales comienzan a mandar los latidos al Registro, sin embargo, el segundo (abajo) comienza a fallar y el servidor se cae, por lo que el servicio se apaga abruptamente, por lo tanto, el Registro no sabe de momento del servicio dejó de responder, sin embargo, después de un tiempo, el Registro detecta que no ha recibido los latidos de ese servicio, por lo que automáticamente lo marca como fuera de servicio y puede mandar en ese momento un notificación a algún administrador o DevOps que administre el servicio.
Conclusión
El Service Registry es hoy en día un componente indispensable en arquitectura de Microservicios o aplicaciones desarrolladas nativamente para la nube, pues permite que los servicios se puedan registrar independientemente de su ubicación física, lo que hace que podamos saber fácilmente su ubicación y posteriormente utilizar técnicas de auto descubrimiento para localizarlos y balancear la carga.
A pesar de que es uno de los elementos más importantes en una arquitectura de Microservicos, por desgracia muchos arquitectos la olvidan al momento de diseñar sus aplicaciones, lo que hace aplicaciones dependientes de las ubicaciones físicas de los Microservicios y finalmente, difíciles de escalar.
Acerca de este libro
Todo lo que acabas de ver en este artículo es solo una pequeña parte del libro Introducción a la arquitectura de software, el libro más completo en español sobre arquitectura de software, donde cubrimos los temas más importantes para convertirte en un arquitecto de software profesional.
¿Quieres convertirte en arquitecto de software pero no sabes cuál es el camino adecuando? o simplemente no sabes que guía estudiar para convertirte en arquitecto de software, te invito a que veas mi libro:
