微服务：分解基于图形数据库的应用程序

Question

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

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

例如，使用关系（A） - >（B），将生成3个微服务，一个服务用于类型A的实体，另一个用于类型B的实体，第三个更高级别用于图形数据库，存储类型A和B的节点，仅包含ID和它们之间的关系。

问题1 ：这种方法在耦合，容错或其他任何我现在无法想到的方面有什么问题吗？

问题2 ：当您将第三个实体投入游戏时，例如（A） - ＆gt;（B），（A） - ＆gt;（C）和（C） - ＆gt;（B），在这种情况下哪一个是最好的方法？

• 我是否坚持只提供一种更高级别服务的策略来维持所有关系？
• 我是否会生成几个更高级别的服务来维护每种类型的关系？

问题3 ：对于相同类型的实体之间的关系，例如（Person） - isFriendOf - ＆gt;（Person），考虑到关注点分离的概念是否适合将关系管理分为不同的服务？

非常欢迎任何意见，反馈和想法。

我一直在研究这个问题，为了清楚起见，我会提出一个更具体的方案，所以讨论它会更容易。 图模型将是这样的：

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

Answer 1

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

至于容错，很难概括，因此最好根据具体情况研究具体情况，并在每种情况下确定如何在其他服务不可用时优雅降级服务

关于问题2和问题3，我首先尝试采用一种通用的抽象方法，但在考虑具体案例后，我最终得出的结论也难以概括。因此，对于这个特定的图模型，我提出了这个可能的解决方案：

所以基本上，对于问题3，答案是肯定的，因为这样，其他用户之后的用户关系可以被其他一些服务使用，并且它不会被迫推迟推荐系统。

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