Одна база данных у разных микросервисов

@joub · Регистрация: 08.01.2013

Студворк — интернет-сервис помощи студентам

Всем доброго!

Надо запилить несколько сэрвисов, и у каждого используется база данных (MySQL)

И у некоторых сэрвисов есть общие справочники (локация: районы, города, улицы, дома)

Подскажите плз, стоит ли использовать одну и ту-же базу, но подключать только те сущности базы (справочники) которые мне необходимы?

Ну и переопределить методы save/update - что-бы нельзя было случайно в них писать...

Или есть другие пути-решения данного вопроса ?

@xoraxax · 22.02.2022, 11:08

вообще никто не мешает использовать несколько баз в проекте. Еще можно сделать отдельный сервис для адресов, например.

@joub · 22.02.2022, 11:11 **[ТС]**

Сообщение от xoraxax

вообще никто не мешает использовать несколько баз в проекте. Еще можно сделать отдельный сервис для адресов, например.

Я вообще про использование одной базы...

@xoraxax · 22.02.2022, 11:23

ну не хочешь несколько исползьуй одну - очевидно же вроде

@joub · 22.02.2022, 11:40 **[ТС]**

Сообщение от xoraxax

ну не хочешь несколько исползьуй одну - очевидно же вроде

В этом и вопрос, на сколько это хорошо/плохо или возможны глюки/сбои?

@korvin_ · 22.02.2022, 11:47

Сообщение от joub

В этом и вопрос, на сколько это хорошо/плохо или возможны глюки/сбои?

У каждого микросервиса должна быть своя/свои БД. Если тебе в разных сервисах нужны данные из одной базы, значит они сильно связаны и это должен быть один сервис.

Сообщение от joub

Ну и переопределить методы save/update - что-бы нельзя было случайно в них писать...
Или есть другие пути-решения данного вопроса?

В каком смысле переопределить? Зачем тебе вообще методы save/update там, где не нужно?

Добавлено через 2 минуты
https://microservices.io/patte... vices.html

@joub · 22.02.2022, 12:03 **[ТС]**

Сообщение от korvin_

У каждого микросервиса должна быть своя/свои БД.

У меня есть сквозной справочник локаций, который используется практически в 7 из 10 модулей монолита, но сами модули слабо друг с другом связанны...

А так-же такая сущность как "Пользователь" , используется просто в 99% моделей, в виде пометки как создателей тех или иных документов, записей, и прочего...

Пользователей я думал вытащить на уровень гетвея (Spring Gateway) но еще не придумал как передавать их в сервисы...

По этой причине и думал использовать единую базу, где хранятся все данные...

@korvin_ · 22.02.2022, 14:19

Сообщение от joub

У меня есть сквозной справочник локаций, который используется практически в 7 из 10 модулей монолита, но сами модули слабо друг с другом связанны...

Никаких сквозных справочников в микросервисной архитектуре быть не должно. Микросервисы общаются через шину сообщений (Message Bus), содержащую всю необходимую информацию.

Допустим, для примера, есть три микросервиса: Профиль (пользователя), Заказы и Доставка. И «справочник» Локаций (адреса доставки), который можно посмотреть как в Профиле, так и при оформлении Доставки.

Пользователь оформляет заказ в мс Заказы, тот отправляет в шину сообщение о том, что заказ сформирован. Далее пользователя переключают на оформление Доставки, тут он может выбрать Локацию из списка ранее использованных, который хранится в локальной БД Доставки, либо добавить новую Локацию. Она сохраняется в локальную БД Доставок, кроме того мс Доставки публикует сообщение в шину, что пользователь такой-то добавил себе новую Локацию. МС Профиль получает это сообщение и обновляет список Локаций пользователя в своей БД. Если пользователь редактирует список Локаций у себя в профиле, то мс Профиль отправляет сообщения об этом в шину, мс Доставки получает эти сообщения и обновляет данные в своей БД.

При этом никаких внутренних ID справочников ни в каких сообщениях в шине быть не должно. Если нужно отправить в шину сообщение типа

JSON
1
2
3
4
5
{
  "bla_bla": "Bla bla",
  "foo": "Bar",
  "location_id": 123
}

то вместо это сообщение должно иметь вид

JSON
1
2
3
4
5
6
7
8
9
{
  "bla_bla": "Bla bla",
  "foo": "Bar",
  "location": {
    "city": "Moscow",
    "street": "...",
    ...
  }
}

Могут быть публичные ID, доступные извне, но они всё равно должны сопровождаться дополнительной информацией, типа:

JSON
1
2
3
4
5
6
7
8
9
10
{
  "bla_bla": "Bla bla",
  "foo": "Bar",
  "location": {
    "id": "c3e90fd7-d4c4-44cd-9c04-d74dde563521",
    "city": "Moscow",
    "street": "...",
    ...
  }
}

Сообщение от joub

А так-же такая сущность как "Пользователь" , используется просто в 99% моделей, в виде пометки как создателей тех или иных документов, записей, и прочего...

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

Сообщение от joub

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

Посмотри как это сделано, например, в Netflix:

Новые блоги и статьи Все статьи Все блоги /
WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .	Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .	Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .	Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114
Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .	Модель микоризы: классовый агентный подход 2 anaschu 06.01.2026 репозиторий https:/ / github. com/ shumilovas/ fungi ветка по-частям. коммит Create переделка под биомассу. txt вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .	Расчёт токов в цепи постоянного тока igorrr37 05.01.2026 / * Дана цепь постоянного тока с сопротивлениями и напряжениями. Надо найти токи в ветвях. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа и решает её. Последовательность действий:. . .	Новый CodeBlocs. Версия 25.03 palva 04.01.2026 Оказывается, недавно вышла новая версия CodeBlocks за номером 25. 03. Когда-то давно я возился с только что вышедшей тогда версией 20. 03. С тех пор я давно снёс всё с компьютера и забыл. Теперь. . .

@joub 9 / 9 / 6 Регистрация: 08.01.2013 Сообщений: 578

	Одна база данных у разных микросервисов 22.02.2022, 10:55. Показов 1889. Ответов 7 Метки нет (Все метки) Всем доброго! Надо запилить несколько сэрвисов, и у каждого используется база данных (MySQL) И у некоторых сэрвисов есть общие справочники (локация: районы, города, улицы, дома) Подскажите плз, стоит ли использовать одну и ту-же базу, но подключать только те сущности базы (справочники) которые мне необходимы? Ну и переопределить методы save/update - что-бы нельзя было случайно в них писать... Или есть другие пути-решения данного вопроса ? 0

@xoraxax 3639 / 2971 / 918 Регистрация: 05.07.2013 Сообщений: 14,220
	22.02.2022, 11:08
	вообще никто не мешает использовать несколько баз в проекте. Еще можно сделать отдельный сервис для адресов, например. 0

@xoraxax 3639 / 2971 / 918 Регистрация: 05.07.2013 Сообщений: 14,220
	22.02.2022, 11:23
	ну не хочешь несколько исползьуй одну - очевидно же вроде 0