尝试找出在使用基于Spring Data Rest或HATEOAS的基于超媒体的微服务时如何处理关系的模式。
如果你有服务A(讲师)和服务B(课程),每个都作为一个独立的应用程序存在。
在两个服务之间建立关系的首选方法是什么。以不需要外部服务的ID列的方式。每个服务都有可能拥有许多需要在同一庄园进行通信的其他服务。
可能的解决方案(不确定正确的路径)
每个服务都有一个第二个表,其中OneToMany包含服务中的主要实体。该表将包含以下字段:
ID,entityID,rel,relatedID
然后在使用Spring Data Rest设置的相反服务中查找查询连接表以查找匹配的记录。
我想要实现的主要目标是任何服务都可以与任意数量的其他服务建立关系,而无需了解其他服务。
答案 0 :(得分:10)
基本步骤如下:
我在this repository中有一个非常基本的例子。该示例包含两个服务:为商店提供地理空间搜索的服务。第二项服务是一些基本的客户管理,如果当前可用,可选择与商店服务集成。
以下是步骤的实施方式:
在我的示例中,消费服务(即客户服务)使用Spring HATEOAS'Traverson
API遍历一组链接关系,直到找到名为by-location
的链接。这是在StoreIntegration中完成的。因此,所有客户端服务需要知道的是根URI(取自我的环境)和一组链接关系。使用HEAD
- 请求存在periodically checks the link。
这当然可以以更复杂的方式完成:将基本URI硬连接到客户端服务可能被认为是次优的,但如果您仍在使用DNS,那么实际上工作得很好(这样您就可以交换实际主机在URI背后硬编码)。尽管如此,这是一种体面的实用方法,如果它改变了URI,仍会重新发现其他服务,不需要额外的库。
对于更复杂的方法,请查看Netflix' Eureka library,它基本上是一个服务注册表。此外,您可能想要查看我们的Spring Cloud integration。
Spring HATEOAS提供了Spring Data REST利用的ResourceProcessor
API。它允许您操纵即将呈现的Resource
实例,例如添加链接到它。可以找到客户服务的实施here。
它基本上采用上面步骤中刚刚发现的链接,并使用众所周知的参数对其进行扩展,从而允许客户只需通过链接即可触发商店地理搜索。
您可以在Spring Cloud的示例项目中找到此示例的更复杂变体。它采用了相同的示例,但切换到Spring Cloud组件,如Eureka集成,收集指标,添加UI等。
答案 1 :(得分:0)
在我的情况下,我只能从服务本身派生相关项目。我的目标是将相关项目抽象到任意数量的服务可以与服务相关并且只需要查找ID或链接。一个想法是@ElementCollection命名与服务的实体ID的连接相关。然后在@Embedded中有一个relLink字段和一个relatedID字段。然后在存储库中执行findby以查找relLink和relatedID。
希望将它抽象得足以基本上模仿多对多的设置。