architecture - 共享数据库与消息架构

Question

昨天我和我的一个 friend 在酒吧里，我们开始讨论他工作的公司正在使用的架构。对话基本上围绕着共享数据库架构与分布式独立应用程序架构的优缺点——我们无法达成共识，在这种情况下，我想听听人们对这两种方法的优缺点的看法。

基本上，他工作的公司拥有一个包含许多不同应用程序的大型架构。一些应用程序只有一个数据库，它们在它们之间共享。例如，有 1 个应用程序为用户提供 UI 以更改引用数据。该引用数据被另一个应用程序使用，该应用程序也访问相同的数据。我相信代码实际上是作为共享库编写的(即两个应用程序都将使用为每个应用程序重新部署的公共(public)代码集(一个将其作为依赖项))。

还有其他应用程序具有数据库，其他应用程序也通过与数据访问代码的直接 JDBC 连接使用该数据库(这两个应用程序之间不常见 - 重复!!呃!)。

我的问题是围绕这种架构的优缺点与每个应用程序在孤岛中包含它的“主”数据的架构。如果应用程序 x 需要来自应用程序 y 的数据，则他们使用 Web 服务或某种消息传递技术来接收该数据。

消息传递方法将引入一个问题，即当前在其他应用程序的数据库中使用的引用数据“代码”(或外键)现在必须从另一个源获取。在当前架构中，这些的“解码”可以随时更改并立即反射(reflect)在外部应用程序中，而不必在复制数据时具有主/从关系 - 或者应用程序 x 必须查询应用程序 y 的替代方案只是为了显示解码值。

我已经阅读了企业集成模式，虽然它确实给出了一些消息传递优势的例子——我不太相信。

谢谢
伊恩

Answer 1

我正在制作这个案例。我相信有非常明确的理由使用其中一个(以及一些尚未提出的观点)。

数据库集成

优点

单一事实来源

交易性

无需管理新技术或中间件

唯一键很容易

缺点

不能很好地扩展。您最终会得到一个运行各种工作负载(如事务和报告)的数据库，或者您最终会使用数据库复制来分配生产负载。

广域分布难。多站点架构更是如此。

技术固定，厂商锁定

数据库中的硬输入(假设 SQL)会强制系统范围内的小更改进行更新，例如更改列的大小。

消息系统

优点

负载可以是分布式的，并且可以使用针对各种任务进行优化的专用系统

替换系统可以与现有系统并行部署。

消息格式(又名网络数据模型)可以进行版本控制，多个版本同时运行

可以支持复杂的广域拓扑 - 例如具有中央集线器的多个实例，在每个实例上共享所有数据的多个实例。

相对容易改造遗留系统，然后无需大量工作即可集成这些系统

缺点

在生产中部署和管理的新系统。

交易难