Как синхронизировать модель БД между микросервисами?

Question

[Александр Лавров]

Итак, есть файл modela.py там хранятся модели таблиц в базе данных. Есть несколько микросервисов испльзкющих эти модели. Вопрос состоит в том, как при изменении модели происходила синхронизация между микоосеовисами. При том, что они на разных серверах, а кодовая база в разных репозитлриях.

Comments

[denizen]

А разве концепция микросервисов не подразумевает того, что у каждого сервиса должна быть своя БД?

[stul5tul]

denizen,

А разве концепция микросервисов не подразумевает того, что у каждого сервиса должна быть своя БД?

Отнюдь не подразумевает.
Из соображений производительности вполне рационально иметь и одну общую БД для всех микросервисах в пределах одного пода.

[lega]

stul5tul, > одну общую БД для всех микросервисах

общая БД, но не общие таблицы, один микросервис отвечает за "таблицу" остальные микросервисы обращаются к нему через апи.
Неправильно лезть напрямую в данные к другому микросервису со своей логикой.

[stul5tul]

lega,

общая БД, но не общие таблицы, один микросервис отвечает за "таблицу" остальные микросервисы обращаются к нему через апи.
Неправильно лезть напрямую в данные к другому микросервису со своей логикой.

и общие таблицы в т.ч.
от задачи зависит
если по чтению - то почему нет, риска испортить данные другого микросервиса отсутствуют.

[Андрей]

stul5tul, только прямые обращения препятствуют изменениям в данных.
Например, в микросервисе лотов добавили флаг "блок_до_снятия", он стал его учитывать в своём апи.
Если остальные лезут в базу - у них тоже надо делать эти изменения...

[lega]

stul5tul, > если по чтению - то почему нет

потому что это говнокод, нарушает концепции построения архитектур, влечет разные негативные факторы в перспективе

[stul5tul]

Андрей,

только прямые обращения препятствуют изменениям в данных.

а если там нет записи? если она там раз в сутки?

[stul5tul]

lega,

потому что это говнокод, нарушает концепции построения архитектур, влечет разные негативные факторы в перспективе

хороший специалист отличается от посредственного тем, что хороший сам понимает когда что делать.

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

[lega]

stul5tul, Все верно, но это не тот случай

[stul5tul]

lega,

Все верно, но это не тот случай

Если человек ставит диагнозы архитектуре ПО по паре слов, не анализируя конкретную ситуацию - это тот самый случай.

[Андрей]

stul5tul, да какая разница, есть там запись или нет там записи?

Вот есть у Вас 20 микросервисов на эту таблицу лотов. Один пишет, 19 читают.
Приходит бизнес и говорит - а дай нам еще галку, чтобы ее поставил - и лот отовсюду исчез, ее снял - все появилось обратно. Независимо от того десятка критериев, что определяют активность лота уже.

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

[stul5tul]

Андрей,

Если у Вас 19 читателей обращаются к одному АПИ - Вы измените одно место.

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

И да - лишний вызов API, но каждый раз - и все ради гипотетической необходимости если бизнес придет, вызывает лишние задержки ежедневно ежезапросно.

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

Это я о том, что современные решения зачастую овер-усложняемые когда надо и когда не надо. Если у меня сценарий использования БД позволяет использовать 1 БД на группу сервисов - почему мне нужно создавать их несколько и добавлять оверхеда на синхронизацию между ними.

Answer 1

[Сергей Горностаев]

Объединить логику доступа к данным в отдельный модуль и вынести его в ещё один репозиторий.

Answer 2

[Иван Шумов]

Не знаю что в python, но в php есть приватные пакеты composer, а в nodejs приватные npm пакеты. Бьюсь об заклад тут должно быть тоже самое

Answer 3

[Jhn Doe from by]

При микросервисах насколько я это вижу: 1бд для всех таблиц, на каждую таблицу у вас - 1 репозиторий, 1 таблица, 1 модель в приложении описывающая эту таблицу, 1 ресурс. Разумеется все репозитории приватные.
Перед всем этим зоопарком из кучи сервисов, ставят api gateway.
Как вы будете связывать данные между этими таблицами - без понятия. Можете вручную это делать, вместо базы данных, можете вынести все модели в 1 репозиторий, а его устанавливать в необходимые сервисы.
Я думал что до микросервисов дожить надо, тогда и вопросов таких не будет, или чтобы кто то в команде имел опыт настройки этого зоопарка