SOA和共享数据库

Question

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

更具体地说，假设我有两项服务：

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

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

做了一点研究，我找到了一些建议的解决方案：

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

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

---

编辑：一年过去了，我对SOA的兴趣减少了，概念的受欢迎程度也是如此。如今，人们似乎更愿意关注RESTful服务。

Answer 1

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

通过复制或任何其他机制复制数据，从而放弃了这一责任。您也可以复制业务规则，或者您最终会遇到需要更新其他服务以更改内部规则的情况。

使用单一数据服务只是“不做SOA”;如果你有一个管理所有数据的地方，你没有独立的服务，你只需要一个服务。

相反，我建议使用第三种方法：使用组合将数据放在一起，完全避免数据库级JOIN操作。

不要考虑需要在数据库中将这两个值连接在一起，而是考虑如何将它们组合在一起：

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

同样是发票电子邮件：可视化地组合从多个服务提供的数据，而无需数据库内加入。

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

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

Answer 2

指导原则是可以缓存不可变数据 这意味着来自客户实体的简单不可变数据可以存在于订单服务中，并且无需在每次需要信息时都转到客户服务。将所有内容分解为隔离的服务，然后始终进行这些远程过程调用会忽略fallacies of distributed computing。 如果您有广泛的报告需求，则需要创建其他服务。我称之为聚合报告服务，它再次获取用于报告目的的只读数据。几年前你可以看到一篇文章I wrote about that for InfoQ

Answer 3

在您引用的SO问题中，各种人都声明服务可以访问其他服务数据，因此订单服务可以具有GetAllWithCustomer功能，该功能将返回所有订单以及该订单的客户详细信息。

此外，我的这个问题可能会有所帮助：

https://softwareengineering.stackexchange.com/questions/115958/is-it-bad-practice-for-services-to-share-a-database-in-soa