Чем это отличается от планирования ограничений на отдельные сессии или клиентов средствами БД? Точно так же сервис не сможет запросом съесть всю память, не сможет занять все ядра и так далее, но только оверхеда будет в разы меньше (не нужна куча виртуалок, гораздо меньше расходов на работу самого сервера управления БД), перекидывать ресурсы будет гораздо проще (поменял ограничения и все), поддержка (с учетом репликации, контроля прав доступа и так далее) будет вообще кратно дешевле.
Т.е. используя одну СУБД - мы решаем все те же задачи, но при этом в разы дешевле. Зачем тогда создавать по БД на сервис?
Ну, это один из вариантов, но я про другое. На основании чего ты выделишь конкретное число ядер и памяти на каждый сервис? Как у тебя получится "подобрать нужные значения чтобы они работали во всех случаях, приложение ещё и развивается/меняется"?
Хм. Вот у тебя 8 ядер, 128GB RAM и 10 сервисов (20 экземпляров). Этого достаточно для штатной нагрузки при условии "все сервисы в одной БД". Как ты поделишь ресуры на 10 БД и при этом увеличишь надежность? Даже если все сервисы у тебя автономны (в реальности так не бывает).
Так если не удается спланировать соединения - точно так же не удастся спланировать ограничения на отдельные СУБД и точно так же оно начнет падать из-за нехватки ресурсов. А число сеансов на сервис как раз легко контролируется. В чем выигрыш-то от "одна база на сервис"?
Даже в PG есть инструменты (хотя и мало) ограничения ресурсов на сеанс. С памятью там сложнее, с IO возможностей больше. В более взрослых БД таких инструментов гораздо больше. И нежелание настраивать СУБД или осознанно выбирать конкретную СУБД - не повод выделять по серверу на каждый сервис.
И? У тебя 1000 соединений на PG, от одного сервиса в пуле 10, эти 10 стали тормозить - и в чем проблема для остальных? Ну, в теории да, кэш страниц вымывается - но и только.
И, главное, как от этого спасет разделение на несколько БД? Кроме того, что подобные проблемы будут происходить чаще?
Только очень мало кто умеет в обратную совместимость, так как это вообще технологически нетривиально. Для синхронных вызовов еще есть решения (особенно если забыть про RESTful), с БД уже сложнее, а вот с брокерами - совсем грустно. Хотя если не нужно уметь откатывать релиз при ошибках, то все чуть проще, но не надежно.
Так как сервисы все-таки взаимодействуют, они уже не являются совсем независимыми. И выбор разных стеков или БД - становится или очень дорогим или вообще невозможным.
Ни в одном определении микросервисов нет ничего про "шину сообщений". Да и какая разница, шина сообщений или сервис-меш? Связность от этого не меняется (ну, если только не pub-sub, при этом связность вырастает).
Например у тебя разные НФТ для разных частей поддомена (за который отвечает команда). Разные требования по безопасности, производительности, жизненному циклу и так далее...
Чем это отличается от планирования ограничений на отдельные сессии или клиентов средствами БД?
Точно так же сервис не сможет запросом съесть всю память, не сможет занять все ядра и так далее, но только оверхеда будет в разы меньше (не нужна куча виртуалок, гораздо меньше расходов на работу самого сервера управления БД), перекидывать ресурсы будет гораздо проще (поменял ограничения и все), поддержка (с учетом репликации, контроля прав доступа и так далее) будет вообще кратно дешевле.
Т.е. используя одну СУБД - мы решаем все те же задачи, но при этом в разы дешевле. Зачем тогда создавать по БД на сервис?
Т.е. по OOM сервера не падают, хорошо.
Про разделение ресурсов обсуждаем в другой ветке, не будем тут дублировать.
Ну, это один из вариантов, но я про другое.
На основании чего ты выделишь конкретное число ядер и памяти на каждый сервис? Как у тебя получится "подобрать нужные значения чтобы они работали во всех случаях, приложение ещё и развивается/меняется"?
Хм. Вот у тебя 8 ядер, 128GB RAM и 10 сервисов (20 экземпляров). Этого достаточно для штатной нагрузки при условии "все сервисы в одной БД".
Как ты поделишь ресуры на 10 БД и при этом увеличишь надежность? Даже если все сервисы у тебя автономны (в реальности так не бывает).
Да я вообще не видел БД, которая складывается от OOM. Это как-то очень криво надо ее настраивать (да и то не факт, что получится).
Так если не удается спланировать соединения - точно так же не удастся спланировать ограничения на отдельные СУБД и точно так же оно начнет падать из-за нехватки ресурсов. А число сеансов на сервис как раз легко контролируется.
В чем выигрыш-то от "одна база на сервис"?
Даже в PG есть инструменты (хотя и мало) ограничения ресурсов на сеанс. С памятью там сложнее, с IO возможностей больше. В более взрослых БД таких инструментов гораздо больше.
И нежелание настраивать СУБД или осознанно выбирать конкретную СУБД - не повод выделять по серверу на каждый сервис.
И? У тебя 1000 соединений на PG, от одного сервиса в пуле 10, эти 10 стали тормозить - и в чем проблема для остальных?
Ну, в теории да, кэш страниц вымывается - но и только.
И, главное, как от этого спасет разделение на несколько БД? Кроме того, что подобные проблемы будут происходить чаще?
А что DBA сказали? Или с ними не обсуждали, "умерло и умерло"?
И это точно было из-за твоего запроса?
Хмм, и какая БД ложиться по OOM от одного запроса?
Только очень мало кто умеет в обратную совместимость, так как это вообще технологически нетривиально. Для синхронных вызовов еще есть решения (особенно если забыть про RESTful), с БД уже сложнее, а вот с брокерами - совсем грустно.
Хотя если не нужно уметь откатывать релиз при ошибках, то все чуть проще, но не надежно.
Ни для одной из этих целей не нужны микросервисы.
Так как сервисы все-таки взаимодействуют, они уже не являются совсем независимыми. И выбор разных стеков или БД - становится или очень дорогим или вообще невозможным.
Это всего лишь одна из множества книг. Как и все прочие - как с верными, так и с неверными утверждениями.
И чье это определение? И кто его придерживается?
И связность никак не зависит от "одна БД" или "несколько БД".
Так и в монолите нет рисков. Добавил archunit для проверки доступов - и все автоматически проверяется.
Сообщения можно передавать кучей разных способов. Обращение к view в БД - тоже отправка сообщения на чтение, никакой разницы. И соответствует ООП )
Ни в одном определении микросервисов нет ничего про "шину сообщений".
Да и какая разница, шина сообщений или сервис-меш? Связность от этого не меняется (ну, если только не pub-sub, при этом связность вырастает).
А ты не путаешь аутентификацию и авторизацию?
Например у тебя разные НФТ для разных частей поддомена (за который отвечает команда). Разные требования по безопасности, производительности, жизненному циклу и так далее...