Модульный Монолит и Микросервисы. Что лучше для масштабирования и производительности?

[@GalimovBulat]

Отличный видос, спасибо! Жду следующего видосика по архитектуре.

[@ЗамирЮсупов-щ9к]

Спасибо! Больше начал погружаться в архитектуру приложений, а тут ваше видео, все разложено по полочкам и не слишком затянуто!

[@databox4279]

Вам спасибо. Не материал, а золото. Есть на Ютубе доклад где рассказывается о том, что команда перевела проект с модного fastapi, на "старый" Django и скорость разработки выросла в 2,5 раза. Итог доклада такой, что инструменты необходимо выбирать под задачи, а не на оборот. Огромная благодарность за видео.

[@SeniorPomidorDeveloper]

Вам пожалуйста! Да, такое ощущение что повальное увеличение все «распиливать» возникло от незнания других инструментов оптимизации.

[@user-Rosev1980]

Спасибо за труд и просвещение!

[@MrVernuk]

Спасибо, Алексей) Как всегда интересно и познавательно 👍 Никогда не вникал в микросервисную архитектуру, но теперь имею представление и различия между монолитом и микросервисами)

[@SeniorPomidorDeveloper]

Вам спасибо что смотрели !

[@koltdota]

Было бы здорово, если бы вы сняли миникурс по фастапи)

[@SeniorPomidorDeveloper]

Хорошая тема, надо подумать

[@artemlaravel8769]

@@SeniorPomidorDeveloper давай джангу с 3-мя фастаппи скристи :D

[@noname52rus]

Спасибо за твои труды, очень интересно!

[@SeniorPomidorDeveloper]

Вам спасибо что смотрели!

[@andyabsent4648]

Спасибо за полезный и уникальный контент.

[@роматарасов-о8л]

когда начинал вкатыватся в программирование и был чистым фронтом на работе надо было по-быстрому стать фулстеком и писать drf именно твои видосы оказались самыми полезными, большое спасибо а в этот видос очень сильно меня порадовал потому-что затронуты очень глубокие темы о которых я слышал только 1 раз краем уха, и не понимал что они значат в общем ты реально крут!

[@SeniorPomidorDeveloper]

Спасибо большое за такой отзыв! Рад что мои видосы помогли, всегда приятно такое слышать.

[@Snooper7]

Дружище, очень ценная инфа. Спасибо!

[@r.chitector]

По-моему такая позиция по вопросу архитектуры очень профессиональная и не «топит» в какую либо из сторон! Для каждой задачи нужно выбрать свой инструмент. И вот мне кажется что сложность или простота будущего развития проекта зависят от профессиональности архитектора на ранних этапах создания приложения.

[@SeniorPomidorDeveloper]

Спасибо! Да, это сложно , найти баланс между скоростью разработки и правильными архитектурными решениями, на ранних этапах проекта. А бывает что и сам архитектор и даже менеджеры не знают как именно проект будет развиваться и в результате закладывают решения не туда, где в конечном итоге возникают сложности. Но в любом случае, это очень интересно, учавствовать в жизни и развитии проекта, даже если приходится делать ошибки.

[@timur8216]

Огромное спасибо! Золотой материал!

[@las_9011]

было очень интересно спасибо большое, как раз на работе сейчас делаем из монолита модульный

[@dmitryzagorevskiy507]

Большое спасибо! Очень хороший материал!

[@dunhillkekov3383]

Спасибо за контент!

[@никита-ш1ы2и]

Спасибо за видео, оно было очень познавательным

[@okseresko]

было сложно.. но полезно!

[@roman.kovalev]

Приятно было послушать :)

[@СергейРазин-ф9х]

Спасибо за видео.

[@ZZZMerk]

Спасибо, супер доступно)

[@dokasan4860]

Отлично! Спасибо!

[@picblade]

Супер! В какой-то момент в голове прозвучала мысль: плох тот микросервис, который не стремится сам в себе стать монолитом и не обзавестись своими модулями :)) В одном проекте встречал подход, о котором краем говорилось в заключении... Монолит, который просто наваливает нужное количество воркеров когда нужно. Это отлично и быстро работает! Мне кажется, микросервисы имеет смысл использовать только когда речь идёт о миллионах одновременных запросов и просто реплицировать апку не получится. Во всех остальных случаях - простая копия на отдельной железке, которая ломится в ту же самую базу - вполне себе вариант. Ну подождёт юзер не секунду, а три.. 😊 Тем более, бывают штуки, которые в принципе нельзя асинхронно выполнить - ничего - ждут и терпят.

[@SeniorPomidorDeveloper]

Согласен. Пользователи подождут ) Вообще они ждут когда выбора нет и приходится что-то считать синхронно. Типа аплоад. А если что-то можно считать асинхронно то тут и микросервис и монолит равны

[@alexeyni722]

заранее спасиибо, и прическа клеевская:D

[@SeniorPomidorDeveloper]

👨🏻‍🦱

[@РоманПермяков-л2ь]

Спасибо за видео! Хочу добавить к теме: - не любой монолит - это модульный монолит. Молиты ругают за склонность к запутыванию кода, модульный монолит старается решить эту проблему. Это полноценная архитектура, в которой многие принципы совпадают с микросервисами. На тему модульного монолита и просто монолита можно почитать про "большой комок грязи" и статьи про модульный монолит - говоря про модульность и определение границ между модулями или микросервисами хорошо бы затронуть тему DDD в частности такую штуку как "ограниченный контекст" - чтобы горизонтально масштабировать монолит надо, чтобы он был stateless, о чем легко можно забыть, когда строишь монолит

[@SeniorPomidorDeveloper]

Согласен. Модульный монолит , я считаю что это просто этап развития инфраструктуры любого монолита. То есть он может до этого этапа и не дойти, по тому что нет нагрузки. Или может быть распилен. Но развиваться он органически будет в таком направлении. И конечно же stateless ! Слава богу что для всяких Django и пр. это уже стало мейнстримом.

[@midgardresident]

@@SeniorPomidorDeveloper можете пояснить про stateless? что значит "монолит должен быть stateless"?

[@SeniorPomidorDeveloper]

Когда не сохраняется информация о состоянии клиента в системе между отдельными запросами. В принципе REST уже должен быть Stateless, это идеология этой архитектуры. Сессии в Django это не Stateless, если мы к примеру в сессии храним какие-то его данные. Ну это немного устаревшая практика на мой взгляд. Все таки каждый запрос должен иметь возможность быть обработанным сам по себе. Раньше бывало что чтобы получить ответ от сервера надо направить несколько запросов, отдельно получить структуру ответа и отдельно данные. Это не Stateless

[@andreyp5764]

Ещё бы добавил что в монолите когда мы вызываем некую функцию (например из ордера дергаем какой-либо функционал продукта) то мы не думаем о том что функция может быть не вызвана. Она будет вызвана в любом случае. В случае сервисов когда мы дергаем его функционал нужно держать в уме что сервис может быть попросту недоступен (выключен/проблема сети и т.д.). Это также нужно обрабатывать: делать запрос пока не выполнится?/вернуть ошибку пользователю?/сохранить куда-то сам запрос и выполнить его позже?

[@SeniorPomidorDeveloper]

Согласен. Не сказал об этом, по тому что по умолчанию думал что все будет работать идеально. ) Ну не то чтобы это большая проблема, мы такие же проблемы решаем когда взаимодействием в внешними сервисами, к которым у нас даже доступа нет, кроме как через публичное api. Но да, это тоже часть оверхеда. Тоже ресурсов требует.

[@alexandr-popov]

Спасибо, хорошее видео Есть пара дополнений по монолиту 1. Базы можно делать отдельные для модулей, если нужно 2. Можно делить по репозиториям модули и импортить только конкретные соседние модули как библиотеки, если необходимо взаимодействие с ними 3. В целом можно настпаивать связность внутри монолита как хочется, например, начать можно с одного репозитория и одной бд, а потом постепенно отделять отдельные модули, если возникает такая необходимость по каким-либо причинам. Так или иначе это позволяет делать максимально независимо все, но при этом оставить тестируемость и не добавлять сетевой оверхед и все сложности с этим связанные

[@SeniorPomidorDeveloper]

Спасибо за комментарий! Да, можно конечно и базы и репозитории делать отдельные на модули. Просто вопрос - зачем. По моему, имеет смысл держать одну реляционную write базу, для удобного проектирования бизнес-логики. И одну NoSQL для скорости, когда связи нас не особо нужны. А именно распиливать код и базу на части, не знаю, если для производительности, то лучше бы другие решения. Для независимости, тоже не очень понимаю что это и зачем коду это. То что сетевое взаимодействие мы уберем, что да, это очень хорошо на мой взгляд. Но вот отсутствие join и трансакций, это не всегда удобно. Но вцелом согласен, если мы все попробовали, и кеширование, и read only базы, и пр, а все ровно не помогает, то наверное лучше несколько баз сделать в одном приложении, и его масштабировать, чем полностью выносить в другой сервис. Надо подумать об этом.

[@alexandr-popov]

​​​@@SeniorPomidorDeveloperя с вами согласен, просто описал возможности, которые покрывают вопросы о огромных командах, которые друг другу мешают при разработке монолита и пр А то многие считают, что минусы единого репозитория и бд решаются только микросервисами

[@aleksey2793]

Но ведь при горизонтальном масштабировании микросервисов мы можем гибко масштабировать их количество. Допустим, узкое место в нашем распределенном решении это Orders. В случае микросервисов мы добавим еще один инстанс Orders. А в случае монолита нам придется добавить еще один инстанс всего приложения, а это дороже в части аренды серверов. Разве нет?

[@SeniorPomidorDeveloper]

А почему дороже? Один репозиторий весит 10Mb , а другой 150Mb. В плане аренды серверов стоит одинаково. В смысле RAM или процессора тоже разница не большая запустим мы скрипт без фреймворка или фаст апи или Джанго . Сами по себе они практически ничего не потребляют, а насколько прожорлив сам код логики, это другой вопрос. Здесь и микро сервис может потреблять много и монолит может мало. От процедуры зависит

[@AKonoplev]

Привет! Я и не знал, что ты видео про программирование делаешь. Классно, что мне ютюб его подсунул! По теме - согласен со всем сказанным, в жизни все так. Единственный момент хотелось бы дополнить или может поспорить по поводу перфоманса. В подавляющем большинстве случаев узким место действительно становится база, но есть небольшой процент случаев когда упираешься в CPU. И вот тут микросервисы позволяют масштабироваться гораздо лучше. Допустим в твоем примере нам нужно высчитывать какую-то хитрую аналитику по всем заказам. Считаем мы ее в реальном времени. И вот пришла черная пятница и количество заказов скакнуло. Вместо того, чтобы наш толстый монолит с функцией аналитики раздеплоивать на кучу машин, мы вытаскиваем функцию аналитики в микросервис и деплоим только его. Требования по памяти и CPU у монолита и микросервиса скорее всего сильно отличаются. Микросервису с аналитикой надо много CPU и мало памяти, монолиту скорее всего наоборот. Поэтому машины нужны разные. Оставлять аналитику в монолите - значит переплачивать за ненужную память, когда нужно много CPU, ведь мы масштабируем маленькую функцию, а все остальное приходится тянуть вместе с ней.

[@SeniorPomidorDeveloper]

Привет Саша! Как удивительно тебя встретить на просторах Ютюба! А казалось еще совсем недавно гуляли в закоулках за Дворцом Культуры, пили пиво и ты мне рассказывал что такое NAT и что должен знать админ , чтобы двигаться по карьере :) Ютюба то тогда не было) И такие как-будто бы незначительные вещи, но сказанные вовремя и вот так по крупицам и сейчас я там где я сейчас. И я доволен. Как твои дела? Ладно, наверное тут не самое лучшее место для таких бесед. ) Если по теме, то да, на счет CPU это хорошее замечание. Действительно, не всегда бутылочное горлышко в базе и не всегда нагрузка на нее. В веб продуктах так чаще, но не всегда. А на счет памяти, тут конечно от платформы зависит (маленький камушек в ваш огород). Вообще конечно если мы можем взять функцию аналитики и вынести в отдельный сервис, это большое счастье. Наверное даже не всем обладателям микросервисов доступно такое. Вообще спасибо за коммент, по делу!

[@mikeofs1304]

стоит добавить, что ридонли подходит в основном для данных некой пользовательской визуализации, и если даннеы взятые от туда использовать для каких то операция которые будут записаны в мастер , то можно получить неконсистентность данных, собственно потому что реляционные отношения напрямую в реальном времени не применяются для реплик, а идут с определенным лагом , хоть и небольшим

[@SeniorPomidorDeveloper]

Ну отставание репликации обычно вообще нулевое, если только база под сильной нагрузкой, то наверное может отставать, но я с таким очень редко встречался. В рамках одной базы это тоже актуально. Взяли данные , пока на основе их что-то вычисляли, они уже в базе поменялись, а в коде старые получается. Тут надо лочить данные и в трансакции их сохранять, конечно тут никакие read only не подходят, надо в одной базе делать.

[@mikeofs1304]

@@SeniorPomidorDeveloper о чем и речь без тразакций никуда. Шардинг спасает

[@АнтонПрядкин]

супер контент

[@Iaxls]

Лайк и небольшая корректировка - монга уже давно полностью отвечает ACID.

[@SeniorPomidorDeveloper]

Это хорошие новости! Но все ровно не совсем полноценная замена реляционной БД. Все эти аггрегации, сотня разных функций и тд. для проектов с множеством логики такое бывает очень надо.

[@У.П.С.0]

Очень интересное видео, теоретически насыщенное. Было бы интересно посмотреть на практику проектирования микросервисов, где наглядно было бы показано как они связаны. Не обязательно со сложной логикой, просто 3 микросервиса, которые связаны так "..." через "..." Ведь предыдущие курсы полностью закоывают вопрос с объяснением того, как работает к примеру гит, celery, redis и прочие сервисы и можно сосредоточиться на конкретных вопросах)

[@SeniorPomidorDeveloper]

Да хотелось бы рассказать в курсе именно про их плюсы, про распределение нагрузки. Не так просто это сделать. Может действительно Azure и Kubernetes использовать.. Что-то мне кажется что не много людей заинтересуется таким (

[@У.П.С.0]

@@SeniorPomidorDeveloper это однозначно найдёт свою аудиторию! Полезность вашего контента беспретендента и она точно не как не кореллирует с просмотрами на ютубе) Да и я сейчас проектирую достаточно обширную платформу для достаточно узкой аудитории и хотелось бы взглянуть на практическое применение возможностей расширения приложения, а если оно ещё и на джанге))) то это однозначно выстрел в сердечко питонистам ищущим пути к самообразованию...

[@SeniorPomidorDeveloper]

Спасибо большое за такой отзыв!

[@SeniorPomidorDeveloper]

@@У.П.С.0 Если руки дойдут то сделаю что-то нибудь такое)

[@glebfadeev9782]

У меня сейчас свой пет проект и его сразу начал делать его в микросервисной архитектуре, в облаке Azure + k8s. Как по мне современные технологии позволяют делегировать задачи роутинга, лоуд балансера, масштабируемость и тд. на клауд Однако использование монолитной архитектуры может привести к ловушке, когда разработчики начинают применять упрощенные решения, которые могут привести к проблемам лишь спустя время, особенно с увеличением нагрузки на систему (банальным пример: inject db context-a просто всюду, которые могут вызвать concurrency exception. конечно это касается ORM ). Кроме того, рефакторинг монолита сложнее, чем микросервиса, для которого достаточно сохранить контракт, а сам сервис можно переписать полностью.

[@SeniorPomidorDeveloper]

Я вообще не против. Облачные решения это круто, я бы конечно делегировал и "роутинга, лоуд балансера, масштабируемость" и тд. Я к тому что инфраструктура должна быть обоснована. Потренироваться на пет-проекте это тоже обоснование. Но если внедрять архитектурное решение, то все-таки , я считаю что отталкиваться мы должны типа от нуля, самой простой схемы, один сервер - одна база. Редко этого достаточно. И тогда архитектурное решение будет определять - предполагаемая нагрузка, тип этой нагрузки, используемые типы и структуры данных, как логически должны быть связаны сущности и тд. И вполне это может привести и к микросервисам, Но ловушка " когда разработчики начинают применять упрощенные решения" , честно не очень понял что это. Что плохого в упрощенных решениях, если они покрывают требования? "concurrency exception." это вообще не относится к монолиту или микросервисам. Это проблема решается довольно простым способом, в том числе и через ORM. По поводу рефакторинга, с одной стороны согласен, один микросервис проще отрефакторить, чем один монолит. Но что проще рефакторить - один репозиторий в 100.000 строк или 10 репозиториев по 10.000 строк каждый? В больших репозиториях мы также хотим "сохранить контракт", а сам код внутри функиции/класса переписать. И также модули обращаются друг к другу через интерфейсы и entry point. Короче я не к тому что одна архитектура плохая, а другая хорошая. И то и другое имеет свои плюсы и издержки, просто в плане рефакторинга, отсутствию связанности и тд. На мой взгляд, это не есть плюсы микросервисов.

[@glebfadeev9782]

@@SeniorPomidorDeveloper Я имел ввиду шорткаты. В монолите можно взять интерфейсе репозитория и засунуть туда, где его быть должны. То есть в монолите возможностей применить антипаттернов больше. А микросервис ограничен своей зоной ответственности. Если смотерть со стороны бизнеса. Мы делаем мвп как получится и на скорую руку, потом монолит будет еле дышать, а микросерисы можно фиксить по мере надобоности. Если какой-то работает слишком долго, то точечно добавим мощности или его перепишем. Монолит чаще требует комплексного подхода

[@SeniorPomidorDeveloper]

Моя идея как раз в том что не нужно рассматривать микрскрвисы как лекарство от антипаттернов. (Их где угодно можно наделать полно)Не нужно его рассматривать как увеличение производства (если монолит еле дышит то давайте его попилим) . Вместо этого я считаю что надо повышать производительность горизонтальным масштабированием - первым делом. И для кода конечно ревью , юнит тесты и прочее. В любом случае этих всех вещей не избежать. А если их фиксить при помощи микросервисов то только проблем себе создаем на ровном месте, а профита имеем мало . Это специфическая архитектура, которая актуальна в больших проектах где нужно экономить деньги и грамотно распределять мощности .

[@dmitrymikhailovnicepianomu8688]

Спасибо. Это видео помогло мне определиться с приоритетом на дальнейшее обучение. Я работаю fullstack react + django в небольшой компании. Хочу расти дальше. Последний год я много изучал фронтенд: верстать хорошо научился, по реакту неплохо прокачался. Но вот как-то обыденно для меня это все. А вот когда я ковыряюсь с django : в shell пишу .explain(analyze=True) и изучаю index scan или seq scan и за сколько м/с что нашлось, то это действительно меня увлекает. Из оптимизации бд я пользовался только дополнительными индексами, в том числе составными и кэшированием. Данное видео открыло для меня новые горизонты и я определился, что более профессионально я хочу развиваться в бэкенде. Спасибо за отличное видео!

[@SeniorPomidorDeveloper]

Даа, архитектура и производительность это большая и очень интересная тема.Если в эту сторону сторону хорошо копать то можно выгодно выглядеть на собеседованиях. И вообще эти знания ценные, по тому что этому особо нигде не учат. Есть теория. Но все ровно каждая инфраструктура выглядит по своему, имеет свои решения.

[@СтаниславРассказов-ы4м]

Мне кажется, что плюсы микросервисов раскрыты не в полной мере . В целом вывод из видео, что производительность плюс минус такая же. Как и расход ресурсов. Но вот совсем по другому микросервисов начинают играть, когда мы подходим к вопросу надёжности всей системы, отказоустойчивости, кластеризации, географического распределения. Дальше вопрос эксплуатации, т.е. обслуживания и обновления. Обновить модуль на монолите - это зачастую вопрос обновления всего монолита, проблемы отката обновления, совместимости всех модулей и библиотек. Эти сложности приводят к удлинению времени между выходом версий. Это плохо скажется на закрытии багов. Дальше вопрос распространения, если это проект, который имеет много инсталляций. И обслуживание всех инсталляций. Ещё вопрос тестирования разработки, т.е. качество продукта. Быстрее деплоить - быстрее тестировать и т.п. Зачастую вопрос качества кода и скорости исправления багов, доставки исправлений без перерыва работы сервиса в разы ценнее у конечного потребителя, чем не глобальные потери производительности. Я не адепт микросервисов, но указанные выше нюансы неразрывны с итоговой оценкой.

[@alexandr-popov]

1. Не понимаю что не так с надёжностью, геораспределением и кластеризацией монолита - деплойте столько реплик аппки сколько нужно и где нужно 2. Все проблемы эксплуатации точно такие же как и в микросервисах, если у вас модули нормально отделены друг от друга, то все решается ровно так же (проблемы совместимости вам на билде уже стрельнут тут, а при микросервисах скорее всего уже после выкатки и мб даже будет необратимо подпорчено что-то), а библиотеки можно использовать разные и на уровне каждого модуля 3. Что вы имеете в виду под инсталляциями не понял 4. Тестирование как раз в монолите самое нормальное, все можно поймать на уровне Билда, а то и раньше вам ide подскажет. В случае микросервисов начинается лабуда с моками, контрактами/клиентами (которые тоже надо в актуальном виде держать) - это муть, а не скорость разработки, так ещё и если что-то пойдет не так зачастую узнается это после релиза и грозит последствиями в виде сломанных данных

[@nononoplzno]

Отказоустойчивость, кластеризация, географическое распределение - решается на монолите плюс-минус так же: масштабируй и балансируй в горизонт сколько угодно, как угодно и где угодно. Обновление да - МС удобнее, быстрее, "тише". Но про билд и деплой было сказано. По поводу "быстрее тестировать и доставлять". Т.к. один МС быстрее исправить/доработать, протестировать и вынести, чем тот же кусок в монолите - сферически да. Но в жизни, если все очень сильно связано и с исправлением/доработками одного МС могут понадобиться исправления/доработки связанных по бизнес-процессу других МС, то тут уже не всегда все так шоколадно. Я тоже не адепт МС, но чуть их "залошили" как будто, да.

[@SeniorPomidorDeveloper]

Да, я тоже думаю про "надёжности всей системы, отказоустойчивости, кластеризации, географического распределения", в случае модульного монолита , мы можем для них использовать те же решения что использовали бы для микросервисов. По поводу "выходов версий" и "инсталляций" не очень понял. Это имеет какое-то отношение к тому как компоненты взаимодействуют внутри инфраструктуры? По api или по вызову функций. Доставка исправлений без перерыва работы - ну это же по сути решается скоростью перегрузки веб-сервера. То есть доли секунды обычно. Быстрее деплоить - быстрее тестировать - это правда. В ситуации с отдельным микросервисом - да. Но опять же возникают интеграционные ошибки , которые тоже надо тестировать и отлавливать. Могут и не возникнуть, то есть в чем то быстрее, но при этом опаснее. Обслуживания и обновления - да, мы можем их отдельно обновлять, что конечно плюс. Мы вот в недавно нашем проекте питон обновляли, в нескольких сервисах уже обновили, а в нескольких еще не успели, никак руки не доходят ) Был бы целиком монолит мы бы сразу везде обновили, хоть и времени бы ушло больше. Не знаю, такое ощущение что тут вопрос - "вам торт целиком или по кусочкам?" . Если уж есть разница то она в производительности и бутылочных горлышках. И можно это наращивать через микросервисы , но вопрос какой ценой.

[@N5O1]

15:44 но для микросервисов можно использовать монореп, а иногда даже лучше иметь именно монорепозиторий, чем несколько отдельно

[@andrewskripko2311]

Спасибо за нагляный и достаточно объективный обзор! только не пойму, почему это монолит не может иметь несколько БД? вполне себе может.

[@SeniorPomidorDeveloper]

Может и это очень даже используется, если к примеру одна база реляционная, другая Mongo, третья типа redis для временных записей и тд. А если подключать к монолиту несколько Postgres , к примеру, то тогда мы как бы собираем все минусы от микросервисов - отсутствие трансакций , джойнов , а вот плюсы микросервисов не приобретаем . То есть большого смысла тут нет.

[@andrewskripko2311]

@@SeniorPomidorDeveloper но если смоделировать ситуацию что у нас есть комментарии к заказу(Order), их же можно вынести в соседнюю базу того же постгрес и тогда при запросе к ручке OrderDetail по id мы можем параллельно сделать запрос к 2ум базам - получается тот же самый плюс как и в микросервисах? Или я ошибаюсь? С записью так-же поидее, писать комменты в БД - не занимаем времени у основной бд.

[@SeniorPomidorDeveloper]

@andrewskripko2311 да, но мы не сможем связывать базы по foreign key и тд. Минус этот остается . А почему бы тогда не вынести в другой сервис эту логику? Два сервера + две базы лучше чем один сервер + две базы

[@andrewskripko2311]

@@SeniorPomidorDeveloper вообще моя специализация фронт, бэк умею, но не эксперт) а разве в микросервисах при таком же устройстве на разных БД, будет работать foreign key? Как вы и говорили, мы не можем там юзать джоины. Как и в моем примере, придётся объединить ответы руками. А по поводу выделения в отдельный сервис (микро?) это тоже tradeoff, работать в одном репо проще и быстрее. На сколько я помню из плюсов которые мы можем получить при отделении - меньше памяти жрем при запуске ещё одного инстанса и можем отделить доступы для работников.

[@SeniorPomidorDeveloper]

@andrewskripko2311 да, все так. По этому и не делают в монолите несколько баз чтобы оставались трансакции и джойны и связи . Это удобно. Мы можем сделать хоть 10 read баз и одну на write. А если их несколько то проще уже и сервис другой сделать, больше будет выгоды. Один репозиторий это конечно удобно, но это не какой-то решающий плюс.

[@Georgii1212]

Zdravstvuite ! Raznica SOA vs mikroservisi ?

[@SeniorPomidorDeveloper]

Насколько я помню, ключевая разница это что SOA используют систему шину для сообщений , а микросервисы полагаются на децентрализованное взаимодействие.

[@artemlaravel8769]

а теперь посомтреть бы как это напрактике делать :D

[@SeniorPomidorDeveloper]

хех

[@alexander.dontsov]

Хорошо посмотреть на разные подходы к архитектуре, но, на мой взгляд, не совсем релевантно их сравнивать в вакууме. Когда организация/компания развивается, растет количество команд, нужно делить зоны ответственности , соответственно архитектура требует гибкости. Поэтому монолиты делятся на микросервисы со временем. Все зависит от конкретного проекта, тз, человеческих ресурсов и бюджета. Когда time to market стоит на первом месте, то вряд ли кто-то в здравом уме будет пилить микросервисы. Если говорить про нюансы, то в микроскросервисах есть ещё сложность с data consistency. Что если нужна запись в двух базах, принадлежащих разным микросервисам, когда один записал, а второй не смог. Гораздо проще это делать в одном app с одной базой.

[@SeniorPomidorDeveloper]

Согласен. Это все очень органично развивается и это правильно. Но понятие «архитектура требует гибкости» описывает скорее субъективное ощущение архитектора, столкнувшегося с кучей неумелых рук, чем какое-то конкретное состояние кода. Я в этом видео и пытаюсь докопаться до того , как и что и зачем менять и причем тут микросервисы и в чем они помогут , а в чем нет.

[@PRIVEDTMEDVED55]

Очень интересное видео, спасибо. Есть вопрос: Сервисы могут обращаются напрямую друг к другу по внутреннему апи или все же должны делать это тоже через gateway?

[@SeniorPomidorDeveloper]

Спасибо! Они могут общаться напрямую либо через очередь сообщений. API Gateway это скорее для взаимодействие с "внешним миром"

[@ВладиславДрагушин]

компоненты - которые возникает из огня, просто ОГНИЩЕ

[@SeniorPomidorDeveloper]

😈

[@ДаниилСоловьев-э6ш]

Классное видео! А что за программа в которой презентацию делаешь?

[@SeniorPomidorDeveloper]

Спасибо! Это Keynote на Маке.

[@Des1gnate]

Apache spark, hive должен решить проблему с бд, разве нет ?

[@SeniorPomidorDeveloper]

Как вариант. Но внедрение и обслуживание такой системы будет явно сложнее, чем монилит с парой read-only или микросервисы. Для огромных массивов данных может spark + hive это будет вообще лучший вариант, но мы тут рассматриваем обычные приложения.

[@Sosed00]

Если между микросервисами появляется хоть малейшая зависимость, то это у же не сервис. Будет крутиться без толку, пока зависимости не подтянутся.

[@SeniorPomidorDeveloper]

Свободу микросервисам!

[@TheEagleDesert]

Спасибо! А под worker что имеется ввиду? Потоки? Несколько инстансов нашего App?

[@SeniorPomidorDeveloper]

Инстансы аппа или инстансы микросервиса . Бывает что там совсем независимый код. Идея в том что он выполняется отложено, относительно веб запроса. К примеру, Celery worker

[@swaytornado8327]

привет. мне нравится твой канал и твои видео. если можно, подскажи мне пожалуйста. я хотел бы написать интернет-магазин. ранее такого не делал. с чего мне начать, что будет верным шагом. спасибо.

[@SeniorPomidorDeveloper]

Можно начать с моих предыдущих курсов. На мой взгляд, интернет магазин это очень крупный проект для того чтобы с него начинать. Лучше с чего-то более простого. Постепенно прийти к магазину. Если он нужен срочно , то лучше скачать движок типа magenta, или на Shopify зарегаться и поработать с платформой.

[@КристинаКостина-ь8р]

Ебейшее видео, продолжай также

[@SeniorPomidorDeveloper]

🤣 спасибо

[@dos6920]

Есть ли смысл создавать несколько баз данных в одном истансе postgres? Это будет считаться как один постгрес с точки зрения производительности?

[@SeniorPomidorDeveloper]

Для одного приложения делать несколько баз в одном postgres наверное не имеет смысла. Мы все ровно один и те же ресурсы железа потребляем. Если у нас два сайта и оба не нагруженные то можно в одном postgres для каждого создать свою базу. Или использовать облачное решение, что чаще всего именно это внутри и делает.

[@РоманПермяков-л2ь]

Производительность зависит не только от железа. Но и от количества данных (тысячи у вас строк или десятки миллионов) - будет влиять на чтение. А ещё от организации данных (внешние ключи, индексы) - будет влиять на запись. В видео говорится про шардирование, цель которого, насколько я понимаю, как раз в том, чтобы сократить количество данных в таблицах. Ещё слышал про кейсы, когда в одной БД выделяют разные схемы для хранения данных разных клиентов (такое проявление мультитенантности), что позволяет уменьшить количество данных в таблицах (просто размазать данные по нескольким таблицам). Так что, если цель ускорить манипуляции с данными внутри БД, то есть способы сделать внутри одного сервера и одной БД.

[@SeniorPomidorDeveloper]

@user-gd5mw6dz5o Согласен что от количества и состава данных зависит. Я думаю что нет смысла в одной БД размазывать по таблицам, если мы говорим про производительность. Ведь у базы данных есть максимальное количество коннектов, есть опять таки процессор, на который очередь при нагрузке и тд. За это все будут как бы конкурировать таблицы. Если уж мы можем таблицу порезать то лучше уж на другое железо, тогда прирост будет очевиден. В случае когда данных много это не влияет на производительность вцелом, но влияет на скорость поиска, на его ресурсопотребление получается . Если отделение данных в другую таблицу это исключительно решение для поиска , возможно иногда бывает оправдано, не уверен. Но для начала всегда стоит использовать индексы , и elasticseaech , потом уже такие радикальные меры внедрять, если совсем никак .

[@РоманПермяков-л2ь]

@@SeniorPomidorDeveloper Эластик пока не пробовал. На работе есть кейс, чтения при котором индекс использовать невозможно и приходится читать всю таблицу целиком. Здесь производительность чтения напрямую зависит от количества данных. Для решения планируем завести денормализованные таблицы специально для чтения. При операциях записи появляется небольшой оверхед на подготовку и запись данных для чтения, но у нас отношение чтения к записи сильно в пользу чтения, поэтому это целесообразно. В качестве хранилища данных для чтения, наверное было бы круто взять mongo, но у нас скромная инфра, поэтому собираемся сделать внутри SQL.

[@SeniorPomidorDeveloper]

А проблема именно в скорости чтения? Или в поиска? Я думаю что тут можно было бы немного разные решения использовать. Денормализация и специальные развернуты данные , тоже тема интересная, хотя далеко не самый простой вариант.

[@nikolaymatveychuk6145]

Ну да. И делить код на файлы люди начали только потому, что это на производительность кода положительно повлияло... и ООП придумали, потому что оно производительность кода увеличивает... и микросервисы - это только ради производительности кода... )) Требование о том, что микросервисы не могут работать на одном сервере обращаясь в одну и ту же БД улыбнуло. Вы уверены, что Вы об архитектуре говорите? Потому что похоже, что Вы говорите о конкретной реализации конкретного кода, которая никак с архитектурой не связана. Микросервисы гипотетически могли бы даже одни и те же таблицы писать и читать, главное чтобы один из них не лез к данным другого (хотя на практике не вижу в этом смысла. но в теории вот это допустимо). Идея микросервисов в том, что нет никакого общего управляющего кода, который устанавливает требования к вызываемому коду типа "у тебя должны быть вот такие и такие методы, чтобы я мог их вызвать, и будь добр мне прокинуть конфиг, чтобы я знал что ты умеешь, я буду это контролировать на своей стороне, и вообще мне нужно будет создать экземпляр твоего основного класса, чтобы к нему обратиться, потому укажи как тебя сконфигурировать". Когда что-то подобное возникает - это монолит. А идея микросервисов, что требования устанавливаются только на протокол API вызовов, и ни один из микросервисов не знает ничего о внутренней структуре любого другого, он знает только спецификацию АПИ других микросервисов, с которыми связана его работа. Это позволяет упростить поддержку кода так как в идеале степень зацепления сводится к нулю вплоть до того, что один микросервис может быть написан на c++, другой на php, один в функциональном стиле, другой в ООП и т.д. Они не обязаны иметь вообще ничего общего, кроме, собственно, протокола взаимодействия, и то даже с протоколом на самом деле один микросервис может работать по http, а другой через unix сокеты по самописному протоколу, а третий и вовсе выискивая в нужной директории новые файлы и как-то их обрабатывая

[@SeniorPomidorDeveloper]

А я утверждаю что смысл любой архитектуры это в первую очередь производительность. Нет смысла ничего городить ради архитектуры кода. Огромные издержки - выгода сомнительная. Архитектура кода вообще может быть какой угодно, можно модули монолита писать без этих тесных связей, чтобы они друг с другом общались через интерфейсы или очереди. И монолит это не про присутствие какого-то "общего управляющего кода, ". Откуда бы ему там взяться и зачем он там нужен? Микросервисы конечно могут обращаться в одну базу, тогда получается что мы оставляем их минусы - оверхед, множество слоев, опять же отсутствие join и транскакций. А вот самый очевидный плюс - это расширение бутылочного горлышка базы , мы как раз его исключаем. Никакой пользы кроме вреда. А про "степень зацепления" - то , что я хотел сказать в видео, что она не возникает от решения неумелого разработчика. А это есть требование бизнес логики, и как ты сервисы не изолируй, эта "степень зацепления" не исчезает, а только обрастает большими слоями. Если какие-то вещи логически связаны, они и останутся связаны, через прямой вызов или через API. По поводу разных языков и протоколов взаимодействия. Если есть такая необходимость, конечно единственный вариант это сделать отдельный сервис. Я вообще ничего не имею против сервисов и микросервисов, все что хочу сказать что это должно быть обосновано и стремление к меньшей связанности, для меня сомнительное обоснование.

[@nikolaymatveychuk6145]

@@SeniorPomidorDeveloper ​Стремление к меньшему зацеплению (coupling) кода - это хорошо. Об этом можно почитать даже у того же Макконнелла, который внятно это объясняет в Совершенном коде. Идея такая общая: чем меньше зацепление - тем меньше нужно менять уже существующего при изменении требований бизнеса, и тем меньше вероятности уронить отправку писем исправляя расчёт скидки, или получить другое настолько же неожиданное поведение. Степень зацепления зависит от разработчика и архитектуры. В монолите почти невозможно избежать высокого зацепления кода. Именно потому большие проекты очень редко бывают монолитами, а возможно и никогда. Потому что если в проекте 10 000 000 строк, то очень хотелось бы понимать, что вот эти 10 000 строк замкнуты в себе, и их изменение ни на что не повлияет, вот эти 100 могут повлиять вот на эти куски кода, а за попытку изменения этих 10 строк нужно немедленно уволить с пометкой "неспособен быть программистом", потому что потенциально может уронить половину системы. Отсутствие join при работе с БД не является проблемой. Я периодически сам от них отказываюсь, потому что когда меня только познакомили ORM поставляющей связывание таблиц, я был в восторге и совал их повсюду. Потом пришло понимание, что если так делать, то иногда возникают ситуации, когда правишь поля системы новостей, а падает система заказов или возникают ошибки при редактировании пользователей :) Должны быть домены, внутри которых связи разрешены, но должны быть и линии разделения, через которые лучше прокинуть список id, а на той стороне код примет их и сделает что нужно: сам прочитает записи, обработает и вернёт, что от него требуется. Управляющий код в модульных системах - это неизбежность. Если он пропадает, мы получаем микросервисы. Они могут крутиться на одном сервере и смотреть в одну базу, но по сути они будут микросервисами. Возможно реализованными с косяками (например читающими данные друг друга напрямую), но это опять же косяк уровня протокола общения, а сама архитектура микросервисная.

[@SeniorPomidorDeveloper]

@@nikolaymatveychuk6145 Ну я согласен, и про разделение ответственности, и про Домены, и что coupling это не оч хорошо для кода. Но как-будто инструменты для их достижения не те. Но вы как-будто утверждаете что микросервисы нужны чтобы "не выстрелить себе в ногу". А может просто не стрелять себе в ногу? ) Чтобы было меньше шансов "уронить половину системы." , случайно что-то там изменив. Даже что надо отказаться от join, чтобы не уронить систему заказов, редактируя новости. Это вообще не понятно, как join может что-то уронить? Такое ощущение что вам не хватает хорошего покрытия юнит-тестами, чтобы эти проблемы не возникали. Что нужно пробросить список id, а потом повторно доставать из базы, чтобы соблюдать линии разделения. По моему, мы так только искусственные трудности создаем, ради идеологии о "хорошей архитектуре". Вообщем я не согласен ) Я как-бы не против микросервисов, я скорее против такого их обоснования.

[@nikolaymatveychuk6145]

@@SeniorPomidorDeveloper разумеется микросервисы не являются панацеей. Это не решение вида "ну у меня микросервисы, мне это не грозит". Просто они об этом же, как и многие другие архитектурные подходы (я спорю больше не о микросервисах, а об идее, что вся архитектура - это ради производительности кода... микросервисы являются просто удобным примером, так как Вы про них заговорили). Они предназначены, для логического разделения кода. У меня нет никаких особых чувств к микросервисам, я сам нередко монолиты пишу, но как Вы сами говорили, надо понимать что и когда нужно делать. Я считаю вредным советом идею, что заниматься архитектурой нужно только если производительность проседает. Насчёт юнит-тестов - это уже детали отдельной реализации, и да, бывают случаи, когда смотришь на возникшие ошибки и понимаешь, что если бы тут нормально тесты были написаны, то всё было бы ок. Кажется Дядюшка Боб писал (может не он, не помню точно), что тесты должны быть последним рубежом, а на самом деле программист должен понимать, что он делает и к какому результату это приведёт. Представьте ситуацию, когда система настолько сложная, что модуль новостей пилит одна команда, а модуль заказов другая, и при изменении модуля заказов валятся новости. Ну можно конечно срочно начать бить в колокола и требовать у тех ребят менять свой код, или править свой в попытке удалить существующую связь (если она оказалась необоснованной), но ведь было бы лучше, если бы этой связи не было изначально :) Так вот микросервисы позволяют такое зацепление кода исключить в большинстве случаев, просто по самой сути архитектуры.

[@SeniorPomidorDeveloper]

@@nikolaymatveychuk6145 Ну есть архитектура кода, а есть архитектура инфраструктуры. Когда я говорю что архитектура нужна для производительности, я скорее имею ввиду второе. А если мы боремся со связанностью, это скорее про первое. Микросервисы они так или иначе присутствуют и в той и в другой. По поводу связей, не очень понимаю как она может возникнуть "необоснованная". Если есть значит нужна. Другое дело что бывает что одна команда выносит какие-то entry point для обращению к своему модулю, а кто-то может их игнорировать и обратиться в обход. Лично я бы для такой проблемы, опять таки, использовал юнит-тесты, или использовал бы linter со своими проверками, код ревью. Но только для этого делать сервис, наверное еще не достаточно этого. Хотя есть подход что на что угодно делать сервис, я не против, только это дорого обойдется. В плане человека-часов, в первую очередь. По поводу юнит-тестов, я их фанат!) В более-менее больших проектах вообще без них не выжить. Они вцелом не противоречат тому чтобы программист сам понимал что он делает и зачем. Даже помогают. Очень часто я на ревью просто прошу добавить пару тестов, а потом смотрю коммиты, а разработчик кроме тестов там еще и код подправил немного. Ну думаю, значит не зря)

[@justinnl4332]

100 докер контейнеров мой проц умрет💀💀

[@SeniorPomidorDeveloper]

🤣 точно

[@SvyatoyVitaliy]

Обидно чувствовать себя слишком тупым даже для туториала =.= p.s. Дата инженер, который кроме SQL и PL/SQL в этой жизни ничего не видел много лет)

[@SeniorPomidorDeveloper]

Ничего. Если немного поработать с туториалом веб приложений то будет более понятно. Вообще свой курс рекомендую, который оранжевый, там и про кеширование и задачи и тд.

[@steel1004]

Микросервисы проще делегировать разным командам или отдельным разработчикам и они не будут мешать друг другу.

[@SeniorPomidorDeveloper]

Да это понятно. Но причина ли это для того чтобы проектировать такую инфраструктуру с такими сложным связями?

[@steel1004]

@@SeniorPomidorDeveloper конечно Чем больше человек на квадратный сантиметр кода тем хуже Будут 70% времени мердж конфликты решать Если команда большая то микросервисная разработка будет быстрее нежели если вся команда будет в одном монолите друг другу мешать

[@SeniorPomidorDeveloper]

@steel1004 В монолите каждый разработчик работает со своим модулем. Мердж конфликты это в принципе редкость, если реально одну функцию несколько человек изменили , такое только по недоразумению бывает. А в микросервисах 70% времени может уходить на описание взаимодействий между сервисами, а не на логику проекта. Опять же, я не к тому что микросервисы это плохо. Просто каждому проекту своя архитектура и микросервисы это большие издержки , которые далеко не всегда будут оправданы

[@steel1004]

@@SeniorPomidorDeveloper в монолите каждый человек работает со своим моделулем... Если было так все просто. Этот модуль регистрируется в общем месте 1 место конфликта этому модулю может потребоваться извне что-то абсолютно новое что надо будет проводить по всей апп чтобы и другие модули могли получить доступ - 2 место конфликта что-то поменять в слое данных в рамках своего модуля и можно разрушить соседний модуль сбора аналитики чистыми sql по твоим данным 3 источник конфликтов, потом твой модуль могут использовать соседние модули и когда меняются контракты в твоём модуле со едете модули ломаются - 4 и тд

[@SeniorPomidorDeveloper]

@steel1004 про какой-то плохой монолит вы рассказываете. Я с такими предпочитаю дело не иметь)