Помимо распределения нагрузки микросервисная архитектура позволяет еще и обеспечивать переиспользование этих самых сервисов. То есть если у компании несколько проектов в которых требуется реализация одинаковой и сложной бизнес-логики, то микросервисный подход будет вполне оправдан.
Мало кто умеет соблюсти разумную достаточность. А вот наплодить ненужных архитектурных сущностей за деньги заказчика и потом еще это обслуживать могут наверное все.
И монолит можно проектировать так, чтобы выделение отдельных сервисов в будущем, если это потребуется, доставляло минимум боли. И жесткие связи и зависимости внутри монолитной системы можно успешно ограничивать (фасады, стратегии, Protected Variations/OCP, инверсия зависимостей). Другое дело, что у программистов зачастую недостаточно квалификации, чтобы так проектировать архитектуру. И недостаточно дисциплины, чтобы следовать всем необходимым правилам. А должность системного архитектора (тот кто и должен следить за всем этим) у нас почему-то не прижилась.
Хороший архитектор должен предвидеть все возможности расширения системы и провести "невидимые" границы между компонентами. В идеале архитектура должна быть такой, чтобы можно было легко от монолитной перейти к микросервисной и наоборот.
Дмитрий Попов реальность обычно такова, что этот хороший архитектор появляется только тогда, когда уже наломали дров и сами не справляются. Потому что мало стартапов могут себе позволить нанять опытного архитектора на начальном этапе проекта
сейчас в решении (сборке всех проектов) столько проектов (длл) что сама среда разработки не выдерживает и перезагружается, хотя ОЗУ хватает. верное видео в целом. что бы понять что хотели написать, в каком проекте нужно было что-то исправить использовал VS code и поиск по всему... и правда много проектов, уровней в веб апи путает. а методы не отрефакторенные это вообще два часа провёл и не понял что ещё нужно поменять.
Я правильно понял, что трехслойная архитектура, это монолит? Можете подробнее раскрыть вопрос ахрихетуры? трехслойную легче покрыть более точными тестами, чем монолит, следовательно проблемы выявляются еще на этапе разработки, проброс экзепшнов, так же дает более подробный стек и за счет того, что каждый слой делает свою работу, расширять и править его проще. Мне нужно соблюдать контракты между слоями, изменение которых не частое явление, а саму логику можно менять как угодно. - это как у меня получается. Но вот модульная архитектура, для меня теория.
AntiBlog неистово плюсую. Потом ещё выясняется что разделили неправильно. И это обрастает костылями для того, чтобы это неправильное разделение компенсировать
Ну, не совсем и не всегда. Возьмём в пример виджет отображения погоды на смартфоне. Если что-то пошло не так и виджет выбрасывает исключение, то можно этот виджет просто скрыть, на состояние всей операционной системы это влиять не будет. Но модульность можно организовать только на масштабных проектах, на небольших это сделать нереально, да и не нужно. Я, пока что, не сталкивался с ситуацией, где можно обойтись без монолитности.
Если разбито на пакеты, то это уже не монолит, по-моему. Монолит - мне больше напоминает, например, ядро Линукса, которое собрано всё вместе, со всеми модулями, без возможности подгрузить ещё что-то. А в видео, похоже, идёт речь о непродуманности интерфейсов между слоями, когда рождается это самое "зацепление", когда взаимная реализация слоёв определяет этот интерфейс между ними. Нового ничего, к сожалению, не узнал.
Чет я тупой такой что ли? Но по-моему тема не раскрыта... Вот сегодня внес изменение даже не в трехзвенку, а в двух - изменил прямо на горячую хранимку (оптимизация запроса) и ничего не сломалось... А если, например, микросервис авторизации какой-нибудь выкючить/сломать и все пользователи не могут войти в систему, вот тебе и модульность... Дак в чем все таки принципиальное отличие?
Что вы подразумеваете по словом двухзвенка? Модульность характеризует независимую разработку и развертывание этих самых модулей. И понятное дело что каждый модуль играет разную роль в работоспособности системы, и скорее всего без одного модуля система не будет работать должным образом, но все же это модули и они обладают свойствами которые я написал выше.
@@dev_zloi В данном ПО отсутствует сервер приложений. Клиентское десктоп приложение работает напрямую с бд, причем основная бизнес логика вынесена в бд(про гениальность решения не будем...). В данном случае слой бд не зависит от клиента и с ней теоретически может работать другой клиент. Это модульность?
А при чем тут отказоустойчивость и модульность? Модульность - это про организацию совместной работы большого количества команд, независимое развертывание и тестирование, горизонтальное масштабирование.
@Румяные Блины микросервис, в данном контексте - это не маленький сервер или сервис с маленьким количеством услуг. "Микросервисы" - это порождение проблемы компилируемых языков (Java, c++, ...), а точнее способ снижения количества кода, который необходимо перекомпиллировать, чтобы внести изменения и быстрее вновь запустить приложение. В мире интерпретируемых языков типа рнр - такой проблемы просто не существует. Только сама перекомпиляция может занимать много времени
Кардинально неверное объяснение монолита. Разделение на монолит и SOA в первую очередь означало одну простую вещь - монолит отвечает за фронтэнд, а сервисы - нет. Старые java приложения с апплетами, jsp; Python Django, RubyOnRails вот типичные инструменты для монолитов. С приходом SOA, а в последствии и microservices, фронт в вебе начали рисовать не на сервере, а на клиенте, и произошел бум ajax. Есть жесткие связи, или нет - да и микросервис можно в спагетти превратить. Это квалификация разработчика. Модульный монолит лишь подразумевает, что это такой же монолит, отрисовывающий фронт, но на модулях. Хватит говорить о жестких связях. У вас может быть Джанго приложение, в котором будет N аппликейшионов, но общаться все эти аппы будут через сообщения по кафке. Слабо связанные компоненты, никак друг от друга не зависящие. А благодаря темплейтам - всё равно монолит, хоть и модульный. Мода жесткие связи называть монолиты пришла с хайпом вокруг микросервисов. SOLID, DDD, куча других практик как писать хороший жестко не связанный код был до этого десятилетия. Но нужен был хайп
Судя по всем у вас "фронтенд головного мозга", очень распространено среди людей, которые не застали программирование до появления веба. "Монолит - это приложение, которое отвечает за фронт"? Эм... надо запомнить этот тезис.
@@S0ERDEVS может быть и фронтэнд головного мозга) нужно заменить "фронтэнд" на "клиент", и всё станет на свои места. Клиент же может быть на чем угодно. Это разделение так же есть и в ядре ОС, и в компиляторе. И мне абсолютно непонятно как термин утратил первоначальный смысл.
@Anton Feoktistov "монолит отвечает за клиент"? Т.е. только клиент-серверные решения могут быть монолитными? Тогда с чего микросервисы не монолитны, у них нет клиента? Может все же откажетесь от этого тезиса? Очевидно же, что глупость сказали.
@@S0ERDEVS наоборот, клиент-сервисные решения по определению не являются монолитом. Томас Эрл, в его книге о SOA, с этого начинает, что есть сервисы и они выставляют АПИ, чаще всего rest или soap(книга 2005-го года). Монолит же не выставляет АПИ для процессинга данных. Как самый яркий пример я привел вебсервисы, которые сами рисуют view - django, ror, jsp, java applets. С приходом микросервисов монолит обрел негативный окрас, и начали говорить о жесткой структуре. Хотя до этого 10 лет все говорили о layers, solid, di и ddd, где и рассказывали как жесткости избежать
soer батя, самый опытный и зрелый it-ютубер; если честно ни бороду, ни остальных не могу серьезно воспринимать
Ербол Утегенов Поддерживаю, Соер Настоящий программист в полном понимании этого слова
Ну у Бороды и формат другой
В МСА разве нет проблем с физ. и лог. моделями данных?
Действительно очень хорошее объяснение, по делу и с реальными примерами. Спасибо!
ну наконец то видосы, я уже думал что канал заброшен. Один из немногих кого я смотрю. Было бы обидно...
Очень достойно.
Так просто описать такие сложные понятия, дорогого стоит.
Очень интересно, спасибо! Давно хотел подобной информации к размышлению
с возвращением, продолжай, хороший контент.
Очень интересно. Спасибо!
Отличное видео!
топчик, кратко и понятно, спасибо
Помимо распределения нагрузки микросервисная архитектура позволяет еще и обеспечивать переиспользование этих самых сервисов. То есть если у компании несколько проектов в которых требуется реализация одинаковой и сложной бизнес-логики, то микросервисный подход будет вполне оправдан.
Спасибо за полезную информацию, что бы посоветовал почитать на эту тему?
Мало кто умеет соблюсти разумную достаточность. А вот наплодить ненужных архитектурных сущностей за деньги заказчика и потом еще это обслуживать могут наверное все.
Почаще выпускай видео, очень интересно
Спасибо, Соер, слушать интересно. Блики и отражения в очках -- отвлекают, мешают сосредоточиться.
Спасибо за тему!
Сначала не прочитал название канала в уведомлениях. Подумал шо какой-то ролик по сталкеру....
Зашел в комменты чтобы написать этот коммент хахахах
Расскажи тоже самое про облачную архитектуру где десятки разных микросервисов )
Круто, значит я не говнокод пишу, а монолит )
😄
:)
копролит
И монолит можно проектировать так, чтобы выделение отдельных сервисов в будущем, если это потребуется, доставляло минимум боли. И жесткие связи и зависимости внутри монолитной системы можно успешно ограничивать (фасады, стратегии, Protected Variations/OCP, инверсия зависимостей). Другое дело, что у программистов зачастую недостаточно квалификации, чтобы так проектировать архитектуру. И недостаточно дисциплины, чтобы следовать всем необходимым правилам. А должность системного архитектора (тот кто и должен следить за всем этим) у нас почему-то не прижилась.
Что скажете о модульных монолитах на уровне кода?
Хороший архитектор должен предвидеть все возможности расширения системы и провести "невидимые" границы между компонентами. В идеале архитектура должна быть такой, чтобы можно было легко от монолитной перейти к микросервисной и наоборот.
Дмитрий Попов реальность обычно такова, что этот хороший архитектор появляется только тогда, когда уже наломали дров и сами не справляются. Потому что мало стартапов могут себе позволить нанять опытного архитектора на начальном этапе проекта
@@user-10248 ну а кто спорит, я написал про идеальный случай.
сейчас в решении (сборке всех проектов) столько проектов (длл) что сама среда разработки не выдерживает и перезагружается, хотя ОЗУ хватает. верное видео в целом. что бы понять что хотели написать, в каком проекте нужно было что-то исправить использовал VS code и поиск по всему... и правда много проектов, уровней в веб апи путает. а методы не отрефакторенные это вообще два часа провёл и не понял что ещё нужно поменять.
Картинка просто прекрасна
спасибо!
Ничего не понял, но это было круто.
Soer на чем ты разворачиваешь сервисы ? Было бы интересно узнать. Спасибо за видео
Звук не совпадает с картинкой
Вам нужно обратиться в учреждение, где ставят диагнозы и выписывают рецепты.
Это нормально, визуальная информация обрабатывается дольше, на звук реакция быстрее, живи с этим фактом
@@ИванИванов-н9т9ъ ....
Я правильно понял, что трехслойная архитектура, это монолит? Можете подробнее раскрыть вопрос ахрихетуры?
трехслойную легче покрыть более точными тестами, чем монолит, следовательно проблемы выявляются еще на этапе разработки, проброс экзепшнов, так же дает более подробный стек и за счет того, что каждый слой делает свою работу, расширять и править его проще. Мне нужно соблюдать контракты между слоями, изменение которых не частое явление, а саму логику можно менять как угодно. - это как у меня получается. Но вот модульная архитектура, для меня теория.
10:20
ЖИЗА ЖИЗА ЖИИИИИИИИИИИИЗАААААААААААААААААА
AntiBlog неистово плюсую. Потом ещё выясняется что разделили неправильно. И это обрастает костылями для того, чтобы это неправильное разделение компенсировать
Я думаю, всё монолит, даже микросервисы, всё ровно же всё ото всего зависит, и идёт месседжинг между микросервисами
Ну, не совсем и не всегда. Возьмём в пример виджет отображения погоды на смартфоне. Если что-то пошло не так и виджет выбрасывает исключение, то можно этот виджет просто скрыть, на состояние всей операционной системы это влиять не будет. Но модульность можно организовать только на масштабных проектах, на небольших это сделать нереально, да и не нужно. Я, пока что, не сталкивался с ситуацией, где можно обойтись без монолитности.
Акторная модель в коде считается монолитом?
Всему своё время и место
Жаль что про встраиваемые системы речь не идет :(
На скорости 1.25, самое оно)
Дык, а что ж такое монолитная архитектура и модульная.
Если разбито на пакеты, то это уже не монолит, по-моему. Монолит - мне больше напоминает, например, ядро Линукса, которое собрано всё вместе, со всеми модулями, без возможности подгрузить ещё что-то.
А в видео, похоже, идёт речь о непродуманности интерфейсов между слоями, когда рождается это самое "зацепление", когда взаимная реализация слоёв определяет этот интерфейс между ними.
Нового ничего, к сожалению, не узнал.
Что значит "трех-слойное приложение"?
Апи-сервис-работа с бд?
Что значит "трёх"? Программисты не знают такого. Есть многослойное приложение. Это понятно.
s/#сложно/#сложна!/
Эти 14 минут в своё время сэкономят миллион
Чет я тупой такой что ли? Но по-моему тема не раскрыта... Вот сегодня внес изменение даже не в трехзвенку, а в двух - изменил прямо на горячую хранимку (оптимизация запроса) и ничего не сломалось... А если, например, микросервис авторизации какой-нибудь выкючить/сломать и все пользователи не могут войти в систему, вот тебе и модульность... Дак в чем все таки принципиальное отличие?
Что вы подразумеваете по словом двухзвенка? Модульность характеризует независимую разработку и развертывание этих самых модулей. И понятное дело что каждый модуль играет разную роль в работоспособности системы, и скорее всего без одного модуля система не будет работать должным образом, но все же это модули и они обладают свойствами которые я написал выше.
@@dev_zloi В данном ПО отсутствует сервер приложений. Клиентское десктоп приложение работает напрямую с бд, причем основная бизнес логика вынесена в бд(про гениальность решения не будем...). В данном случае слой бд не зависит от клиента и с ней теоретически может работать другой клиент. Это модульность?
@@BASic_37 скорее всего в данном случае нет. Если приложении изначально разрабатываллсь не как модульное, то это монолит.
@@dev_zloi т.е. модульность это на уровне ощущения?
А при чем тут отказоустойчивость и модульность? Модульность - это про организацию совместной работы большого количества команд, независимое развертывание и тестирование, горизонтальное масштабирование.
Норм ликбез.
+
Как можно "плавно" перейти от монолита к микросервисам?
@Румяные Блины микросервис, в данном контексте - это не маленький сервер или сервис с маленьким количеством услуг. "Микросервисы" - это порождение проблемы компилируемых языков (Java, c++, ...), а точнее способ снижения количества кода, который необходимо перекомпиллировать, чтобы внести изменения и быстрее вновь запустить приложение. В мире интерпретируемых языков типа рнр - такой проблемы просто не существует. Только сама перекомпиляция может занимать много времени
Кардинально неверное объяснение монолита. Разделение на монолит и SOA в первую очередь означало одну простую вещь - монолит отвечает за фронтэнд, а сервисы - нет. Старые java приложения с апплетами, jsp; Python Django, RubyOnRails вот типичные инструменты для монолитов. С приходом SOA, а в последствии и microservices, фронт в вебе начали рисовать не на сервере, а на клиенте, и произошел бум ajax.
Есть жесткие связи, или нет - да и микросервис можно в спагетти превратить. Это квалификация разработчика.
Модульный монолит лишь подразумевает, что это такой же монолит, отрисовывающий фронт, но на модулях.
Хватит говорить о жестких связях. У вас может быть Джанго приложение, в котором будет N аппликейшионов, но общаться все эти аппы будут через сообщения по кафке. Слабо связанные компоненты, никак друг от друга не зависящие. А благодаря темплейтам - всё равно монолит, хоть и модульный.
Мода жесткие связи называть монолиты пришла с хайпом вокруг микросервисов. SOLID, DDD, куча других практик как писать хороший жестко не связанный код был до этого десятилетия. Но нужен был хайп
Судя по всем у вас "фронтенд головного мозга", очень распространено среди людей, которые не застали программирование до появления веба. "Монолит - это приложение, которое отвечает за фронт"? Эм... надо запомнить этот тезис.
@@S0ERDEVS может быть и фронтэнд головного мозга) нужно заменить "фронтэнд" на "клиент", и всё станет на свои места. Клиент же может быть на чем угодно. Это разделение так же есть и в ядре ОС, и в компиляторе. И мне абсолютно непонятно как термин утратил первоначальный смысл.
@Anton Feoktistov "монолит отвечает за клиент"? Т.е. только клиент-серверные решения могут быть монолитными? Тогда с чего микросервисы не монолитны, у них нет клиента? Может все же откажетесь от этого тезиса? Очевидно же, что глупость сказали.
@@S0ERDEVS наоборот, клиент-сервисные решения по определению не являются монолитом. Томас Эрл, в его книге о SOA, с этого начинает, что есть сервисы и они выставляют АПИ, чаще всего rest или soap(книга 2005-го года).
Монолит же не выставляет АПИ для процессинга данных. Как самый яркий пример я привел вебсервисы, которые сами рисуют view - django, ror, jsp, java applets.
С приходом микросервисов монолит обрел негативный окрас, и начали говорить о жесткой структуре. Хотя до этого 10 лет все говорили о layers, solid, di и ddd, где и рассказывали как жесткости избежать
@Anton Feoktistov, чем дальше, тем веселее. Если ROR приложение выдало HTML, то оно монолит, если JSON, то нет?
Очень много умных слов монолит, архитектура, микросервисы и т.д. а тема монолита не раскрыта... За попытку объяснить 5, за объяснение 2 :(
скорость 1.75
Чувак не вдавливай очки себе в лицо! Перед людьми все таки выступаешь!
Вообще-то перед камерой. Но поржал с твоего коммента.