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

Question

[Narts]

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

Comments

[shurshur]

Не существует универсального ответа. Зависит от специфики задачи, требований к нагрузкам, к безопасности, к ресурсу команды разработки... Опять же, если это уже прекрасно работает, не нужно это "чинить" ради неясной идеи.

В общем и целом - да, это вполне нормально для подавляющего большинства проектов.

[check197]

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

Answer 1

[login40k]

Не поддержу отвечающих выше. В мире микросервисных архитектур есть популярный антипаттерн https://microservices.io/patterns/data/shared-data... - шаренная база данных. Это обратная сторона паттерна database per servive. Чтобы избегать проблем с шаренными хранилищами применяют, те самые, "глобальные" апи, которые принадлежат конкретной системе. Эта система и ее команда управляют доступом к этой БД. Эти апи называют CRUD интерфейсами например.

Comments

[pkokoshnikov]

Обратная сторона подхода база на сервис.
Допустим вам нужен какой то справочник(набор данных который везде одинаковый), и он нужен вам при старте, то есть вы не можете без него работать. Тогда если этот справочник закрыт апи, то вы не сможете стартовать сервисы если сервис справочник недоступен или его сломали при деплое. Тогда напрашивается вариант персистент с кешем в самих сервисах. Либо хранение этого справочника локально в каждом сеовисе. Что согласитесь довольно сильное усложнение всей архитектуры.
На мой взгляд нужно отталкиваться от требований и критичности сервисов. Если требования позволяют нужно упрощать, и нет ничего проще одной базы, к тому же как правило, база данных один из самых надежных компонентов системы, вероятность выхода из строя котрого гораздо ниже чем сервиса справочника.
Поэтому слепое следование практикам всегда плохо, всегда нужно взвешивать плюсы и минусы для вашего случая.

[login40k]

pkokoshnikov, исходя из принципа изоляции, который как раз сейчас в основе cell based architecture в uber/amazon/etc используется как раз ваши данные необходимо тиражировать в локальные независимые хранилища. оценка критичности правильный подход, но критичность систем может меняться и переходить из шаренных хранилищ на персональные может быть чрезвычайно дорого, не сопоставимо со стоимостью хранения дублированных данных.

Answer 2

[rPman]

Да, это нормальная практика, если 'клиенты бд' (для веб это бакэнд) работают с ней не в монопольном режиме либо учитывают этот момент и самостоятельно отслеживают коллизии (такие ситуации редко бывают, обычно веб приложения сразу пишут правильно).

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

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

Answer 3

[Everything_is_bad]

Тут нельзя явно сказать нормально или не нормально, всегда есть за и против, может формат данных в базе уже никто не будет менять. А может и нет, и тут проблема, например, простейший случай, переименовали поле в базе, надо теперь во всех сервисах это же сделать. А может и не надо, может они уже "ходят в базу" через один общий слой (или хотя бы ORM). И т.д., и т.п.

Comments

[Петр Слободянюк]

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

Answer 4

[Антон Антон]

Основная проблема в синхронном изменении всех сервисов при изменении структуры БД. А API можно версионировать, сохраняя обратную совместимость пока все сервисы не перейдут на новую версию.

Answer 5

[Saboteur]

Нормальная практика, но это зависит от задачи.

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

А вариант, когда один сервис пишет, другой активно читает, третий периодически делает какие-то отчеты, четвертый просто мониторит - вполне себе норма.

Answer 6

[MaksMur]

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

Answer 7

[el_gato]

Нормальная - если приложение небольшое, все микросервисы пишутся одним человеком/командой нпример.

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

Answer 8

[mayton2019]

Да. Нормальная. Для сервисов.

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