Refactorización fuera del patrón de base de datos compartida

Question

En el trabajo, tenemos varias aplicaciones con bases de datos en un servidor SQL centralizado. Cuando una aplicación necesita trabajar con datos de otra aplicación, solo la consulta o la actualiza a través de la base de datos. Creo que este es el patrón de "Base de Datos Compartida" como se describe en el libro de Patrones de Integración Empresarial (Hohpe & Woolf).

Estas dependencias cruzadas de bases de datos nos están causando muchos, muchos dolores de cabeza. El más grande de estos en este momento es que nos encontramos con problemas de rendimiento en el servidor SQL, y no podemos escalar debido a las dependencias entre bases de datos. Creo que lo que debemos hacer es alejarnos del patrón Shared Database hacia un sistema de mensajería como se describe en el libro EIP. Cada aplicación sería responsable de todos sus propios datos, y otras aplicaciones que quieran acceder a esos datos la obtendrían a través de los servicios (¿en un bus de mensajería?).

• ¿Por dónde empezamos a refactorizar hacia el patrón de mensajes?
• ¿Comenzamos refacturando una de las aplicaciones para administrar su propia base de datos de aplicaciones?
• ¿Qué pasa con las otras aplicaciones actualmente integradas con esa a través de la base de datos?
• ¿Es esta la mejor manera de desacoplar nuestras dependencias de bases de datos o deberíamos comenzar en otro lugar?

Answer 1

Sugeriría una transición de 3 fases.

1. Agregue una capa de mensajes a cada una de sus aplicaciones.
2. Cambie todo el acceso a datos entre aplicaciones para usar la capa de mensajes recién creada.
3. Escale las bases de datos (ahora independientes) según sea necesario.

Además, supongamos que tiene 3 aplicaciones; A, B y C.

También puede ver esto como 3 transiciones separadas:

• Aplicación A

  • Añadir mensajería a un
  • Cambio llamadas a A en B & C

• Aplicación B

  • Añadir mensajería a B
  • Cambio llamadas a B en un & C

• Aplicación C

  • Añadir mensajería a C
  • Cambio llamadas a C en A & B

En este punto del proceso, los resultados son los mismos que al final de la fase 2, y la fase 3 puede continuar. La diferencia es simplemente si es más productivo enfocarse en un tipo de refactorización o enfocarse en una aplicación.

Answer 2

La mensajería puede ser una de las maneras más elegantes de ir. Sin embargo, también requiere un poco de trabajo y tendrá que cambiar con el tiempo a medida que cambia cada base de datos. Hemos adoptado el enfoque "más fácil" simplemente haciendo que cada aplicación sepa cómo iniciar sesión en la otra base de datos, y luego consultar cada base de datos desde allí. Hemos encontrado que la mayoría de las consultas cruzadas de bases de datos son bastante livianas y, por lo tanto, no representan una base de código sustancial en la segunda aplicación. Existe cierta duplicación de consultas de selección, pero ha sido menos trabajo de lo que hubiera sido un sistema de mensajes.

Todo depende del grado en el que empujará y extraerá datos. Si es sustancial, los mensajes son la mejor manera de hacerlo. Si es mínimo, tal vez una nueva conexión simple a la otra base de datos sea un camino a seguir.

Answer 3

También consideraría cómo usan las aplicaciones la base de datos. Normalmente, una base de datos (ambas implementaciones de diseño &) debe caer en una de dos categorías diferentes: transaccional (OLTP) o informar (OLAP).

Una base de datos transaccional bien diseñada (e implementada) debe proporcionar un rendimiento excelente en un escenario típico de aplicación de línea de negocio; Del mismo modo, una base de datos de informes bien diseñada (e implementada) debería proporcionar un excelente rendimiento al consultar grandes cantidades de complejidad de los datos.

Otra distinción importante es la diferencia entre 'tiempo real' y 'casi en tiempo real'.

Supongamos que su aplicación necesita realizar operaciones transaccionales (en tiempo real) y algunos informes sobre datos actuales/anteriores; necesitará dos almacenes de datos: uno transaccional creado únicamente para la velocidad operativa para admitir las operaciones de las aplicaciones en "tiempo real" y otro que contenga datos "históricos" que se compilarán exclusivamente para generar informes.

El truco es averiguar cuántos datos necesita conservar en el almacén de datos transaccionales y cuándo/cómo moverlos al almacén de datos de informes.