database - modelado - microservicios sql server

Microservicios y uniones de bases de datos

Question

Para las personas que están dividiendo las aplicaciones monolíticas en microservicios, ¿cómo manejan el enigma de separar la base de datos? Las aplicaciones típicas en las que he trabajado hacen mucha integración de bases de datos por razones de rendimiento y simplicidad.

Si tiene dos tablas que son lógicamente distintas (contextos delimitados si lo desea) pero a menudo realiza un procesamiento agregado en grandes volúmenes de esos datos, entonces en el monolito es más que probable que evite la orientación de los objetos y, en su lugar, use el estándar de su base de datos ÚNASE para procesar los datos en la base de datos antes de devolver la vista agregada a su nivel de aplicación.

¿Cómo justifica dividir dichos datos en microservicios donde presumiblemente se le requerirá ''unir'' los datos a través de una API en lugar de hacerlo en la base de datos?

Leí el libro de microservicios de Sam Newman y en el capítulo sobre la división del Monolito, da un ejemplo de "Rompiendo relaciones de clave externa", donde reconoce que hacer una unión a través de una API será más lento, pero continúa diciendo si su aplicación es lo suficientemente rápida de todos modos, ¿importa que sea más lenta que antes?

Esto parece un poco simplista? ¿Cuáles son las experiencias de las personas? ¿Qué técnicas usaste para hacer que las uniones API funcionen de manera aceptable?

Answer 1

CQRS --- Command Query Aggregation Pattern es la respuesta a esto según Chris Richardson. Deje que cada microservicio actualice su propio Modelo de datos y genere los eventos que actualizarán la vista materializada que tiene los datos de unión requeridos de microservicios anteriores. Este MV podría ser cualquier NoSql DB o Redis o Elasticsearch optimizado para consultas. Esta técnica conduce a una consistencia eventual que definitivamente no es mala y evita las uniones del lado de la aplicación en tiempo real. Espero que esto responda.

Answer 2

En Microservices creas diff. leer modelos, por ejemplo, por ejemplo: si tiene dos diferencias. contexto limitado y alguien quiere buscar en ambos datos, entonces alguien necesita escuchar los eventos de ambos contextos limitados y crear una vista específica para la aplicación.

En este caso, se necesitará más espacio, pero no se necesitarán combinaciones ni combinaciones.

Answer 3

Está bien que los servicios tengan copias replicadas de solo lectura de ciertos datos de referencia de otros servicios.

Dado eso, cuando intente refactorizar una base de datos monolítica en microservicios (en lugar de reescribir), lo haría

• crear un esquema db para el servicio
• crear * vistas versionadas ** en ese esquema para exponer datos de ese esquema a otros servicios
• hacer une contra estos puntos de vista de solo lectura

Esto le permitirá modificar de forma independiente los datos / estructuras de la tabla sin interrumpir otras aplicaciones.

En lugar de usar vistas, también podría considerar usar disparadores para replicar datos de un esquema a otro.

Esto sería un progreso incremental en la dirección correcta, estableciendo las uniones de sus componentes, y un cambio a REST se puede hacer más adelante.

* Las vistas se pueden ampliar. Si se requiere un cambio importante, cree un v2 de la misma vista y elimine la versión anterior cuando ya no sea necesario. ** o Funciones con valores de tabla, o Sprocs.

Answer 4

Separaría las soluciones para el área de uso, por ejemplo, operacional y de informes.

Para los microservicios que operan para proporcionar datos para formularios individuales que necesitan datos de otros microservicios (este es el caso operativo), creo que usar uniones API es el camino a seguir. No irá por grandes cantidades de datos, puede hacer la integración de datos en el servicio.

El otro caso es cuando necesita hacer grandes consultas sobre una gran cantidad de datos para realizar agregaciones, etc. (el caso del informe). Para esta necesidad, pensaría en mantener una base de datos compartida, similar a su esquema original y actualizarla con eventos de sus bases de datos de microservicios. En esta base de datos compartida, podría continuar utilizando sus procedimientos almacenados, lo que le ahorraría esfuerzo y respaldaría las optimizaciones de la base de datos.

Answer 5

• Cuando el rendimiento o la latencia no importan demasiado (sí, no siempre los necesitamos), está perfectamente bien usar API RESTful simples para consultar los datos adicionales que necesita. Si necesita hacer varias llamadas a diferentes microservicios y devolver un resultado, puede usar el patrón API Gateway .

• Está perfectamente bien tener redundancia en entornos de persistencia Polyglot . Por ejemplo, puede usar la cola de mensajería para sus microservicios y enviar eventos de "actualización" cada vez que cambie algo. Otros microservicios escucharán los eventos requeridos y guardarán datos localmente. Entonces, en lugar de consultar, mantiene todos los datos requeridos en el almacenamiento adecuado para microservicios específicos.

• Además, no se olvide del almacenamiento en caché :) Puede usar herramientas como Redis o Memcached para evitar consultar otras bases de datos con demasiada frecuencia.