Comments 2
Спасибо, внимательно слежу за всей цепочкой ваших публикаций и буду ещё пересчитывать.
Использование отдельной микросервисной БД кажется полезным для:
Горизонтального масштабирования производительности: вынести части нагрузки из монолитной БД.
Безопасности: построить интерфейсы для доступа к данным с проверкой доступа, убрать из адресного пространства БД лишний код.
видел падения всей БД на бою из-за багов plpythonu, postgis, jsquery и т.п.
Обслуживания: восстановить испорченную БД проще, если она небольшая.
молниеносное восстановление важно для операторов связи, например
Стабильности: сделать сервис доступным, даже если часть БД на обслуживании.
Ещё много чего хорошего вроде ослабленной связи между БД, повышения скорости разработки за счёт закрепления команд за сервисами, ...
Но каждый из плюсов имеет с изнанки охапку минусов:
Хорошая производительность доступа к данным или их объединения данных возможна, если важные данные уже есть локально в БД: часто данные копируются хотя бы частично между микросервисами.
по опыту, степень размножения важных данных бывает не менее 2, чаще около 3.
Приходится договориться, что источником "правды" в данных будет единственная БД-владелец. К тому же, все изменения должны быть сперва в БД-владельце (источнике "правды"), а каждый из микросервисов должен следить актуальностью своей копией данных.
разработка актуализации копий данных в микросервисах отнимает у разработчиков много времени, велика цена ошибки: если эту актуализацию сделать топорно, то база данных окажется перегруженой по записи данных
Классическая проблема синхронизации снэпшотов в распределённых системах требует особенных подходов к разработке, в том числе блокировок более чем в 1 БД за транзакцию, распределённых транзакций, частичных откатов с применением saga, и т.п.
Даже если восстановить испорченную микросервисную БД проще, то не факт, что после восстановления она будет консистентна с другими БД.
нужно проработать какую-то досинхронизацию на этот счёт: обычно сразу же после аварии в спешке.
Пларировать изменения в БД хоть и проще за счёт поддержания неизменными интерфейсов, но разработка и координация изменений зачастую сложнее, потому что, например, надо поддерживать разные версии интерфейсов.
По личным примерам, вижу много компаний, которые сознательно отказались от разделения монолитной БД на микросервисные, потому что затраты на это велики, людей не хватает, требуется сильно изменить подходы к работе, а польза хоть и очевидна, но и минусы тоже на виду. В то же время теперь уже никто не отказывается от выноса старых данных или тяжёлой функциональности в отдельные БД, потому что так просто дешевле эксплуатировать. Ну а новую функциональность все стараются сразу разрабатывать с микросервисными БД, чтобы сильно не перерабатывать/усложнять монолитную БД-ядро.
Спасибо за комментарий. Со всеми минусами соглашусь. Выделение отдельной БД под каждый микросервис создает очень много дополнительных издержек (это дорого, надо поддерживать и т.д.) - собственно, как вы и озвучили.
Но зачастую, эти минусы компенсируются с лихвой той же бесперебойностью.
Приведу один простой пример из практики:
Крутилось у нас 2 независимых сервиса(это были сервис клиентских обращений и сервис триггеров, хотя это и не сильно важно для примера). Для хранения сессионной информации они использовали общий редис(на разных db, но это не принципиально). После очередного релиза сервис триггеров начал складывать в тот же редис свой кэш, на который разработчики забыли повесить TTL, как результат, была исчерпана вся память Redis`a и пошла деградация. И, что самое забавное, на виновника торжества эта деградация повлияла не сильно(начали медленнее отрабатывать триггерные действия - не велика беда), а вот сервис обращений, который по сути является одним из ключевых функциональных узлов, прилёг знатно. Восстановили всё достаточно быстро, но осадочек остался.
В общем, всё индивидуально и к каждой конкретной ситуации надо подходить с умом)
Когда и как переходить с монолита на микросервисы. Миграция данных