java - Neo4J 在微服务架构中

Question

为了与 DDD 和限界上下文保持一致，众所周知，当您创建微服务时，您应该保持关注点分离。

Neo4J 的主要好处之一是将您的“连接”数据保存在 Neo4J 中，以便有效地查询它们之间的关系。

在选择使用 Neo4J 时，这两种对立的力量似乎使微服务架构决策变得困难。

您是否有多个微服务连接到 Neo4J 数据库并相应地保留自己的域？

或者

您是否有一个微服务与 Neo4J 的数据库连接来控制持久性和查询？

两者似乎都不太对...

Answer 1

这里讨论了每服务数据库的模式，并将选项分解为：

1. 共享数据库，但每个服务的私有表。
2. 共享数据库，但每个服务的私有模式。
3. 每个服务单独的数据库。

显然 3 将是最昂贵的，因为您希望每个 Neo4j 实例都在自己的服务器上，因此它具有专用的内存和硬件，如果您需要一个集群解决方案，那么这将成为一个单独的集群每个服务。不推荐，特别是如果只是意识形态是这个决定的驱动力。

1 和 2 是更好的选择，特别是如果跨微服务访问的数据本质上是相关的，因为 Neo4j 在存储连接数据时效果最好，并且在多个数据库之间孤立的数据越多，它的价值就越低。

也就是说，这些选项存在一些挑战。

Neo4j 不使用表，并且目前没有单独的模式来划分不同用户之间数据的可见性。

虽然您可以让微服务仅使用仅涉及图形特定部分的已定义查询，但这通常比所需的控制更宽松。

您可以改用子图访问控制方法，这是我最推荐的一种。

这归结为创建过程来封装您希望可用于每个微服务的查询（直接使用 Java API，或从过程代码进行 Cypher 查询），然后为每个微服务创建自定义角色（没有读取权限)，但允许他们调用适当的程序。这确保了每个微服务的自定义角色只允许通过允许的过程与图进行交互（当然，这些过程可以做任何他们想做的事情，而不受调用用户的角色或权限的限制）。

就多租户方法而言，将数据在单个数据库上的不同图表之间保持分离，这是目前备受关注的一个功能，并且正在实施中。在 2018 年即将发布的版本中寻找它。也就是说，这是否对您有用取决于此功能的实现以及您的数据的性质。

Answer 2

我们不喜欢跨多个服务共享数据库，这使得它们的部署和升级变得困难。

通常，您可以从多个微服务中获取事件流，并且一个或多个微服务使用 neo4j 创建特定于其用例的图形数据结构。

在这种情况下会发生数据复制，因此您必须明智地决定何时复制数据。

Answer 3

您可以使用几种模式。

这一次仍然存在 MS 共享数据库的可能性，只要它在其有限的上下文中。由于仅在翻译层之外，数据层上不应有共享。

或者，您可以将 Neo4j 视为支持使用图的某些微服务的数据库，例如推荐、欺诈等。然后，该数据库可以由事件源架构中的域事件填充。

Answer 4

我建议每个微服务有一个 Neo4j 实例。然后，每个微服务都拥有自己的数据库。