5 patrones de diseño en microservicios

Empecemos por algo sencillo para entender el diseño en microservicios: ¿qué es la arquitectura de microservicios? Es un conjunto de pequeños servicios, los cuales se comportarán de manera autónoma e independiente. Cada uno deberá englobar una parte de la lógica de negocio en específico.

Con palabras algo más formales podemos definirlo como un estilo arquitectónico para el desarrollo de aplicaciones.

Por ejemplo, si tenemos una aplicación de una tienda, dos posibles servicios podrían ser Order y Product. Cada uno gestionará toda la lógica relativa a esa parte de la aplicación.

Y diréis, ¿pero que ventajas me aporta esta arquitectura con respecto a la arquitectura en monolito?

• Servicios autónomos e independientes.
• Descentralizacion.
• Escalabilidad.
• Flexibilidad ante posibles cambios.
• Aislamiento en caso de fallo.

En este artículo, vamos a mencionar cinco tipos de patrones de diseño de microservicios, para que elijáis el que mejor creáis que se adapta a vuestro proyecto.

Aggregator pattern

Implementa un punto de gestión en común entre los diferentes servicios, con el propósito de recolectar información de estos o implementar una funcionalidad específica.

Este patrón se encargará de recoger información de cada servicio, aplicar lógica de negocio requerida y publicarla para el resto de servicios, pudiendo consumirla los que la requieran.

Ventajas:

• Reducción de posible sobrecarga de comunicación entre servidor – cliente.
• Centralización de lógica de negocio.
• Fácil implementación.
• Provee de single-access-point para los servicios.

Event Sourcing

La comunicación entre servicios es un gran pilar de esta arquitectura. Para gestionar esto podemos aplicar el patron Event Sourcing. Nos permitirá tener un punto centralizado para la gestión y difusión de todos los eventos enviados entre servicios. Cada uno de ellos mandará una serie de eventos que indicarán las acciones que se están realizando para, más tarde, ser almacenadas en event store.

Una posible implementación podría ser cuando la aplicación persistirá estos eventos dentro de la store. Ésta ofrecerá una API, la cual será accesible para todos los servicios, pudiendo así añadir o recuperar eventos que un servicio ha emitido.

Por otro lado event store podría comportarse como un message broker (tal vez ésta sea la implementación mas común), pudiendo suscribirse a ella todos los servicios que lo requieran.

Ventajas:

• Persistencia de eventos, pudiendo tener un histórico de estos.
• Posibilidad de implementar queries para determinar el estado de un servicio en cualquier momento.
• Previene de posibles conflictos en sistemas concurrentes.
• Acoplamiento débil entre servicios.

Command Query Responsibility Segregation (CQRS)

Este patrón sera una buena implementación cuando tenemos un acceso a una sola base de datos. La aplicación se va a dividir en dos implementaciones:

• Commands: gestionarán todas las peticiones que conlleven una modificación del recurso.
• Queries: gestionarán, por el contrario, todas las peticiones que consulten información de uno o varios recursos.

Con esto conseguimos una abstracción de los datos que se van a modificar de los que serán datos de lectura.

Ventajas:

• Mayor disponibilidad de datos.
• Consigue sistemas mas flexibles y fáciles de mantener.
• Separación de responsabilidades en escritura y lectura.

Database per service

Este patrón prove a cada microservicio de su propia base de datos. Suele ser el siguiente paso a seguir cuando migramos de un monolito a arquitectura de microservicios.

Evitaremos un fuerte acoplamiento entre servicios y la capa de persistencia de datos. Con esta estructura, la base de datos pasará a ser parte de la implementación de cada servicio. Esta no deberá ser accesible desde otros servicios, para obtener datos entre ellas usaremos el patron event-driven.

Ventajas:

• Bajo acoplamiento.
• Aplicación escalable.
• Alta disponibilidad.
• Posibilidad de usar diferentes tecnologías dentro de una misma aplicación, usando en cada servicio la que requiera.

Saga pattern

Para este caso gestionaremos las posibles transacciones entre servicios usando sagas.

Pero, ¿que es una saga? Una saga es una secuencia de operaciones que va a actualizar cada servicio y publicará un mensaje o desencadenará la siguiente acción de la operación. Cada operación pasará a formar parte de una saga, la cual va a garantizar que se completen todas las operaciones y que cada transacción se ejecute de manera concurrente.

Este patrón lo usaremos para conservar la consistencia de datos entre servicios.

Para este patrón tenemos dos principios:

1. Choreography

Cada transacción va a publicar eventos los cuales desencadenan otras transacciones en otros servicios.

2. Orchestration

En este caso tendremos un orquestador que será el que se encargue de gestionar qué transacción de va a ejecutar y en qué servicio.

Ventajas:

• Posibilita la gestión de transacciones basándose en mensajes y teniendo así un acoplamiento débil.
• Consistencia entre servicios.
• Buen uso en transacciones con poca complejidad y pocos pasos.

Conclusiones

En este pequeño articulo hemos expuesto algunas de las principales soluciones que podemos aplicar en nuestros proyectos para conseguir que sean mas consistentes, flexibles y accesibles, tanto para el caso de migración de una arquitectura en monolito, como para un nuevo proyecto.

No hay por qué implementar cada uno de ellos, ya que lo principal es mirar las necesidades que tendrá nuestra aplicación, y nuestro propio criterio.

Usar patrones de diseño siempre será una base solida sobre la que poder partir, pero luego el verdadero arte lo crearemos nosotros.