Комментарии 10
а зачем эти крайности?
делать модульное приложение которое раьотает как единое целое но с возможность разработки и тестирование отдельных модулей.
Монолиты и микросервисы: что выбрать разработчику
То, что наиболее подходит для текущего проекта. Ваш кэп.
Монолиты и микросервисы позволяют не только построить эффективную
систему, которая долго просуществует без серьезных изменений, но и
создать удобную кодовую базу
После нескольких прочтений смысл этого пассажа понять так и не удалось.
А какие варианты ещё есть, которые не монолиты и не микросервисы, от которых система неэффективная и кодовая база неудобная?
А ещё есть распределённые монолиты, которые зачастую и пилят...
Монолиты связаны одной кодовой базой и соответственно все компоненты в приложении опираются на один стек. Не получится гибко выбирать версии и писать приложение на разных языках
Вы так говорите как-будто это что-то плохое. Когда в проекте единая версия языка, библиотек и один стек. Это упрощает разработку, поддержку и менеджмент персонала. Вообще стек и технологии должен выбрать ведущий инженер ещё до начала проекта, а не толпа сениоров с 2 годами посреди проекта пишет новый сервис на Go.
Тем более что микросервисы тоже можно заставить быть такими. Достаточно чтобы у вас была монорепа.
Секретная джедайская техника: делать монолит, любой модуль которого можно легко задеплоить, как отдельный сервис.
Монолиты связаны одной кодовой базой и соответственно все компоненты в приложении опираются на один стек. Не получится гибко выбирать версии и писать приложение на разных языках;
Точно? А вот наш стек позволяет собирать бинарник (программу) из модулей на разных языках...
А еще есть LLVM...
Монолиты — это вариант для большинства Enterprise-продуктов, стартапов (туда же Minimum viable product и Proof of concept) и приложений с тесно связанной бизнес-логикой.
Очень сомнительное утверждение. Ну разве что "модульные монолиты" (которые и не монолиты вовсе).
Идея собрать приложение как конструктор — из сервисов, которые содержат какую-то законченную логику и хранят данные независимо от других сервисов
А теперь представьте, что БД у вас - десятки тысяч объектов (таблиц, индексов). Терабайты данных. И все эти объекты и данные используются совместно (в основном) всеми сервисами.
Получите неимоверный геморрой с репликацией данных. И лаги по данным в разных сервисах. проблемы с разрешением коллизий (когда два сервиса одновременно изменили одни и те же данные, но они об этом еще не знают...)
Наш проект не существует сам по себе — он является частью общей инфраструктуры и обрабатывает данные, которые приходят со стороны.
Аналогично
Над проектом работает не одна команда — на данный момент у нас есть разделение на несколько направлений, в которых параллельно идет разработка. У нас разные темпы, и мы выстраиваем независимую друг от друга логику. Мы имеем разные циклы разработки, и было важно отделить модули не только логически.
Аналогично
Перед нами стоит задача сделать отказоустойчивую, расширяемую систему, способную гибко и быстро адаптироваться к изменяющимся бизнес-требованиям.
Аналогично. Высокопроизводительная, высоконагруженная, высоконадежная система. АБС банка из топ-10 с 50млн клиентов.
можно добиться и другим путём — разделением монолита на модули
Бинго!
БД одна - все работают с ней в реальном времени. Система "многопользовательская" - все, что работает (любая программа), работает в рамках своего "задания" (job), которое является своего рода "контейнером" - своя память, свои настройки окружения. Падение (или принудительное закрытие) одного задания никак не влияет на остальные. Программа может быть вызвана как синхронно (в том же задании), так и асинхронно (в отдельном фоновом задании).
Для обмена данными система предоставляет предостаточно средств - очереди (системные объекты - простые, быстрые), пользовательские пространства, пользовательские индексы и т.п.
Программа может быть собрана из модулей, написанных на разных языках - мы не ограниченный каким-то одним. Процедура внутри программы может быть как внутренней (внутри той же программы), так и внешней - внутри сервисной программы (динамическая библиотека) или вообще отдельной программой (но внутри вызывающей программы она описывается как внешняя процедура).
Любая программа разрабатывается, тестируется и внедряется независимо от остальных. Ее внутренняя логика всегда может быть изменена (при условии обратной совместимости контракта) при необходимости и независимо от всего остального.
сохраняется простота использования монолитов в разработке, отладке и согласованности данных, а еще позволяют, как микросервисы, разделить приложение на слабосвязанные модули
Именно так.
Если в микросервисах сервисы физически отделены друг от друга, то в модульных монолитах ответственность за поддержку разделения ложится на плечи разработчиков
Смысл ускользает. Что значит "сервисы физически разделены"? Каждый сервис выполняет свою логическую функцию? Так в модульном монолите точно также - каждая логическая функция реализуется в виде отдельного объекта, который может быть вызван из любого места, любого другого объекта. И никакой особой супердисциплины тут не надо. Вопрос исключительно архитектурный.
Чтобы определить степень независимости модуля, стоит обратить внимание на количество зависимостей и их силу. Другими словами, сколько модулей взаимодействуют с текущим и какое количество его методов реализуется в остальных. Если зависимостей слишком много, то, возможно, модули следует объединить.
Крайне спорное утверждение. Если модуль Б вызывается только из модуля А и не выполняет логически обособленной функции, его можно объединять с модулем А. Один модуль - одна логическая функция.
Такой подход мне кажется наиболее интересным, так как совмещает простоту и эффективность, но работать с чистой реализацией модульных монолитов мне пока не доводилось
Ну не повезло...
Когда необходимо повысить отказоустойчивость, чтобы отказ одного модуля не прекращал работу других
Нонсенс. Если у вас из бизнес-процесса выпадает кусок логики, весь процесс становится невалидным.
Когда есть техническое обоснование, почему какая-то из частей приложения должна работать с отличным от всего приложения стеком
Точно также реализуется в модельных монолитах.
Когда приложение уже является крупным продуктом и предполагается что будущем количество функциональностей будет возрастать, так же как и количество пользователей
Модульный монолит все это позволяет делать ровно с таким же успехом.
Когда важно сократить цикл разработки, обеспечить параллельную разработку несколькими командами
Аналогично.
Монолиты и микросервисы: что выбрать разработчику