Microservicios sin duplicación de datos.

Me resulta difícil evitar la duplicación de datos o una base de datos compartida, incluso para el diseño de microservicios más simple, lo que me hace pensar que me falta algo. Aquí hay un ejemplo básico del problema que estoy enfrentando. Asumiendo que alguien está usando una aplicación web para administrar un inventario, necesitaría dos servicios; uno para el inventario que administra los artículos y la cantidad en stock y un servicio de usuarios que administraría los datos de los usuarios. Si queremos una auditoría de quién almacenó la base de datos, podríamos agregar el ID de usuario a la base de datos para el servicio de inventario como último inventario por valor.

Al usar la aplicación, es posible que queramos ver todos los artículos que se están agotando, y una lista de quién los almacenó la última vez para que podamos pedirles que lo repongan nuevamente. Utilizando la arquitectura descrita anteriormente, se realizaría una solicitud al servicio de inventario para recuperar los detalles del artículo de todos los artículos en los que la cantidad es inferior a 5. Esto devolvería una lista que incluye los ID de usuario. Luego, se realizaría una solicitud por separado al servicio de usuarios para obtener el nombre de usuario y los detalles de contacto para la lista de ID de usuario obtenida del servicio de inventario.

Esto parece terriblemente ineficiente y no se necesitan muchos más servicios antes de realizar múltiples solicitudes a diferentes API de servicios, que a su vez realizan múltiples consultas a la base de datos. Una alternativa es replicar los detalles de los usuarios en los datos del inventario. Cuando un usuario cambia sus datos de contacto, deberíamos replicar el cambio a través de todos los demás servicios. Pero esto no parece encajar con la idea de contexto acotado de los microservicios. También podríamos usar una sola base de datos y compartirla entre diferentes servicios, y tener todos los problemas de una base de datos de integración .

¿Cuál es la forma correcta / mejor de implementar esto?

Extrañé por completo dónde se te pide que dupliques.

Un principio central de los microservicios es que el servicio sea la autoridad única. Eso significa que el inventario y la gestión de usuarios pueden estar completamente separados. Diseñaría la gestión de usuarios para que ni siquiera sepa que existe el sistema de inventario.

Pero diseñaría el sistema de inventario para que nunca almacene nada sobre los usuarios que no sea una identificación de usuario. Eso se ocupa de su problema de propagar los cambios de información del usuario.

En cuanto a las cosas que necesitan información de inventario e información del usuario, como registros, auditorías e impresiones, no se actualizan a medida que la información cambia. Son un registro de lo que fue. De nuevo, no propagas el cambio.

Entonces, en todos los casos, cuando desea la información de usuario más reciente, solicita el servicio de información de usuario.

Me resulta difícil evitar la duplicación de datos ...

Según el ebook de Microsoft sobre arquitectura de microservicios , no hay nada de malo en la duplicación de datos. Básicamente, la duplicación de datos aumenta el desacoplamiento entre los servicios y, por lo tanto, fortalece sus roles como una autoridad única. Un pasaje relevante:

Y finalmente (y aquí es donde surgen la mayoría de los problemas cuando se construyen microservicios), si su microservicio inicial necesita datos que originalmente pertenecen a otros microservicios, no confíe en hacer solicitudes sincrónicas para esos datos. En su lugar, replique o propague esos datos (solo los atributos que necesita) en la base de datos del servicio inicial usando la consistencia eventual (típicamente usando eventos de integración ...

se realizaría una solicitud al servicio de inventario para recuperar los detalles del artículo de todos los artículos donde la cantidad es inferior a 5. Esto devolvería una lista que incluye las ID de usuario. Luego, se realizaría una solicitud por separado al servicio de usuarios para obtener el nombre de usuario y los detalles de contacto para la lista de ID de usuario obtenida del servicio de inventario.

De hecho si.

De acuerdo, en un monolito podría tener un modelo de inventario al que consulta los elementos relevantes, introducirlo en un modelo de usuario y obtener los mismos datos.

O podría llevarlo más lejos, si los tiene en la misma base de datos relacional y escribe SQL y la base de datos tomará la tabla de inventario y la tabla de usuario, hace algo de magia y obtiene los datos que busca.

Independientemente de cómo lo hagas, en algún lugar habrá un código que esencialmente obtiene una lista de identificadores de usuario del sistema de inventario, los introduce en el sistema de usuario y compila una lista de datos.

La pregunta que debe responder es sobre el rendimiento y el mantenimiento y otras cualidades "suaves".

El principal beneficio de los microservicios es el escalado.Si tiene diez mil usuarios en una máquina y es un poco lento, puede agregar otra máquina y el sistema se vuelve el doble de rápido. Agregue ocho más y es diez veces más rápido. (La escala lineal es probablemente optimista, pero es lo ideal y no eso irracional esperar).

Y esto es por servicio . Si el sistema de inventario es el cuello de botella, se usa para más que informes sobre usuarios, puede agregar más máquinas solo a ese servicio . Las máquinas también pueden ser especializadas; Este servicio necesita mucha memoria, hace cálculos pesados ​​y necesita más CPU.

Si no necesita el escalado, hay otro beneficio de los microservicios: son modulares . Por supuesto, las aplicaciones monolíticas también pueden ser modulares, y tiene una base de datos normalizada y ... pero en la práctica, las paredes entre módulos son como paredes de vidrio en el mejor de los casos y líneas en la arena en el peor de los casos. Los microservicios están separados por acero sólido.

Si su sistema de usuario literalmente se incendia, eso no afectará a su sistema de inventario en lo más mínimo. No podrá imprimir informes bonitos sobre quién almacenó qué, pero los clientes podrán realizar pedidos seguros sabiendo que los artículos almacenados están allí.

Y no duplica datos en microservicios , como tampoco lo hace en una base de datos relacional (*). En una base de datos relacional puede hacer una unión , y el equivalente es fusionar las listas en código como se describe.

También puedes agregar una vista , el equivalente es agregar un nuevo servicio que combine por usted; eso resultaría en tres solicitudes; uno para el nuevo servicio y luego ese servicio hace los dos originales. Las bases de datos relacionales tienen elementos sofisticados que optimizan las vistas, que deben implementarse en el nivel de servicio. No lo obtienes "gratis".

El almacenamiento en caché es diferente de la duplicación de datos en que si dos valores no coinciden, usted sabe cuál está mal. A menudo se usa en microservicios para aumentar la disponibilidad a expensas de la coherencia (teorema CAP). Dado que las bases de datos relacionales eliminan completamente la disponibilidad en el altar de la consistencia, es menos común en ellas. Diría que no hay nada inherente en los microservicios que facilite el almacenamiento en caché, pero en la práctica el almacenamiento en caché es una preocupación principal y que facilita el almacenamiento en caché en microservicios .

(*) Si tiene sentido duplicar datos en un enjambre de microservicios, entonces probablemente tendría sentido en la base de datos relacional equivalente a.