architecture - pattern - Arquitectura de base de datos compartida frente a mensajería

multiple microservices same database

Question

Estuve ayer en el pub con un amigo y comenzamos a hablar de la arquitectura en uso en la empresa en la que trabaja. La conversación básicamente rodeó las ventajas y desventajas de una arquitectura de base de datos compartida frente a una arquitectura distribuida de aplicaciones independientes: no pudimos llegar a un consenso, en cuyo caso me gustaría escuchar las opiniones de las personas sobre los pros / contras de ambos enfoques.

Básicamente, la empresa para la que trabaja tiene una gran arquitectura con muchas aplicaciones diferentes. Algunas aplicaciones tienen una sola base de datos que comparten entre ellas. Por ejemplo, hay 1 aplicación que proporciona una interfaz de usuario para que los usuarios alteren los datos de referencia. Esta información de referencia es utilizada por otra aplicación que también accede a los mismos datos. Creo que el código en realidad está escrito como bibliotecas compartidas (es decir, ambas aplicaciones usarán un conjunto de códigos común que se redistribuirá para cada uno (uno lo tiene como dependencia)).

También hay otras aplicaciones con una base de datos que también usan otras aplicaciones mediante conexión JDBC directa con código de acceso a datos (no es común entre las dos aplicaciones, ¡duplicado! ¡Erghh!).

Mi pregunta es sobre los pros / contras de esta arquitectura frente a una arquitectura donde cada aplicación contiene sus datos "maestros" en el silo. Si una aplicación x requiere datos de la aplicación y usan servicios web o alguna tecnología de mensajería para recibir esa información.

El enfoque de mensajería introduciría un problema por el cual los ''códigos'' de datos de referencia (o claves externas) que se usan dentro de los db de otras aplicaciones, ahora tienen que ser obtenidos de otra fuente. En la arquitectura actual, las "decodificaciones" de estos pueden cambiar en cualquier momento y reflejarse en la aplicación externa de inmediato, en lugar de tener que tener una relación maestro / esclavo donde se copian los datos, o una alternativa donde la aplicación x tiene que consultar la aplicación y solo para mostrar los valores de decodificación.

Había leído Enterprise Integration Patterns y, aunque ofrece algunos ejemplos de las ventajas de la mensajería, no estoy tan convencido.

Gracias Iain

Answer 1

Aquí hay una estafa de una arquitectura de base de datos compartida, que es suficiente para evitarlo:

Acoplamiento ajustado : si una aplicación requiere cambios en las tablas maestras de la base de datos, las otras aplicaciones necesitarán volverse a probar y posiblemente cambiar para acomodar esos cambios.

Las arquitecturas de bases de datos compartidas terminan evitando cambios serios en el esquema. La base de datos maestra y las aplicaciones asociadas tienden a estancarse, dando como resultado una empresa que no puede ofrecer productos nuevos e innovadores.

Este artículo de MSDN , uno de muchos, explica cómo los servicios poco compactos pueden ayudar con el escenario anterior. Los sistemas débilmente acoplados pueden innovar y cambiar sin que el resto de la empresa tenga que cambiar al mismo tiempo, lo que lleva a una empresa que puede responder bien a las demandas de los clientes.

Answer 2

Estoy en el proceso de hacer que este mismo caso funcione. Creo que hay razones muy claras para usar una u otra (y algunos puntos que aún no se han hecho).

Integración de base

Pros

• Única fuente de verdad
• Transaccionalidad
• No hay nueva tecnología o middleware para administrar
• Las claves únicas son fáciles

Contras

• No escala bien Usted termina con un solo DB que ejecuta varias cargas de trabajo, como transacciones e informes, o termina con la replicación de la base de datos para distribuir la carga de producción.

• La distribución de área amplia es difícil. Las arquitecturas de sitios múltiples lo son aún más.

• La tecnología es fija y el proveedor está bloqueado
• El tipeo duro en una base de datos (suponiendo que sea SQL) fuerza las actualizaciones de todo el sistema para pequeños cambios como cambiar el tamaño de una columna.

Sistema de mensajería

Pros

• La carga se puede distribuir y se utilizan sistemas especializados que están optimizados para diversas tareas
• Los sistemas de reemplazo se pueden implementar en paralelo con los sistemas existentes.
• Los formatos de mensaje (también conocido como modelo de datos de red) se pueden versionar y se ejecutan varias versiones simultáneamente
• Toplogies complejos de área amplia pueden ser compatibles, por ejemplo, múltiples instancias con un concentrador central, múltiples instancias con todos los datos compartidos en cada instancia.
• Relativamente fácil de adaptar a los sistemas heredados y estos sistemas se pueden integrar sin mucho trabajo

Contras

• Nuevo sistema para implementar y administrar en producción.
• La transaccionalidad es difícil

Answer 3

Las ventajas de la integración basada en mensajes sobre una base de datos compartida son en mi opinión muy difíciles de articular.

Existe el argumento inevitable de que los DBA quieren modelar todas las relaciones entre las entidades para que los datos sean 100% consistentes en todo momento. Por otro lado, tiene los desarrolladores advirtiendo a los DBA sobre el acoplamiento cerrado que surge de la arquitectura monolítica y cómo las aplicaciones vinculadas a las tablas maestras no se pueden cambiar fácilmente.

Creo que estos dos argumentos están arañando la superficie y construir un sistema que sea fácil de cambiar es un desafío, independientemente de cómo se realice la integración. Quiero presentar otro tipo de argumento para SOA y la integración basada en mensajes.

Lo que se reduce a esto es esto:

1. La integración de bases de datos compartidas generalmente es impulsada por una vista del mundo de "gran sistema".
2. La integración basada en mensajes generalmente está impulsada por una visión del mundo de "sistema pequeño".

¿Cuántas veces se ha encontrado con sistemas grandes con cientos de usuarios que hacen muchos, muchos trabajos diferentes que soportan funciones comerciales múltiples y diversas? Me encuentro con ellos todo el tiempo. Son el elemento básico del software empresarial en este momento.

Una cosa que todos estos sistemas parecen tener en común es que son muy caros de cambiar. Y una de las razones para esto es, como dice Joe R en su respuesta , un acoplamiento estrecho.

Sin embargo, debemos considerar dos tipos de acoplamiento.

El primero se llama acoplamiento tecnológico y esto significa acoplamiento vertical dentro de la pila de tecnología, generalmente n-tiered, entre un nivel y otro nivel.

Así que tenemos un acoplamiento entre la base de datos y la capa de acceso a datos de una aplicación, el acoplamiento entre la capa de acceso a datos y la lógica de negocios, etc. Considerar ese acoplamiento como malo o incorrecto parece ser generalmente aceptado, pero pensar racionalmente no deberíamos esperar , o incluso bienvenido, un alto grado de acoplamiento entre, por ejemplo, el DTO de usuario, la clase UserRepository y la tabla de la base de datos de usuario?

Consideremos qué significa realmente el acoplamiento en el nivel de implementación. El acoplamiento ocurre cuando los conceptos que "pertenecen" a una cosa se filtran a otra cosa. Esta fuga es inevitable cuando tienes varias capas básicamente hablando entre sí sobre la misma entidad comercial.

El segundo tipo de acoplamiento, y el que me gustaría abordar, es el acoplamiento de capacidad comercial , también llamado acoplamiento horizontal. Aquí es donde tenemos conceptos que pertenecen a una capacidad empresarial que se filtran a otra capacidad comercial.

Es mi afirmación que este acoplamiento horizontal se fomenta mediante el uso de bases de datos como una plataforma de integración .

Como ejemplo, imagine un sistema de back-end típico que soporta un sistema de sitio web de comercio electrónico. Por lo general, tendría sus capacidades básicas de inventario, pedidos, precios y CRM.

Si modelamos este dominio dentro de una única base de datos, de hecho estamos combinando diferentes capacidades. Cada restricción de clave externa potencialmente aumenta el grado de acoplamiento entre estas capacidades. De hecho, el sistema en este punto ya puede considerarse como varios "servicios" diferentes integrados en una base de datos compartida .

Esta es la imagen del "gran sistema" del mundo, que es respaldada y fomentada mediante la vinculación de diferentes áreas de su empresa mediante enormes bases de datos de más de 500 tablas.

Contraste esto con la imagen de "sistema pequeño" del mundo, donde en nuestro ejemplo, inventario de aplicaciones web de back-end, pedidos, precios y CRM son aplicaciones completamente separadas, con sus propias pilas de tecnología, sus propios equipos de proyecto, sus propios calendarios de lanzamiento y sus propias bases de datos.

Cada aplicación, o servicio , tendrá su propia comprensión de lo que es una entidad dada, y que se ajustará a la definición de esa entidad de acuerdo con la capacidad de negocio que soporta.

Un ejemplo de esto es el "Usuario". CRM tendrá una definición de usuario muy diferente a la ordenación o el cumplimiento. El pedido solo se preocupa por el usuario en términos de lo que el usuario está comprando. CRM se preocupa por otras cosas, como los patrones de compra de los clientes, y la atención se preocupa por el nombre, la dirección, etc. Esto no se logra fácilmente con una única tabla de usuarios en una base de datos compartida.

Esta imagen para mí es preferible a la ruta de la base de datos compartida y la razón principal es que el sistema resultante modelará mejor los procesos comerciales reales que se supone que debe soportar. Uno de los principios principales de DDD es que un sistema debe parecerse tanto como sea posible al negocio que lo posee.

En un negocio típico, estas diferentes capacidades no son implementadas por un gran equipo de negocios, sino que son implementadas por pequeños equipos, a menudo completamente separados unos de otros, que se comunican entre sí a menudo mediante el envío de solicitudes y directivas, o permitiendo que otro equipo sepa que un cierto proceso o tarea ha sido iniciada / completada, etc.

OK, pero sin la base de datos compartida, el sitio web ahora depende de los datos de todos estos servicios diferentes para su interfaz de usuario. Todavía necesita mostrar estas cosas juntas en la misma pantalla. ¿Cómo puede la capa de "presentación" del sitio web armar todo esto y presentarlo en la interfaz de usuario?

Más importante aún, ¿qué pasa si CRM quiere saber cuándo un cliente ordena algo? ¿Qué sucede si el pedido quiere saber cuándo cambian los precios de los productos o cuándo los productos están agotados en el inventario? Si estos servicios están completamente separados, ¿cómo pueden intercambiar datos?

En primer lugar, abordar la cuestión de la interfaz de usuario, esto se puede hacer con interfaces de usuario compuestas . Hay muchas técnicas para esto, pero basta decir que es un paisaje relativamente conocido y no es nuestro enfoque aquí.

La segunda pregunta de cómo se comunican estos servicios es, bueno, intercambian mensajes. ¿Qué tipo de mensajes? Eventos . Los eventos son publicados por un sistema para que sean consumidos por cualquier otro sistema que esté interesado en ese evento.

En nuestro ejemplo de comercio electrónico, los tipos de eventos podrían ser:

1. OrderPlaced
2. CustomerUpgradedToGold
3. Producto descontado
4. StockExhausted

Estos eventos tienen un significado comercial. Eso significa que podemos obtener un beneficio adicional con el enfoque de sistema pequeño, que es que el medio de integración en sí tiene un significado comercial, y se puede expresar en el lenguaje comercial, que se presta bien a las metodologías de scrum y ágiles.

Entonces, no creo que desde una perspectiva tecnológica haya mucha diferencia entre los enfoques de integración de la Base de datos frente a la Mensajería. Pero creo que hay una gran diferencia en las fuerzas motrices detrás de ellos, y en mi opinión, el resultado lógico de la adopción de una mentalidad de sistemas pequeños proporciona un mejor valor empresarial en general.

Espero que esto ayude y no sea tan difícil.