Micro-servicios y replicación de datos

Formé 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 dirigida por eventos nos permitirían a corregir la base de datos de datos compartidos subyacente de la bola de barro.

Lo que aprendimos fue que los microservicios y una arquitectura dirigida por eventos nos obligaron a deshacernos de la base de datos subyacente de bola de barro de datos compartidos.

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

Si usted comparte los datos, ciertamente solo un servicio puede TENER UN REGISTRO; es el único servicio que escribe en el registro, y cualquier otro usuario de los mismos datos debe 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 que los datos en esa forma? Tal vez quiera una agregación. ¿Obtiene su servicio de "propietario / escritura" para escribir datos agregados en beneficio de otro servicio? Te aconsejo que no.

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

La mejor solución que tuvimos fue una duplicación significativa y la desnormalización de nuestros datos. Los servicios de micro 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 despacho postal deba 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 despacho" incluye la dirección de destino como parte de los datos del mensaje, entonces el servicio de despacho ya no necesita rastrear las direcciones cambiantes relacionadas con los clientes; solo direcciones de punto en el tiempo relacionadas con los 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 direcciones procesa el comando inicial desde la interfaz de usuario. Una vez que sus datos son correctos, publica un evento para notificar a todos los demás servicios interesados "Dirección de 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 tenga que realizar una acción importante, debe tener una copia de la información lo suficientemente actualizada para actuar correctamente, ya sea que se realice un seguimiento independiente o como parte del mensaje que está respondiendo. a.

El almacenamiento de datos compartido iría en contra de la arquitectura de 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 más que el servicio completo. Sus microservicios no serían independientes si compartieran el almacenamiento común y cualquier cambio en el mecanismo de almacenamiento, la validación u otras restricciones tendrían que implementarse en ambos servicios. En la práctica, esto nunca sucede y pronto hace que se eviten cambios serios en ambas aplicaciones.

Por lo tanto, use un servicio como la única forma de acceder a sus datos, por ejemplo. Cuentas Puede suceder que la implementación de 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 de información específica posible debe ir al microservicio de Cuentas.

  

necesitaría tener acceso a las mismas instancias de datos maestros, p. ej.   Cuentas, Productos

No es lo mismo. Cada microservicio debe hacer su propio mapeo de Cuentas, Productos, etc. Estamos asumiendo que cada microservicio tendrá una forma diferente de trabajar con las entidades.

En Domain Driven Design esto es común, donde cada contexto acotado (¡en la misma aplicación!) puede asignar la misma entidad de una manera diferente.

Si necesita más información, le recomiendo el libro Microservicios de construcción: Diseño de sistemas de grano fino

¿Ha considerado el concepto de registros de esqueleto basados en un conjunto maestro?

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