Neo4J在微服务架构中

Question

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

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

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

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

OR

你有一个微服务与Neo4J的数据库连接控制持久性和查询吗？

两者似乎都不对......

Answer 1

每服务数据库的模式为discussed here，并将选项分解为：

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

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

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

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

Neo4j不使用表格，目前没有单独的架构来划分不同用户之间的数据可见性。

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

您可以使用subgraph access control方法，这是我建议您满足需求的方法。

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

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

Answer 2

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

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

在此数据中会发生重复，因此您必须明智地调用何时复制数据。

Answer 3

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

Answer 4

您可以使用多种模式。

一旦MS共享数据库仍有可能，只要它在有限的上下文中。 仅在转换层之外，数据层上不应该共享。

或者，您可以看到Neo4j作为数据库为某些使用该图的微服务供电，例如推荐，欺诈等。然后可以通过事件采购架构中的域事件填充该数据库。