Шпаргалка по Микросервисам: www.faang.school/java-junior-library? Мой Java Буткемп: www.faang.school/? Java Magics. Курс для начинающих: www.faang.school/java-magics?
Просто аплодирую стоя 👏👏👏👏👏👏 Я недавно начал обучение, потихоньку вникаю во всю эту кухню, но нигде не видел такой обширной информации, которая рассказывает весь широкий спектр работы над проектами и работы разработчика в целом. Везде только и говорят, нужно научиться кодить, но никто не заикнулся о десятках других инструментах, которые необходимы, чтобы ваш код появился на свет. Это как сказать, повару, что он будет готовить борщ и промолчать о всех инструментах и продуктах, в конце концов тонкостях, которыми он должен уметь пользоваться (ну с борщом ясно пример лёгкий, потому что все знают как он готовиться ), но не каждый хоть раз в своей жизни видел (не говоря о делал) как с нуля рождается приложение. У меня всё. Спасибо! Всё ещё аплодирую 😂😂😂 👏👏👏👏👏
Поинт про масштабирование монолита и нагрузку на железо неверный. В микросервисах нагрузка на CPU, память и особенно сеть в разы выше и затраты на железо куда больше. Связано это с тем, что в микросервисах очень много сетевой активности, и вместо того чтобы дешево вызвать метод в монолите, в микросервисах нужно делать RPC запросы либо через gRPC, что менее накладно, либо через http. Плюс появляется нехилый оверхед из-за latency. Также по памяти требования намного выше, если раньше у вас было 10 инстансов монолита и они жрали по 500мб памяти, то после распила на микросервисы это будет 100 инстансов по 200-300мб, потому что оверхед на рантайм всегда есть, глупо его игнорировать.
@@slayers2966 уже сейчас есть большой спрос не спецов, которые умеют "фарш обратно" провернуть. За прошлую декаду натворили. И дело тут не в том, что микросервисы это плохо. А в том что их повпихивали там где это не нужно не думая о цене. А цены кусаются: девопс + инфра + замедление цикла + доп разработчики. За 5 лет на средней руки проэкте это выбивается в 500k $. Уменеджмента волосы дыбом встают когда они видят что этот выбор им стоил примерно как новенькая яхта.
Вы описали проблемы сервисной архитектуры. В микросервисной архитектуре синхронные веб-вызовы (http, grpc, ...) не используются вообще. Использование веб-вызовов - это признак того, что у вас что-то вроде распределенного монолита, но точно не микросервисная архитектура
Редко пишу коментарри, но после простмотра почти всех видео Влада, хочу поблагодарить за очень классные видеою. Я так понимаю что ты восновном работаешь в java, я учусь на python но из-за хорошей подачи информации мне очень интересно смотреть. Жду больше видео.
Как же приятно тебя слушать, когда ты не транслируешь свой (надеюсь - временный) нарциссизм. Великолепное видео. Слушал полутарочасовые лекции по Кафке - не понял, зачем нужна Кафка. А ты так запросто объяснил, даже не акцентируя на этом! Теперь абсолютно ясно. Супер!
Очень крутое видео, классный автор канала, так легко все объясняет, что даже мне стало понятно! Отдельное спасибо за прекрасную инфографику, представляю сколько труда в нее вложено! Вы большой молодец!
Ляяяяяяяяяяяяя Пушка бомба аллигатор Жирный плюс за то что он поясняет что сервак это отдельный комп Как я раннее писал под одним видосом Что так же при введений нового слова Диплойд ( так же объяснил и рассказал что это такое и с чем его едят) Так же очень круто что он не забывает показывать все это дело в картинках ( в схемах) , а так же что бы все двигалось Так же круто он ввел новую фичу с ценником 1000$ или же 3000$ ( новые пользователи лучше усваивают и понимают , для чего и за чем Так как на деньгах тоже проще объяснить ) Не забывает повторять и объяснять все те же слова что были в предыдущих видео (повторение мать учения) Что подчеркивает , внимательность Влада , а так же понимание и улучшения скила в учительском понимание Что бы донести информацию до любого человека и без разницы чем он занимается или же кем работает Работа учитель донести информацию до любого человека хоть сантехник, хоть бухгалтер, хоть парикмахер Монолит и микро -сервис знал чем отличаются Больше всего я смотрел как он работает над собой и как он качественно доносит информацию до зрителя И это просто пушка А не как у меня на курсах , ментор знает за программирование, но ни черта толком не может объяснить порой на человеческом - колхозном языке Что бы людям было понятно Программист который способен объяснить и разжевать на простом человеческом языке Это прям высший пилотаж ® ► ♫ ☼ ◄ Зачет √
Шикарный контент, много полезной инфы без воды, отдельное спасибо за иллюстрации, с ними лучше запоминается и усваивается. К сожалению почитав комменты сложилось впечатление, что не все пункты на 100% истина, хотя вероятно в IT не бывает тем по которым все поддерживают какое-то мнение и не имеют своего))
Хорошо рассказываешь, анимации достойные. Не торопливо, подробно, по несколько раз с разных сторон, но не скучно. Лайк поставил, подписался. Можно было ещё упомянуть про то. что когда на микросервисы делишь апу, то приходится выделять общие либы, которые тоже кто-то должен поддерживать. И самое херовое, когда в этих либах появляются долгоиграющие баги. Плюс проблемы подключения плагинов через позднее связывание, из-за которых приходится писать обвязку адаптеров, что увеличивает вложенность кода. А в случае работы с нескольими сторонними сервисами, у которых схожее, но всё же отличное апи, в адаптеры приходится вставлять костыли.
1. Разработчик ленты сальтерил в бд таблицу изменив колонку с varchar2 на clob, а остальные сервисы ожидают тот же varchar2 - куда пойдут все микросерсисы? 2. Масштабирование - как правило это все на ВМ и гипервизор становится тем что ранее был монолит и т.о. только усложняется все , без полезного выхлопа. 3. Обмен между сервисами очень неприятен для отделов безопасности и доставляет проблемы при работе, т.к. могут вводиться правила-запреты которые сведут на нет работоспособность.
На счет первого. На примере . net если разраб поменял колонку то он скорее всего и модель на которую маппит таблицу тоже обновил и тогда апи модель поменяется и можно обновить нугет пакет нашего сервиса. И все проблемы нет все остальные сервисы обновят нугет пакет и будут ждать уже новый тип
Про брокера Kafka прям очень жду. Сейчас актуально - устроился в сопровождение внедрения ПО, много вопросов. По большей части сам разбираюсь в архитектурных схемах, свои проекты ещё не начались.Подписался!
Таня привет! Очень интересный влог, здорово, что у вас много разных мероприятий, которые собирают людей для общения, да ещё такое разнообразие по интересам. Покупки супер! Правильно, себя надо тоже баловать❤
Молодец, классно. Я по сути в целом все это знал, но последняя часть была полезной. Если есть малая преза в 2 слайда с плюсами и минусами каждой архитектуры было бы круто, чисто чтобы сохранить
Не кажется ли что проблема жесткого связывания, это чисто архитектурная проблема монолита? И просто замена локальных вызов на вызовы по сети никак проблему не решает, кроме как заставляет программистов вязаться по веб интефейсам, и тем самым косвенно лечит архитектурные проблемы. Так почему же просто изначально не лечить архитектурные проблемы, а не городить костыль в виде микросервисов которые используют вызовы по сети вместо локальных вызовов из одной код бейз, тем самым существенно замедляя работу приложения, +ряд других проблем микросервисов
Для новичков видео будет полезным. Но про то что микросервисная архитектура значительно сложнее тут можно подискутировать. Если каждый микросервис написан грамотно и предоставляет апишку т.е. чёткую систему для взаимодействия с ним, а так же отслеживает успешное получение данных другим микросервисом то разработка такого приложения просто в кайф. И да у каждого микросервиса обязательна своя отдельная база данных, а если от неё что-то нужно другим микросервисам апишка в помощь.
Было бы интересно еще услышать про то как организовать зависимости этих всех микросервисов. Что бы при деплоее проверялись версии контрактов между собой и так далее
Как связаны монолит и coupling ? Кто заставляет все модули связывать между собой ? Условно модуль отправки сообщений может знать не знать о каких то доменных модулях. Да и доменный модуль может напрямую не импортировать модуль отправки сообщений, а использовать ту или иную реализацию ивентов.
Супер разбор. Никогда не думал что пойму эту казалось сложную тему за 49 минут. Большое спасибо. Но слово "Ошибка" пишется через букву И )) Не знаю по приколу ты написал через Ы или по правде ошибся, но бросилось в глаза в самом последней части на 47 минуте :)
Вопрос о монолите. Так разве принципы SOLID они не об этом в том числе говорят, чтобы не связывать компоненты? Абстракция, инкапсуляция, внедрение зависимостей... Всё что ты перечислил в недостатках монолита скорее выглядит как кривая архиктерура, или я что-то не так понял? My bad, разобрался. Архитектура это только одна проблема, куда важнее возможность масштабирования при развертывании. Тем не менее, думаю, стоит упомянуть, что в идеале, даже разрабатывая монолит, лучше заранее планировать архиктуру так, чтобы компоненты были минимально связанны друг с другом. И единственная разница, которая должна быть в этом случае -- что данные передаются через внешний источник, а не внутри приложения. И тогда будет удобнее поддерживать и удобнее расширять и при необходимости сделать компоненты внешними, просто изменив каналы получения и отправки данных.
Хорошее видео получилось, прям смотрю и вижу архитектуру нашего приложения. Только есть кажется неточность относительно Prometheus. На сколько я понимаю Prometheus сам ходит за метриками к сервисам на определённые ендпоинты сервисов, которые и выдают определённые метрики.
Лол, всё думал, что там за микросервисы эти прекрасные существа придумали, а оно вон чё) То, что можно решать в отдельном классе делать отдельной прогой... ихи-хиыы
TL;DR: Очень притянуто за уши и местами выводы весьма странные, местами вообще противоречивые. 1) Изолированность. То что преподносится как "отличие" монолитов - жесткое связывание, на самом деле проблема кода и (не)соблюдения SOLID, хотя на самом деле при верном проектировании мы получаем абсолютно тот же обмен данными как в монолите (мы передаем данные через DTO, либо четко следуем интерфейсам и используем геттеры и сеттеры), но передача данных осуществляется внутри приложения, а не на разных серверах, что сильно быстрее и не имеет тех проблем обмена данными, имеющихся в МС. 2) Ответственность. Ну и деплой сразу. В любом случае - монолит или МС - вы должны знать что делают другие части, по сути в обоих случаях вы используете АПИ другого объекта. Так что все равно надо понимать как работают другие части, как бы не хотелось ограничиться чисто своим кусочком кода. И не знаю как в "больших компаниях", но в тех где я работал обычно есть правило - один комит по задачам не деплоится с другим. Все идут в своем порядке. Тогда откат одной фичи не ломает остальной рабочий функционал. Ну и это более актуально для компилируемых приложений, для условного пхп фикс не требует отдельного сервера и прочих танцев для замены 1 файла. 3) Надежность. В принципе, обсуждаются те же проблемы что и с остальным - связанность, которая как бы не проблема монолита, а проблема кода. И проблема сложных зависимостей и связанных с ней багов так же остается в МС (компоненты так же обмениваются данными, просто это происходит чуть сложнее), теперь ее просто сложнее отследить. К слову, при "отваливании" каких-нибудь нотификаций, монолит абсолютно так же не развалится и не пойдет в разнос, просто пропадут нотификации. А при отваливании авторизации проблемы будут при любой архитектуре во всем приложении. 4) Масштабирование. Тут немного странно это подается, так как нагрузка в современных приложениях это не "код ленты не вывозит", а в 99% случаев это либо нагрузка на бд, либо запросы с внешних апи, которые имеют свою пропускную способность и лимиты/квоты. И тут как бы вы не масштабировали сервера ленты, база быстрее не заработает. Предположим, что у ленты свои сервера бд, которые имеют чисто свои данные по ленте, и больше ничего, все остальное что напрямую не относится к новостям. Тогда мы разворачиваем кластер и добавляем пару серверов для бд ленты... Беда в том, что как и говорил автор, все компоненты связаны, не напрямую, но запрос ленты тянет за собой запрос на рекомендации, на пользовательские данные, на еще кучу всего, и при этом все это не бегает внутри приложения, а бегает по внешним сервисам, которые в итоге получают практически такую же нагрузку, но все это еще накладывается на накладные расходы промежуточных линкующих сервисов/сетей... Молчу о том что есть "небольшой" нюанс - в итоге будет дешевле поставить +пару серверов для монолита, чем расставлять на каждом поднагруженном сервере по паре серверов послабее, так как чем мощнее сервер, тем дешевле он выходит на условное количество операций/сек. 5) Гибкость/изоляция МС как преимущества: Две основные фичи - изоляция (о чем я выше говорил) и разные стеки для разных микросервисов. С изоляцией спорно, "но окэй", а вот зоопарк стеков технологий это прям киллер фича микросервисов. Собсно рождение МС как концепции начиналось именно с выноса кусков монолита в отдельный сервис, так как этот кусок на текущем стеке "не вывозит". Дальше эксперименты по разбивке всего на все и вот эти все попытки связать кучу всего в одно работающее распределенное приложение. На сегодня это уже +-отлаженный процесс, так что особо прям фантазии для построения МС архитектуры много ума не надо, читаем доки, настраиваем, профит. И по скилам - особо от монолита не отличается (так как по сути мы и пишем маленький монолит), проблемы начинаются на этапе связывания, синхронизации, проверки консистентности и кучи бд, состоящих из частично надцать раз дублирующихся данных, что больше задача для архитекторов и сеньоров. То есть реально спецов там нужно мизер, но это именно "сливки" сообщества, которых и так нифига нет и охота за ними идет похлеще чем за синей птицей. Что создает определенные проблемы, особенно в свете последних событий. Вывод в отдельном коменте.
Имхо, применение мс архитектуры зависит от потребностей проекта. Развертка и настройка не из самых простых. Следовательно выбор зависит от бюджета проекта и временных рамок...
Тут много толковых комментариев про неочевидные преимущества микросервисов над монолитами. Но мне кажется не поднята основная тема - это докеры и соответственно Kubernets. Именно они позволили сравнительно легко оперировать и поднимать образы микросервисов при нагрузках. Хайп на микросервы только из-за докеров IMHO.
В монолите компоненты тоже могут быть изолированы друг от друга. А насчёт Кафки и другой хуеты для реализации взаимодействия компонентов помимо сложности самих этих инструментов, сами компоненты должны стать сложнее по части ipc
Привет всем. После просмотра возник вопрос, а почему бы не использовать кластерную архитектуру, которая будет производной от монолитной и микросервисной: это будет приложение, где функционал поделен на кластеры, подобно микросервисам, но расположенный на одном или нескольких серверах для обеспечения отказоустойчивости. Таким образом мы сохраняес микросервисный функционал, но при этом общение между кластерами осуществляется не по сети, а в рамках сервера, что исключает проблемы по потере данных при пересылке по сети. Что скажете?
Влад, выхожу на маркет через пару месяцев, обучаюсь в буткемпе уже 8 й месяц. Интересно, можно ли с тобой провести пару индивидуальных курсов? За видео огромное спасибо, просто нереально, тебе нужно на английском выпускать тоже, уверен аудитория увеличится в разы.
Монолог про монолит очень спорный. Давайте доведем идею до абсурда, а потом ее раскритикуем. А вот про проблемы микросервисов рассказано хорошо :) Видно, что наболлело
Шпаргалка по Микросервисам: www.faang.school/java-junior-library?
Мой Java Буткемп: www.faang.school/?
Java Magics. Курс для начинающих: www.faang.school/java-magics?
Можешь дать топ 10 тулзов спринга которые ты юзаешь на проектах и которые востребованы
ХАХАХАХАХАХ "Микросервисы Простыми Словами за 1 Час" КЛЮЧЕВОЕ СЛОВО "ПРОСТЫМИ И ЧЕЛЫЫЫЙ ЧАС"
классно что ссылка не рабочая 1ая
Бро, сделай подобное видео про Kubernetes. Лайк, кто за)
Да зачем он нужен, этим девопс занимается, программисту это не к чему
@@СергейДенисов-ф6б не совсем согласен. Всё чаще и чаще от девелоперов требуют разбираться в оркестраторах. Не везде есть штатные девопсы.
@@СергейДенисов-ф6б супер супер спорно. Многим разработчикам очень нужны знание кубера
@@СергейДенисов-ф6б чтобы пет-проекты в соло поднимать хотя бы)
@@СергейДенисов-ф6б с таким мышлением ты ограничиваешь свое развитие и как следствие доходы
ждём про кафку всей маршруткой
Просто аплодирую стоя 👏👏👏👏👏👏
Я недавно начал обучение, потихоньку вникаю во всю эту кухню, но нигде не видел такой обширной информации, которая рассказывает весь широкий спектр работы над проектами и работы разработчика в целом. Везде только и говорят, нужно научиться кодить, но никто не заикнулся о десятках других инструментах, которые необходимы, чтобы ваш код появился на свет. Это как сказать, повару, что он будет готовить борщ и промолчать о всех инструментах и продуктах, в конце концов тонкостях, которыми он должен уметь пользоваться (ну с борщом ясно пример лёгкий, потому что все знают как он готовиться ), но не каждый хоть раз в своей жизни видел (не говоря о делал) как с нуля рождается приложение. У меня всё. Спасибо! Всё ещё аплодирую 😂😂😂 👏👏👏👏👏
Вы так круто и понятно рассказываете, респект 😊
Сделайте, пожалуйста, про REST подобное видео
поддежка
Поинт про масштабирование монолита и нагрузку на железо неверный.
В микросервисах нагрузка на CPU, память и особенно сеть в разы выше и затраты на железо куда больше.
Связано это с тем, что в микросервисах очень много сетевой активности, и вместо того чтобы дешево вызвать метод в монолите, в микросервисах нужно делать RPC запросы либо через gRPC, что менее накладно, либо через http. Плюс появляется нехилый оверхед из-за latency.
Также по памяти требования намного выше, если раньше у вас было 10 инстансов монолита и они жрали по 500мб памяти, то после распила на микросервисы это будет 100 инстансов по 200-300мб, потому что оверхед на рантайм всегда есть, глупо его игнорировать.
как думаешь, компании будут продолжать переходить на микросервисы или возвращаться обратно к монолитам?
@@slayers2966 уже сейчас есть большой спрос не спецов, которые умеют "фарш обратно" провернуть. За прошлую декаду натворили.
И дело тут не в том, что микросервисы это плохо. А в том что их повпихивали там где это не нужно не думая о цене.
А цены кусаются: девопс + инфра + замедление цикла + доп разработчики. За 5 лет на средней руки проэкте это выбивается в 500k $.
Уменеджмента волосы дыбом встают когда они видят что этот выбор им стоил примерно как новенькая яхта.
@@slayers2966 модульный монолит
А есть разница между "micro services" и " web services". или это одно и тоже?
Вы описали проблемы сервисной архитектуры. В микросервисной архитектуре синхронные веб-вызовы (http, grpc, ...) не используются вообще. Использование веб-вызовов - это признак того, что у вас что-то вроде распределенного монолита, но точно не микросервисная архитектура
Огромнейшее спасибо! 2ой день смотрю ваши объяснения. Всё так понятно и доступно, давно такого контента не видела.
Влад, спасибо тебе безграничное. Очень важная, базовая тема для всех, кто в айти.
Редко пишу коментарри, но после простмотра почти всех видео Влада, хочу поблагодарить за очень классные видеою. Я так понимаю что ты восновном работаешь в java, я учусь на python но из-за хорошей подачи информации мне очень интересно смотреть. Жду больше видео.
Как же приятно тебя слушать, когда ты не транслируешь свой (надеюсь - временный) нарциссизм.
Великолепное видео.
Слушал полутарочасовые лекции по Кафке - не понял, зачем нужна Кафка. А ты так запросто объяснил, даже не акцентируя на этом! Теперь абсолютно ясно. Супер!
Очень крутое видео, классный автор канала, так легко все объясняет, что даже мне стало понятно! Отдельное спасибо за прекрасную инфографику, представляю сколько труда в нее вложено! Вы большой молодец!
НА 24.30 мин. вместо микросервисов нужно сказать монолит) А видео просто великолепное!
Да, я в какой то момент подумал что я что то прослушал
Влад, ждём кафку, спасибо за видосы!
Ляяяяяяяяяяяяя Пушка бомба аллигатор Жирный плюс за то что он поясняет что сервак это отдельный комп Как я раннее писал под одним видосом Что так же при введений нового слова Диплойд ( так же объяснил и рассказал что это такое и с чем его едят) Так же очень круто что он не забывает показывать все это дело в картинках ( в схемах) , а так же что бы все двигалось Так же круто он ввел новую фичу с ценником 1000$ или же 3000$ ( новые пользователи лучше усваивают и понимают , для чего и за чем Так как на деньгах тоже проще объяснить ) Не забывает повторять и объяснять все те же слова что были в предыдущих видео (повторение мать учения) Что подчеркивает , внимательность Влада , а так же понимание и улучшения скила в учительском понимание Что бы донести информацию до любого человека и без разницы чем он занимается или же кем работает Работа учитель донести информацию до любого человека хоть сантехник, хоть бухгалтер, хоть парикмахер Монолит и микро -сервис знал чем отличаются Больше всего я смотрел как он работает над собой и как он качественно доносит информацию до зрителя И это просто пушка А не как у меня на курсах , ментор знает за программирование, но ни черта толком не может объяснить порой на человеческом - колхозном языке Что бы людям было понятно Программист который способен объяснить и разжевать на простом человеческом языке Это прям высший пилотаж ® ► ♫ ☼ ◄ Зачет √
Было очень интересно смотреть, всё понятно с первого раза. Спасибо за такой контент! 👏👏👏
Очень классная подача!! Очень интересно смотреть и слушать. Благодарю за труд.
Спасибо, Влад! Я благодаря твоим видосам начинаю понимать, что у меня на работе происходит ))
Шикарный контент, много полезной инфы без воды, отдельное спасибо за иллюстрации, с ними лучше запоминается и усваивается. К сожалению почитав комменты сложилось впечатление, что не все пункты на 100% истина, хотя вероятно в IT не бывает тем по которым все поддерживают какое-то мнение и не имеют своего))
Хорошо рассказываешь, анимации достойные. Не торопливо, подробно, по несколько раз с разных сторон, но не скучно. Лайк поставил, подписался.
Можно было ещё упомянуть про то. что когда на микросервисы делишь апу, то приходится выделять общие либы, которые тоже кто-то должен поддерживать. И самое херовое, когда в этих либах появляются долгоиграющие баги. Плюс проблемы подключения плагинов через позднее связывание, из-за которых приходится писать обвязку адаптеров, что увеличивает вложенность кода. А в случае работы с нескольими сторонними сервисами, у которых схожее, но всё же отличное апи, в адаптеры приходится вставлять костыли.
Хорошее видео для новичков
Чел спасибо тебе за кучу сэкономленного времени и денег) Я понял, что для микро стартапа нужен монолит)
КРАСАВЧИК ВСЁ ПОНЯТНО ОБЪЯСНИЛ РЕСПЕКТ.
Спасибо вам огромное! , очень наглядное и познавательное видео!
Ждём разбор Кафки. А ещё лучше её заменитель - Redpanda. А ещё лучше сравнение обоих
1. Разработчик ленты сальтерил в бд таблицу изменив колонку с varchar2 на clob, а остальные сервисы ожидают тот же varchar2 - куда пойдут все микросерсисы?
2. Масштабирование - как правило это все на ВМ и гипервизор становится тем что ранее был монолит и т.о. только усложняется все , без полезного выхлопа.
3. Обмен между сервисами очень неприятен для отделов безопасности и доставляет проблемы при работе, т.к. могут вводиться правила-запреты которые сведут на нет работоспособность.
На счет первого. На примере . net если разраб поменял колонку то он скорее всего и модель на которую маппит таблицу тоже обновил и тогда апи модель поменяется и можно обновить нугет пакет нашего сервиса. И все проблемы нет все остальные сервисы обновят нугет пакет и будут ждать уже новый тип
Про брокера Kafka прям очень жду. Сейчас актуально - устроился в сопровождение внедрения ПО, много вопросов. По большей части сам разбираюсь в архитектурных схемах, свои проекты ещё не начались.Подписался!
Полезное видео, все доступно и понятно рассказано!
Таня привет! Очень интересный влог, здорово, что у вас много разных мероприятий, которые собирают людей для общения, да ещё такое разнообразие по интересам. Покупки супер! Правильно, себя надо тоже баловать❤
Спасибо, очень круто! Ждем другие видео, разъясняющие архитектуру приложений
Смотрю перед собесом на системного аналитика, очень круто структурирует информацию
Молодец. Разжевываешь очень хорошо. Спасибо тебе за это. Лайк и подписка
Молодец, классно. Я по сути в целом все это знал, но последняя часть была полезной.
Если есть малая преза в 2 слайда с плюсами и минусами каждой архитектуры было бы круто, чисто чтобы сохранить
Спасибо, Влад. Очень полезное видео!
Не кажется ли что проблема жесткого связывания, это чисто архитектурная проблема монолита? И просто замена локальных вызов на вызовы по сети никак проблему не решает, кроме как заставляет программистов вязаться по веб интефейсам, и тем самым косвенно лечит архитектурные проблемы. Так почему же просто изначально не лечить архитектурные проблемы, а не городить костыль в виде микросервисов которые используют вызовы по сети вместо локальных вызовов из одной код бейз, тем самым существенно замедляя работу приложения, +ряд других проблем микросервисов
шш! тише ты, нельзя такое говорить еще :)
Для новичков видео будет полезным. Но про то что микросервисная архитектура значительно сложнее тут можно подискутировать. Если каждый микросервис написан грамотно и предоставляет апишку т.е. чёткую систему для взаимодействия с ним, а так же отслеживает успешное получение данных другим микросервисом то разработка такого приложения просто в кайф. И да у каждого микросервиса обязательна своя отдельная база данных, а если от неё что-то нужно другим микросервисам апишка в помощь.
и это ничем не будет отличаться от связанности между компонентами в монолите
Было бы интересно еще услышать про то как организовать зависимости этих всех микросервисов. Что бы при деплоее проверялись версии контрактов между собой и так далее
Буду ждать ролик всё о работе инженера нагрузочного тестирования))
Можно также монолит пилить в разных репозиториях. Делаешь артифакт, через зависимость подключаешь к основному ппроекту
Как связаны монолит и coupling ? Кто заставляет все модули связывать между собой ? Условно модуль отправки сообщений может знать не знать о каких то доменных модулях. Да и доменный модуль может напрямую не импортировать модуль отправки сообщений, а использовать ту или иную реализацию ивентов.
Про ТУЗы интересно,сам процесс подключения к БД, к Кафке и т.д. Про установку SSL сертов. Много в общем вопросов по инфраструктуре во всех контурах.
Крутое видео, спасибо!❤
Спасибо за видос!Доступно, красиво!
Спасибо! Ждем новые видео)
Спасибо! Кратко, понятно, полезно!!!
Спасибо тебе за такое информативное видео
Супер разбор. Никогда не думал что пойму эту казалось сложную тему за 49 минут. Большое спасибо. Но слово "Ошибка" пишется через букву И )) Не знаю по приколу ты написал через Ы или по правде ошибся, но бросилось в глаза в самом последней части на 47 минуте :)
Вопрос о монолите. Так разве принципы SOLID они не об этом в том числе говорят, чтобы не связывать компоненты? Абстракция, инкапсуляция, внедрение зависимостей... Всё что ты перечислил в недостатках монолита скорее выглядит как кривая архиктерура, или я что-то не так понял? My bad, разобрался. Архитектура это только одна проблема, куда важнее возможность масштабирования при развертывании. Тем не менее, думаю, стоит упомянуть, что в идеале, даже разрабатывая монолит, лучше заранее планировать архиктуру так, чтобы компоненты были минимально связанны друг с другом. И единственная разница, которая должна быть в этом случае -- что данные передаются через внешний источник, а не внутри приложения. И тогда будет удобнее поддерживать и удобнее расширять и при необходимости сделать компоненты внешними, просто изменив каналы получения и отправки данных.
Крутой и очень понятный разбор. Жду теперь ролик про Kafka
Очень классное объяснение, молодец !👍
Люто плюсую. Спасибо
Офигеть! Супер круто))) спасибо)
Благодарю за видео. Очень полезно.
Хорошее видео получилось, прям смотрю и вижу архитектуру нашего приложения. Только есть кажется неточность относительно Prometheus. На сколько я понимаю Prometheus сам ходит за метриками к сервисам на определённые ендпоинты сервисов, которые и выдают определённые метрики.
Это же "чистая архитектура"! Привет дяде Бобу!
Хотелось бы видео про load balancer. Спасибо за труд!
8 минут и всё уже в целом понятно, но интересно что дальше.. смотрим, подписываемся..
Огонь, жду видео про service discovery, service registry, service mesh, saga, kubernets...
Лол, всё думал, что там за микросервисы эти прекрасные существа придумали, а оно вон чё) То, что можно решать в отдельном классе делать отдельной прогой... ихи-хиыы
спасибо, хорошие у тебя видео)
Крутой видик, спасибо большое за труд
Спасибо и от тестировщиков!)
Спасибо)
TL;DR: Очень притянуто за уши и местами выводы весьма странные, местами вообще противоречивые.
1) Изолированность. То что преподносится как "отличие" монолитов - жесткое связывание, на самом деле проблема кода и (не)соблюдения SOLID, хотя на самом деле при верном проектировании мы получаем абсолютно тот же обмен данными как в монолите (мы передаем данные через DTO, либо четко следуем интерфейсам и используем геттеры и сеттеры), но передача данных осуществляется внутри приложения, а не на разных серверах, что сильно быстрее и не имеет тех проблем обмена данными, имеющихся в МС.
2) Ответственность. Ну и деплой сразу. В любом случае - монолит или МС - вы должны знать что делают другие части, по сути в обоих случаях вы используете АПИ другого объекта. Так что все равно надо понимать как работают другие части, как бы не хотелось ограничиться чисто своим кусочком кода. И не знаю как в "больших компаниях", но в тех где я работал обычно есть правило - один комит по задачам не деплоится с другим. Все идут в своем порядке. Тогда откат одной фичи не ломает остальной рабочий функционал. Ну и это более актуально для компилируемых приложений, для условного пхп фикс не требует отдельного сервера и прочих танцев для замены 1 файла.
3) Надежность. В принципе, обсуждаются те же проблемы что и с остальным - связанность, которая как бы не проблема монолита, а проблема кода. И проблема сложных зависимостей и связанных с ней багов так же остается в МС (компоненты так же обмениваются данными, просто это происходит чуть сложнее), теперь ее просто сложнее отследить. К слову, при "отваливании" каких-нибудь нотификаций, монолит абсолютно так же не развалится и не пойдет в разнос, просто пропадут нотификации. А при отваливании авторизации проблемы будут при любой архитектуре во всем приложении.
4) Масштабирование. Тут немного странно это подается, так как нагрузка в современных приложениях это не "код ленты не вывозит", а в 99% случаев это либо нагрузка на бд, либо запросы с внешних апи, которые имеют свою пропускную способность и лимиты/квоты. И тут как бы вы не масштабировали сервера ленты, база быстрее не заработает. Предположим, что у ленты свои сервера бд, которые имеют чисто свои данные по ленте, и больше ничего, все остальное что напрямую не относится к новостям. Тогда мы разворачиваем кластер и добавляем пару серверов для бд ленты... Беда в том, что как и говорил автор, все компоненты связаны, не напрямую, но запрос ленты тянет за собой запрос на рекомендации, на пользовательские данные, на еще кучу всего, и при этом все это не бегает внутри приложения, а бегает по внешним сервисам, которые в итоге получают практически такую же нагрузку, но все это еще накладывается на накладные расходы промежуточных линкующих сервисов/сетей... Молчу о том что есть "небольшой" нюанс - в итоге будет дешевле поставить +пару серверов для монолита, чем расставлять на каждом поднагруженном сервере по паре серверов послабее, так как чем мощнее сервер, тем дешевле он выходит на условное количество операций/сек.
5) Гибкость/изоляция МС как преимущества: Две основные фичи - изоляция (о чем я выше говорил) и разные стеки для разных микросервисов. С изоляцией спорно, "но окэй", а вот зоопарк стеков технологий это прям киллер фича микросервисов. Собсно рождение МС как концепции начиналось именно с выноса кусков монолита в отдельный сервис, так как этот кусок на текущем стеке "не вывозит". Дальше эксперименты по разбивке всего на все и вот эти все попытки связать кучу всего в одно работающее распределенное приложение. На сегодня это уже +-отлаженный процесс, так что особо прям фантазии для построения МС архитектуры много ума не надо, читаем доки, настраиваем, профит. И по скилам - особо от монолита не отличается (так как по сути мы и пишем маленький монолит), проблемы начинаются на этапе связывания, синхронизации, проверки консистентности и кучи бд, состоящих из частично надцать раз дублирующихся данных, что больше задача для архитекторов и сеньоров. То есть реально спецов там нужно мизер, но это именно "сливки" сообщества, которых и так нифига нет и охота за ними идет похлеще чем за синей птицей. Что создает определенные проблемы, особенно в свете последних событий. Вывод в отдельном коменте.
Шикарный комментарий по делу. Прочитал с интересом!
12:48 боже, Леонардо ДиКаприо в лучшие годы...
Ура! Микросервисы!!!
Очень кстати!
На мой взгляд, лучшее объяснение микросервисов из всех, что видел. Спасибо огромное за простую и лаконичную подачу столь сложного материала! 🙏🏽
Это было очень интересно!
Привет, очень жду docker compose))) логичное продолжение docker
Let'sss gooo!🔥🔥🔥
Привет из Воронежа)))
Спасибо, Влад, очень интересно рассказываешь. За*6иcь 👍
дядя валера и на джаве и на пайтоне работает, вот это мужик
Имхо, применение мс архитектуры зависит от потребностей проекта. Развертка и настройка не из самых простых. Следовательно выбор зависит от бюджета проекта и временных рамок...
Влад опять радует своих подписчиков топовым контентом, спасибо)
(Опоздал на премьеру 😢)
Очень понятно, даже для полных нулей)
прикольная прическа на 12:48
ждем видео про кафку и спринг
Отказоустойчивость выше - да.
Но у майкросервисов тоже бывают конфликты API, а монолит может быть написан по феншую "loose coupling high cohesion"
Кросавчег. Я только не понял, почему старый добрый принцип изоляции назвали микросервисами. Потому что они связываются через интернет?
Спасибо Влад, топ
Супер!
Анимации и правда помогают)
видос лютая имба, автору +rep
Оооо да ждал такое видео
спасибо!
Тут много толковых комментариев про неочевидные преимущества микросервисов над монолитами. Но мне кажется не поднята основная тема - это докеры и соответственно Kubernets. Именно они позволили сравнительно легко оперировать и поднимать образы микросервисов при нагрузках. Хайп на микросервы только из-за докеров IMHO.
В монолите компоненты тоже могут быть изолированы друг от друга. А насчёт Кафки и другой хуеты для реализации взаимодействия компонентов помимо сложности самих этих инструментов, сами компоненты должны стать сложнее по части ipc
24:30 преимущества по сравнению с монолитом, оговорочка
Ох уж эти игры-сервисы, достали...
Влад, спасибо. Кафка, редис, GRPC были бы интересны.
Надо видео, как на практике можно реализовать Сагу)
Было бы славно посмотреть про Spring
Да. тоже бы посмотрел бы про него. Надеялся что следующий видос за это будет. Так как вроде понимаю. а вроде нет(
А что именно не понимаете? Там же не так сложно, у Алишера есть хороший гайд @@StellaDemchenko
документацию открой да почитай
@@ButerTomatovichна душничах
Привет! Что думаешь про копилот в VS Code?
Привет всем. После просмотра возник вопрос, а почему бы не использовать кластерную архитектуру, которая будет производной от монолитной и микросервисной: это будет приложение, где функционал поделен на кластеры, подобно микросервисам, но расположенный на одном или нескольких серверах для обеспечения отказоустойчивости. Таким образом мы сохраняес микросервисный функционал, но при этом общение между кластерами осуществляется не по сети, а в рамках сервера, что исключает проблемы по потере данных при пересылке по сети.
Что скажете?
Влад, выхожу на маркет через пару месяцев, обучаюсь в буткемпе уже 8 й месяц. Интересно, можно ли с тобой провести пару индивидуальных курсов? За видео огромное спасибо, просто нереально, тебе нужно на английском выпускать тоже, уверен аудитория увеличится в разы.
За монолит!
отличная прическа🔥
Лайк !
Монолог про монолит очень спорный. Давайте доведем идею до абсурда, а потом ее раскритикуем. А вот про проблемы микросервисов рассказано хорошо :) Видно, что наболлело
Ну как говорится... За мналиииит
Кроме всех спасибо. Не забуду процитировать красное слово с одного из последних слайдов: "ОШЫБКА!", все Gramma Nazi снимают шляпу))