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

Question

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

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

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

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

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

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

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

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

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

Answer 1

根据这个问题的答案（在程序员堆栈交换中）你如何处理微服务架构中的共享概念？似乎实际上最初提出的方法是一个很好的方法。如果在将不同部分扼杀到不同服务中时正确完成了关注点分离，那么就不应该存在耦合问题。

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

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

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

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