Database SOA和共享数据库

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

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

• CustomerService

  ：包含我的

  Customers

  数据库表和相关业务逻辑

• OrderService

  ：包含我的

  订单

  表和逻辑

现在，如果我需要用SQL语句

连接
客户
和
订单
表，该怎么办？如果这些表包含数百万个条目，那么如果我必须使用SOAP/XML通过网络发送数据，将导致无法接受的性能。以及如何执行
连接

通过做一些研究，我发现了一些建议的解决方案：


在需要时制作所需数据的本地副本。但是没有封装，那么使用SOA有什么意义呢？对此进行了讨论，但没有达成明确的共识
设置封装所有数据库数据的。我猜它会变得非常庞大（每个存储过程基本上只有一个API调用），并且需要随时更新。对我来说，这似乎与这个概念有关

如果您对此有任何意见，请告诉我。
在此上下文中，“服务”的定义原则之一是，它绝对拥有其负责区域内的数据以及对该数据的操作

通过复制或任何其他机制复制数据可以免除这一责任。要么你也复制业务规则，要么你最终会陷入一种需要更新其他服务来更改内部规则的情况

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

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

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

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

同样，发票电子邮件：可视化地组合来自多个服务的数据，而不需要数据库中的连接

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

第二，您可以更轻松地更改应用程序的外部。如果您有小的、可组合的部分，您可以轻松地添加它们，并以新的方式重新排列这些部分。
指导原则是缓存不可变的数据是可以的
这意味着来自客户实体的简单不可变数据可以存在于订单服务中，而无需在每次需要信息时都转到客户服务。将所有内容断开为独立的服务，然后总是进行这些远程过程调用，这会忽略。
如果您有广泛的报告需求，则需要创建附加服务。我称之为聚合报告服务，它再次获取用于报告目的的只读数据。您可以看到几年前的一篇文章
在您引用的SO问题中，不同的人表示服务可以访问另一个服务数据，因此订单服务可以具有GetAllWithCustomer功能，该功能将返回所有订单以及该订单的客户详细信息

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

在寻找线索时，我没有想到你的想法——这是一种有趣的方法。如果我不需要加入

JOIN，原来的问题就不会出现了。然而，在我的例子中，

JOIN

似乎很难回避，因为它不是为了表达目的。但我会考虑一下。您指出的一个关键点是，服务应该拥有自己的数据和相关操作。在这一点上，国内一直存在分歧。感谢您的回复！Udi Dahan在这里有一个博客：-他的工作在形成我对这个主题的看法方面是非常宝贵的，你会在那里发现更多有价值的信息。你是说客户服务只能访问客户数据，而订单服务只能访问订单数据吗？我在托马斯·厄尔的书中没有提到这一点？请你提供一份参考资料好吗？@PaulTDavies我现在没有什么具体的书可以推荐，但它是我观点来源的一个坚实的总结。具体来说，请参见“外部数据”与“内部数据”的讨论。@DanielPittman这种方法的一个问题是：如果我要搜索一组合并的结果，并对两个表中的字段进行筛选，该怎么办。从住在柴郡的顾客那里找到所有超过100英镑的订单？使用组合方法，我必须从订单服务中找到所有超过100英镑的订单，从客户服务中找到所有来自柴郡的客户，然后使用组合服务找到交叉点。与使用数据库联接相比，订单和客户的集合将大得多，性能将大大降低。好书。我想缓存其他服务的数据与您描述的事件驱动机制相结合是可行的。对于数据不经常更改的服务，我认为我可以让服务每晚更新一次缓存，而不是