微服务：分解基于图形数据库的应用程序
Microservices: decomposing a graph db based application
我打算将我开始构建的一个应用程序分解为带有图形数据库的整体应用程序，并将其分解为微服务。但我面临的困境是试图找到一个合适的解决方案来拆分不同的服务，同时又不失去图形数据库提供的好处。
我最初考虑的想法是将每个不同的实体拆分成它自己的微服务，使用文档存储来持久保存每个服务上的数据。然后定义更高级别的服务来管理这些关系。
例如关系 (A)-->(B)，将产生 3 个微服务，一个服务用于 A 类型的实体，另一个服务用于 B 类型的实体，第三个更高级别的图形数据库，存储类型 A 和 B 的节点，仅包含 ID 和它们之间的关系。
问题1：这种方式在耦合性、容错性或者其他我现在想不出来的方面有什么问题吗？
问题2：当你把第三个实体扔进游戏时，比如(A)-->(B)，(A)-->(C)和(C)-->(B)，在这种情况下哪种方法最好？
- 我是否坚持仅通过一项更高级别的服务来维护所有关系的策略？
- 我是否生成多个更高级别的服务来维护每种类型的关系？
问题3：对于同类型实体之间的关系，例如(Person)--isFriendOf-->(Person)，请记住这个概念关于关注点分离，将关系管理分离到不同的服务中是否合适？
非常欢迎任何意见、反馈和想法。
我一直在研究这个问题，为了清楚起见，我将提出一个更具体的场景，这样讨论起来会更容易。
图模型将是这样的：
这里的目标是实现一个歌曲播放列表推荐服务，试图根据用户已经听过的歌曲的流派和艺术家，以及来自其他用户听过的其他歌曲，当前用户听过的其他歌曲。
根据这个问题的答案（在 Programmers Stack Exchange 中）How do you handle shared concepts in a microservice architecture? 似乎实际上最初提出的方法是一个很好的方法。如果在将不同部分扼杀为不同服务时正确地完成了关注点分离，那么就不会有耦合问题。
至于容错性，很难一概而论，所以最好逐案研究具体情况，并确定在每种情况下，如何在其他服务不可用时优雅地降级服务.
关于问题2和问题3，一开始我尝试采用概括性的抽象方法，但在考虑具体案例后，我得出的结论同样难以概括。所以对于这个特定的图形模型，我想出了这个可能的解决方案：
所以基本上，对于问题3，答案是肯定的，因为这样，用户关注其他用户的关系可以被其他一些服务使用，而不会被迫依赖于推荐系统。
关于问题 2，它取决于领域模型，因为首先将用户服务与友谊服务分开是有意义的，这种关系不需要在推荐服务中复制，虽然所有其他关系确实相关，但将它们放在一起是有意义的，至少在不需要再次拆分它们以便能够重新用于其他服务时。
我打算将我开始构建的一个应用程序分解为带有图形数据库的整体应用程序，并将其分解为微服务。但我面临的困境是试图找到一个合适的解决方案来拆分不同的服务，同时又不失去图形数据库提供的好处。
我最初考虑的想法是将每个不同的实体拆分成它自己的微服务，使用文档存储来持久保存每个服务上的数据。然后定义更高级别的服务来管理这些关系。
例如关系 (A)-->(B)，将产生 3 个微服务，一个服务用于 A 类型的实体，另一个服务用于 B 类型的实体，第三个更高级别的图形数据库，存储类型 A 和 B 的节点，仅包含 ID 和它们之间的关系。
问题1：这种方式在耦合性、容错性或者其他我现在想不出来的方面有什么问题吗？
问题2：当你把第三个实体扔进游戏时，比如(A)-->(B)，(A)-->(C)和(C)-->(B)，在这种情况下哪种方法最好？
- 我是否坚持仅通过一项更高级别的服务来维护所有关系的策略？
- 我是否生成多个更高级别的服务来维护每种类型的关系？
问题3：对于同类型实体之间的关系，例如(Person)--isFriendOf-->(Person)，请记住这个概念关于关注点分离，将关系管理分离到不同的服务中是否合适？
非常欢迎任何意见、反馈和想法。
我一直在研究这个问题，为了清楚起见，我将提出一个更具体的场景，这样讨论起来会更容易。 图模型将是这样的：
这里的目标是实现一个歌曲播放列表推荐服务，试图根据用户已经听过的歌曲的流派和艺术家，以及来自其他用户听过的其他歌曲，当前用户听过的其他歌曲。
根据这个问题的答案（在 Programmers Stack Exchange 中）How do you handle shared concepts in a microservice architecture? 似乎实际上最初提出的方法是一个很好的方法。如果在将不同部分扼杀为不同服务时正确地完成了关注点分离，那么就不会有耦合问题。
至于容错性，很难一概而论，所以最好逐案研究具体情况，并确定在每种情况下，如何在其他服务不可用时优雅地降级服务.
关于问题2和问题3，一开始我尝试采用概括性的抽象方法，但在考虑具体案例后，我得出的结论同样难以概括。所以对于这个特定的图形模型，我想出了这个可能的解决方案：
所以基本上，对于问题3，答案是肯定的，因为这样，用户关注其他用户的关系可以被其他一些服务使用，而不会被迫依赖于推荐系统。
关于问题 2，它取决于领域模型，因为首先将用户服务与友谊服务分开是有意义的，这种关系不需要在推荐服务中复制，虽然所有其他关系确实相关，但将它们放在一起是有意义的，至少在不需要再次拆分它们以便能够重新用于其他服务时。