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

【问题标题】：Microservices: decomposing a graph db based application微服务：分解基于图形数据库的应用程序
【发布时间】：2015-12-17 04:20:53
【问题描述】：

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

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

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

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

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

问题3：对于同一类型的实体之间的关系，例如(Person)--isFriendOf-->(Person)，牢记关注点分离的概念，将关系管理分离到不同的服务中是否合适？

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

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

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

【问题讨论】：

【解决方案1】：

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

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

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

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

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

【讨论】：