> Да, я много где читал, что в одном контейнере докера должно быть одно приложение, но нигде не было внятного и убедительного объяснения почему. Заодно всегда деликатно обходится вопрос о накладных расходах при обмене данными между контейнерами.Представь себе внутрикорпоративный продукт собственного производства. Бизнес заказывает функции, разработчики делают, админы деплоят и админят. Такие программы могут быть условно говоря двух типов: монолитные и микросервисные. Монолитное приложение - это одна большая программа выполняемая на одном большом хосте или ВМ. Все её модули и она сама находятся в оперативной памяти и выполняются на одном процессоре. Это очень быстро и удобно. Чтобы сделать такую софтину отказоустойчивой и сбалансировать её нагрузку тебе нужно создать вторую третью и т. д. сущность и поставить балансировщик. В зависимости от типа запросов к приложению наличия или отсутствия клиент-серверных привязок в рамках сессий или потоков датаграмм ты настроишь свои балансировщики на 2-ом, 4-ом или 7-ом уровне. Таким образом это приложение может быть горизонтально смасштабировано по количеству соединений, но что если сессии пользователей сложны и один пользователь может нагрузить узел так, что ресурсов не хватит? Это ахиллесова пята монолитных приложений, они имеют потолок и часто упираются в невозможность вертикального масштабирования узла. Например, если монолитная корпоративная соплекуха требует 24 ядра и 128 ГБ оперативной памяти на одном узле, то "подкинуть ресурсов" на гипервизоре будет трудно, если на одном физическом CPU у вас предел в 128. Докидывание пары гигабайт с соседнего сокета только замедлит приложение еще сильнее, а если показать виртуалке не 24 ядра, а например 2 сокета по 12 ядер, то производительность приложения будет завесеть от того приучили этот монолит к многопроцессорности или оно на это смотрит глазами ядра ОС... в общем это печально и это предел.
Логичным способом будет разделить функционал приложения на 2 части. Например из 146 функций мы возьмём 40 и положим на первый сервер приложений (например фронтенд) а оставшиеся 106 перевалим на бекенд и свяжем их через API, которое сами и напишем. Сделаем HA/LB и получим уже что-то более производительное без покупки баснословно дорогого железа или тончайших системных оптимизаций (бизнесу начхать на академические упражнения им работать надо). И вот так и будем жить пока 106 на бекенде не превратится в 206 и снова всё повторится. Далее разрубим тьолстый бекенд на 2, потом на 3 и потом....
И вот потом начнётся следующая проблема. Полный граф взаимодействия всех типов серверов приложений порождает сложность в сопровождении, мониторинге производительности, обновлении и изменении функционала. Каждый раз добавляя новые вершины в этот граф сложность системы вырастает нелинейно и те самые сетевые издержки начинают стремительно ухудшать производительность автоматизированной системы в целом.
Вот тут нам и подходит микросервисная архитектура. Каждый модуль каждого приложения мы положим в отдельный контейнер и сделаем так, что обмен информацией будет происходить не по цепочке запросов а в очередях брокера кластеризованной шины данных, как бы соединяющих все эти маленькие контейнеры с микросервисами (самодостаточными функциональными модулями решающие простую задачу и отдающиеся по API).
Красиво и элегантно микросервисная архитектура выглядит тогда, когда сверху над ней есть автоматизация CI/CD, чтобы не человек (админ) занимался установками, а это делали разработчики по своим расписаниям. Чтобы и тесты и мониторинг всё автоматически поднималось, создавалось и работало без помощи админа, который занимается железной инфраструктурой и общими вопросами.
Над вами тут смеются, потому что вы используете докер, как средство админства, в то время как это средство разработчиков, которые избавляются от вас как от админа при разработке своих задач =) по факту нет, конечно, им требуется еще и вся инфраструктура, чтобы оно работало, просто своими автоматизациями занимаются сами.
Если нужен хостинг, то докеры вам не нужны, вам нужны контейнеры или виртуалки. Запихивать в докер 1001 приложение и еще и настраивать какое-то взаимодействие между ними - это всё назло кондуктору, куплю билет - пойду пешком.
Если мы говорим о производительности, то в условиях однопроцессорного сервера потенциально бесконечной мощности (оно не существует в объективной реальности) монолитная архитектура всегда выигрывает по производительности, потому что нет никаких межсущностных API, прослоек в виде сети, всё работает напрямую вызывая функцию по имени из соседнего блока оперативной памяти. В реальности никаких бесконечных мощностей не будет и уперевшись в проблемы вертикального масштабирования, микросервисная архитектура будет выигрывать по соотношению производительность к стоимости владения. Кстати, обратите внимание, как процениваются облака и сравните с проценкой традиционного хостинга. А еще в реальности микросервисная архитектура может быть вредна (маленькое приложение разнесли на кучу еще более мелких в условиях плохой сети), не возможна (куча легаси монолитного вендорспецифичного софта), дорога (когда покупаются все контейнеры в облаках) и вообще это всё вопросы не вашего ума дела, это за вас решат разработчики корпоративного софта.
