微服務：分解一個基於圖形數據庫的應用程序

Question

我打算分解一個應用程序，我開始用圖形數據庫構建爲一個整體到微服務中。但我面臨的困境是試圖找到一個適當的解決方案來分割不同的服務，而不是放棄圖形數據庫提供的好處。

我最初考慮的想法是將每個不同的實體分成它自己的微服務，使用文檔存儲來保存每個服務上的數據。然後定義一個更高級的服務來管理關係。例如，在關係（A） - >（B）中，將產生3個微服務，一個用於A型實體的服務，另一個用於B型實體，另一個用於圖形數據庫，存儲類型A和B的節點，僅包含ID和它們之間的關係。

問題1：在耦合，容錯或其他我現在無法想到的方法中，這種方法有什麼問題嗎？ （A） - >（B），（A） - >（C）和（C） - >（B）當您將第三個實體投入遊戲時， ，哪一個在這種情況下是最好的方法？

• 我是否堅持只有一個更高層次的服務來維護所有關係？
• 我是否生成幾個更高級別的服務來維護每種類型的關係？

問題3：在相同的類型，例如（人）的實體之間的關係的情況下 - isFriendOf - >（人），銘記的關注點分離的概念，它是是否適用於將關係管理分爲不同的服務？

任何輸入，反饋和想法都非常受歡迎。

---

我一直在做一些關於這個問題的研究，併爲清楚起見，我將提出一個更具體的情況，所以它會更容易一下討論。 圖形模型將是這樣的：

的目標在這裏將實現歌曲的播放列表推薦服務，試圖找到一個給定的用戶還沒有聽過的歌曲，基於流派以及來自用戶已經收聽的歌曲的藝術家以及來自其他用戶收聽的其他歌曲的藝術家，其次是當前用戶。

Answer 1

根據這個問題的答案（在程序員堆棧交換）How do you handle shared concepts in a microservice architecture?似乎實際上最初提出的方法是一個很好的方法。如果在將不同的部分扼殺到不同的服務時將問題分開，那麼不應該存在耦合問題。

對於容錯，很難一概而論，所以最好是逐個研究具體情況，並在每種情況下確定在其他服務不可用時如何正常降級服務。

關於問題2和問題3，我首先試圖採用一種廣義的抽象方法，但在考慮具體的案例後，我最終得出的結論也很難概括。因此，對於這個特定的圖模型，我想出了這個可能的解決方案：

所以基本上，問題3的答案是肯定的，因爲這樣一來，下面的其他用戶的用戶之間的關係可以用通過其他服務，它不會被迫在推薦系統上下降。

而對於問題2，它依賴於域模型，因爲將用戶服務從友誼服務中分離出來是有意義的，因爲這種關係不需要在推薦服務中複製，雖然所有其他關係確實是相關的，但將它們保持在一起是合理的，至少在沒有必要再分割它們以便能夠被重新用於其他服務的情況下是合理的。