Больше полезных материалов и видео на моем канале, telegram: t.me/digital_train

Минусы монолита описанные как будто бы больше на мифы смахивают (особенно если смотреть на них не в вакууме, а сравнивать с микросервисами): - "в монолите сложно понять какой модуль на какой влияет", - не согласен. Сложно понять какие микросервисы друг на друга влияют (сама по себе трассировка, сервис дискавери, поиск проблем и отслеживание циклических вызовов, совместимость апи и прочие проблемы), как и в целом сопровождение микросервисов на порядок сложнеее чем совпровождение монолита, тк в случае монолита простым поиском по коду проекта или дебаггером все можно просмотреть и в билд тайме 99% ошибок взаимодействия ловить можно, надо только те же самые хорошие практики современные использовать чтобы не скатывать все к "big ball of mud" - "сложно масштабировать" - какая по сути разница копию всего приложения развернуть или только его части? разверните X копий (или настройте автоскейл горизонтальный как вам надо) и если нагрузка на модуль платежей будет выше чем нагрузка на модуль такси, то просто какой-то больший процент реплик будет занят обработкой платежей, а какой-то меньший процент реплик займет обработка запросов такси. Ну и в крайних случаях, если очень хочется, можно вынести какой-нибудь ОДИН модуль из монолита, не трогая большую часть других модулей. - "гибкость и простота разаработки, обновления" - ну так если у вас монолит модульный, вы можете эти модули как угодно тасовать, менять и тд (и в том числе, как уже упоминал выше, можно вынести некоторые модули из монолита если такая потребность по какой-то очень важной причине настанет). По поводу истории с булевыми флагами и тестированием - уже давно придумали разные стратегии выкатки сложных обнвлений - типо канареек , фича флагов, A/B и прочих стратегий, которые в монолите тоже можно применять схожим образом как и в случае с микросервисами

@digital_train

17 күн бұрын

Спасибо за развернутый ответ По первому пункту - речь идет о протекании абстракций, в микросервисах эта проблема отсутствует т.к. код физически разделен network и общается через API (предлагаю случаи с некорректно построенной архитектурой, API не рассматривать). Отсюда есть большой плюс, что локальное внесение изменений в код (без изменений API) не может сломать код в другом микросервисе По второму пункту - про содержание микросервисов, в видео это отмеченно, что микросервисы требуют дополнительных затрат т.к. все процессы тестировния, логирования и тд нам нужно поддерживать для всех микросервисов. В монолите за счет меньшего количество сущностей администрирование упрощается По третьему пункту - про масштабирование. Если в монолите мы изначально заложим возможность масштабирования, то в этом случае можно эволюционно прийти к скейлинга отдельных модулей (выделяя их или нет). Часто так бывает, что монолит пишут без видения того что инстансов может быть несколько и как следствие даже простейшее создание второго инстанса может быть проблемой, в отличии от микросервисов где это является ключевым вопросов (то есть мы его никак не потеряем) По последнему пункту - про обновления, действительно если в код заложить систему плагинов то ей можно управлять так же гибко как и в случае с микросервисами, системой флагов или другими механизмами (бренчинг и тд). Но как показывает практика никто этого не делает и в большинстве случаев код прийдется переписывать. Резюмирую - если архитектор с головой то он и монолит построит такой, что большой части проблем удастся избежать. Плюс микросервисов здесь в том что все эти вопросы мы разбираем на самом первом этапе проектирования