несколько микро сервисов, совместно использующих одну базу данных SERVER (один контейнер, несколько баз данных)

Question

Рекомендуется ли подключать несколько служб к одному и тому же серверу базы данных, но каждая из которых имеет свою собственную базу данных.Я думаю, что иметь один экземпляр Postgres лучше, чем каждый сервис / контейнер, имеющий свой собственный экземпляр.

Мой вопрос заключается в том, чтобы каждая служба:

1. работала в своем собственном контейнере с экземпляром сервера БД в том же контейнере
2. работала в своем собственном контейнере и БДдля этой службы запустить в отдельном контейнере только для БД (несколько контейнеров БД / один на службу)
3. один СЕРВЕР БД, несколько баз данных, один контейнер для всех баз данных и все службы подключают этот сервер контейнера / БД

Я понимаю, что у каждой службы должен быть свой собственный БД, но это также означает, что они должны быть полностью отделены даже на сервере.

Я предполагаю, что причина в том, что я хочу иметь один БД СЕРВЕРтак что ресурсы не будут «потрачены впустую» как несколько экземпляров db-сервера, работающего

Я также понимаю, что наличие одного сервера будет означать, что все сервисы будут связаны аппаратно

Answer 1

Да, можно иметь несколько служб на одном сервере.

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

Answer 2

Это не имеет значения.Современные инфраструктуры, как правило, не заботятся о накладных расходах при запуске нескольких копий одного и того же сервиса.Поскольку ввод-вывод базы данных часто может быть критической точкой производительности, вам может оказаться более управляемым не делиться базой данных, поэтому вы можете подвергать базы данных более высокой нагрузке на выделенном и / или более крупном оборудовании.

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

Что бы вы ни решили, вам почти наверняка нужно сделать все параметры (хост, база данных, имя пользователя, пароль) настраиваемыми , обычно через переменные среды.(Я вижу слишком много вопросов SO, имена хостов которых жестко запрограммированы в исходном коде.) Вы должны иметь возможность развертывать одно и то же изображение с разными параметрами в средах разработки, тестирования и производства, которые обычно имеют разные имена хостов.