Микросервисы - Простым Языком на Понятном Примере
Vložit
- čas přidán 17. 05. 2024
- Микросервисы на простом примере. Для тех кто не понимает, что это такое.
Разверните IT-инфраструктуру для веб-проектов любой сложности со скидкой 20%: slc.tl/vum0w
Пишу про свой стартап для подготовки к собеседованиям, рынок труда и способы развития разработчиков в телеграм канале - подписывайся: t.me/artemshumeiko
Заполните форму, если хотите курс по авторизации: forms.gle/krPVortjDERNRAgZ7
Погружение в Backend разработку на Python за 3 месяца - научись писать API с нуля до вывода в продакшен на моем авторском курсе: clck.ru/3AHAXK (есть 3 бесплатных урока)
🚨 Продажи открыты только до 31 мая 2024 года! 🚨
Прочитать отзывы к курсу можно на Stepik: clck.ru/3AHAZN
Python сообщество в телеграме (здесь тебе помогут с любым вопросом): t.me/python_community_rus
Поддержать меня и получить ранний доступ к видео можно здесь: boosty.to/artemshumeiko
0:00 - Микросервисы нужно знать!
0:36 - Пример монолита
3:41 - Проблемы монолита
6:24 - Пример микросервисов
11:04 - Плюсы и минусы микросервисов
16:56 - Мой опыт работы с микросервисами в компании
18:48 - Нужны ли микросервисы в пет-проектах и стартапах?
#микросервисы #шумейко
Пишу про свой стартап для подготовки к собеседованиям, рынок труда и способы развития разработчиков в телеграм канале - подписывайся: t.me/artemshumeiko
Заполните форму, если хотите курс по авторизации: forms.gle/krPVortjDERNRAgZ7
Погружение в Backend разработку за 3 месяца - научись писать API с нуля до вывода в продакшен на моем авторском курсе: clck.ru/3AHAXK (есть 3 бесплатных урока)
Прочитать отзывы к курсу можно на Stepik: clck.ru/3AHAZN
Завершение рассказв очень напомнило мне урок географии в 1985 году, когда, не побоюсь этого слова, мастер разговорного жанра, неонила Семеновна, минут сорок рассказывала о преимкществах краснодарского чая перед индийским, и закончила свою леккцию слвами - «Лично мне он не нравится»
Вот так и здесь - «использую ли я микросервисы в своем стартапе? - Конечно, нет!»
Техническое видео про микросервисы интересно. Особенно как общаются они между собой.
как сказал один синьор знакомый: "научитесь пожалуйста делать нормальные монолиты, прежде чем прикасаться к микросервисам" Микросервисы, это то, что делают, если уже нельзя обойтись монолитом
Прикол в том, что монолит, пилят на микромонолиты и, продают их как микросервисы.
Микросервисы нужны только тогда, когда монолит начинает несправляться с нагрузкой. Монолит очень долго можно разгонять как за счет более быстрых серверов, так и за счет разворачивания большего количестваа копий. Это вообще не подход к разработке, а оптимизация расходов и нагрузки для больших проектов. Кроме как в крупных продуктовых компаниях, микросервисы мало где еще нужны.
А вообще да, смешно собеседовать людей, кторые с горящими глазами рассказывают про микросервисы, а сами нормальный код писать не способны.
@@user-qo5ou9uj3g полностью с Вами согласен. Это уже стало своего рода маркером у меня, когда человек много говорит о микросервисах, очень вероятно что хромает написание монолитов.
Просим реальный пример🤝
Поднять свой локальный кластер на кубере
Написать пару сервисов + гейтвей
Это будет топовый топ
сделаю!
По поводу дублирования, можно выносить общие части в отдельные пакеты, которые просто подключаются. Или в субмодули в гите. К микросервисам обычно идёт ещё логирование в одном месте, что может обеспечить kafka, rabbitmq.
Поработал я в компании, где был монолит + древний питон 2 (в 2024) это просто жесть:)
Давай угадаю а на собесе задавали вопросы типо оператор моржа, как свитч-элс писать на пайтоне, ф-стриги с опрерациями внутри. Тут такой прихоидшь в первый день работы а там принт без скобок стоит.
@@Hardy_21 не, спрашивали чутка по базам данных и по джанго. Самый лайт собес был
Нержавейка 😂😂😂
Интересно узнать про общение микросервисов)
Че там узнавать, брокер сообщений или база.
Так жду этот выпуск
Ждём реальный пример, спасибо за видео
Приятная картина. Хорошее качество и освещение
спасибо!
Никогда не жалко приятных слов приятному человеку
Но со звуком не очень, какие-то шумы
Можно было бы прогнать звуковую дорожку через нейросеть
Большое спасибо за информацию.
лайк, теперь ждем видео по распределенным транзакциям)
Круто объяснил, спасибо за видос!)
Артем, в видео сказал, что не используешь микросервисы для своего стартапа в силу объективных причин, а какой монолит тогда используешь?
всмысле какой? На FastAPI одно единое приложение
Хотелось бы видео где будет рассказано масштабирование бд в микросервисах и как добиваться её консистентности
Самый нагруженный сервис, поэтому мы напишем его на пайтоне ))
19:00 Из моего опыта, путь через монолит это путь боли. Лучше день потерять, потом за 5 минут долететь. Даже на ранних стадиях, опять же из моего опыта, наиболее оптимально SOA модель(разбиение по бизнес процессам и рутинам) с общей БД. Это позволяет быстро бежать, при этом улучшает масштабирование отодвигая оверлоад и в дальнейшем создает меньше проблем при дроблении. Да, кстати, в такой модели можно даже коммуникации между сервисами пустить через ДБ, это сильно упростит код.
11:35
# душность mode on
"манго" во всех падежах и числах пишется одинаково
"маракуйя" в Р.П. мн.ч. будет - "маракуй"
# душность mode off
Спасибо за видео! Заставило задуматься над архитектурой своего проекта)
По сути монолит и микросервисы различаются тем, что монолите разные блоки лежат на одном сервере и общаются напрямую, а в микросервисах общаются через http. Но это не значит, что чтобы что-то изменить в монолите, надо изучить весь код. Если надо изменить что-то в авторизации, ты лезешь в авторизацию и разбираешься с ней. С таким же успехом можно сказать, что надо изучить все микросервисы, чтобы внести правку с один из них.
Существует такое вещь как gRPC чтобы общаться между серверами)
Микросервисы тоже могут деплоится на один сервер и работать рядом друг с другом особенно когда они маленькие и ненагруженные. Различие в том что микросервисы позволяют оптимизировать отдельно каждый сервис под конкретные бизнес требования. Допустим один сервис должен быстро что-то считать - добавляем ему CPU получше. Другой сервис у нас обрабатывает данные о пользователях - настраиваем там шифрование и дополнительную защиту чтобы ФИО и адреса хакеры не похакали. Третий сервис может обрабатывать много запросов но каждый запрос простой - добавляем памяти. Если бы был монолит то все такие оптимизации нужно было бы делать на одном сервисе а это дорого и неудобно т.к. способы оптимизации могут конфликтовать между собой.
@@frexil2210 gRPC тоже общается через http, только через http/2.
Но речь не об этом, а о тезисе, что в монолит сложно вносить изменения, потому что его сначала надо весь изучить (весь код).
Отчасти это правда. Изменения бизнес логики в одном месте программы могут привести к ошибкам в казалось бы не связанных модулях. Именно потому что всё переплетено. Поэтому изучать может потребоваться много.
@@user-qx8ol8dc9l такое и в микросервисах может быть. В интерфейсе что-то поменяли и ищи свищи, где это аукнется )
15:06 А в очередь брокера они как попадают, голубями?
17:12 Это называется "Несвязность". Можно, наверное, назвать это изолированностью. Это описано в спецификации определения "Микросервисы"
А почему ты решил, что память которую ест монолит равна суммарной памяти микросервисов? Монолит при прочих равных должен есть меньше
И не только память.. Он ещё и ресурсы проца меньше жрёт. И вообще, при использовании ORM легче кодить.. Но.. плата за это в том, что сложнее обслуживать и новый сотрудник въезжает 2-3 месяца минимум ((.
@@avmaksimov а при чем тут орм?
@@VaeV1ct1s , в монолите описал один раз. И используй в разных частях программы.
@@avmaksimov что мешает использовать орм в микросервисах? Большей чуши в жизни не слышал
Давно хотел об этом узнать спасибо!
Ожидаем реальные примеры)
будут!
Годный контент
Спасибо!
Возник такой вопрос: насколько оправданным и реализуемым может быть проект, в котором есть база данных, админка от нее будет на Джанго, а API для обычных пользователей написано на FastAPI.
Есть тут рациональное зерно в экономии на создании более-менее приличной админки, или проще все написать на 1 фреймворке?
Чем меньше в проекте фреймворков тем легче найти разработчика который все напишет и сможет поддерживать. Поэтому Django с админкой + АПИ на DRF или FastAPI + fastapi-admin.
@@victorbrylew1775 спасибо, надо познакомиться с fastapi-admin
Хочу поправить про монолит. Если есть нагрузка на какой-то блок монолита, то используются потоки. И тупо увеличивается число потоков. А, как известно, взаимодействие между потоками более дешёвые для компа операции, чем с процессами.
Но про поиск ошибок актуально.
В Django, все велосипеды уже реализованы. С аутентификацией , авторизацией и прочее.
Спасибо за ролик, всë как всегда круто 😎
Спасибо!
Хорошее видео, но с нагрузкой напутано. Карточки товаров самое низконагруженная часть.
Очень интересный выпуск, спасибо. У меня вот на работе микросервисная архитектура, но в единственном экземпляре. Т.е. масштабируемость не требуется. В целом удобно для разработки, т.к. можешь концентрироваться на отдельном микросервисе. Но про дебаг жиза - сложно порой разобраться.
P.S. насчет изменений в авторизации и => изменениях во всех репозиториях - не согласен. Для таких ситуаций авторизация, например, должена быть вынесена как отдельный пакет)
Тогда удобно обновить можно
Отдельный пакет подойдёт, если язык один. В ролике был упор на то, что языки могут использоваться разные
Самая частая проблема вовсе не с нагрузкой на код, а с нагрузкой на базу, какой бы она не была.
Нужно техническое видео. Что такое микросервисы в общем много где сказано. Но новичку понятнее не становится.
Как именно происходит связь?
Общая ли у них бд? Если разные, то как он вообще синхранизирует информацию?
Как организовывать кодовую базу и репозитории?
такое видео будет!)
Спасибо за видео, отличный разбор верхнеуровневый) Да, было бы круто увидеть какой-то подробный технический разбор того, как грамотно организовать микросервисную архитектуру на бэкенде, настроить общение сервисов через брокеры и т.п., чтобы можно было на каких-то простейших примерах пощупать это всё. Особенно в отношении работы с брокерами было бы полезно, они сейчас на любой вакансии джуновской нужны.
будет!
@@artemshumeikoэто прям супер)
8:27 ошибка монтажа? про один сервис рассказал два раза
Спасибо, поправил
ну такое. просто байт на микросервисы, хотя у микросервисов минусы более значительные и построить их нормально (хотя бы нормально) в разы тяжелее, чем построить монолит с чистой архитекторуй. джуну микросервисы не нужны - это бред, шиза
Хайп. Сейчас только ленивый не пилит монолит на микросервисы))
ох уж эти любители монореп. когда делаешь изменение в троке и сидишь минут 20 пока перебилдится что бы проверить.
Как раз, джуниор легко сможет разобраться в микросервисе или даже запилить с нуля.. А в минолите не каждый сходу
@@avmaksimov по поводу разобраться согласен, когда у сервиса одна задача тут как не крути будет приятнее, но по поводу написать... возможно зависит от назначения микросервиса, но опять же не уверен
@@OYAnapмикросервисы тож можно закинуть в одну репу и получится монорепа. Если вы чё то хотите проверить и для этого перебилдживаете целый проект, я бы задумался
Школьников натаскивают на ЕГЭ, программистов на собес. Наверно что-то не так с ЕГЭ и собес.
Не хочу душнить, но придется))) на мапе сервисов показана аутентификация а написано авторизация.
Дык, еще и про идентификацию можно добавить )
6:00 Это какой-то новый тренд? Создаётся ощущение что сейчас каждый имеет курсы "Как войти в IT". Это уже немного не здоровО выглядит.
Общение между сервисами хттп - это верно... Очереди используются не для общения... И апи у брокеров тоже может быть через хттп...
ток http2 + gRPC, а не обычный rest api :)
Главное чтобы курьер не ушел в другой город
Артем, а Вы не думали сделать на вашем сайте возможность выкладывать платные курсы (просто вариант образовательной платформы, хотя бы в формате видео). Сайт доступен не из рф без впн, что сильно упрощает жизнь)
спасибо
Есть в планах записать видео по паттернам, которые используються в микросервисах по типу saga, transactional outbox, back for fronend, CQRS, api getaweay etc. Что Вы на практике используете
да какой курс? я нищий, мне надо научиться сначала работать программистом, чтобы было чем оплачивать курсы
Эмм... А как же персистентность данных, саги, ретраи и т.д.? Так то красиво всё, но если начать писать микросервисы судя по таким видео, то можно вообще не стартануть. До них нужно дорасти. Берите golang, rust и т.д., за глаза хватит без всяких микросервисов для старта и хорошей такой нагрузки. Если вы из этого вырастите, то я вас поздравляю, вы единорог и можете нанять индусов которые вам быстро и задёшево распилят монолит. Если крупная компания, да, микросервисы, в остальных случаях - монолит. Дёшево и сердито. Ну и нагрузку распределить на монолите можно не хуже чем в микросервисах.
на Go монолит собрались пилить? вы серьезно или не подумав? вас гугел за такое в аду лично жарить будет..🤣
Стоит ли полностью переходить с Джанго на go?
Если вы уже работаете мидлом или сеньором, то в свободное время я бы учил. Если ищете работу или работаете на стартовых позициях, я бы не распылялся и пытался добиться успеха в Джанго
@@artemshumeiko спасибо большое за ответ
За Монолит
Артем, какой микросервис быстрее, на Go или Fastapi?
Go конечно, сам язык быстрее Питона
твой вопрос звучит как "что быстрее фреймворк или язык", звучит довольно странно
@@marcoinsane149 у тебя с пониманием прочитанного проблемы? Написано какой микросервис.
@@AntiBandera да знаю я это, что за токсичный тип ))
@@AntiBandera дебилок, не тебе писал
Руководство для РП-ника, как выжать деньги из заказчика...
новичку норм объяснение, сойдет.)))
ну если совсем на тоненького, то сойдет. стоит подучить как масштабируются приложения на разных яп. а то получилось как будто у ИИ спросил и зачитал.😁
Че за прикол делать видео мега тихим, даде с шумодавом по улице в наущниках идк, н***я не слышу
Не в обиду автору, но ожидал чего-то большего, чем повторения ролика годовой давности. Очень поверхностно, почти никакие технологии не затронуты, про брокеры пару слов мельком, про логирование микросервисов ещё меньше сказал... Ну, такое...
Можно было бы полностью разобрать весь технический стэк, с докером, кубером, консулом, брокерами (рэбит/кафка), логированием (кибана/графана) и показать на примере как всё это в коде реализовать.
А так, получилась очень маленькая статья, которая есть в гугле по каждой ссылке и читается за 5 минут, только растянутая на 20 минут видео.
P.S. Я не хейтер и посмотрел ВСЕ видео на твоём канале. Чистый конструктив. Слишком поверхностно получилось.
Спасибо за отзыв!
Видео и рассчитано на новичков) Поэтому оно и называется «простым языком».
Видео с написанием кода микросервисов, перечислением стека и т.п. обязательно будет. Смешивать воедино фундамент и прикладное использование мне кажется плохой идеей, поэтому и не стал тут углубляться в детали реализации
Ну это прям слишком "простым языком", просто каждая статья плюс-минус то же самое описывает, а вот практических примеров с парой микросервисов их оркестированием и логгирование -- вот этого мало.
@@artemshumeiko Было бы здорово взять пример скажем с 3 микросервисами и показать как выстроить взаимодействие между ними. С пробрасыванием request_id сквозь всю цепочку микросервисов используемых в запросе пользователя для логирования, регистрацией в consul и т.д. Вот этого добра маловато в ютубе.
@@artemshumeiko Привет. В один из видео ты говорил что записываешь видео на ютуб только по тем темам, которые плохо раскрыты на СНГ-ютубе. Если это действительно так - сделай хороший обзор на библиотеку FastStream. Недавно для себя её открыл - это нечто. Либа из коробки поддерживает 5 брокеров сообщений и имеет структуру как FastAPI, кучу интеграций, инструменты тестирования и CI. В общем, конфетка, но вот на СНГ-ютубе буквально 0 видео по ней. Тупо нечего посмотреть. Хорошая тема была бы, как раз в догонку по микросервисам.
Дублирование кода - это не минус архитектуры микросервисов, а минус дизайна кода...
И как его избежать, если у тебя действительно все сервисы на разных языках? Не делать сервисы на разных языках?)
@@Ivan-Bagrintsev вынести общий код в компонент или даже в микросервис. Сорсы компонента можно хранить в отдельной ветке. Так сойдет?
@@ookhands3843, если у тебя везде разные языки, один компонент не сильно поможет. Если у тебя все utils в одном микросервисе, то ты только что сломал отказоустойчивость всего проекта
@@ookhands3843 если у тебя всё на разных языках, один компонент тебе не сильно поможет. Если у тебя все utilities в одном микросервисе, поздравляю, ты сломал отказоустойчивость всего проекта
Если у тебя сервисы на разных языках, общий компонент тебе не поможет. Если у тебя есть сервис со всеми утилитарными вещами, к которому обращаются все другие сервисы, у тебя нет отказоустойчивости
Как говорится, чтобы понимать на какие куски делить, нужно сначала монолит запилить)) а где база в этой солянке? Все таки истина должна быть одна.
ты втираешь мне какую то дичь 🤦♂🤦♂🤦♂🤦♂🤦♂
читаете:
Building Microservices: Designing Fine-Grained Systems
Designing Data-Intensive Applications
конструктив будет?
@@artemshumeiko please find constructive in the books that I mentioned 😊
спасибо