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