¿Por qué usar un descubridor de servicios?
Cuando un cliente hace una petición a una API REST necesita saber la localización en la red (dirección IP y puerto) de la instancia del servicio. En aplicaciones más tradicionales las localizaciones eran relativamente estáticas ya que solían ejecutarse en el mismo hardware físico. En aplicaciones más actuales, basadas en la nube con máquinas virtuales o contenedores, los localizaciones cambian con relativa frecuencia.
Con la llegada de estas nuevas estrategias en la nube también surgen nuevos retos como el cambio dinámico de las localizaciones debido a la auto escalada de servicios, los fallos, las actualizaciones. Los clientes necesitan usar un servicio que sea capaz de aportar soluciones de manera que para los servicios sea lo más transparente posible.
En la siguiente imagen se puede apreciar la problemática que puede llegar a tener un cliente para saber a qué instancia del servicio hacer la petición y más si las localizaciones son dinámicas.
Principalmente hay dos patrones para el descubrimiento de servicio: client-side discovery y server-side discovery.
Client Side Discovery Pattern
En esta estrategia, el cliente es el responsable de determinar la red de localizaciones de instancia de servicios disponibles y de balancear las peticiones entre ellas. El «Registro de servicios» tiene la responsabilidad de conocer la localización de todos los servicios disponibles. El cliente pregunta al «Registro de servicios» y usa un algoritmo de balanceo de carga para seleccionar una instancia.
En el siguiente diagrama se puede ver como cada instancia utiliza un cliente de registro para indicar su localización al «Servicio de registro». Cuando la aplicación cliente pregunta al servicio, este devuelve un listado con las instancias disponibles y su localización con lo que la aplicación cliente ya puede seleccionar una de las instancias.
La ventaja de este patrón es que no cambia mucho la arquitectura a la cuál sólo se le añade el «Servicio de registro». Esto da pie a que la aplicación cliente pueda tomar decisiones para el balanceo.
La principal desventaja es que este patrón es que acopla a la aplicación cliente el «Registro de servicios». Se debe implementar esa lógica para todas las aplicaciones clientes y estas pueden estar en distintos lenguajes de programación.
Service-Side Discovery Pattern
Esta estrategia también utiliza el «Registro de servicios» y la distintas instancias como en la estrategia anterior en la cual se incluye un nuevo componente: el balanceador de carga.
El balanceador de carga tiene la responsabilidad de redirigir la petición de la aplicación cliente a una de las instancias del servicio. El balanceador de carga pregunta al «Servicio de registro» las instancias de los servicios que están disponibles y la localización de estas.
Nota: los ELB de AWS usan esta estrategia.
Uno de los principales beneficios de esta estrategia es que para la aplicación cliente sólo hay un servicio con los que se abstrae todo el comportamiento de registro de servicios. El cliente se simplifica al no tener que implementar toda esta parte.
Una desventaja es que se incrementa la complejidad de la arquitectura del sistema al tener que añadir otro componente. El balanceador de carga sería otro elemento de alta disponibilidad que se necesita desplegar, configurar y administrar.
El servicio de registro
El servicio de registros es otro servicio, el cual trata con la gestión de las instancias de servicio disponibles y sus localizaciones. Los clientes que hacen uso de ese servicio pueden almacenar en caché el listado devuelto por el servicio de registro pero puede quedar desactualizado rápidamente.
Un ejemplo de servicio de registro podría ser Netflix Eureka, el cual provee un API REST para la gestión de las instancias de servicio. Una instancia de servicio registra su localización haciendo una petición POST. Cada 30 segundos, este debe refrescar su estado usando una petición PUT. Una instancia deja de estar disponible si hace una petición DELETE o si el servicio de registro hace una petición al servicio de instacia y obtiene un timeout. Para obtener el listado de servicios disponibles se debe realizar una petición de tipo GET.
Para registrar y desregistrar las instancias se pueden utilizar dos estrategias:
Self-Registration Pattern.
Third-party Registration Pattern.
El patrón de auto registro o «Self-Registration Pattern»
Con el Self-Registration Pattern es la propia instancia la que tiene la responsabilidad de registrar y desregistrar del servicio de registro. También tiene la responsabilidad de mandar el heartbeat para saber que sigue operativa.
La principal ventaja es que es relativamente simple y no requiere de otros componentes del sistema.
Por otro lado, se está acoplando las instancias de servicio a al servicio de registro. Esto se puede solventar con el patrón «Third-Party Registration Pattern».
El patrón de registro de terceros o «Third-Party Registration Pattern»
El Third-Party Registration Pattern utiliza un componente nuevo, «Service Registration», que tiene la responsabilidad de gestionar los registros.
Este componente monitoriza los cambios del conjunto de instancias registrando ya sea sondeando el entorno de despliegue o suscribiéndose a eventos. Cuando este advierte una nueva instancia entonces la registra en el «Registro de servicios».
El mayor beneficio es que los servicios están desacoplados del servicio de registro. El registro de instancias de servicio se trata de una manera centralizada dentro de un servidor dedicado.
La desventaja es que se añade un nuevo componente a la arquitectura del sistema que se necesita desplegar, configurar y administrar.
Resumen
En una aplicación de microservicios, el conjunto de instancias de servicio puede cambiar dinámicamente. Para que un cliente pueda hacer una petición a un servicio se debe usar un mecanismo de descubrimiento de servicios.
Una parte clave del descubrimiento de servicios es el servicio de registro. Este es otro servicio el cual modela el conjunto de instancias que están disponibles y sus localizaciones. Este provee una API para la gestión.
Hay dos estrategias a la hora para el descubrimiento de servicios.
Descubrimiento del lado del cliente: los clientes consultan al servicio de registro, seleccionan a qué servicio realizar la llamada y, posteriormente, hacen la llamada.
Descubrimiento del lado del servidor: los clientes hacen la llamada a un router el cual consulta al servicio de registro y redirige la petición a las instancias disponibles.
Hay dos maneras en las que las instancias de servicio se registran y se desregistran en el servicio de registro:
El patrón de auto-registro: las propias instancias se registran en el registro de servicio.
El patrón de registro de terceros: otro componente trata con el registro de las instancias de servicio.
No hay comentarios:
Publicar un comentario