Comments 10
На Хабре не так уж много информации о модульных монолитах в целом и практически ничего о конкретных вариантах их реализации.
А зачем? Не, ну в смысле, я согласен, что вам возможно интересно, но по большому счету, вот две крупные рыбины из этого пруда: JavaEE и OSGI. Обе они о том, как строить модульные системы. При этом система работает внутри т.н. «контейнера», который обеспечивает некоторые сервисы для модулей. То есть, в каком-то смысле, построенные на их базе системы и будут такими вот модульными монолитами.
Почему особо не пишут о них? Возможно, потому что и той и другой уже почти лет по 20? Возможно потому, что широко известные (по рекламе микросервисов) ужастики про монолиты редко целиком соответствуют реальности, так как настоящие монолиты, крупняк, они все модульные — иначе их скорее всего просто не написали бы.
Монолит — это программная система, состоящая из ровно одной единицы развёртывания.
"Програмная система" - это совокупность програмного и аппаратного обеспечения для выполнения определенной функции и она никак не может состоят из одной единицы развертывания. Например CRM не может выполнять возложенные на нее функции без БД, сервера приложений, клиента для доступа к этой CRM и т.д.. Но если следовать данной логике, получаем что микросервис сам является "програмной системой", а следовательно и монолитом. А если развивать мысль дальше, то мы придем к тому, что микросервисная архитектура также является одной единцей развервертования и эта единица - информационная система.
Монолитная система не подразумевает некачественного дизайна и отсутствия модульности. То, что система монолитная, ничего не говорит о её качестве.
Как насчет нормальной обработки отказов в монолитной системе средствами самой системы?
Модульный монолит — это способ проектирования монолитной системы с учётом модульности.
«Настоящий» модуль должен быть независимым, самостоятельным и иметь чётко определённый интерфейс.
Тогда в чем отличие модуля от микросервиса? В том, что работает либо все, либо ничего?
Тогда в чем отличие модуля от микросервиса? В том, что работает либо все, либо ничего?
Монолит — это программная система, состоящая из ровно одной единицы развёртывания.
Вроде в вопросе и содержится ответ) микросервис - это отдельная единица деплоя, а модуль - это часть одной большой единицы деплоя.
docker compose up овер_много_контейнеров.yaml, монолит или много микросервисов?
docker compose, в котором есть redis, postgres и рэббит - это монолит?
Если рассматривать информационную систему в целом, то постгрес, редис и кроль, а также другие сущности docker compose, например какой-то рест апи (читай микросервис) будут модулями информационной системы. При этом развернуты эти модули могут быть как одна единица (docker compose) так и по отдельности.
Приведу ещё пример... Дан набор скриптов на PHP, которые выполняют одно простое действие, например на get запрос шлют ответ hello. Этот набор скриптов может интегрироваться в различные cms (wordpress, drupal, bitrix, etc). Одной единицей развертывания с cms он не является, так может устанавливаться в cms сильно позже установки самой сms. Ещё и при этом, этот набор скриптов может работать и отдельно от cms. Этот набор скриптов будет модулем или микросервисом?
Например CRM не может выполнять возложенные на нее функции без БД, сервера приложений, клиента для доступа к этой CRM и т.д.
Конечный пользователь действительно работает с системой как с единым целым. Но разрабатывать эту систему как единое целое просто невозможно, потому что все ее детали слишком сложно одновременно удержать в голове.
Об этом говорит Стив Макконел в книге Совершенный код. Он называет управление сложностью основным императивом(законом) разработки. Не погрязнуть в сложности нам помогает декомпозиция. Следуя принципу Separation of concerns нужно разделить одно большое сложное на более маленькие части, которые уже проще осознать и понять. Главное, чтобы эти части получились максимально независимыми(абсолютно независимыми сделать конечно не выйдет) иначе все равно придется "подгружать" в голову дополнительные знания о зависимостях.
Декомпозируя описанную вами систему, мы можем использовать клиент-серверную архитектуру, которая описывает зоны ответственности и правила взаимодействия каждой составляющей. Далее можно перейти на "сервер"(backend) и декомпозировать его дальше, применяя ту или иную архитектуру(n-tier, sliced, clean). Таким образом в идеале, решая конкретную задачу можно будет сосредоточиться на относительно небольшом участке системы.
Тогда в чем отличие модуля от микросервиса? В том, что работает либо все, либо ничего?
Развивая мысль управления сложностью и тот и другой служат одной цели - получение максимально самостоятельной части системы, над которой можно работать независимо. Просто микросервисы идут дальше модулей и выстраивают "физические" границы между собой, потому что работают в разных процессах.
Плюс к этому позволяют более гибко масштабировать как сами сервисы так и их разработку, быть толератным к отказу части системы. Но при этом добавляют операционных расходов на свое обслуживание и мониторинг.
А если развивать мысль дальше, то мы придем к тому, что микросервисная архитектура также является одной единцей развервертования и эта единица - информационная система.
Не стоит эту мысль развивать таким образом. Использование микросервисов неоправдано, если они спроектированы так, что развернуть их можно только все одновременно. Независимое развертывание - одно из преимуществ микросервисов, которое к тому же способствует независимой разработке. И один из важных аспектов проектирования является в управлении зависимостями между ними, чтобы минимизировать область влияния вносимых в один из микросервисов изменений.
При этом развернуты эти модули могут быть как одна единица (docker compose) так и по отдельности.
Ну, это всё же разные единицы деплоя. У них нет общей памяти, они хостятся в разных процессах.
Отсылаю к книжке https://learning.oreilly.com/library/view/building-evolutionary-architectures/9781491986356/ch04.html#idm45678212630456
Docker compose в вашем примере - это architectural quanta, архитектурный квант.
Цитата из книги
An architectural quantum is an independently deployable
component with high functional cohesion, which includes all the
structural elements required for the system to function properly. In a monolithic architecture, the quantum is the entire application
То есть, есть разница между архитектурным квантом и монолитом.
Ну и это ответ на второй вопрос
Этот набор скриптов будет модулем или микросервисом?
Сервисы не делятся на два множества: монолиты и микросервисы. Есть много разных видов архитектур, включая big ball of mud (отсутствие архитектуры), монолит, модульный монолит, SOA и т.д.
В зависимости от вашего типа архитектуры набор скриптов может быть и модулем монолита и набором доменных скриптов в SOA и выделенными микросервисами (при условии их отдельного деплоя).
Модульный монолит. Начало