Микросервисы: как эффективно бороться с зависимостями данных между микросервисами

Я разрабатываю приложение, использующее подход к разработке микросервисов со средним стеком. Я столкнулся с ситуацией, когда данные должны быть разделены между несколькими микросервисами. Например, предположим, что у меня есть пользовательские службы, службы видео, сообщений (отправка / получение, входящие и т. Д.). Теперь записи видео и сообщений принадлежат записи учетной записи. Когда пользователи создают видео и отправляют / получают сообщение, существует внешний ключ (userId), который должен быть связан с записями видео и сообщений, которые они создают. У меня есть сценарии, в которых мне нужно отображать имя, отчество и фамилию, связанные, например, с каждым видео. Предположим теперь, что во внешнем интерфейсе пользователь просматривает список видео, загруженных в систему, по 50 за раз. В худшем случае я мог бы увидеть ситуацию, когда возникает 50 запросов, когда каждое видео привязано к уникальному пользователю.

Кажется, есть два подхода к этому вопросу:

Во-первых, я вызываю API-интерфейс к пользовательской службе и привязываю каждого пользователя к каждому видео в списке. Это кажется неэффективным, поскольку если я буду делать по одному звонку для каждого видео, это может стать по-настоящему болтливым. Во втором сценарии вызова api я получал список видео и отправлял отдельный список внешних ключей пользователя для запроса, чтобы каждый пользователь был привязан к каждому видео. Это кажется более эффективным, но все же кажется, что я теряю производительность, собирая все вместе, чтобы отправить для отображения, или, как бы то ни было, этим нужно манипулировать.

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

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


person user1790300    schedule 07.06.2017    source источник


Ответы (2)


Меня тоже интересует этот вопрос.

Во-первых, очень часто встречается описанный вами сценарий. Пользователи, видео и сообщения - определенно три разных микросервиса. Нет проблемы в том, как вы разбили систему на части.

Во-вторых, есть несколько вариантов решения проблемы обмена данными. Взгляните на отличную статью от auth0: https://auth0.com/blog/introduction-to-microservices-part-4-dependencies/

person Sergey Yarotskiy    schedule 08.06.2017

Не ограничивайте свое дизайнерское решение двумя описанными вами вариантами. Самое сложное в микросервисах - это понять, что такое сервис и как разделить ваше приложение на части / сервисы, которые имеет смысл реализовать как «микросервис».

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

Из того, что я вижу в вашем примере, я бы разработал 1 микросервис, который выполняет запрос. Помните, что одна из основ проектирования микросервиса - быть максимально независимым. Нет необходимости усложнять сервисы, это не SOA.

https://martinfowler.com/articles/microservices.html -> отличное чтение!

С уважением, Ларс

person Lars    schedule 08.06.2017
comment
Согласитесь, однако, в целом, я не думаю, что в статье Льюиса / Фаулера есть что-то, что можно сказать о составе услуг, что полезно для OP здесь. - person tom redfern; 08.06.2017
comment
Не согласен. Нет проблем с тем, как приложение было разбито на микросервисы. Все решения разумны. - person Sergey Yarotskiy; 08.06.2017
comment
Возникает вопрос: если три микросервиса, описанные выше, объединить в одну, может ли это потенциально привести к созданию своего рода более крупной монолитной службы, поскольку для пользователя будет создано больше возможностей? Если вы не говорите о создании микросервиса, который объединяет данные из необходимых зависимостей. - person user1790300; 09.06.2017
comment
@tomredfern - статья не фокусируется на этой конкретной проблеме, но в ней говорится о границах между сервисом и контекстом, на которые, я думаю, важно обратить внимание. - person Lars; 09.06.2017
comment
Мне нравится статья @SergeyYarotskiy, которую он опубликовал в своем ответе, но в ней тоже говорится о случае слияния служб в одну, если службы становятся слишком болтливыми, что я попытался обрисовать в своем первоначальном ответе. - person Lars; 09.06.2017