Arquitectura de microservicios en Ruby: una guía práctica de configuración

El uso de la arquitectura de microservicios está ganando cada vez más popularidad, principalmente por su escalabilidad, mayor flexibilidad y aislamiento de fallos. No es necesario implementar tu proyecto en una arquitectura monolítica; puedes optar por una solución más escalable en la que los servicios funcionen de forma independiente, pero sigan comunicándose entre sí.

A continuación, te guiaremos a través del proceso de configuración de Ruby con ejemplos prácticos reales y recomendaciones útiles.

Introducción a los microservicios

Cuando se habla del enfoque estándar cliente-servidor, el backend suele funcionar sobre la base de un sistema monolítico, que incluye todo el acceso a los datos y la lógica de dominio. La interacción con el backend se lleva a cabo a través de la capa de API. Con una arquitectura de microservicios, el sistema se divide en servicios más pequeños, en los que cada parte cuenta con sus propios recursos y dominio. Además, todos estos servicios se escalan de forma independiente.

Los servicios están conectados e interactúan a través de la arquitectura de broker. Todo el proceso funciona de la siguiente manera: los mensajes se envían al intermediario a través de los servicios y, a continuación, estos mensajes se enrutan al destino correspondiente. Esto significa que los servicios no deben estar conectados entre sí directamente, sino que solo deben saber cómo interactuar con el intermediario. Este enfoque resulta extremadamente beneficioso para el aislamiento de los servicios y para una mayor seguridad en general.

Aspectos relacionados con la interacción y la mensajería  

Para permitir la interacción con el intermediario, se utiliza la capa asíncrona. La interacción se asemeja en cierto modo a HTTP. Funciona de la siguiente manera: los servicios envían la solicitud a través del intermediario y, a continuación, reciben la respuesta.

Este enfoque implica que cada servicio se centra únicamente en determinadas responsabilidades individuales. El sistema está organizado de tal manera que los servicios solo interactúan con el bróker, pero otras partes del sistema pueden utilizar sus operaciones.

Creación de microservicios con Ruby    

Tomemos, por ejemplo, una arquitectura con un broker y un par de servicios en Ruby. Para poner en marcha el proceso correctamente, empieza por configurar el broker tras comprobar que funciona correctamente. Puedes añadir microservicios en Ruby.

Cuando hablamos del proyecto de un servicio concreto, este suele incluir las siguientes partes:

• Una configuración que incluye los niveles de registro, los ajustes de la base de datos y la dirección del broker.
• Inicializadores que se encargan de determinar las dependencias.
• Objetos de transferencia de datos (DTO) y objetos de acceso a datos (DAO).
• Repositorios que controlan las operaciones de acceso a los datos.
• Los mapeadores son necesarios para la conversión entre DAO y DTO.
• Clases de servicio necesarias para la orquestación de los repositorios y la implementación de los puntos finales de negocio.

Creación de un servicio sencillo de «Persona»

Veamos ahora un ejemplo del servicio «Persona». El primer paso consiste en configurar la conexión a la base de datos y definir la tabla de personas. El modelo DAO es necesario para la representación de los registros de la tabla, y el DTO se utiliza para la representación de la estructura de la carga útil externa.

A continuación, se utiliza un mapeador para la conversión entre DTO y DAO. Todos estos componentes se unen mediante el repositorio para garantizar operaciones de mayor nivel. El último paso consiste en utilizar la clase de servicio para unificar todo y proporcionar una respuesta estructurada.

Por ejemplo, con el método «get» es posible recuperar información sobre todos los usuarios. En caso de que no se reciba ninguna de esta información, se generará el error estándar 404. Si dicha información está disponible, se convierte a un DTO y se devuelve al cliente. A continuación, el servicio se vincula al broker, se asocian las rutas y se garantiza que las solicitudes entrantes se envíen al gestor adecuado.

Para probar los puntos finales, solo se necesitarán pequeños scripts. Mediante una lógica sencilla de gestión de errores, el comportamiento general entre todos los procesos resulta mucho más fácil de probar y predecible.

Uso de los patrones de repositorio

Los servicios de la arquitectura descrita no se comunican directamente con los modelos de la base de datos. Se basan principalmente en repositorios, que a su vez se basan en el principio de mapeadores, DTO y DAO. Este enfoque presenta un par de ventajas específicas:

• Dado que todos los accesos a los datos se centralizan en los repositorios, esto tiene un impacto positivo en la lógica de las consultas y en el almacenamiento.
• El principio fundamental de funcionamiento se basa en la gestión de mensajes y la lógica de negocio.
• Garantías de un contrato estable gracias a los DTO.

Los microservicios funcionan principalmente según el principio de separación precisa, en el que cada servicio tiene su propia estructura y estrategia de almacenamiento individuales. La combinación de patrones disciplinados y un diseño de mensajería basado en un bróker hace que este enfoque sea mucho más fácil de mantener y más flexible.