Service SOA：跨多个服务连接数据

假设我们有两种服务：产品和订单。根据我对SOA的理解，我知道每个服务都可以有自己的数据存储（一个单独的数据库，或同一数据库中的一组表）。但不允许任何服务直接接触另一个服务的数据存储

现在，假设我们已经将产品和订单数据独立地存储在产品和订单服务中。在订单服务中，我们可以通过产品ID来识别产品

我的问题是：在这种架构下，如何在“相同”页面上显示订单列表和产品详细信息

我的理解是，我应该从OrderService获取OrderItems列表。每个OrderItem都有一个ProductID。现在，如果我单独调用ProductService来检索每个产品的详细信息，这将是非常低效的

你将如何处理这个问题

干杯，

---

Mosh

SOA只是在web服务背后部署组件的流行语。您拥有多少数据存储完全取决于您。在某些情况下，在单个组件后面进行数据分区是有意义的，在其他情况下，所有数据都位于一个服务后面，在其他情况下，许多公开服务接口的组件通过数据库的连接协议连接到同一个数据库。通过解决问题来解决问题，而不是强加人为的约束。

我认为SOA中没有任何原则要求服务具有单独的数据存储。一般来说，这实际上是不切实际的。是的，您可以使用产品和订单服务，客户机可以像您所说的那样使用web服务调用进行连接，这在某些情况下是可以接受的。但这并不意味着如果您已经了解客户的行为和性能要求，就不能为客户提供特定的服务。

---

我的意思是，你们应该有一个搜索服务，返回订单和产品，并在数据库中完成连接。这很实用，可以解决您的业务问题。

我做了一些研究，发现了两种不同的解决方案

1-服务可以在本地缓存其他服务的数据。但这需要一个pub/sub机制，因此应该发布数据源中的任何更改，以便订阅服务可以更新其本地缓存。这一实现成本很高，但却是最快的解决方案，因为服务在本地具有所需的数据。它还通过防止服务依赖于其他服务的数据来提高服务的可用性。换句话说，如果另一个服务不可用，它仍然可以通过缓存数据来完成其工作

2-或者，服务可以通过提供标识符列表从另一个服务查询对象的“列表”。这可以防止单独调用目标服务以获取给定对象的详细信息。这更容易实现，但在性能方面不如解决方案1快。此外，如果目标服务不可用，源服务将无法完成其工作

希望这能帮助其他遇到这个问题的人

---

Mosh

另一种方法是使用某种位于SOA服务之外的数据源。此数据源可以被视为数据缓存、操作数据源甚至数据仓库。提取包可以从服务（和/或某种实时机制）导出数据。您可以根据需要查询此数据源

这种方法的优点是维护了SOA黑盒，并且您可以在知道如何耦合服务的情况下交换服务

缺点是增加了复杂性和维护开销。

DB集成（当两个服务在一个DB中共享一个表时，这实际上就是您所说的）在很多级别上都是错误的！ 它完全打破了软件工程的一些主要原则

松耦合， 封装 关注点分离

服务应完全独立（以获得该名称），即：

它决不能依赖其他人来确保其数据的一致性和连贯性

它不能依赖他人来保证其数据的安全

它不能依赖于外部实现（仅接口）

在DB级别共享数据的两个服务无法保证前者的任何一个

您“控制”这两个服务的事实完全无关。今天你控制。。。明天你可能想外包或更换其中一项服务。这应该像确保适当的接口到位一样简单

设想两个服务共享一个表，其中包含某个字段（varchar）。现在一个服务需要将该字段更改为数字。。。砰的一声，其他服务停止工作-松耦合进入排水管

大多数时候，诀窍在于正确定义服务范围，明确规定服务做什么和不做什么。您还应该避免将所有内容都转换为服务。将您的服务粒度设置为高，服务将开始随处可见，集成难题将升级

---

尽管如此，在某些情况下，服务之间的数据集成会带来一些挑战。主要的前提是，数据只能属于一个服务。数据与影响数据一致性和一致性的业务逻辑有着内在的联系，因此，任何给定数据都不应该由多个服务控制。

不幸的是，在“我是否可以在SOA中使用共享数据库？”，这完全不相干，也无助于回答最初的问题

通常情况下，在现实世界中，数据已经存储在不同的系统中。例如，客户数据来自CRM，产品数据来自SAP，合同数据来自另一个不同的来源

这不是一个问题