Микросервисы с общей базой данных - PullRequest
0 голосов
/ 29 февраля 2020

Я создал два микросервиса, и оба имеют доступ для чтения и записи к общей базе данных. Один сервис создает / обновляет данные пользователя. Другая служба считывает данные пользователя непосредственно из БД и создает отчеты. Теперь возникает вопрос: если второй микросервис должен обновить некоторые пользовательские данные по причине, следует ли мне использовать первый микросервис для обновления пользовательских данных или напрямую обновлять пользовательские данные в БД из второго микросервиса, поскольку он уже имеет доступ для записи в общую базу данных , Есть ли лучшая практика для этого вида использования?

Ответы [ 2 ]

1 голос
/ 29 февраля 2020

Если у вас есть два микросервиса, для выполнения которых необходимо считывать и записывать одни и те же данные, проблема не в том, какую технику или технологию вы используете для этого (подключение к общей базе данных или предоставление REST API), а в том, почему это происходит на первом месте.

Прежде чем делиться данными, рассмотрите следующие два варианта:

  1. Почему два отдельных микросервиса во-первых? Если они читают и записывают одни и те же данные, то они могут выполнять одну и ту же обязанность, и они должны быть одним микросервисом, а не двумя.

  2. Служат ли данные одной ответственности или более? Если вы моделируете свои данные / базу данных так, чтобы они выполняли две обязанности, то вам нужны не только два микросервиса, но и две базы данных. Я не знаю ваш вариант использования, поэтому трудно сказать, но, например, если вы храните цену продукта и описание продукта в одной таблице, микросервисы как по ценам, так и по каталогам будут совместно использовать базу данных, когда на практике они только нужно поделиться ProductId.

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

  1. Вы можете оптимизировать и масштабировать конвейер чтения иначе, чем конвейер записи.

  2. При необходимости читаемая модель может быть снабжена данными из нескольких моделей записи (представьте, что вы ищете и сортируете товары по названию, категории, цене, рейтингу и т. Д. c).

0 голосов
/ 29 февраля 2020

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

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

По сути, это решит ваш вопрос.

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