Architecture 从共享数据库模式中重构

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

这些跨数据库的依赖性给我们带来了很多麻烦。目前最大的问题是，我们在SQL server上遇到了性能问题，并且由于跨数据库依赖关系而无法扩展。我认为我们应该做的是从共享数据库模式转向EIP书中描述的消息传递系统。每个应用程序都将负责自己的所有数据，而希望访问这些数据的其他应用程序将通过服务（通过消息传递总线？）获取这些数据

• 我们从哪里开始重构消息传递模式
• 我们是否从重构其中一个应用程序开始，以管理其自己的应用程序数据库
• 那么，目前通过数据库与该应用程序集成的其他应用程序呢
• 这是分离数据库依赖关系的最佳方法，还是应该从其他地方开始

---

我建议采用3相转变

向每个应用程序添加消息传递层

更改所有跨应用程序数据访问以使用新创建的消息传递层

根据需要扩展（现在是独立的）数据库

另外，假设你有3份申请；A、 B和C

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

• 应用程序A
  • 将消息添加到
  • 将呼叫更改为B&C中的A
• 应用程序B
  • 将消息添加到B
  • 将呼叫更改为A&C中的B
• 应用程序C
  • 向C添加消息
  • 在A&B中将呼叫更改为C

---

在该过程的这一点上，结果与第2阶段结束时相同，第3阶段可以继续进行。区别仅仅在于专注于一种重构还是专注于一个应用程序更高效。

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

---

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

我也会考虑应用程序如何使用数据库。通常，数据库（设计和实现）应分为两个不同的类别之一：事务性（OLTP）或报告性（OLAP）

一个设计良好（并实现良好）的事务数据库应该在典型的业务线应用场景中提供优异的性能；同样，一个设计良好（并且实现良好）的报告数据库在查询大量复杂数据时应该提供优异的性能

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

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

然后，诀窍是确定需要在事务数据存储中保留多少数据，以及何时/如何将其移动到报告数据存储中