Микросервисы: разложение приложения на основе графа db

Question

Я планирую разложить приложение, которое я начал строить в виде монолита с помощью базы данных графов в микросервисы. Но дилемма, с которой я столкнулась, пытается найти правильное решение для разделения различных сервисов и не потерять преимущества, предоставляемые базой данных графа.

Идея, которую я изначально рассмотрел, состоит в том, чтобы разделить каждый отдельный объект на свой собственный микросервис, используя хранилище документов для сохранения данных для каждой службы. Затем определите службу более высокого уровня для управления отношениями.

Например, с отношением (A) -> (B), создаст 3 микросервиса, службу для объектов типа A, другую для объектов типа B и третий более высокий уровень с базой данных графа, хранящие узлы типа A и B, содержащие только идентификаторы и отношения между ними.

Вопрос 1: Есть ли что-то не так с этим подходом в отношении сцепления, отказоустойчивости или чего-либо еще, о котором я не могу сейчас думать?

Вопрос 2: Когда вы бросаете в игру третью сущность, например (A) -> (B), (A) -> (C) и (C) -> (B) , какой из них будет лучшим подходом в этом сценарии?

• Я придерживаюсь стратегии только одного обслуживания более высокого уровня, чтобы поддерживать все отношения?
• Я создаю несколько сервисов более высокого уровня для поддержания каждого типа отношений?

Вопрос 3: В случае отношений между субъектами одного и тем же типа, например (Person) - isFriendOf -> (Person), имея в виде концепции разделения проблем, это разрешить разделить управление отношениями на другую услугу?

Любой вход, отзывы и идеи очень приветствуются.

---

Я делал некоторые исследования по этому вопросу, и ради ясности, я предлагаю более конкретный сценарий, так будет легче обсуждать об этом. модель график будет выглядеть примерно так:

Целью здесь было бы реализовать услугу рекомендации списка воспроизведения песни, пытаясь найти песни, которые данный пользователь еще не прислушиваются, основанные на жанры и исполнители из песен, которые пользователь уже прослушивал, а также из других песен, прослушанных другими пользователями, за которыми следует текущий пользователь.

Answer 1

В соответствии с ответом на этот вопрос (в разделе «Обмен программаторами») How do you handle shared concepts in a microservice architecture? кажется, что на самом деле первоначальный предлагаемый подход является хорошим. Если разделение проблем выполняется должным образом при удушении разных частей в разные службы, тогда не должно возникать проблем с связью.

Что касается отказоустойчивости, трудно обобщить, поэтому было бы лучше изучить специфику в каждом конкретном случае и определить в каждой ситуации, как изящно отказаться от обслуживания, когда другие службы недоступны.

Что касается вопросов 2 и 3, я сначала попытался обобщить абстрактный подход, но, рассмотрев конкретный случай, я закончил вывод, который также трудно обобщить. Таким образом, для этой конкретной модели графа, я придумал это возможное решение:

Так в основном, на вопрос 3, ответ да, потому что таким образом, могут быть использованы отношения пользователей следующих других пользователей другой службой, и она не будет вынуждена опираться на систему рекомендаций.

И на вопрос 2 он относится к модели домена, поскольку имеет смысл разделить службу пользователя, помимо службы дружбы, в первую очередь, что отношения не нужно тиражировать в службе рекомендаций, в то время как все другие отношения действительно связаны между собой, имеет смысл держать их вместе, по крайней мере, в то время как нет необходимости раздроблять их снова, чтобы иметь возможность использовать их для других служб.