针对单一数据库架构的多个应用

Question

我们正在为内部应用程序创建新策略。我们目前有大约10-15个应用程序直接针对同一个数据库。这显然不是很好，我们想评估我们的选择。据我所知，我们必须做出选择：

• 复制数据库并使用复制等使其同步
• 在数据库和10-15个应用程序之间创建一个新的应用程序。
• 其他？

我非常想听听你对此的看法。我相信第二个选择是要走的路，这也为我们提供了一个实现缓存的有效层。但是，您如何为所有应用程序公开此图层？ Web服务/休息是否可行，或者还有其他更好的方法吗？

Answer 1

分析您公开的选项：

  

复制数据库并使用复制等使它们同步

如果所有应用程序都需要访问同一个数据库，我发现重复它是一个糟糕的决定，因为你会遇到同步问题（过时的数据等）。

  

在数据库和10-15个应用程序之间创建一个新的应用程序。

这确实是一个很好的可能性。如果您不希望所有这些应用程序依赖于数据库的实现细节（例如，对一个表进行更改会影响所有这些应用程序的代码），则可以将数据库“隐藏”在提供“业务有意义的“对这些”客户端应用程序的操作“。

如果您只是遇到性能问题，我建议您对数据库进行群集（而不是手动复制）。

Answer 2

我认为流行语的答案是“面向服务的架构” - 这确实是选项2.

这是一项大规模的工作，需要探索许多令人兴奋的死角 - 但基本上，不要考虑数据库和表格，而应考虑这15个应用程序所需的服务。有些可能是共享的，有些可能是特定于一个应用程序。找到一种向应用程序公开这些服务的方法 - 但请记住，Web服务调用可能比等效的直接数据库调用慢得多，因此不要将“面向服务的体系结构”视为必须在所有地方引入Web服务 - 它更像是一种心态而非产品规格。

复制和同步 - 根据我的经验 - 创建非常脆弱的系统，其故障模式会伤害大脑甚至思考。

其他 - 好吧，你实际上并没有说出你要解决的具体问题是什么。如果它的性能 - 解决性能问题最便宜的方法就是抛出硬件问题。如果它是可管理性 - SOA可以帮助解决这个问题 - 但它通常还会在混合中引入额外的基础架构，这也需要维护。确保你真正清楚你的架构选择是什么，因为没有单一的“最佳”解决方案 - 所有这些都是关于权衡。

Answer 3

我不明白为什么10-15个应用程序必须共享数据库？真的所有应用程序都必须使用所有表吗？

首先将每个应用程序唯一的表移动到一个单独的数据库中。

完成后，应该很容易看到多个应用程序访问同一数据库是否会出现任何问题。通常，除非应用程序开始缓存数据，否则无关紧要（因为您永远不会知道另一个应用程序是否更新了您缓存的某些数据）。最典型的方法是使用某种消息传递。

Answer 4

一个未提及的选项是在存储过程/触发器等中使用逻辑的一部分......不是一个好主意，而是一个不少的想法。

我想说你的第二个选择是最好的选择。如果您使用的是.NET平台，那么WCF非常简单而且功能强大。