Нормальная ли практика, когда несколько сервисов подключены к одной бд?

Есть несколько веб-сервисов: апи для фронта, чат-бот, несколько вспомогательных сервисов. Все они "ходят" в одну базу данных. Нормальная ли это практика или все сервисы должны ходить не в бд напрямую, а в единый "глобальный" апи, который только он ходит в бд напрямую?
  • Вопрос задан
  • 11323 просмотра
Пригласить эксперта
Ответы на вопрос 8
@login40k
Не поддержу отвечающих выше. В мире микросервисных архитектур есть популярный антипаттерн https://microservices.io/patterns/data/shared-data... - шаренная база данных. Это обратная сторона паттерна database per servive. Чтобы избегать проблем с шаренными хранилищами применяют, те самые, "глобальные" апи, которые принадлежат конкретной системе. Эта система и ее команда управляют доступом к этой БД. Эти апи называют CRUD интерфейсами например.
Ответ написан
@rPman
Да, это нормальная практика, если 'клиенты бд' (для веб это бакэнд) работают с ней не в монопольном режиме либо учитывают этот момент и самостоятельно отслеживают коллизии (такие ситуации редко бывают, обычно веб приложения сразу пишут правильно).

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

Естественно разработка этих проектов не может быть независимой, любые правки должны учитывать сразу все бакэнды и тестировать сразу все. Но очень часто, второй проект подчиненный, и правят в нем только шаблоны интерфейса.
Ответ написан
Комментировать
@Everything_is_bad
Тут нельзя явно сказать нормально или не нормально, всегда есть за и против, может формат данных в базе уже никто не будет менять. А может и нет, и тут проблема, например, простейший случай, переименовали поле в базе, надо теперь во всех сервисах это же сделать. А может и не надо, может они уже "ходят в базу" через один общий слой (или хотя бы ORM). И т.д., и т.п.
Ответ написан
Fragster
@Fragster
помогло? отметь решением!
Основная проблема в синхронном изменении всех сервисов при изменении структуры БД. А API можно версионировать, сохраняя обратную совместимость пока все сервисы не перейдут на новую версию.
Ответ написан
Комментировать
saboteur_kiev
@saboteur_kiev Куратор тега Веб-разработка
software engineer
Нормальная практика, но это зависит от задачи.

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

А вариант, когда один сервис пишет, другой активно читает, третий периодически делает какие-то отчеты, четвертый просто мониторит - вполне себе норма.
Ответ написан
Комментировать
@MaksMur
Без разницы как ходят, если таблицы конечно не лочатся из за кривой схемы бд.
Главные плюсы одного апи на вход - это дальнейшее сопровождение, когда тебе нужно будет поменять тип поля или изменить запрос, это будет в одном репозитории а не в пяти. Или добавить кэш на частые запросы на редко обновляемые данные.
Ответ написан
Комментировать
el_gato
@el_gato
Нормальная - если приложение небольшое, все микросервисы пишутся одним человеком/командой нпример.

Проблемы появляются когда над сервисами работает куча команд, приложение становится большим, появляются шумные соседи, кому-то вообще не очень подходит выбранная технология, как это все разбить потом непонятно - так как куча общих таблиц, обновлять сложно - так как возникнут конфликты рано или поздно в общих компонентах. Кто-то хочет обновить какой-то из компонентов - другие команды к этому не готовы. и т.д
Ответ написан
Комментировать
mayton2019
@mayton2019
Bigdata Engineer
Да. Нормальная. Для сервисов.

Но если речь идет о микро-сервисах то считается что у них не должно быть единой точки
отказа. Тоесть они в некотором роде - независимы друг от друга. И если у них есть зависимость
в виде централизованной БД то тогда они все являются как-бы кусочками монолита. И тогда
идея микро-сервисности как-бы теряется.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы