Завершение рассказв очень напомнило мне урок географии в 1985 году, когда, не побоюсь этого слова, мастер разговорного жанра, неонила Семеновна, минут сорок рассказывала о преимкществах краснодарского чая перед индийским, и закончила свою леккцию слвами - «Лично мне он не нравится» Вот так и здесь - «использую ли я микросервисы в своем стартапе? - Конечно, нет!»
как сказал один синьор знакомый: "научитесь пожалуйста делать нормальные монолиты, прежде чем прикасаться к микросервисам" Микросервисы, это то, что делают, если уже нельзя обойтись монолитом
Микросервисы нужны только тогда, когда монолит начинает несправляться с нагрузкой. Монолит очень долго можно разгонять как за счет более быстрых серверов, так и за счет разворачивания большего количестваа копий. Это вообще не подход к разработке, а оптимизация расходов и нагрузки для больших проектов. Кроме как в крупных продуктовых компаниях, микросервисы мало где еще нужны. А вообще да, смешно собеседовать людей, кторые с горящими глазами рассказывают про микросервисы, а сами нормальный код писать не способны.
@@КонстантинКуцевалов-ш1р полностью с Вами согласен. Это уже стало своего рода маркером у меня, когда человек много говорит о микросервисах, очень вероятно что хромает написание монолитов.
эх, много лет ковыряюсь в монолитах, в последнее время в очень больших, недавно был опыт создания микросервиса, я прям как на курорте побывал. Всё зависит от проекта но я бы выбрал микросервисы.
@@ВВВППП-в6г ключевое то, что вы много лет писали монолиты, проблема в том, что чаще люди пол года поработают с монолитом и сразу берутся за микросервисы.
По поводу дублирования, можно выносить общие части в отдельные пакеты, которые просто подключаются. Или в субмодули в гите. К микросервисам обычно идёт ещё логирование в одном месте, что может обеспечить kafka, rabbitmq.
По сути монолит и микросервисы различаются тем, что монолите разные блоки лежат на одном сервере и общаются напрямую, а в микросервисах общаются через http. Но это не значит, что чтобы что-то изменить в монолите, надо изучить весь код. Если надо изменить что-то в авторизации, ты лезешь в авторизацию и разбираешься с ней. С таким же успехом можно сказать, что надо изучить все микросервисы, чтобы внести правку с один из них.
Микросервисы тоже могут деплоится на один сервер и работать рядом друг с другом особенно когда они маленькие и ненагруженные. Различие в том что микросервисы позволяют оптимизировать отдельно каждый сервис под конкретные бизнес требования. Допустим один сервис должен быстро что-то считать - добавляем ему CPU получше. Другой сервис у нас обрабатывает данные о пользователях - настраиваем там шифрование и дополнительную защиту чтобы ФИО и адреса хакеры не похакали. Третий сервис может обрабатывать много запросов но каждый запрос простой - добавляем памяти. Если бы был монолит то все такие оптимизации нужно было бы делать на одном сервисе а это дорого и неудобно т.к. способы оптимизации могут конфликтовать между собой.
@@frexil2210 gRPC тоже общается через http, только через http/2. Но речь не об этом, а о тезисе, что в монолит сложно вносить изменения, потому что его сначала надо весь изучить (весь код).
Отчасти это правда. Изменения бизнес логики в одном месте программы могут привести к ошибкам в казалось бы не связанных модулях. Именно потому что всё переплетено. Поэтому изучать может потребоваться много.
Нужно техническое видео. Что такое микросервисы в общем много где сказано. Но новичку понятнее не становится. Как именно происходит связь? Общая ли у них бд? Если разные, то как он вообще синхранизирует информацию? Как организовывать кодовую базу и репозитории?
@@artemshumeiko Ждем с нетерпением Видео! Только без воды, а то уже чувствую зрение подводить начало глаза быстро устают, вроде нормально человек объясняет, понятливо, но столько рекламы и якорей, что сбивают с толку. Понятно реклама двигатель прогресса.
База часто одна с разными схемами, но могут быть и разные. Связь между сервисами через REST/gRPC или через kafka, или даже записи в определенной общей базе. Код чаще свой в разных проектах в гите, но может быть common с общими классами (как правило dto), когда это действительно очень надо.
19:00 Из моего опыта, путь через монолит это путь боли. Лучше день потерять, потом за 5 минут долететь. Даже на ранних стадиях, опять же из моего опыта, наиболее оптимально SOA модель(разбиение по бизнес процессам и рутинам) с общей БД. Это позволяет быстро бежать, при этом улучшает масштабирование отодвигая оверлоад и в дальнейшем создает меньше проблем при дроблении. Да, кстати, в такой модели можно даже коммуникации между сервисами пустить через ДБ, это сильно упростит код.
Спасибо за повествование. Объясните, пожалуйста, почему бы в своём проекте "с нуля" не использовать микросервисы? Ведь с точки зрения кода для взаимодействия с "модулями" системы никакой разницы нет. Если монолит хороший - там и так всё разбито и каждый кусок отвечает за свою часть (пусть и с одной базой, например). И если изначально закладываем микросервисы, реализовали транспорт между модулями, для каждого сервиса выделили базу данных - то, логически, они связаны только через брокер (например), это позволяет писать хороший код. А вот сложности пока не понимаю. То, что это дороже - вопрос спорный, можно и в одном докер-компоузе развернуть всю свою архитектуру (лишь бы ресурсов хватило), и локально тоже это может запускаться в докер-контейнерах одной командой. Зато какие преимущества имеем: еще на этапе написания кода не получится сделать "плохо", потому что сервисы слабо связаны. Если вдруг придётся что-то масштабировать - это займёт несколько минут, т.к. в каждом сервисе есть свой докерфайл и реализовать CI/CD с балансировщиком - дело нехитрое. Я понимаю сложность распиливания легаси-монолита на микросервисы - это прям жопа, извините. Но если проект с нуля, стек один, то почему сразу не пилить архитектурно правильно?
11:35 # душность mode on "манго" во всех падежах и числах пишется одинаково "маракуйя" в Р.П. мн.ч. будет - "маракуй" # душность mode off Спасибо за видео! Заставило задуматься над архитектурой своего проекта)
Спасибо за видео, отличный разбор верхнеуровневый) Да, было бы круто увидеть какой-то подробный технический разбор того, как грамотно организовать микросервисную архитектуру на бэкенде, настроить общение сервисов через брокеры и т.п., чтобы можно было на каких-то простейших примерах пощупать это всё. Особенно в отношении работы с брокерами было бы полезно, они сейчас на любой вакансии джуновской нужны.
Пожалуй, поставлю лайк и подпишусь. Очень подробно рассказали про тему, спасибо! У вас очень хорошая видеокамера, изображение очень чёткое. Очень красивый задний фон (цвета) и отражение от лампы не отображается на ваших очках! 👍👍👍
Хочу поправить про монолит. Если есть нагрузка на какой-то блок монолита, то используются потоки. И тупо увеличивается число потоков. А, как известно, взаимодействие между потоками более дешёвые для компа операции, чем с процессами. Но про поиск ошибок актуально.
вот про базу данных в микросервисах мучает вопрос, допустим, есть микросервис пользователей, есть микросервис товаров и категорий товаров, есть микросервис отвечающий за корзину заказов товаров пользователями, как система отчетов должна собирать данные со всех баз чтоб состряпать отчет/дашборд со статистиками продаж и пр. и так же как микросервис корзины будет понимать какой товар заказали в плане что товар добавили в корзину но купить не купили, вернулись через час в корзину а товар уже закончился на складе, как быть?
так можно еще и каждую колонку в каждой таблице в микросервис упаковать и на каждый микросервис 10 индусов типа это ИИ в кусты спрятать . "взлетит" проект )
ну такое. просто байт на микросервисы, хотя у микросервисов минусы более значительные и построить их нормально (хотя бы нормально) в разы тяжелее, чем построить монолит с чистой архитекторуй. джуну микросервисы не нужны - это бред, шиза
@@avmaksimov по поводу разобраться согласен, когда у сервиса одна задача тут как не крути будет приятнее, но по поводу написать... возможно зависит от назначения микросервиса, но опять же не уверен
@@okyesanapмикросервисы тож можно закинуть в одну репу и получится монорепа. Если вы чё то хотите проверить и для этого перебилдживаете целый проект, я бы задумался
Очень интересный выпуск, спасибо. У меня вот на работе микросервисная архитектура, но в единственном экземпляре. Т.е. масштабируемость не требуется. В целом удобно для разработки, т.к. можешь концентрироваться на отдельном микросервисе. Но про дебаг жиза - сложно порой разобраться. P.S. насчет изменений в авторизации и => изменениях во всех репозиториях - не согласен. Для таких ситуаций авторизация, например, должена быть вынесена как отдельный пакет) Тогда удобно обновить можно
Эмм... А как же персистентность данных, саги, ретраи и т.д.? Так то красиво всё, но если начать писать микросервисы судя по таким видео, то можно вообще не стартануть. До них нужно дорасти. Берите golang, rust и т.д., за глаза хватит без всяких микросервисов для старта и хорошей такой нагрузки. Если вы из этого вырастите, то я вас поздравляю, вы единорог и можете нанять индусов которые вам быстро и задёшево распилят монолит. Если крупная компания, да, микросервисы, в остальных случаях - монолит. Дёшево и сердито. Ну и нагрузку распределить на монолите можно не хуже чем в микросервисах.
И не только память.. Он ещё и ресурсы проца меньше жрёт. И вообще, при использовании ORM легче кодить.. Но.. плата за это в том, что сложнее обслуживать и новый сотрудник въезжает 2-3 месяца минимум ((.
Возник такой вопрос: насколько оправданным и реализуемым может быть проект, в котором есть база данных, админка от нее будет на Джанго, а API для обычных пользователей написано на FastAPI. Есть тут рациональное зерно в экономии на создании более-менее приличной админки, или проще все написать на 1 фреймворке?
Чем меньше в проекте фреймворков тем легче найти разработчика который все напишет и сможет поддерживать. Поэтому Django с админкой + АПИ на DRF или FastAPI + fastapi-admin.
Есть в планах записать видео по паттернам, которые используються в микросервисах по типу saga, transactional outbox, back for fronend, CQRS, api getaweay etc. Что Вы на практике используете
Микросервисы не панацея а скорее выход из ситуации когда мощностей уже не хватает - это раз. Во-вторых пример в видео уж очень простой, нормальная микросервисная архитектура нуждается еще в оркестраторе, довольно сложная система которую развернуть далеко не каждому под силу
Всем нужен стандартизированный способ оценки. В идеале объективный. Иначе как предлагаете оценивать? Гадалку звать? Совершенных методов нет, но ничего лучше пока не придумано 😊
Артем, а Вы не думали сделать на вашем сайте возможность выкладывать платные курсы (просто вариант образовательной платформы, хотя бы в формате видео). Сайт доступен не из рф без впн, что сильно упрощает жизнь)
Да уж хрень. Не совсем парень понимает что такое масштабирование. В настоящее время необходимо запускать больше одного экземпляра для надежности, а не производительности. Любые микросервисы ресурса будут жрать больше чем монолит с той же функциональностью. Остальные приемущества мкс весьма сомнительны. В мкс проще внести изменение казалось бы в одно место, в один микросервис. И оно кодом не затронет другие по идее. Но обычно изменение параметров в5дет за собой изменения множества мкс, которые менять и деплоить необходимо одновременно или мутить переходные версии. В монолите в одной репе изменил, пепезапустил и готово. А чтобы понять что в коде происходит и где что надо менять в случае с монолитом ты можешь бегать по файликам в одной репе. В мкс надо бегать по куче репозиториев. А разные языки это переписывание одной и той же функциональности на разных языках ты даже общие классы не сможешь намутить. Микросервисы это очень непросто, не оптимально и тяжело поддерживать нужна куча спецов. Микросервисы это шоколадная река, а люди кто верят в них как в что то по умолчанию хорошее это сказочные пони и единороги. В монолитах нет ничего плохого и они замечательные для небольших компаний технически ранней зрелости в бизнесе невысокой надежности.
Микросервис это путь, только для действительно BIG сервисов. Типа(сберонлайн и.т.п), там где количество одновременно работающих пользователей достигает сотни тысяч, когда другого выхода просто нет. Для всех остальных это сложно, долго и дорого, нужен реально большой штат, что бы это добро всё содержать. Хорошо спроектированный монолит, можно оптимизировать достаточно долго, но да в какой то момент, если ваша убер компания дорастает до критической отметки.
Ну, упустил такую маааленькую штуку как транзакции... что будет если у тебя сервис упал, или нужно откатить операции при последовательной обработке, что необходимо писать SAGA и т.д... а так, да, микросервисы очень хороши... сам говорит монолит надо выучить, а с микриками все проще, и тут же - надо знать все микросервисы на хреновой туче языков чтоб отдебажить... ну прям гений
Если вы уже работаете мидлом или сеньором, то в свободное время я бы учил. Если ищете работу или работаете на стартовых позициях, я бы не распылялся и пытался добиться успеха в Джанго
новичку норм объяснение, сойдет.))) ну если совсем на тоненького, то сойдет. стоит подучить как масштабируются приложения на разных яп. а то получилось как будто у ИИ спросил и зачитал.😁
@@ookhands3843, если у тебя везде разные языки, один компонент не сильно поможет. Если у тебя все utils в одном микросервисе, то ты только что сломал отказоустойчивость всего проекта
@@ookhands3843 если у тебя всё на разных языках, один компонент тебе не сильно поможет. Если у тебя все utilities в одном микросервисе, поздравляю, ты сломал отказоустойчивость всего проекта
Если у тебя сервисы на разных языках, общий компонент тебе не поможет. Если у тебя есть сервис со всеми утилитарными вещами, к которому обращаются все другие сервисы, у тебя нет отказоустойчивости
Ну все как обычно, хотя на что я надеялся, очередное бля-бля-бля и самолюбование. Тонны дистилированыой воды без всякой примеси чего-нибудь важного. Увы.
Приглашаю на мой Практический курс по Backend разработке по всем актуальным технологиям: artemshumeiko.ru
Завершение рассказв очень напомнило мне урок географии в 1985 году, когда, не побоюсь этого слова, мастер разговорного жанра, неонила Семеновна, минут сорок рассказывала о преимкществах краснодарского чая перед индийским, и закончила свою леккцию слвами - «Лично мне он не нравится»
Вот так и здесь - «использую ли я микросервисы в своем стартапе? - Конечно, нет!»
Объяснил же, что нет смысла использовать для стартапа. Нагрузки нет, идея не проверена. Потратил ты кучу времени, а идея просто не взлетела.
как сказал один синьор знакомый: "научитесь пожалуйста делать нормальные монолиты, прежде чем прикасаться к микросервисам" Микросервисы, это то, что делают, если уже нельзя обойтись монолитом
Прикол в том, что монолит, пилят на микромонолиты и, продают их как микросервисы.
Микросервисы нужны только тогда, когда монолит начинает несправляться с нагрузкой. Монолит очень долго можно разгонять как за счет более быстрых серверов, так и за счет разворачивания большего количестваа копий. Это вообще не подход к разработке, а оптимизация расходов и нагрузки для больших проектов. Кроме как в крупных продуктовых компаниях, микросервисы мало где еще нужны.
А вообще да, смешно собеседовать людей, кторые с горящими глазами рассказывают про микросервисы, а сами нормальный код писать не способны.
@@КонстантинКуцевалов-ш1р полностью с Вами согласен. Это уже стало своего рода маркером у меня, когда человек много говорит о микросервисах, очень вероятно что хромает написание монолитов.
эх, много лет ковыряюсь в монолитах, в последнее время в очень больших, недавно был опыт создания микросервиса, я прям как на курорте побывал. Всё зависит от проекта но я бы выбрал микросервисы.
@@ВВВППП-в6г ключевое то, что вы много лет писали монолиты, проблема в том, что чаще люди пол года поработают с монолитом и сразу берутся за микросервисы.
Капустка обглядела, поставила лайк и стала продвинутее.
По поводу дублирования, можно выносить общие части в отдельные пакеты, которые просто подключаются. Или в субмодули в гите. К микросервисам обычно идёт ещё логирование в одном месте, что может обеспечить kafka, rabbitmq.
Просим реальный пример🤝
Поднять свой локальный кластер на кубере
Написать пару сервисов + гейтвей
Это будет топовый топ
сделаю!
По сути монолит и микросервисы различаются тем, что монолите разные блоки лежат на одном сервере и общаются напрямую, а в микросервисах общаются через http. Но это не значит, что чтобы что-то изменить в монолите, надо изучить весь код. Если надо изменить что-то в авторизации, ты лезешь в авторизацию и разбираешься с ней. С таким же успехом можно сказать, что надо изучить все микросервисы, чтобы внести правку с один из них.
Существует такое вещь как gRPC чтобы общаться между серверами)
Микросервисы тоже могут деплоится на один сервер и работать рядом друг с другом особенно когда они маленькие и ненагруженные. Различие в том что микросервисы позволяют оптимизировать отдельно каждый сервис под конкретные бизнес требования. Допустим один сервис должен быстро что-то считать - добавляем ему CPU получше. Другой сервис у нас обрабатывает данные о пользователях - настраиваем там шифрование и дополнительную защиту чтобы ФИО и адреса хакеры не похакали. Третий сервис может обрабатывать много запросов но каждый запрос простой - добавляем памяти. Если бы был монолит то все такие оптимизации нужно было бы делать на одном сервисе а это дорого и неудобно т.к. способы оптимизации могут конфликтовать между собой.
@@frexil2210 gRPC тоже общается через http, только через http/2.
Но речь не об этом, а о тезисе, что в монолит сложно вносить изменения, потому что его сначала надо весь изучить (весь код).
Отчасти это правда. Изменения бизнес логики в одном месте программы могут привести к ошибкам в казалось бы не связанных модулях. Именно потому что всё переплетено. Поэтому изучать может потребоваться много.
@@Владислав-б7ф4я такое и в микросервисах может быть. В интерфейсе что-то поменяли и ищи свищи, где это аукнется )
Поработал я в компании, где был монолит + древний питон 2 (в 2024) это просто жесть:)
@@hardline_fc не, спрашивали чутка по базам данных и по джанго. Самый лайт собес был
Нержавейка 😂😂😂
Скок платили :)?
Нужно техническое видео. Что такое микросервисы в общем много где сказано. Но новичку понятнее не становится.
Как именно происходит связь?
Общая ли у них бд? Если разные, то как он вообще синхранизирует информацию?
Как организовывать кодовую базу и репозитории?
такое видео будет!)
@@artemshumeiko Ждем с нетерпением Видео!
Только без воды, а то уже чувствую зрение подводить начало глаза быстро устают, вроде нормально человек объясняет, понятливо, но столько рекламы и якорей, что сбивают с толку.
Понятно реклама двигатель прогресса.
База часто одна с разными схемами, но могут быть и разные. Связь между сервисами через REST/gRPC или через kafka, или даже записи в определенной общей базе. Код чаще свой в разных проектах в гите, но может быть common с общими классами (как правило dto), когда это действительно очень надо.
@JesusChristIsMyLord спасибо, хорошо расписал
19:00 Из моего опыта, путь через монолит это путь боли. Лучше день потерять, потом за 5 минут долететь. Даже на ранних стадиях, опять же из моего опыта, наиболее оптимально SOA модель(разбиение по бизнес процессам и рутинам) с общей БД. Это позволяет быстро бежать, при этом улучшает масштабирование отодвигая оверлоад и в дальнейшем создает меньше проблем при дроблении. Да, кстати, в такой модели можно даже коммуникации между сервисами пустить через ДБ, это сильно упростит код.
Интересно узнать про общение микросервисов)
Че там узнавать, брокер сообщений или база.
Медиатор😁
@@ZVA_NOOK Какая база, овощная?
ТЫ ПРОСТО ЛУЧШИЙ!! СПАСИБО ТЕБЕ!!
Спасибо за поддержку!
Так жду этот выпуск
Приятная картина. Хорошее качество и освещение
спасибо!
Никогда не жалко приятных слов приятному человеку
Но со звуком не очень, какие-то шумы
Можно было бы прогнать звуковую дорожку через нейросеть
Спасибо за повествование. Объясните, пожалуйста, почему бы в своём проекте "с нуля" не использовать микросервисы? Ведь с точки зрения кода для взаимодействия с "модулями" системы никакой разницы нет. Если монолит хороший - там и так всё разбито и каждый кусок отвечает за свою часть (пусть и с одной базой, например). И если изначально закладываем микросервисы, реализовали транспорт между модулями, для каждого сервиса выделили базу данных - то, логически, они связаны только через брокер (например), это позволяет писать хороший код. А вот сложности пока не понимаю. То, что это дороже - вопрос спорный, можно и в одном докер-компоузе развернуть всю свою архитектуру (лишь бы ресурсов хватило), и локально тоже это может запускаться в докер-контейнерах одной командой. Зато какие преимущества имеем: еще на этапе написания кода не получится сделать "плохо", потому что сервисы слабо связаны. Если вдруг придётся что-то масштабировать - это займёт несколько минут, т.к. в каждом сервисе есть свой докерфайл и реализовать CI/CD с балансировщиком - дело нехитрое. Я понимаю сложность распиливания легаси-монолита на микросервисы - это прям жопа, извините. Но если проект с нуля, стек один, то почему сразу не пилить архитектурно правильно?
Как с микросервисами решактся вопрос шаблонизации? Этому выделяется отдельный микросервис?
Самый нагруженный сервис, поэтому мы напишем его на пайтоне ))
11:35
# душность mode on
"манго" во всех падежах и числах пишется одинаково
"маракуйя" в Р.П. мн.ч. будет - "маракуй"
# душность mode off
Спасибо за видео! Заставило задуматься над архитектурой своего проекта)
Хотелось бы видео где будет рассказано масштабирование бд в микросервисах и как добиваться её консистентности
Техническое видео про микросервисы интересно. Особенно как общаются они между собой.
Большое спасибо за информацию.
Подскажите, пожалуйста! Что за сервис/приложение в которой описаны схемы на видео? Похоже на Miro/Metro)
miro
Зашибись, что миро поддерживает импорт из drawio
17:12 Это называется "Несвязность". Можно, наверное, назвать это изолированностью. Это описано в спецификации определения "Микросервисы"
Спасибо за видео, отличный разбор верхнеуровневый) Да, было бы круто увидеть какой-то подробный технический разбор того, как грамотно организовать микросервисную архитектуру на бэкенде, настроить общение сервисов через брокеры и т.п., чтобы можно было на каких-то простейших примерах пощупать это всё. Особенно в отношении работы с брокерами было бы полезно, они сейчас на любой вакансии джуновской нужны.
будет!
@@artemshumeikoэто прям супер)
лайк, теперь ждем видео по распределенным транзакциям)
Пожалуй, поставлю лайк и подпишусь. Очень подробно рассказали про тему, спасибо! У вас очень хорошая видеокамера, изображение очень чёткое. Очень красивый задний фон (цвета) и отражение от лампы не отображается на ваших очках! 👍👍👍
Ожидаем реальные примеры)
будут!
Хочу поправить про монолит. Если есть нагрузка на какой-то блок монолита, то используются потоки. И тупо увеличивается число потоков. А, как известно, взаимодействие между потоками более дешёвые для компа операции, чем с процессами.
Но про поиск ошибок актуально.
Друзья, а может кто-то пояснить, что подразумевается под масштабированием? Для чего нужно множить экземпляры приложения? Заранее очень благодарен
вот про базу данных в микросервисах мучает вопрос, допустим, есть микросервис пользователей, есть микросервис товаров и категорий товаров, есть микросервис отвечающий за корзину заказов товаров пользователями, как система отчетов должна собирать данные со всех баз чтоб состряпать отчет/дашборд со статистиками продаж и пр. и так же как микросервис корзины будет понимать какой товар заказали в плане что товар добавили в корзину но купить не купили, вернулись через час в корзину а товар уже закончился на складе, как быть?
так можно еще и каждую колонку в каждой таблице в микросервис упаковать и на каждый микросервис 10 индусов типа это ИИ в кусты спрятать . "взлетит" проект )
ну такое. просто байт на микросервисы, хотя у микросервисов минусы более значительные и построить их нормально (хотя бы нормально) в разы тяжелее, чем построить монолит с чистой архитекторуй. джуну микросервисы не нужны - это бред, шиза
Хайп. Сейчас только ленивый не пилит монолит на микросервисы))
ох уж эти любители монореп. когда делаешь изменение в троке и сидишь минут 20 пока перебилдится что бы проверить.
Как раз, джуниор легко сможет разобраться в микросервисе или даже запилить с нуля.. А в минолите не каждый сходу
@@avmaksimov по поводу разобраться согласен, когда у сервиса одна задача тут как не крути будет приятнее, но по поводу написать... возможно зависит от назначения микросервиса, но опять же не уверен
@@okyesanapмикросервисы тож можно закинуть в одну репу и получится монорепа. Если вы чё то хотите проверить и для этого перебилдживаете целый проект, я бы задумался
Очень интересный выпуск, спасибо. У меня вот на работе микросервисная архитектура, но в единственном экземпляре. Т.е. масштабируемость не требуется. В целом удобно для разработки, т.к. можешь концентрироваться на отдельном микросервисе. Но про дебаг жиза - сложно порой разобраться.
P.S. насчет изменений в авторизации и => изменениях во всех репозиториях - не согласен. Для таких ситуаций авторизация, например, должена быть вынесена как отдельный пакет)
Тогда удобно обновить можно
Отдельный пакет подойдёт, если язык один. В ролике был упор на то, что языки могут использоваться разные
Огонь! 🔥
Самая частая проблема вовсе не с нагрузкой на код, а с нагрузкой на базу, какой бы она не была.
Эмм... А как же персистентность данных, саги, ретраи и т.д.? Так то красиво всё, но если начать писать микросервисы судя по таким видео, то можно вообще не стартануть. До них нужно дорасти. Берите golang, rust и т.д., за глаза хватит без всяких микросервисов для старта и хорошей такой нагрузки. Если вы из этого вырастите, то я вас поздравляю, вы единорог и можете нанять индусов которые вам быстро и задёшево распилят монолит. Если крупная компания, да, микросервисы, в остальных случаях - монолит. Дёшево и сердито. Ну и нагрузку распределить на монолите можно не хуже чем в микросервисах.
на Go монолит собрались пилить? вы серьезно или не подумав? вас гугел за такое в аду лично жарить будет..🤣
Ждём реальный пример, спасибо за видео
Давно хотел об этом узнать спасибо!
Два вопроса : в чем разница между SOA (сервисно ориентированная архитектура) и микросервисами ? Между сервисом и микросервисом ? Спасибо.
SOA - distributed monolith. Microservices are about deployments
@@ivanaphanasyev9743;)))) нет
Кто является экземпляром пожалуйста объясните
А почему ты решил, что память которую ест монолит равна суммарной памяти микросервисов? Монолит при прочих равных должен есть меньше
И не только память.. Он ещё и ресурсы проца меньше жрёт. И вообще, при использовании ORM легче кодить.. Но.. плата за это в том, что сложнее обслуживать и новый сотрудник въезжает 2-3 месяца минимум ((.
@@avmaksimov а при чем тут орм?
@@k3l3vr444 , в монолите описал один раз. И используй в разных частях программы.
@@avmaksimov что мешает использовать орм в микросервисах? Большей чуши в жизни не слышал
И нормализация данных в сервисах - это боль
В Django, все велосипеды уже реализованы. С аутентификацией , авторизацией и прочее.
Привет
Видимо ты не любишь PHP ?
Все круто на видео описано , но вот когда на листе не говоришь о PHP, это не хорошо )
Pascal тоже следует упомянуть 😅
6:00 Это какой-то новый тренд? Создаётся ощущение что сейчас каждый имеет курсы "Как войти в IT". Это уже немного не здоровО выглядит.
Возник такой вопрос: насколько оправданным и реализуемым может быть проект, в котором есть база данных, админка от нее будет на Джанго, а API для обычных пользователей написано на FastAPI.
Есть тут рациональное зерно в экономии на создании более-менее приличной админки, или проще все написать на 1 фреймворке?
Чем меньше в проекте фреймворков тем легче найти разработчика который все напишет и сможет поддерживать. Поэтому Django с админкой + АПИ на DRF или FastAPI + fastapi-admin.
@@victorbrylew1775 спасибо, надо познакомиться с fastapi-admin
Артем, в видео сказал, что не используешь микросервисы для своего стартапа в силу объективных причин, а какой монолит тогда используешь?
всмысле какой? На FastAPI одно единое приложение
Есть в планах записать видео по паттернам, которые используються в микросервисах по типу saga, transactional outbox, back for fronend, CQRS, api getaweay etc. Что Вы на практике используете
Круто объяснил, спасибо за видос!)
Хорошее видео, но с нагрузкой напутано. Карточки товаров самое низконагруженная часть.
8:27 ошибка монтажа? про один сервис рассказал два раза
Спасибо, поправил
Спасибо за ролик, всë как всегда круто 😎
Микросервисы не панацея а скорее выход из ситуации когда мощностей уже не хватает - это раз. Во-вторых пример в видео уж очень простой, нормальная микросервисная архитектура нуждается еще в оркестраторе, довольно сложная система которую развернуть далеко не каждому под силу
Школьников натаскивают на ЕГЭ, программистов на собес. Наверно что-то не так с ЕГЭ и собес.
Всем нужен стандартизированный способ оценки. В идеале объективный.
Иначе как предлагаете оценивать? Гадалку звать?
Совершенных методов нет, но ничего лучше пока не придумано 😊
Модульный монолит и скалирование нагрузки в облаке просто существуют....
Не хочу душнить, но придется))) на мапе сервисов показана аутентификация а написано авторизация.
Дык, еще и про идентификацию можно добавить )
Спасибо!
Общение между сервисами хттп - это верно... Очереди используются не для общения... И апи у брокеров тоже может быть через хттп...
ток http2 + gRPC, а не обычный rest api :)
15:06 А в очередь брокера они как попадают, голубями?
Артем, а Вы не думали сделать на вашем сайте возможность выкладывать платные курсы (просто вариант образовательной платформы, хотя бы в формате видео). Сайт доступен не из рф без впн, что сильно упрощает жизнь)
Да уж хрень. Не совсем парень понимает что такое масштабирование. В настоящее время необходимо запускать больше одного экземпляра для надежности, а не производительности. Любые микросервисы ресурса будут жрать больше чем монолит с той же функциональностью. Остальные приемущества мкс весьма сомнительны. В мкс проще внести изменение казалось бы в одно место, в один микросервис. И оно кодом не затронет другие по идее. Но обычно изменение параметров в5дет за собой изменения множества мкс, которые менять и деплоить необходимо одновременно или мутить переходные версии. В монолите в одной репе изменил, пепезапустил и готово. А чтобы понять что в коде происходит и где что надо менять в случае с монолитом ты можешь бегать по файликам в одной репе. В мкс надо бегать по куче репозиториев. А разные языки это переписывание одной и той же функциональности на разных языках ты даже общие классы не сможешь намутить. Микросервисы это очень непросто, не оптимально и тяжело поддерживать нужна куча спецов.
Микросервисы это шоколадная река, а люди кто верят в них как в что то по умолчанию хорошее это сказочные пони и единороги.
В монолитах нет ничего плохого и они замечательные для небольших компаний технически ранней зрелости в бизнесе невысокой надежности.
Главное чтобы курьер не ушел в другой город
Микросервис это путь, только для действительно BIG сервисов. Типа(сберонлайн и.т.п), там где количество одновременно работающих пользователей достигает сотни тысяч, когда другого выхода просто нет. Для всех остальных это сложно, долго и дорого, нужен реально большой штат, что бы это добро всё содержать. Хорошо спроектированный монолит, можно оптимизировать достаточно долго, но да в какой то момент, если ваша убер компания дорастает до критической отметки.
Годный контент
Спасибо!
Ну, упустил такую маааленькую штуку как транзакции... что будет если у тебя сервис упал, или нужно откатить операции при последовательной обработке, что необходимо писать SAGA и т.д... а так, да, микросервисы очень хороши... сам говорит монолит надо выучить, а с микриками все проще, и тут же - надо знать все микросервисы на хреновой туче языков чтоб отдебажить... ну прям гений
Стоит ли полностью переходить с Джанго на go?
Если вы уже работаете мидлом или сеньором, то в свободное время я бы учил. Если ищете работу или работаете на стартовых позициях, я бы не распылялся и пытался добиться успеха в Джанго
@@artemshumeiko спасибо большое за ответ
спасибо
новичку норм объяснение, сойдет.)))
ну если совсем на тоненького, то сойдет. стоит подучить как масштабируются приложения на разных яп. а то получилось как будто у ИИ спросил и зачитал.😁
но суровая жиза такова: лучше хреновый монолит, чем хреновый микросервис.
За Монолит
Артем, какой микросервис быстрее, на Go или Fastapi?
Go конечно, сам язык быстрее Питона
твой вопрос звучит как "что быстрее фреймворк или язык", звучит довольно странно
@@marcoinsane149 у тебя с пониманием прочитанного проблемы? Написано какой микросервис.
@@AntiBandera да знаю я это, что за токсичный тип ))
@@AntiBandera дебилок, не тебе писал
да какой курс? я нищий, мне надо научиться сначала работать программистом, чтобы было чем оплачивать курсы
Руководство для РП-ника, как выжать деньги из заказчика...
Че за прикол делать видео мега тихим, даде с шумодавом по улице в наущниках идк, н***я не слышу
Дублирование кода - это не минус архитектуры микросервисов, а минус дизайна кода...
И как его избежать, если у тебя действительно все сервисы на разных языках? Не делать сервисы на разных языках?)
@@Ivan-Bagrintsev вынести общий код в компонент или даже в микросервис. Сорсы компонента можно хранить в отдельной ветке. Так сойдет?
@@ookhands3843, если у тебя везде разные языки, один компонент не сильно поможет. Если у тебя все utils в одном микросервисе, то ты только что сломал отказоустойчивость всего проекта
@@ookhands3843 если у тебя всё на разных языках, один компонент тебе не сильно поможет. Если у тебя все utilities в одном микросервисе, поздравляю, ты сломал отказоустойчивость всего проекта
Если у тебя сервисы на разных языках, общий компонент тебе не поможет. Если у тебя есть сервис со всеми утилитарными вещами, к которому обращаются все другие сервисы, у тебя нет отказоустойчивости
Пишите на Go монолиты, разбивая в них все на микросервисы (гоша это позволяет) и будет Вам счастье.
По 10-15 минут манги рассматривают 😅😅😅
Ну все как обычно, хотя на что я надеялся, очередное бля-бля-бля и самолюбование. Тонны дистилированыой воды без всякой примеси чего-нибудь важного. Увы.
Как говорится, чтобы понимать на какие куски делить, нужно сначала монолит запилить)) а где база в этой солянке? Все таки истина должна быть одна.
ты втираешь мне какую то дичь 🤦♂🤦♂🤦♂🤦♂🤦♂
читаете:
Building Microservices: Designing Fine-Grained Systems
Designing Data-Intensive Applications
конструктив будет?
@@artemshumeiko please find constructive in the books that I mentioned 😊
все минусы монолита натянуты как … на глобус, ни один нормальный монолит так не сделан
спасибо