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

Question

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

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

我非常想听听您对此的看法。我相信第二种选择是可行的方法，这也为我们提供了一个有效的层来实现缓存。但是如何为所有应用程序公开这一层呢？Webservices/rest 会成为解决之道吗？还是有其他更好的方法来做到这一点？

Answer 1

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

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

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

其他 - 嗯，你实际上并没有说出你想要解决的具体问题是什么。如果是性能的话，解决性能问题最便宜的方法就是使用硬件来解决问题。如果是可管理性——SOA 可以提供帮助——但它通常还会在组合中引入额外的基础设施，而这些基础设施也需要维护。确保您真正清楚是什么推动了您的架构选择，因为没有单一的“最佳”解决方案 - 这都是关于权衡的。