¿Es una mala práctica que los servicios compartan una base de datos en SOA?

16

Recientemente he estado leyendo los Patrones de integración empresarial de Hohpe y Woolf, algunos de los libros de Thomas Erl sobre SOA y viendo varios videos y podcasts de Udi Dahan et al. en CQRS y sistemas controlados por eventos.

Los sistemas en mi lugar de trabajo sufren un alto acoplamiento. Aunque cada sistema en teoría tiene su propia base de datos, existe una gran cantidad de unión entre ellos. En la práctica, esto significa que hay una gran base de datos que utilizan todos los sistemas. Por ejemplo, hay una tabla de datos de clientes.

Gran parte de lo que he leído parece sugerir desnormalizar datos para que cada sistema use solo su base de datos, y cualquier actualización de un sistema se propague a todos los demás mediante mensajes.

Pensé que esta era una de las maneras de imponer los límites en SOA: cada servicio debería tener su propia base de datos, pero luego leí esto:

enlace

y sugiere que esto es incorrecto.

Segregar las bases de datos parece ser una buena manera de desacoplar los sistemas, pero ahora estoy un poco confundido. ¿Es esta una buena ruta para tomar? ¿Se recomienda alguna vez que segregar una base de datos, decir un servicio SOA, un contexto DDD Bounded, una aplicación, etc.?

    
pregunta Paul T Davies 24.10.2011 - 17:42

5 respuestas

12

El desacoplamiento solo funciona si realmente hay separación. Considera si tienes un sistema de pedido:

  • Tabla: CLIENTE
  • Tabla: ORDEN

Si eso es todo lo que tienes, no hay razón para desacoplarlos. Por otro lado, si tienes esto:

  • Tabla: CLIENTE
  • Tabla: ORDEN
  • Tabla: CUSTOMER_NEWSLETTER

Entonces podría argumentar que ORDER y CUSTOMER_NEWSLETTER son parte de dos módulos totalmente separados (pedidos y mercadeo). Quizás tenga sentido moverlos a bases de datos separadas (una para cada tabla) y que ambos módulos compartan el acceso a la tabla de CLIENTES común en su propia base de datos.

Al hacerlo, está simplificando cada módulo, pero está aumentando la complejidad de su capa de datos. A medida que su aplicación crece más y más, puedo ver una ventaja al separar. Habrá más y más "islas de datos" que realmente no tienen relación entre sí. Sin embargo, siempre habrá algunos datos que cruzan todos los módulos.

La decisión de colocarlos en diferentes bases de datos físicas generalmente se basaría en restricciones del mundo real, como la frecuencia de las copias de seguridad, las restricciones de seguridad, la replicación en diferentes ubicaciones geográficas, etc. No separaría las tablas en diferentes bases de datos físicas solo debido a separando preocupaciones Eso se puede manejar de manera más simple con diferentes esquemas o vistas.

    
respondido por el Scott Whitlock 24.10.2011 - 18:00
8

Donde trabajo, tenemos un ESB a la que están conectadas 6 aplicaciones diferentes (o debería decir "puntos finales") . Esas 6 aplicaciones funcionan con 3 esquemas de Oracle diferentes en 2 instancias de base de datos. Algunas de estas aplicaciones coexisten en el mismo esquema no porque estén relacionadas, sino porque nuestra infraestructura de base de datos está administrada por un proveedor externo y obtener un nuevo esquema solo toma una eternidad (también, por supuesto, no tenemos acceso a DBA) ... realmente toma tanto tiempo que en un momento pensamos en reutilizar un esquema existente "temporalmente" para poder continuar con el desarrollo. Para imponer la "separación" de los datos, los nombres de las tablas tienen un prefijo, por ejemplo, "CST_" para el cliente. Además, tenemos que trabajar con un esquema que, por algunas razones válidas, no podemos cambiar de manera absoluta ... Es extraño, lo sé. Por supuesto, como siempre sucede, "temporalmente" se ha convertido en "temporar-namently" si sabes lo que quiero decir ;-)

Nuestras diferentes aplicaciones se conectan a sus respectivos esquemas de base de datos y trabajan con sus propios paquetes PL / SQL y nos prohibimos totalmente interactuar directamente con tablas / datos que están fuera de nuestro dominio de aplicación.

Cuando una de las aplicaciones conectadas al ESB necesita información fuera de su dominio, llama al servicio relacionado en el ESB para obtener los datos, incluso si esa información está de hecho en el mismo esquema, lo que requiere en teoría solo una pequeña declaración de unión en una de las solicitudes SQL .

Hacemos eso para poder dividir nuestro dominio de aplicación en diferentes esquemas / bases de datos, y para que los servicios en el ESB sigan funcionando correctamente cuando ocurra (es Navidad muy pronto, estamos tramando los dedos)

Ahora, esto puede parecer extraño y horrible desde el exterior, pero hay razones para eso y solo quería compartir esta experiencia concreta para mostrarle que una o más bases de datos no son tan importantes. ¡Espera, lo es! , por muchas razones (+1 para Scott Whitlock, consulta el último párrafo sobre la copia de seguridad y por lo que te pueden meter en problemas). Pero es igual de importante que creo que tus servicios SOA sean bien diseñado, al menos esa es mi opinión, y no soy un DBA. En última instancia, todas sus bases de datos pertenecen a su "datawarehouse empresarial", ¿no?

Finalmente, no reformularé el último párrafo de Scott Whitlock, particularmente este

  
    

No separaría las tablas en diferentes bases de datos físicas solo por cuestiones de separación.

  

es realmente super importante. No lo hagas si no hay razón.

    
respondido por el Jalayn 24.10.2011 - 18:56
7

He visto las peores pesadillas posibles en la arquitectura de software debido a la integración de datos, y la mejor arma contra este tipo de desorden con el que me he topado hasta ahora en los contextos delimitados con DDD-Style. Lo que no está muy lejos de "SOA hecho bien", en cierto sentido.

Sin embargo, los datos en sí no son la mejor manera de atacar el problema. Uno debe centrarse en el comportamiento esperado / necesario y llevar los datos a donde importa. Es posible que terminemos teniendo algo de duplicación de esta manera, pero esto no suele ser un problema en comparación con los bloques de la evolución del sistema, casi siempre asociados con arquitecturas integradas en datos.

Para simplificarlo: si está buscando sistemas acoplados libremente, no permanezca acoplado a los datos. Opte por sistemas encapsulados y un canal de comunicación bien estructurado en el medio, que actúe como "lingua franca".

    
respondido por el ZioBrando 12.11.2011 - 15:54
6

El desacoplamiento de las bases de datos y mantener los datos consistentes entre ellos es una tarea de nivel experto. Es muy fácil equivocarse y terminar con los problemas de duplicados, etc., que el sistema actual está diseñado para evitar. Francamente, tomar un sistema en funcionamiento y hacer esto es prácticamente una garantía de introducir nuevos errores sin valor real para los usuarios.

    
respondido por el HLGEM 24.10.2011 - 19:12
1

Si se hace correctamente, separar las preocupaciones comerciales en diferentes bases de datos (o al menos diferentes esquemas) es una virtud .

Consulte la descripción de Martin Fowler del patrón CQRS :

  

A medida que nuestras necesidades se vuelven más sofisticadas, nos alejamos constantemente de [tratar un sistema de información como un almacén de datos CRUD] ... El cambio que introduce CQRS es dividir ese modelo conceptual en modelos separados para actualizar y mostrar ... Hay espacio por variación considerable aquí. Los modelos en memoria pueden compartir la misma base de datos, en cuyo caso la base de datos actúa como la comunicación entre los dos modelos. Sin embargo, también pueden usar bases de datos separadas , lo que hace que la base de datos del lado de la consulta se realice de forma efectiva mediante una base de datos de informes en tiempo real. En este caso, debe existir algún mecanismo de comunicación entre los dos modelos o sus bases de datos.

Y Principios arquitectónicos de NServiceBus :

  

Separación de consulta de comando

     

Una solución que evita este problema separa los comandos y las consultas a nivel del sistema, incluso por encima del cliente y el servidor. En esta solución hay dos "servicios" que abarcan tanto al cliente como al servidor: uno a cargo de los comandos (crear, actualizar, eliminar) y el otro a cargo de las consultas (leer). Estos servicios se comunican solo a través de mensajes: uno no puede acceder a la base de datos del otro ...

Y Segregación de responsabilidad de comando y consulta (CQRS)

  

Segregación de responsabilidad de comando y consulta

     

La mayoría de las aplicaciones lee los datos con más frecuencia que los que escriben. Sobre la base de esa declaración, sería una buena idea hacer una solución donde fácilmente pueda agregar más bases de datos para leer, ¿verdad? Entonces, ¿qué pasa si configuramos una base de datos dedicada solo para leer? Aun mejor; ¿Qué pasa si diseñamos la base de datos de manera que sea más rápido leerla? Si diseña sus aplicaciones basándose en los patrones descritos en la arquitectura CQRS, tendrá una solución escalable y rápida para leer datos.

    
respondido por el Jim G. 24.01.2015 - 00:45

Lea otras preguntas en las etiquetas