database - SOA 和共享数据库

Question

我不了解 SOA(面向服务的架构)和数据库。虽然我被 SOA 概念(将可重用的业务逻辑封装到服务中)所吸引，但我无法弄清楚如果其他服务/系统需要封装在服务中的数据表，它应该如何工作——或者 SOA 是否合适 < em>完全在这种情况下？

更具体地说，假设我有两个服务:

• CustomerService:包含我的Customers 数据库表和关联的业务逻辑。
• OrderService:包含我的Orders 表和逻辑。

现在，如果我需要使用 SQL 语句JOIN Customers 和 Orders 表怎么办？如果表包含数百万个条目，如果我必须使用 SOAP/XML 通过网络发送数据，将导致无法接受的性能。以及如何执行JOIN？

经过一些研究，我发现了一些建议的解决方案:

• Use replication在需要时制作所需数据的本地副本。但是没有封装，那么使用 SOA 有什么意义呢？这是讨论on StackOverflow但没有明确的共识。
• 设置 Master Data Service它封装了所有数据库数据。我猜它会变得非常庞大(基本上每个存储过程都有一个 API 调用)并且需要一直更新。对我来说，这似乎与 enterprise data bus 有关概念。

如果您对此有任何意见，请告诉我。

Answer 1

在此上下文中，“服务”的定义原则之一是它绝对拥有其负责区域中的数据，以及对该数据的操作。

通过复制或任何其他机制复制数据，可以摆脱这种责任。您要么也复制业务规则，要么最终会遇到需要更新其他服务以更改内部规则的情况。

使用单一数据服务只是“不做SOA”；如果您只有一个地方管理所有数据，那么您就没有独立的服务，您只有一项服务。

相反，我会建议第三种选择:使用组合将数据放在一起，完全避免数据库级别的 JOIN 操作。

与其考虑需要在数据库中将这两个值连接在一起，不如考虑如何在边缘将它们组合在一起:

当您为客户呈现 HTML 页面时，您可以提供来自多个服务的 HTML 并将它们以视觉方式组合在一起:客户详细信息来自客户服务，订单详细信息来自订单服务。

发票电子邮件也是如此:可视化地组合从多个服务提供的数据，无需数据库内连接。

这样做有两个好处:第一，你不需要加入数据库，甚至不需要将数据存储在同类型的数据库中。现在，每项服务都可以使用最适合其需要的任何数据存储。

第二，您可以更轻松地更改应用程序的外部。如果您有可组合的小部件，您可以轻松添加并以新的方式重新排列这些部件。