Neo4J在微服務架構中

Question

為了與DDD和有界上下文保持一致，眾所周知，當您創建微服務時，應保持關注點分離。

Neo4J的主要優點之一是將您的“連接”數據保留在Neo4J中，以便有效地查詢它們之間的關系。

當選擇使用Neo4J時，這兩個相反的力量似乎使微服務架構決策變得困難。

您是否有多個微服務連接到Neo4J db並相應地保留其自己的域？

要么

您是否有一個微服務，它具有與Neo4J的數據庫連接以控制持久性和查詢？

兩者似乎都不正確...

Answer 1

此處討論了“每個服務的數據庫”模式，並細分了以下選項：

1. 共享數據庫，但每個服務都有專用表。
2. 共享數據庫，但每個服務都有專用模式。
3. 每個服務使用獨立的數據庫。

顯然3將是最昂貴的，因為您希望每個Neo4j實例都在其自己的服務器上，以便具有專用的內存和硬件，並且，如果您需要集群解決方案，那么它將變成每個服務一個單獨的集群。 不建議這樣做，尤其是當意識形態是決定的驅動力時。

1和2是更好的選擇，特別是如果跨微服務訪問的數據具有內在關聯性時，因為Neo4j在存儲連接的數據時效果最佳，並且在多個數據庫之間存儲的數據越多，丟失的價值就越大。

也就是說，這些選項存在一些挑戰。

Neo4j不使用表，並且當前沒有單獨的架構來划分不同用戶之間的數據可見性。

雖然您可以讓微服務僅使用僅接觸圖的特定部分的已定義查詢，但這通常比所需的控件寬松。

您可以改用子圖訪問控制方法，這是我最推薦的一種方法。

這歸結為創建過程，該過程封裝了您希望可用於每個微服務的查詢（可以直接使用Java API或從過程代碼中進行Cypher查詢），然后為每個微服務創建自定義角色（無讀取權限） ），但允許他們調用適當的程序。 這樣可以確保僅允許每個微服務的自定義角色通過允許的過程與圖進行交互（並且這些過程當然可以執行它們想要的任何操作，而不受調用用戶的角色或權限的約束）。

就多租戶方法而言，將數據保持在單個數據庫的不同圖形之間是分開的，這是當前引起人們高度關注的功能，並且正在實施中。 在2018年即將發布的版本中尋找這一點。也就是說，這對您是否有用取決於此功能的實現以及數據的性質。

Answer 2

我們不希望跨多個服務共享數據庫，這會使它們的部署和升級變得困難。

通常，您可以從多個微服務獲取事件流，並且一個或多個微服務使用neo4j來創建特定於其用例的圖數據結構。

在這種情況下，將發生數據復制，因此您必須明智地決定何時復制數據。

Answer 3

我建議每個微服務有一個Neo4j實例。 然后，每個微服務都擁有自己的數據庫。

Answer 4

您可以使用幾種模式。

一次，仍然存在MS共享數據庫的可能性，只要它在其有限上下文內即可。 由於僅在轉換層之外，因此在數據層上不應共享任何內容。

或者，您可以將Neo4j視為支持利用該圖的某些微服務的數據庫，例如推薦，欺詐等。然后可以通過事件源體系結構中的域事件來填充該數據庫。