graph-databases - 微服务:分解基于图数据库的应用程序

Question

我计划将我开始构建的应用程序分解为带有图形数据库的整体式微服务。但我面临的困境是试图找到一个合适的解决方案来拆分不同的服务，而不是失去图形数据库提供的好处。

我最初考虑的想法是将每个不同的实体拆分为它自己的微服务，使用文档存储将数据保存在每个服务上。然后定义一个更高级别的服务来管理这些关系。

例如，对于关系 (A)-->(B)，将产生 3 个微服务，一个为类型 A 的实体服务，另一个为类型 B 的实体提供服务，以及具有图形数据库的第三个更高级别，存储类型为A 和 B，仅包含 ID 以及它们之间的关系。

问题 1 : 这种方法在耦合、容错或其他我现在想不到的方面有什么问题吗？

问题 2 : 当你将第三个实体扔进游戏时，例如 (A)-->(B)、(A)-->(C) 和 (C)-->(B)，哪个是最好的方法在这种情况下？

我是否坚持只使用一种更高级别的服务来维护所有关系的策略？

我是否会生成多个更高级别的服务来维护每种类型的关系？

问题 3 : 对于同类型实体之间的关系，例如(Person)--isFriendOf-->(Person)，考虑到关注点分离的概念，将关系的管理分离成一个不同的服务？

非常欢迎任何输入、反馈和想法。

我一直在做一些关于这个主题的研究，为了清楚起见，我会提出一个更具体的场景，这样讨论起来会更容易。
图模型将是这样的:



这里的目标是实现歌曲播放列表推荐服务，尝试根据用户已经听过的歌曲的流派和艺术家以及其他人听过的其他歌曲，尝试找到给定用户还没有听过的歌曲。用户，然后是当前用户。

Answer 1

根据这个问题的答案(在程序员堆栈交换中)How do you handle shared concepts in a microservice architecture?似乎实际上最初提出的方法是一个很好的方法。如果在将不同的部分扼杀到不同的服务中时正确地进行了关注点分离，那么就不应该存在耦合问题。

至于容错，很难一概而论，所以最好逐案研究具体情况，并在每种情况下确定如何在其他服务不可用时优雅地降级服务。

对于问题2和问题3，我一开始试图采取广义抽象的方法，但在考虑了一个具体案例后，我最终得出了同样难以概括的结论。所以对于这个特定的图模型，我想出了这个可能的解决方案:



所以基本上，对于问题3，答案是肯定的，因为这样一来，关注其他用户的用户关系可以被其他服务使用，而不会被迫依赖于推荐系统。

对于问题 2，它取决于域模型，因为首先将用户服务与友谊服务分开是有意义的，因此不需要在推荐服务中复制这种关系，而所有其他关系确实是相关的，将它们保持在一起是有意义的，至少在不需要再次拆分它们以便能够重用于其他服务的情况下。