Neo4J在微服务架构中

此处讨论了“每个服务的数据库”模式，并细分了以下选项：

1. 共享数据库，但每个服务都有专用表。
2. 共享数据库，但每项服务都有专用模式。
3. 每个服务使用单独的数据库。

显然3将是最昂贵的，因为您希望每个Neo4j实例都在其自己的服务器上，以便具有专用的内存和硬件，并且，如果您需要集群解决方案，那么它将变成每个服务一个单独的集群。不建议这样做，尤其是当意识形态是决定的驱动力时。

1和2是更好的选择，尤其是如果跨微服务访问的数据具有内在关联性时，因为Neo4j在存储连接的数据时效果最佳，并且在多个数据库之间存储的数据越多，丢失的价值就越大。

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

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

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

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

这归结为创建过程，该过程封装了您希望可用于每个微服务的查询（可以直接使用Java API或从过程代码中进行Cypher查询），然后为每个微服务创建自定义角色（无读取权限） ），但允许他们调用适当的程序。这确保了仅允许每个微服务的自定义角色通过允许的过程与图进行交互（并且这些过程当然可以执行它们想要的任何操作，而不受调用用户的角色或权限的约束）。

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