重构远离共享数据库模式

Question

在工作中，我们在集中式SQL服务器中有几个数据库应用程序。每当一个应用程序需要处理来自另一个应用程序的数据时，它只是查询它或通过数据库更新它。我相信这是“企业集成模式”一书（Hohpe＆amp; Woolf）中描述的“共享数据库”模式。

这些跨数据库依赖性正在给我们带来许多令人头疼的问题。现在最大的问题是我们在SQL服务器上遇到性能问题，并且由于跨数据库依赖性而无法扩展。我认为我们应该做的是从共享数据库模式转向EIP手册中描述的消息传递系统。每个应用程序都将负责所有自己的数据，而其他想要访问该数据的应用程序将通过服务（在消息传递总线上？）来获取它。

• 我们从哪里开始重构消息传递模式？
• 我们首先重构其中一个应用程序来管理自己的应用程序数据库吗？
• 那么其他应用程序目前通过数据库与那个应用程序集成了什么？
• 这是解耦数据库依赖关系的最佳方式，还是应该从其他地方开始？

Answer 1

我建议进行3阶段过渡。

1. 为每个应用程序添加消息传递层。
2. 更改所有跨应用程序数据访问权限以使用新创建的消息传递层。
3. 根据需要扩展（现在独立的）数据库。

另外，假设您有3个申请; A，B和C.

您还可以将其视为3个单独的过渡：

• 申请A

  • 将消息添加到A
  • 在B＆amp ;;中将呼叫更改为A. ç

• 申请B

  • 将消息添加到B
  • 在A＆amp ;;中将呼叫更改为B. ç

• 申请C

  • 将消息传递添加到C
  • 在A＆amp ;;中将呼叫更改为C.乙

在此过程中，结果与阶段2结束时的结果相同，阶段3可以继续进行。不同之处在于，专注于某种重构还是专注于应用程序是否更有效率。

Answer 2

消息传递肯定是更优雅的方式之一。但是，它还需要一些工作，并且随着每个数据库的更改而不得不随时间变化。我们采用“更简单”的方法，只需让每个应用程序知道如何登录到其他数据库，然后从那里查询每个数据库。我们发现大多数跨数据库查询非常简单，因此不会在第二个应用程序中构成实质性的代码库。选择查询有一些重复，但它的工作量比消息传递系统少。

这一切都取决于你将推动和拉动数据的程度。如果它是实质性的，那么消息传递是最好的方式。如果它是最小的，那么也许可以通过一个简单的新连接到另一个数据库。

Answer 3

我还会考虑应用程序如何使用数据库。通常，数据库（设计和实现）应分为两类：事务（OLTP）或报告（OLAP）。

设计良好（并实现）的事务数据库应该在典型的业务线应用程序场景中提供出色的性能;同样，设计良好（并实施）的报告数据库在查询大量复杂数据时应提供出色的性能。

另一个重要区别是“实时”和“近实时”之间的差异。

让我们假设您的各种应用程序需要执行事务（实时）操作和一些当前/旧数据的报告;您需要两个数据存储：一个专门用于支持应用程序“实时”操作的操作速度的事务存储，另一个包含纯粹用于报告的“历史”数据。

然后，要弄清楚您需要在事务数据存储中保留多少数据，以及何时/如何将其移动到报告数据存储。