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

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

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

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

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

问题2:当你将第三个实体投入游戏时,例如(A) - >(B),(A) - >(C)和(C) - >(B),哪一个将是这种情况下的最佳方法？

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

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

问题3:在相同类型的实体,例如间(人)的关系的情况下- isFriendOf - >(人),铭记的关注点分离的概念,它被appropiate以分离关系的管理进入不同的服务？

任何意见,反馈和想法都非常受欢迎.

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

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