微服务架构中的 Neo4J

Question

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

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

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

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

或者

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

两者似乎都不太正确......

Answer 1

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

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

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

1 和 2 是更好的选择，特别是如果跨微服务访问的数据本质上是相关的，因为 Neo4j 在存储连接的数据时效果最好，并且随着数据在多个数据库之间孤立的程度增加而失去其价值。

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

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

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

您可以使用子图访问控制方法，这是我最推荐的满足您需求的方法。

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

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