Каковы "реальные" решения для предотвращения дублирования данных в микросервисах? - PullRequest
0 голосов
/ 02 июля 2018

Предположим, у меня есть микросервис для обмена сообщениями. Микросервис знает, как отправлять электронные письма. У сервиса есть шаблоны электронных писем, которые имеют своего рода «движок шаблонов», такой как pugjs, и могут заменять данные в теле сообщения.

У меня есть служба пользователя (например, для аутентификации / авторизации) и служба банковского счета (у каждого пользователя есть такая). Между микросервисом пользователя и микросервисом банковского счета ясно, что нам не нужно дублировать какие-либо данные, кроме пользовательского uuid.

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

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

  • Я не могу обмениваться базами данных между микросервисами
  • Я не могу делать синхронные запросы между микросервисами

Хорошо ... Я могу использовать брокера, и каждый раз, когда новый пользователь создается / обновляется, микросервис Messaging может хранить эти данные. Но на самом деле это глупость:

  • Я не хочу иметь противоречия с этими данными, и сложно синхронизировать вещи
  • Время и сложность разработки Микросервиса Messaging теперь должны учитывать: прослушивать и извлекать соответствующие данные из событий, сохранять согласованность данных о других доменах / службах, управлять сохраненными данными в базе данных
  • И подумайте о микросервисе сообщений. Неужели я должен хранить все данные, необходимые для разбора шаблонов?

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

Итак, как использовать микросервисы без дублирования данных?

1 Ответ

0 голосов
/ 03 июля 2018

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...