Recientemente, participé en la investigación y el desarrollo del proyecto de la empresa y encontré algunos problemas menores en la gestión de datos. Basándome en experiencias pasadas, registré el patrón de diseño de datos de microservicios aquí.

Los servicios en una arquitectura de microservicios están poco acoplados y se pueden desarrollar, implementar y escalar de forma independiente. Cada microservicio requiere diferentes tipos de datos y almacenamiento, por lo que cada microservicio tiene su propia base de datos.

1. Base de datos de cada servicio

Cada microservicio tiene su propia base de datos y puede elegir libremente cómo administrar los datos.

1.1 Beneficios de tener una base de datos por servicio

Laxamente acoplados, cada servicio puede enfocarse más en su propio campo profesional
Libre elección de tipos de bases de datos, como RDBMS como MySQL, bases de datos de columna ancha como Cassandra, bases de datos de documentos como MongoDB, almacenes de clave-valor como Redis y bases de datos de gráficos como Neo4J.

¿Necesito usar un servidor de base de datos diferente para cada servicio? Este no es un requisito difícil. Veamos qué podemos hacer.

1.2 Si está utilizando RDMS, incluya las siguientes funciones:

Tablas privadas : cada servicio posee un conjunto de tablas a las que solo ese servicio puede acceder.
Esquema de base de datos dedicado : cada servicio tiene un esquema de base de datos privado.
Servidor de base de datos dedicado : cada servicio tiene su propio servidor de base de datos.

1.3 El reto de tener una base de datos para cada servicio

Consultas que requieren conectarse a varias bases de datos : el siguiente esquema de datos puede superar este desafío.

Abastecimiento de eventos
Composición de la API
Separación de responsabilidad de consulta de comando (CQRS)

Transacciones en múltiples bases de datos : para resolver este problema, podemos usar el patrón Saga .

2. Trazabilidad de eventos

Con el abastecimiento de eventos, el estado de una entidad comercial se rastrea mediante una serie de eventos que cambian el estado. Cada vez que cambia el estado de una entidad comercial, se agrega un nuevo evento a la lista de eventos. Dado que guardar un evento es una sola operación, es de naturaleza atómica. Al reproducir eventos, la aplicación reconstruye el estado actual de la entidad.

Las aplicaciones guardan eventos en un almacén de eventos, que es una base de datos de eventos. Los eventos se pueden agregar y recuperar del almacenamiento utilizando su API. El almacén de eventos también actúa como intermediario de mensajes. Los servicios pueden suscribirse a eventos a través de su API. Cuando un servicio guarda un evento en el almacén de eventos, se envía a todos los suscriptores interesados. Cuando una entidad tiene una gran cantidad de eventos, la aplicación puede guardar periódicamente una instantánea del estado actual de la entidad para optimizar la carga. La aplicación busca la instantánea más reciente y los eventos que han ocurrido desde esa instantánea para reconstruir el estado actual. Esto reduce el número de eventos a reproducir.

2.1 Beneficios del abastecimiento de eventos

Su uso resuelve uno de los desafíos clave de las arquitecturas basadas en eventos y permite la publicación confiable de eventos cuando cambia el estado.
Los problemas de desajuste de impedancia relacional de objetos se evitan mediante eventos persistentes en lugar de objetos de dominio.
Proporciona registros de auditoría 100 % fiables para las entidades.
Permite la ejecución de consultas temporales que determinan el estado de una entidad en cualquier momento.
La lógica empresarial basada en el abastecimiento de eventos implica el intercambio de eventos entre entidades débilmente acopladas. Facilita mucho la migración de una aplicación monolítica a una arquitectura de microservicios.

2.2 Desventajas del abastecimiento de eventos

Hay un cierto costo de aprendizaje, y todavía es una tecnología inmadura.
Consultar el almacén de eventos es difícil y requiere una consulta típica para reconstruir el estado de la entidad. Puede resultar en consultas ineficientes y complejas. Por lo tanto, las aplicaciones deben utilizar la separación de responsabilidad de consulta de comando (CQRS) para implementar consultas. A su vez, esto significa que las aplicaciones deben manejar datos finalmente consistentes.

3. Composición API

Puede utilizar el patrón de composición de la API para implementar operaciones de consulta que recuperan datos de varios servicios. En este patrón, las operaciones de consulta se implementan invocando el servicio que posee los datos y luego combinando los resultados.

3.1 Beneficios de la composición API

Una forma conveniente de consultar datos en una arquitectura de microservicio.

3.2 Desventajas de la composición del API

A veces, las consultas dan como resultado uniones de memoria ineficientes para grandes conjuntos de datos.

4. Separación de responsabilidad de consulta de comando (CQRS)

Los RDBMS se usan comúnmente como sistemas transaccionales de registros y bases de datos de búsqueda de texto como Elasticsearch o Solr para consultas de búsqueda de texto. Algunas aplicaciones mantienen las bases de datos sincronizadas escribiendo en ambas al mismo tiempo. Otros copian regularmente datos del RDBMS al motor de búsqueda de texto. Las aplicaciones construidas sobre esta arquitectura aprovechan múltiples bases de datos, las propiedades transaccionales de un RDBMS y las capacidades de consulta de una base de datos de texto. CQRS generaliza esta arquitectura.

Las arquitecturas de microservicio enfrentan tres desafíos comunes al implementar consultas.

Utilice el patrón de composición de la API para recuperar datos dispersos en varios servicios, lo que genera uniones en memoria costosas e ineficientes.
Los datos se almacenan en un formato o base de datos que no puede admitir de manera eficiente las consultas requeridas por el servicio propietario de los datos.
La separación de preocupaciones significa que el servicio que posee los datos no debe ser responsable de implementar operaciones de consulta.

Los tres problemas se pueden resolver usando el patrón CQRS.

El objetivo principal de CQRS es la separación o separación de preocupaciones. Por lo tanto, el modelo de datos persistentes se divide en dos partes: el lado del comando y el lado de la consulta.

Las operaciones de creación, actualización y eliminación se implementan mediante módulos del lado del comando y modelos de datos. Las consultas se implementan mediante módulos del lado de la consulta y modelos de datos. Al suscribirse a los eventos publicados por la línea de comando, el lado de la consulta mantiene su modelo de datos sincronizado con el lado del comando

4.1 Beneficios de CQRS

Logre un cumplimiento de consultas eficiente : si implementa consultas utilizando el patrón de composición de API, puede experimentar uniones de memoria costosas e ineficientes para grandes conjuntos de datos. Para estas consultas, es más eficiente usar vistas CQRS que unen previamente los datos de dos o más servicios.
Capacidad para implementar de manera eficiente muchos tipos de consultas : a menudo es difícil admitir todas las consultas con un único modelo de datos persistente. En CQRS, se definen una o más vistas para implementar de manera eficiente una consulta específica, eliminando la limitación de un único almacén de datos.
Habilita consultas en la aplicación basadas en Event Sourcing : CQRS también supera una limitación importante de Event Sourcing. El almacén de eventos solo admite consultas basadas en claves principales. El patrón CQRS soluciona esta limitación definiendo una o más vistas agregadas que se mantienen actualizadas al suscribirse al flujo de eventos publicado por el agregado de fuente de eventos.
Mejoras en la separación de preocupaciones : el modelo de dominio y el modelo de datos persistentes no admiten comandos ni consultas. CQRS separa los lados de comando y consulta del servicio en módulos de código y esquemas de base de datos separados.

4.2 Desventajas de CQRS

Arquitectura más compleja : para actualizar y consultar las vistas, los desarrolladores deben escribir servicios del lado de la consulta. Las aplicaciones pueden usar diferentes tipos de bases de datos, lo que agrega complejidad para los desarrolladores y DevOps.
Manejo del retraso de la replicación : hay un retraso entre la publicación de un evento en el lado del comando y el procesamiento del evento en el lado de la consulta y la actualización de la vista.

Cinco, modo Saga

Con las sagas, puede mantener la coherencia de los datos en una arquitectura de microservicios sin utilizar transacciones distribuidas. Defina una saga para cada comando que actualice los datos en varios servicios. Una saga es una secuencia de transacciones locales. Las transacciones locales actualizan los datos dentro de un solo servicio utilizando el marco de transacciones ACID.

Las sagas utilizan transacciones de compensación para revertir los cambios. Supongamos que falla la enésima transacción de saga. Las primeras (n-1) transacciones se deben deshacer. Como resultado, se iniciará un total de (n-1) transacciones de compensación para revertir los cambios en orden inverso.

5.1 Coordinación de la saga

Para implementar una saga, necesita lógica para coordinar sus pasos. Una vez que un comando del sistema ha iniciado una saga, la lógica de coordinación debe seleccionar e instruir a la primera saga para que ejecute una transacción local. Una vez que se completa la transacción, el coordinador de orquestación selecciona e invoca al siguiente participante de la saga. Este proceso continúa hasta que se completa la leyenda. Si la transacción local falla, la saga debe ejecutar transacciones de compensación en orden inverso.

5.2 Hay varias formas de construir la lógica de coordinación de una saga:

Orquestación : Distribuir la toma de decisiones y la secuenciación entre los participantes de la saga. Se comunican principalmente mediante el intercambio de eventos.

5.2.1 Ventajas de la saga basada en orquestación

Simplicidad: los servicios publican eventos cuando se crean, actualizan o eliminan objetos comerciales.
Dependencias simples : no se introducen dependencias circulares.
Conexión flexible : el servicio implementa una API llamada por el orquestador, por lo que no necesita estar al tanto de los eventos publicados por los participantes de la saga.
Lógica empresarial simplificada : en el orquestador de saga, la lógica de coordinación de saga está localizada. Los objetos de dominio desconocen las sagas en las que están involucrados.

5.2.2 Desventajas basadas en la coreografía

Más difícil de entender: la orquestación distribuye la implementación de saga entre los servicios, y cada servicio es independiente, lo que requiere que cada administración comprenda cada servicio.
Dependencias circulares entre servicios : los participantes de la saga se suscriben a los eventos de los demás, lo que a menudo crea dependencias circulares.
Riesgo de acoplamiento estrecho : los participantes de una saga deben suscribirse a todos los eventos que les afectan.

Orquestación : la lógica de coordinación de una saga debe centralizarse en una clase orquestadora de saga. Durante una saga, el orquestador envía mensajes de comando a los participantes, diciéndoles qué acciones deben realizar.

Patrones de diseño de datos para la arquitectura de microservicios