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