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