web services - orientada - Arquitectura de microservicios: uso compartido de datos cruzados
microservicios base de datos (3)
Considere los siguientes micro servicios para un proyecto de tienda en línea:
El Servicio de Usuarios mantiene los datos de la cuenta sobre los usuarios de la tienda (incluyendo nombre, apellido, dirección de correo electrónico, etc.)
El servicio de compras realiza un seguimiento de los detalles sobre las compras de los usuarios.
Cada servicio proporciona una interfaz de usuario para ver y administrar sus entidades relevantes. La página de índice del Servicio de compras enumera las compras. Cada artículo de compra debe tener los siguientes campos:
Identificación, nombre completo del usuario que compra, título del artículo comprado y precio.
Además, como parte de la página de índice, me gustaría tener un cuadro de búsqueda para permitir que el gerente de la tienda busque compras comprando el nombre de usuario.
No tengo claro cómo recuperar los datos que no tiene el Servicio de compras, por ejemplo, el nombre completo de un usuario. El problema empeora cuando intenta hacer cosas más complicadas, como compras de búsqueda comprando el nombre de usuario.
Pensé que obviamente puedo resolver esto al sincronizar usuarios entre los dos servicios al transmitir algún tipo de evento en la creación del usuario (y guardar solo las propiedades de usuario relevantes en el servicio de compra). Eso está lejos de ser ideal en mi perspectiva. ¿Cómo lidias con esto cuando tienes millones de usuarios? ¿crearías millones de registros en cada servicio que consume datos de los usuarios?
Otra opción obvia es exponer una API al final del Servicio de usuarios que devuelve detalles del usuario basados en identificadores proporcionados. Eso significa que cada carga de página en el Servicio de compras, tendré que hacer una llamada al Servicio de usuarios para obtener los nombres de usuario correctos. No es ideal, pero puedo vivir con eso.
¿Qué hay de implementar una búsqueda de compra basada en el nombre de usuario? Bueno, siempre puedo exponer otro punto final de la API al final del Servicio de usuarios que recibe el término de consulta, realizar una búsqueda de texto sobre nombres de usuarios en el Servicio de usuarios y luego devolver todos los detalles de usuario que coinciden con los criterios. En el Servicio de compras, asigne los ID relevantes a los nombres correctos y muéstrenlos en la página. Este enfoque tampoco es ideal.
¿Me estoy perdiendo de algo? ¿Hay otro enfoque para implementar lo anterior? ¿Tal vez el hecho de que estoy enfrentando este problema es una especie de olor a código? me encantaría escuchar otras soluciones.
Está bien mantener los datos apropiados en diferentes bases de datos, se llama Polyglot Persistence . Sí, le gustaría mantener los datos y datos del usuario sobre las compras por separado y usar la cola de mensajes para sincronizar. Millones de usuarios me parecen bien, es escalabilidad, no problema de diseño ;-)
En caso de búsqueda, es probable que desee buscar más que simplemente nombre de usuario, ¿verdad? Por lo tanto, si utiliza la cola de mensajes para actualizar datos entre servicios, también puede enrutar fácilmente estos datos a ElasticSearch, por ejemplo. Y desde la perspectiva de ElasticSearch, realmente no importa qué campo indexar: nombre de usuario o título del producto.
Esta parece ser una pregunta muy común y central al pasar a microservicios. Ojalá hubiera una buena respuesta para eso :-)
Sobre el patrón sugerido ya mencionado aquí, usaría el término Denormalización de Datos en lugar de Persistencia Polyglot, ya que no necesariamente tiene que estar en diferentes tecnologías de persistencia. El punto es que cada servicio maneja sus propios datos. Y sí, tiene duplicación de datos y generalmente necesita algún tipo de bus de eventos para compartir datos entre servicios.
Hay otra opción, que es una especie de opinión sobre la primera: hacer la búsqueda en sí misma como un servicio separado.
Entonces, en su ejemplo, tiene el servicio de usuario para administrar usuarios. Los servicios de compras administran las compras. Cada uno maneja sus propios datos y solo los datos que necesita (por lo que, por ejemplo, el servicio de Compras realmente no necesita el nombre de usuario, solo el ID). Y tiene un tercer servicio, el Servicio de búsqueda, que consume datos producidos por otros servicios y crea una "vista" de búsqueda a partir de los datos combinados.
Usualmente uso ambos enfoques. A veces tengo otro servicio que está encima de otros servicios y combina los datos. Realmente no me gusta este enfoque porque está causando dependencias y acoplamiento entre servicios. Entonces, en general, en mis últimos proyectos, intentamos mantener la persistencia políglota.
También piense, si necesita tener x solicitudes HTTP sub para combinar datos en algún tipo de servicio de middleware, lo llevará a una mayor latencia. Siempre intentamos reducir la cantidad de solicitudes para una tarea y manejar todo lo que es posible a través de colas asincrónicas. (especialmente sincronización de datos)