SOA:跨多个服务连接数据

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

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

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

DB集成(当两个服务在一个DB中共享一个表时,您所说的集成)在许多级别上都是错误的! 它完全打破了软件工程的一些主要原则

松耦合, 封装 关注点分离

1. 它决不能依赖他人来确保其数据的一致性和连贯性
2. 它不能依赖他人来保证其数据的安全
3. 它不能依赖于外部实现(仅接口)

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

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

假设两个服务共享一个表,其中有一个字段(varchar)。现在一个服务需要将该字段更改为数字。。。砰的一声,另一个服务停止工作-松脱的耦合下降到排水管。

大多数时候,诀窍在于正确定义服务范围,明确规定服务做什么和不做什么。你也应该避免把一切都变成服务。将您的服务粒度设置为高,服务将开始无处不在,集成难题将升级。

另一种方法是在SOA服务之外使用某种数据源。这个数据源可以看作是数据的缓存、操作数据源,甚至是数据仓库。提取包可以从服务(和/或某种实时机制)导出数据。您可以根据需要查询此数据源。

这种方法的优点是维护了SOA黑匣子,您可以交换一个知道如何耦合的服务。

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

我不认为SOA中有任何原则认为服务应该有单独的数据存储。一般来说,这实际上是不切实际的。是的,您可以使用产品和订单服务,客户机可以使用您所说的web服务调用进行连接,这在某些情况下可能是可以接受的。但这并不意味着,如果您已经知道客户的行为和性能要求,就不能为客户提供特定的服务。
我的意思是,您应该有一个搜索服务,返回订单和产品,并在数据库中完成连接。这很实用,可以解决您的业务问题。

不幸的是,在“我是否可以在SOA中使用共享数据库”的语句请求中,整个讨论都在恶化,这完全不相关,也无助于回答最初的问题。

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

从技术上讲,这并不是要将这些数据整合在一起,而是要理解只有一个数据源。换句话说,在您的企业中,只有一个数据所有者负责维护它并确保正确的数据质量。