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

@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:

Новые блоги и статьи Все статьи Все блоги /
Модель микоризы: классовый агентный подход 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. С тех пор я давно снёс всё с компьютера и забыл. Теперь. . .	Модель микоризы: классовый агентный подход anaschu 02.01.2026 Раньше это было два гриба и бактерия. Теперь три гриба, растение. И на уровне агентов добавится между грибами или бактериями взаимодействий. До того я пробовал подход через многомерные массивы,. . .	Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Programma_Boinc 28.12.2025 Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Налог на собак: https:/ / ********/ gallery/ V06K53e Финансовый отчет в Excel: https:/ / ********/ gallery/ bKBkQFf Пост отсюда. . .	Кто-нибудь знает, где можно бесплатно получить настольный компьютер или ноутбук? США. Programma_Boinc 26.12.2025 Нашел на реддите интересную статью под названием Anyone know where to get a free Desktop or Laptop? Ниже её машинный перевод. После долгих разбирательств я наконец-то вернула себе. . .

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

	Одна база данных у разных микросервисов 22.02.2022, 10:55. Показов 1869. Ответов 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