Стоит ли делать отдельный микросервис для Баз данных?
Здравствуйте, на проекте возник вопрос в реализации дополнительного микросервиса, направленного для работы и управления системы хранения (Релыционными и не реляционными базами данных), и здесь мнения команды разделились. Кто то счетает это хорошей идеей, как возможность связать все сервисы а так же получать актуальную информацию, в добавок упростить и ускорить разработку (Но сразу скажу, у нас направление на качество, а не на скорость). Кто то наоборот, счетает что возможны большие задержки сети и трудности в расширении, так как по мере нагрузки любого сервиса, нужно будет увеличивать ресурсы всех сервисов, тем самым делая его менее отказоустойчивым. Так же скажу, что на сервис планируется большая нагрузка. Всем добра.
Пока звучит как "в нашей микросервисной архитектуре мало сервисов и мы решили запилить еще". Т.к. непонятно что это за сервис и с чего он вдруг понадобился, как это все связано с хранением в других сервисах и т.п. Быть может это какая-то бессмысленная хрень, а может это чтото вроде DWH, но текущего описания для понимания совсем недостаточно.
Сервис должен быть не "для базы данных", а реализовавать какую-то функциональную бизнес-логику. А при такой постановке вопроса всё выглядит так, будто бы решили сделать сервис для хитровывернутого выполнения SQL-запросов.
Если БД используют несколько микросервисов, то (согласно философии микросервисов) это неправильно.
В таком случае, выделяй отдельный микросервис-прослойку для БД. Но это будет уже не БД, а другой, полноценный сервис - со своими API, репозиторием, версионированием и т.д.
Судя по множественности баз - имеет смысл. Особенно в случае что остальные внешние сервисы для микросервисов являются например только rest... Ну и нет вопроса производительности.
Сергей Соловьев, монолит и производительность в общем-то не очень связаны между собой, точнее совсем не связаны. По крайней мере если под производительностью понимать производительность работы по, а не сопровождаемость/модифицируемость)
d-stream, я имею ввиду, что если у нас не хайлоад и особых требований по производительности нет, то можно начать с монолита. Его гораздо лечге разрабатывать и поддерживать
Сергей Соловьев, да, монолит будет попроще в разработке, а в производительности скорее выиграет хотя бы за счёт того что вызовы процедур/методов внутри кода несколько пошустрее вызовов l7
И что самое забавное - до определенного предела этот монолит ещё и будет менее требовательным к ресурсам чем кучка микросервисов)
Нам нечего тут чего-то конкретного посоветовать, мы вообще ничего не знаем про систему. Ну и сразу, микросервисы выделяются по сущностям системы, а не по инструментам. Так же у вас должен быть архитектор, который однозначно скажет, нужно ли вам именно такое решение.
Простой
Простой
Простой
Средний
Средний
