为了与 DDD 和限界上下文保持一致，众所周知，当您创建微服务时，您应该保持关注点分离。
Neo4J 的主要优势之一是在 Neo4J 中保存您的“连接”数据，以便有效地查询它们之间的关系。
在选择使用 Neo4J 时，这两种相反的力量似乎使微服务架构决策变得困难。
您是否有多个微服务连接到 Neo4J 数据库并相应地保留它们自己的域？
或
您是否有一个与 Neo4J 建立数据库连接的微服务来控制持久性和查询？
两者似乎都不对...
最佳答案
database-per-service 的模式是discussed here ，并将选项分解为:
- 共享数据库，但每个服务都有私有(private)表。
- 共享数据库，但每个服务的私有(private)架构。
- 每个服务的独立数据库。
显然 3 将是最昂贵的，因为您希望每个 Neo4j 实例都在自己的服务器上，因此它有专用的内存和硬件，如果您需要集群解决方案，那么这将成为一个单独的集群 -服务。不推荐，尤其是当意识形态是这个决定的驱动因素时。
1 和 2 是更好的选择，特别是如果跨微服务访问的数据本质上是相关的，因为 Neo4j 在存储连接数据时效果最好，并且随着数据在多个数据库之间的孤立越多，它的值(value)就越大。
也就是说，这些选项存在一些挑战。
Neo4j 不使用表，目前也没有单独的架构来划分不同用户之间的数据可见性。
虽然您可以让微服务仅使用仅触及图形特定部分的已定义查询，但这通常比所需的控制更宽松。
您可以改为使用 subgraph access control方法，这是我最推荐的一种方法，可以满足您的需求。
这归结为创建过程来封装您希望对每个微服务可用的查询(直接使用 Java API，或从过程代码中进行 Cypher 查询)，然后为每个微服务创建自定义角色 (没有读取权限)，但允许他们调用适当的过程。这确保每个微服务的自定义角色只允许通过允许的过程与图交互(当然，过程可以做他们想做的任何事情，而不受调用用户的角色或权限的限制)。
就 Multi-Tenancy 方法而言，在单个数据库中将不同图形之间的数据分开，这是目前备受关注的一个功能，并且正在实现中。在 2018 年即将发布的版本中寻找此功能。也就是说，这对您是否有用取决于此功能的实现以及您的数据的性质。
关于java - 微服务架构中的 Neo4J，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49606124/