微服务架构中的 Neo4J
Neo4J In Microservices Architecture
为了与 DDD 和限界上下文保持一致，众所周知，当您创建微服务时，您应该保持关注点分离。
Neo4J 的主要优势之一是将您的 "connected" 数据保存在 Neo4J 中，以便高效地查询它们之间的关系。
在选择使用 Neo4J 时，这两种相反的力量似乎使微服务架构决策变得困难。
您是否有多个微服务连接到 Neo4J 数据库并相应地保留它们自己的域？
或
您是否有一个微服务与控制持久性和查询的 Neo4J 数据库连接？
两者似乎都不对...
我建议每个微服务有一个 Neo4j 实例。然后，每个微服务都拥有自己的数据库。
database-per-service的模式是discussed here，将选项分解为：
- 共享数据库，但每个服务都有私有表。
- 共享数据库，但每个服务的私有模式。
- 每个服务单独的数据库。
显然 3 将是最昂贵的，因为您希望每个 Neo4j 实例都在其自己的服务器上，因此它具有专用的内存和硬件，如果您需要集群解决方案，那么这将成为一个单独的 cluster-per-service。不推荐，尤其是当意识形态是这个决定的驱动因素时。
1 和 2 是更好的选择，尤其是当跨微服务访问的数据本质上相关时，因为 Neo4j 在存储连接数据时效果最佳，并且在多个数据库之间孤立的数据越多，其价值就越大。
也就是说，这些选项存在一些挑战。
Neo4j 不使用表，目前没有单独的架构来划分不同用户之间的数据可见性。
虽然您可以让微服务仅使用仅涉及图形特定部分的已定义查询，但这通常比所需的控制更宽松。
您可以改用 subgraph access control 方法，这是我最推荐的一种方法。
这归结为创建过程来封装您希望对每个微服务可用的查询（直接使用 Java API，或者从过程代码中进行 Cypher 查询） ，然后为每个微服务创建自定义角色（没有读取权限），但允许他们调用适当的过程。这确保了每个微服务的自定义角色只允许通过允许的过程与图交互（当然，过程可以做他们想做的任何事情，而不受调用用户的角色或权限的限制）。
就 multi-tenancy 方法而言，在单个数据库中将不同图形之间的数据分开，这是目前备受关注的一个功能，并且正在实施中。在 2018 年即将发布的版本中寻找它。也就是说，这是否对您有用取决于此功能的实现以及您的数据的性质。
您可以使用多种模式。
这一次仍然有 MS 共享数据库的可能性，只要它在它们的有界上下文中。
由于仅在翻译层之外，不应在数据层上共享。
或者，您可以将 Neo4j 视为支持某些利用图形的微服务的数据库，例如推荐、欺诈等。然后可以在 event-sourcing 架构中由 domain-events 填充该数据库。
我们不喜欢跨多个服务共享数据库，这使得它们的部署和升级变得困难。
通常，您可以从多个微服务中获取事件流，一个或多个微服务使用 neo4j 创建特定于其用例的图形数据结构。
在此过程中会发生数据重复，因此您必须明智地决定何时复制数据。
为了与 DDD 和限界上下文保持一致，众所周知，当您创建微服务时，您应该保持关注点分离。
Neo4J 的主要优势之一是将您的 "connected" 数据保存在 Neo4J 中，以便高效地查询它们之间的关系。
在选择使用 Neo4J 时，这两种相反的力量似乎使微服务架构决策变得困难。
您是否有多个微服务连接到 Neo4J 数据库并相应地保留它们自己的域？
或
您是否有一个微服务与控制持久性和查询的 Neo4J 数据库连接？
两者似乎都不对...
我建议每个微服务有一个 Neo4j 实例。然后，每个微服务都拥有自己的数据库。
database-per-service的模式是discussed here，将选项分解为：
- 共享数据库，但每个服务都有私有表。
- 共享数据库，但每个服务的私有模式。
- 每个服务单独的数据库。
显然 3 将是最昂贵的，因为您希望每个 Neo4j 实例都在其自己的服务器上，因此它具有专用的内存和硬件，如果您需要集群解决方案，那么这将成为一个单独的 cluster-per-service。不推荐，尤其是当意识形态是这个决定的驱动因素时。
1 和 2 是更好的选择，尤其是当跨微服务访问的数据本质上相关时，因为 Neo4j 在存储连接数据时效果最佳，并且在多个数据库之间孤立的数据越多，其价值就越大。
也就是说，这些选项存在一些挑战。
Neo4j 不使用表，目前没有单独的架构来划分不同用户之间的数据可见性。
虽然您可以让微服务仅使用仅涉及图形特定部分的已定义查询，但这通常比所需的控制更宽松。
您可以改用 subgraph access control 方法，这是我最推荐的一种方法。
这归结为创建过程来封装您希望对每个微服务可用的查询（直接使用 Java API，或者从过程代码中进行 Cypher 查询） ，然后为每个微服务创建自定义角色（没有读取权限），但允许他们调用适当的过程。这确保了每个微服务的自定义角色只允许通过允许的过程与图交互（当然，过程可以做他们想做的任何事情，而不受调用用户的角色或权限的限制）。
就 multi-tenancy 方法而言，在单个数据库中将不同图形之间的数据分开，这是目前备受关注的一个功能，并且正在实施中。在 2018 年即将发布的版本中寻找它。也就是说，这是否对您有用取决于此功能的实现以及您的数据的性质。
您可以使用多种模式。
这一次仍然有 MS 共享数据库的可能性，只要它在它们的有界上下文中。 由于仅在翻译层之外，不应在数据层上共享。
或者，您可以将 Neo4j 视为支持某些利用图形的微服务的数据库，例如推荐、欺诈等。然后可以在 event-sourcing 架构中由 domain-events 填充该数据库。
我们不喜欢跨多个服务共享数据库，这使得它们的部署和升级变得困难。
通常，您可以从多个微服务中获取事件流，一个或多个微服务使用 neo4j 创建特定于其用例的图形数据结构。
在此过程中会发生数据重复，因此您必须明智地决定何时复制数据。