Micro servicios y replicación de datos

Estoy creando una nueva aplicación y estaba leyendo sobre la arquitectura de microservicios. La arquitectura en sí tiene mucho sentido desde el punto de vista del desarrollo, la implementación y la gestión del ciclo de vida. Sin embargo, un problema que surgió fue con respecto a cómo manejar los datos maestros.

Por ejemplo, tengo 2 aplicaciones, por ejemplo, la aplicación de ventas y una aplicación de tickets. Suponga que ambas aplicaciones se crean como microservicios propios. Sin embargo, ambas aplicaciones, cuando se implementan (suponiendo que se implementan por separado, dicen que Sales usa MongoDB y Ticketing usa MariaDB), tendrían que tener acceso a las mismas instancias de datos maestros, por ejemplo, Cuentas, Productos. Esto significaría que habría una aplicación de propietario para una entidad de datos maestros dada (por ejemplo, para Cuentas, podría ser la aplicación de Ventas) y una parte interesada (por ejemplo, la aplicación de Venta de entradas necesitaría tener información sobre Cuentas).

Hay varias formas de lograrlo: - Replicación de datos de maestro a interesado - Lectura síncrona de interesado a maestro (el paradigma de la arquitectura de microservicios no recomienda la dependencia de sincronización) - Repositorio centralizado propio

Además, incluso dentro de Cuentas, puede haber una parte central que es común tanto para Ventas como para Venta de entradas (por ejemplo, nombre de cuenta, dirección, etc.). Sin embargo, algunos aspectos de la Cuenta SOLO pueden ser relevantes para Ventas y otros SÓLO relevantes para Boletos.

¿Alguna idea / mejores prácticas / opiniones sobre cualquiera de las opciones mencionadas anteriormente?

Fui parte de un equipo que construyó con éxito una arquitectura de microservicios utilizando un bus de servicio.

Inicialmente, creíamos que los microservicios y una arquitectura basada en eventos nos permitirían arreglar la base de datos subyacente de datos compartidos.

Lo que aprendimos fue que los microservicios y una arquitectura basada en eventos nos obligaron a deshacernos de la base de datos subyacente de datos compartidos.

Creo que los datos compartidos son increíblemente difíciles de hacer bien con los microservicios, para mí es extremadamente difícil. Recomiendo no permitir que los servicios vean los datos de los demás. Si no puede consultarlo, no puede introducir accidentalmente una dependencia.

Si haces compartir datos, sin duda alguna un solo servicio puede ser dueño de un registro; es el único servicio que escribe en el registro, y cualquier otro usuario de los mismos datos debería tener acceso de solo lectura.

Desafortunadamente, incluso esta pequeña cantidad administrada de intercambio introduce un acoplamiento significativo entre sus servicios. ¿Qué pasa si un servicio no quiere los datos en esa forma? Quizás quiera una agregación. ¿Obtiene su servicio de "propietario / escritura" para escribir datos agregados en beneficio de otro servicio? Yo aconsejaría que no.

¿Qué sucede si el propietario desea conservar los datos en una forma diferente? Entonces cada servicio de lector necesita ser actualizado. Esa es una pesadilla de mantenimiento.

La mejor solución que tuvimos fue una importante duplicación y desnormalización de nuestros datos. Los micro servicios mantuvieron sus propias copias de los datos que les interesaban.

Los mensajes a menudo se publicaban con suficientes datos de acompañamiento para procesarlos.

Por ejemplo, puede imaginar que un servicio de envío postal puede necesitar realizar un seguimiento de los cambios en la dirección de un cliente, en caso de que necesite publicar algo. Pero si su mensaje "artículo listo para envío" incluye la dirección de destino como parte de los datos del mensaje, entonces el servicio de envío ya no necesita rastrear direcciones cambiantes relacionadas con los clientes; solo direcciones de punto en el tiempo relacionadas con elementos a medida que se envían.

No puedo sugerir cómo diseñar soluciones con datos sincronizados. Nuestras soluciones de datos se construyeron alrededor de la idea de "consistencia eventual".

Entonces, cuando un cliente actualiza su dirección, el servicio de Dirección procesa el comando inicial desde la IU. Una vez que sus datos son correctos, publica un evento para notificar a todos los demás servicios interesados ​​"Dirección del cliente actualizada", con la dirección completa adjunta como datos. Esos servicios actualizarán sus propios almacenes de datos con las partes de los datos que les interesan.

La idea es que cada vez que un servicio tiene que tomar una acción importante, debe tener una copia de la información lo suficientemente actualizada como para actuar correctamente, ya sea de forma independiente o como parte del mensaje al que está respondiendo.

El almacenamiento de datos compartidos iría en contra de la arquitectura del microservicio. El punto es que si hay Cuentas, debería haber un servicio para manejarlas y no debería haber otra forma de interactuar con estas Cuentas que a través del servicio. Sus microservicios no serían independientes si compartieran almacenamiento común y cualquier cambio en el mecanismo de almacenamiento, validación u otras restricciones tendrían que implementarse en ambos servicios. En la práctica, esto nunca sucede y pronto hace que se evite que ambas aplicaciones sufran cambios graves.

Por lo tanto, utilice un servicio como la única forma de acceder a sus datos, por ejemplo, Cuentas. Puede suceder que implementar una función en algún otro servicio requiera un cambio en el servicio de Cuentas, y eso está bien. Solo recuerde que la lógica específica de cualquier servicio debe estar en ese servicio y la menor cantidad posible de cosas específicas debe ir al microservicio de Cuentas.

necesitaría tener acceso a las mismas instancias de datos maestros, por ejemplo, Cuentas, Productos

No es el mísmo. Cada micro servicio debe hacer su propio mapeo para Cuentas, Productos, etc. Asumimos que cada micro servicio tendrá una forma diferente de trabajar con las entidades.

En el diseño impulsado por dominio esto es común, donde cada contexto acotado (¡en la misma aplicación!) Puede mapear la misma entidad de una manera diferente.

Si necesita más información, le recomiendo el libro Building Microservices: Designing Fine-Grained Systems

¿Has considerado el concepto de esqueleto de registros basado en un conjunto maestro?

Por ejemplo, un microservicio maneja cuentas y el otro maneja productos. Un tercero puede mantener registros de ambos para su propósito específico de dominio.