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