Здравствуйте! В vs code возможно нет такой функции. Может она и не нужна. Мы в любом случае запускаем приложение из консоли. IDE по сути нужен только чтобы код редактировать. Можно просто идти дальше. Единственное, наверное придется руками импорты в питон файлах прописывать . Эта функция позволяет их импортировать автоматически, чем я пользуюсь в курсе постоянно
Ну курс админский , по этому тренируем админские скилы. Вообще это полезная штука, если знаешь хотя бы один консольный редактор кода, то в любой ситуации не окажешься беспомощным. Даже если сервер перестал отвечать по сети и надо подойти и прямо в него клавиатуру подключить.
Спасибо, Алексей) Как всегда интересно и познавательно 👍 Никогда не вникал в микросервисную архитектуру, но теперь имею представление и различия между монолитом и микросервисами)
Инстансы аппа или инстансы микросервиса . Бывает что там совсем независимый код. Идея в том что он выполняется отложено, относительно веб запроса. К примеру, Celery worker
Здравствуйте сеньор, хотел бы узнать ваше мнение , мне говорили что в современной разработке используют DRF нежели просто Django с шаблонами и формами и надо изучать DRF чем изучать шаблоны и формы и что с ними связано , как вы думаете как лучше поступить?
Здравствуйте! Конечно DRF! У меня целый курс посвящен их сравнению (нативного Django и DRF). Я там делаю веб страницы обоими способами и их сравниваю . Это самые первые видео на канале , они с белой обложкой
@@SeniorPomidorDeveloper конечно Чем больше человек на квадратный сантиметр кода тем хуже Будут 70% времени мердж конфликты решать Если команда большая то микросервисная разработка будет быстрее нежели если вся команда будет в одном монолите друг другу мешать
@steel1004 В монолите каждый разработчик работает со своим модулем. Мердж конфликты это в принципе редкость, если реально одну функцию несколько человек изменили , такое только по недоразумению бывает. А в микросервисах 70% времени может уходить на описание взаимодействий между сервисами, а не на логику проекта. Опять же, я не к тому что микросервисы это плохо. Просто каждому проекту своя архитектура и микросервисы это большие издержки , которые далеко не всегда будут оправданы
@@SeniorPomidorDeveloper в монолите каждый человек работает со своим моделулем... Если было так все просто. Этот модуль регистрируется в общем месте 1 место конфликта этому модулю может потребоваться извне что-то абсолютно новое что надо будет проводить по всей апп чтобы и другие модули могли получить доступ - 2 место конфликта что-то поменять в слое данных в рамках своего модуля и можно разрушить соседний модуль сбора аналитики чистыми sql по твоим данным 3 источник конфликтов, потом твой модуль могут использовать соседние модули и когда меняются контракты в твоём модуле со едете модули ломаются - 4 и тд
Офигенный формат. Это уникальный материал в ру сегменте. Я так понимаю, что на реальной работе большую часть времени и занимает рефакторинг, а не написание с 0. Интересно посмотреть как Вы разбираете незнакомую для вас бизнес логику.
Спасибо что отреагировали на самое менее просматриваемое видео! Ну у меня более лидовская позиция, по этому чаще приходится заниматься рефакторингом, оптимизацией, всякой инфраструктурой . У мидлов это больше конечно разработки чем рефакторинга.
@@SeniorPomidorDeveloper Я сел учиться выносить бизнес логику пет проекта в отдельный слой и вспомнил, что у Вас есть ролики с рефакторингом проектов =). Есть буквально 4-5 каналов в RU сегменте (это вместе с вашим) с действительно полезной информацией о python/django, по которой можно учиться. Все эти каналы объединяет то, что очень мало просмотров и подписок. Авторов это демотивирует, но с развивающим контентом всегда так. Просмотры дают ролики на темы: "как выучить python за час в 2024 году", "как вкатиться за 3 месяца на позицию мидла" и так далее по кликбейтному списку. Люди не хотят учиться, хотят развлекаться. А если и учиться, то чтобы было не сложно и сразу результат. Обещают же на каждом столбе, что программистом может стать любой за 6-9-12 месяцев, только курс пройди =)). Я дал себе слово, что когда мой код начнет приносить доход, то буду снимать видео на те темы которые мало раскрыты или не раскрыты вовсе, чтобы самоучкам было легче. Невзирая на количество просмотров, т.к. исход затеи мне примерно понятен, но нужно вернуть туда, откуда взял =). Огромная Вам благодарность за ваши труды. Удачи, просмотров, подписок.
Это хорошие новости! Но все ровно не совсем полноценная замена реляционной БД. Все эти аггрегации, сотня разных функций и тд. для проектов с множеством логики такое бывает очень надо.
Хорошо посмотреть на разные подходы к архитектуре, но, на мой взгляд, не совсем релевантно их сравнивать в вакууме. Когда организация/компания развивается, растет количество команд, нужно делить зоны ответственности , соответственно архитектура требует гибкости. Поэтому монолиты делятся на микросервисы со временем. Все зависит от конкретного проекта, тз, человеческих ресурсов и бюджета. Когда time to market стоит на первом месте, то вряд ли кто-то в здравом уме будет пилить микросервисы. Если говорить про нюансы, то в микроскросервисах есть ещё сложность с data consistency. Что если нужна запись в двух базах, принадлежащих разным микросервисам, когда один записал, а второй не смог. Гораздо проще это делать в одном app с одной базой.
Согласен. Это все очень органично развивается и это правильно. Но понятие «архитектура требует гибкости» описывает скорее субъективное ощущение архитектора, столкнувшегося с кучей неумелых рук, чем какое-то конкретное состояние кода. Я в этом видео и пытаюсь докопаться до того , как и что и зачем менять и причем тут микросервисы и в чем они помогут , а в чем нет.
Для одного приложения делать несколько баз в одном postgres наверное не имеет смысла. Мы все ровно один и те же ресурсы железа потребляем. Если у нас два сайта и оба не нагруженные то можно в одном postgres для каждого создать свою базу. Или использовать облачное решение, что чаще всего именно это внутри и делает.
стоит добавить, что ридонли подходит в основном для данных некой пользовательской визуализации, и если даннеы взятые от туда использовать для каких то операция которые будут записаны в мастер , то можно получить неконсистентность данных, собственно потому что реляционные отношения напрямую в реальном времени не применяются для реплик, а идут с определенным лагом , хоть и небольшим
Ну отставание репликации обычно вообще нулевое, если только база под сильной нагрузкой, то наверное может отставать, но я с таким очень редко встречался. В рамках одной базы это тоже актуально. Взяли данные , пока на основе их что-то вычисляли, они уже в базе поменялись, а в коде старые получается. Тут надо лочить данные и в трансакции их сохранять, конечно тут никакие read only не подходят, надо в одной базе делать.
У меня сейчас свой пет проект и его сразу начал делать его в микросервисной архитектуре, в облаке Azure + k8s. Как по мне современные технологии позволяют делегировать задачи роутинга, лоуд балансера, масштабируемость и тд. на клауд Однако использование монолитной архитектуры может привести к ловушке, когда разработчики начинают применять упрощенные решения, которые могут привести к проблемам лишь спустя время, особенно с увеличением нагрузки на систему (банальным пример: inject db context-a просто всюду, которые могут вызвать concurrency exception. конечно это касается ORM ). Кроме того, рефакторинг монолита сложнее, чем микросервиса, для которого достаточно сохранить контракт, а сам сервис можно переписать полностью.
Я вообще не против. Облачные решения это круто, я бы конечно делегировал и "роутинга, лоуд балансера, масштабируемость" и тд. Я к тому что инфраструктура должна быть обоснована. Потренироваться на пет-проекте это тоже обоснование. Но если внедрять архитектурное решение, то все-таки , я считаю что отталкиваться мы должны типа от нуля, самой простой схемы, один сервер - одна база. Редко этого достаточно. И тогда архитектурное решение будет определять - предполагаемая нагрузка, тип этой нагрузки, используемые типы и структуры данных, как логически должны быть связаны сущности и тд. И вполне это может привести и к микросервисам, Но ловушка " когда разработчики начинают применять упрощенные решения" , честно не очень понял что это. Что плохого в упрощенных решениях, если они покрывают требования? "concurrency exception." это вообще не относится к монолиту или микросервисам. Это проблема решается довольно простым способом, в том числе и через ORM. По поводу рефакторинга, с одной стороны согласен, один микросервис проще отрефакторить, чем один монолит. Но что проще рефакторить - один репозиторий в 100.000 строк или 10 репозиториев по 10.000 строк каждый? В больших репозиториях мы также хотим "сохранить контракт", а сам код внутри функиции/класса переписать. И также модули обращаются друг к другу через интерфейсы и entry point. Короче я не к тому что одна архитектура плохая, а другая хорошая. И то и другое имеет свои плюсы и издержки, просто в плане рефакторинга, отсутствию связанности и тд. На мой взгляд, это не есть плюсы микросервисов.
@@SeniorPomidorDeveloper Я имел ввиду шорткаты. В монолите можно взять интерфейсе репозитория и засунуть туда, где его быть должны. То есть в монолите возможностей применить антипаттернов больше. А микросервис ограничен своей зоной ответственности. Если смотерть со стороны бизнеса. Мы делаем мвп как получится и на скорую руку, потом монолит будет еле дышать, а микросерисы можно фиксить по мере надобоности. Если какой-то работает слишком долго, то точечно добавим мощности или его перепишем. Монолит чаще требует комплексного подхода
Моя идея как раз в том что не нужно рассматривать микрскрвисы как лекарство от антипаттернов. (Их где угодно можно наделать полно)Не нужно его рассматривать как увеличение производства (если монолит еле дышит то давайте его попилим) . Вместо этого я считаю что надо повышать производительность горизонтальным масштабированием - первым делом. И для кода конечно ревью , юнит тесты и прочее. В любом случае этих всех вещей не избежать. А если их фиксить при помощи микросервисов то только проблем себе создаем на ровном месте, а профита имеем мало . Это специфическая архитектура, которая актуальна в больших проектах где нужно экономить деньги и грамотно распределять мощности .
Вот потому и не позвонили, видимо :) Кроме того, что код должен работать, он ещё и должен быть адекватно структурирован. Ну правда, у Вас isFirst определяется в дереве наследования не на том же уровне, на котором возникает сам класс First :) То же самое и с Second. Но методы isFirst и isSecond нельзя реализовывать в самих классах First и Second, так как это породит сильное зацепление двух классов, которые знать друг о друге ничего не должны. Однако принципы SOLID запрещают определить поведение в Parent, а потом First и Second сделать его потомками и там изменить поведение. Из этого делаем вывод, что Parent, First и Second не связаны родством, а являются классами одного уровня абстракции. При этом First и Second - это классы-состояния, а Parent поставляет интерфейс определения этого состояния. Потому решено: A и B должны иметь множественное наследование Parent+First и Parent+Second, при этом Parent должен поставлять методы isFirst и isSecond, которые проверяют self на isinstance соответствующего класса. Возможно авторы теста предполагали что-то другое, но я только такую структуру вижу адекватной, без лишних связей и с возможностью расширения.
Ну да. И делить код на файлы люди начали только потому, что это на производительность кода положительно повлияло... и ООП придумали, потому что оно производительность кода увеличивает... и микросервисы - это только ради производительности кода... )) Требование о том, что микросервисы не могут работать на одном сервере обращаясь в одну и ту же БД улыбнуло. Вы уверены, что Вы об архитектуре говорите? Потому что похоже, что Вы говорите о конкретной реализации конкретного кода, которая никак с архитектурой не связана. Микросервисы гипотетически могли бы даже одни и те же таблицы писать и читать, главное чтобы один из них не лез к данным другого (хотя на практике не вижу в этом смысла. но в теории вот это допустимо). Идея микросервисов в том, что нет никакого общего управляющего кода, который устанавливает требования к вызываемому коду типа "у тебя должны быть вот такие и такие методы, чтобы я мог их вызвать, и будь добр мне прокинуть конфиг, чтобы я знал что ты умеешь, я буду это контролировать на своей стороне, и вообще мне нужно будет создать экземпляр твоего основного класса, чтобы к нему обратиться, потому укажи как тебя сконфигурировать". Когда что-то подобное возникает - это монолит. А идея микросервисов, что требования устанавливаются только на протокол API вызовов, и ни один из микросервисов не знает ничего о внутренней структуре любого другого, он знает только спецификацию АПИ других микросервисов, с которыми связана его работа. Это позволяет упростить поддержку кода так как в идеале степень зацепления сводится к нулю вплоть до того, что один микросервис может быть написан на c++, другой на php, один в функциональном стиле, другой в ООП и т.д. Они не обязаны иметь вообще ничего общего, кроме, собственно, протокола взаимодействия, и то даже с протоколом на самом деле один микросервис может работать по http, а другой через unix сокеты по самописному протоколу, а третий и вовсе выискивая в нужной директории новые файлы и как-то их обрабатывая
А я утверждаю что смысл любой архитектуры это в первую очередь производительность. Нет смысла ничего городить ради архитектуры кода. Огромные издержки - выгода сомнительная. Архитектура кода вообще может быть какой угодно, можно модули монолита писать без этих тесных связей, чтобы они друг с другом общались через интерфейсы или очереди. И монолит это не про присутствие какого-то "общего управляющего кода, ". Откуда бы ему там взяться и зачем он там нужен? Микросервисы конечно могут обращаться в одну базу, тогда получается что мы оставляем их минусы - оверхед, множество слоев, опять же отсутствие join и транскакций. А вот самый очевидный плюс - это расширение бутылочного горлышка базы , мы как раз его исключаем. Никакой пользы кроме вреда. А про "степень зацепления" - то , что я хотел сказать в видео, что она не возникает от решения неумелого разработчика. А это есть требование бизнес логики, и как ты сервисы не изолируй, эта "степень зацепления" не исчезает, а только обрастает большими слоями. Если какие-то вещи логически связаны, они и останутся связаны, через прямой вызов или через API. По поводу разных языков и протоколов взаимодействия. Если есть такая необходимость, конечно единственный вариант это сделать отдельный сервис. Я вообще ничего не имею против сервисов и микросервисов, все что хочу сказать что это должно быть обосновано и стремление к меньшей связанности, для меня сомнительное обоснование.
@@SeniorPomidorDeveloper Стремление к меньшему зацеплению (coupling) кода - это хорошо. Об этом можно почитать даже у того же Макконнелла, который внятно это объясняет в Совершенном коде. Идея такая общая: чем меньше зацепление - тем меньше нужно менять уже существующего при изменении требований бизнеса, и тем меньше вероятности уронить отправку писем исправляя расчёт скидки, или получить другое настолько же неожиданное поведение. Степень зацепления зависит от разработчика и архитектуры. В монолите почти невозможно избежать высокого зацепления кода. Именно потому большие проекты очень редко бывают монолитами, а возможно и никогда. Потому что если в проекте 10 000 000 строк, то очень хотелось бы понимать, что вот эти 10 000 строк замкнуты в себе, и их изменение ни на что не повлияет, вот эти 100 могут повлиять вот на эти куски кода, а за попытку изменения этих 10 строк нужно немедленно уволить с пометкой "неспособен быть программистом", потому что потенциально может уронить половину системы. Отсутствие join при работе с БД не является проблемой. Я периодически сам от них отказываюсь, потому что когда меня только познакомили ORM поставляющей связывание таблиц, я был в восторге и совал их повсюду. Потом пришло понимание, что если так делать, то иногда возникают ситуации, когда правишь поля системы новостей, а падает система заказов или возникают ошибки при редактировании пользователей :) Должны быть домены, внутри которых связи разрешены, но должны быть и линии разделения, через которые лучше прокинуть список id, а на той стороне код примет их и сделает что нужно: сам прочитает записи, обработает и вернёт, что от него требуется. Управляющий код в модульных системах - это неизбежность. Если он пропадает, мы получаем микросервисы. Они могут крутиться на одном сервере и смотреть в одну базу, но по сути они будут микросервисами. Возможно реализованными с косяками (например читающими данные друг друга напрямую), но это опять же косяк уровня протокола общения, а сама архитектура микросервисная.
@@nikolaymatveychuk6145 Ну я согласен, и про разделение ответственности, и про Домены, и что coupling это не оч хорошо для кода. Но как-будто инструменты для их достижения не те. Но вы как-будто утверждаете что микросервисы нужны чтобы "не выстрелить себе в ногу". А может просто не стрелять себе в ногу? ) Чтобы было меньше шансов "уронить половину системы." , случайно что-то там изменив. Даже что надо отказаться от join, чтобы не уронить систему заказов, редактируя новости. Это вообще не понятно, как join может что-то уронить? Такое ощущение что вам не хватает хорошего покрытия юнит-тестами, чтобы эти проблемы не возникали. Что нужно пробросить список id, а потом повторно доставать из базы, чтобы соблюдать линии разделения. По моему, мы так только искусственные трудности создаем, ради идеологии о "хорошей архитектуре". Вообщем я не согласен ) Я как-бы не против микросервисов, я скорее против такого их обоснования.
@@SeniorPomidorDeveloper разумеется микросервисы не являются панацеей. Это не решение вида "ну у меня микросервисы, мне это не грозит". Просто они об этом же, как и многие другие архитектурные подходы (я спорю больше не о микросервисах, а об идее, что вся архитектура - это ради производительности кода... микросервисы являются просто удобным примером, так как Вы про них заговорили). Они предназначены, для логического разделения кода. У меня нет никаких особых чувств к микросервисам, я сам нередко монолиты пишу, но как Вы сами говорили, надо понимать что и когда нужно делать. Я считаю вредным советом идею, что заниматься архитектурой нужно только если производительность проседает. Насчёт юнит-тестов - это уже детали отдельной реализации, и да, бывают случаи, когда смотришь на возникшие ошибки и понимаешь, что если бы тут нормально тесты были написаны, то всё было бы ок. Кажется Дядюшка Боб писал (может не он, не помню точно), что тесты должны быть последним рубежом, а на самом деле программист должен понимать, что он делает и к какому результату это приведёт. Представьте ситуацию, когда система настолько сложная, что модуль новостей пилит одна команда, а модуль заказов другая, и при изменении модуля заказов валятся новости. Ну можно конечно срочно начать бить в колокола и требовать у тех ребят менять свой код, или править свой в попытке удалить существующую связь (если она оказалась необоснованной), но ведь было бы лучше, если бы этой связи не было изначально :) Так вот микросервисы позволяют такое зацепление кода исключить в большинстве случаев, просто по самой сути архитектуры.
@@nikolaymatveychuk6145 Ну есть архитектура кода, а есть архитектура инфраструктуры. Когда я говорю что архитектура нужна для производительности, я скорее имею ввиду второе. А если мы боремся со связанностью, это скорее про первое. Микросервисы они так или иначе присутствуют и в той и в другой. По поводу связей, не очень понимаю как она может возникнуть "необоснованная". Если есть значит нужна. Другое дело что бывает что одна команда выносит какие-то entry point для обращению к своему модулю, а кто-то может их игнорировать и обратиться в обход. Лично я бы для такой проблемы, опять таки, использовал юнит-тесты, или использовал бы linter со своими проверками, код ревью. Но только для этого делать сервис, наверное еще не достаточно этого. Хотя есть подход что на что угодно делать сервис, я не против, только это дорого обойдется. В плане человека-часов, в первую очередь. По поводу юнит-тестов, я их фанат!) В более-менее больших проектах вообще без них не выжить. Они вцелом не противоречат тому чтобы программист сам понимал что он делает и зачем. Даже помогают. Очень часто я на ревью просто прошу добавить пару тестов, а потом смотрю коммиты, а разработчик кроме тестов там еще и код подправил немного. Ну думаю, значит не зря)
привет. мне нравится твой канал и твои видео. если можно, подскажи мне пожалуйста. я хотел бы написать интернет-магазин. ранее такого не делал. с чего мне начать, что будет верным шагом. спасибо.
Можно начать с моих предыдущих курсов. На мой взгляд, интернет магазин это очень крупный проект для того чтобы с него начинать. Лучше с чего-то более простого. Постепенно прийти к магазину. Если он нужен срочно , то лучше скачать движок типа magenta, или на Shopify зарегаться и поработать с платформой.
По-моему такая позиция по вопросу архитектуры очень профессиональная и не «топит» в какую либо из сторон! Для каждой задачи нужно выбрать свой инструмент. И вот мне кажется что сложность или простота будущего развития проекта зависят от профессиональности архитектора на ранних этапах создания приложения.
Спасибо! Да, это сложно , найти баланс между скоростью разработки и правильными архитектурными решениями, на ранних этапах проекта. А бывает что и сам архитектор и даже менеджеры не знают как именно проект будет развиваться и в результате закладывают решения не туда, где в конечном итоге возникают сложности. Но в любом случае, это очень интересно, учавствовать в жизни и развитии проекта, даже если приходится делать ошибки.
Ещё бы добавил что в монолите когда мы вызываем некую функцию (например из ордера дергаем какой-либо функционал продукта) то мы не думаем о том что функция может быть не вызвана. Она будет вызвана в любом случае. В случае сервисов когда мы дергаем его функционал нужно держать в уме что сервис может быть попросту недоступен (выключен/проблема сети и т.д.). Это также нужно обрабатывать: делать запрос пока не выполнится?/вернуть ошибку пользователю?/сохранить куда-то сам запрос и выполнить его позже?
Согласен. Не сказал об этом, по тому что по умолчанию думал что все будет работать идеально. ) Ну не то чтобы это большая проблема, мы такие же проблемы решаем когда взаимодействием в внешними сервисами, к которым у нас даже доступа нет, кроме как через публичное api. Но да, это тоже часть оверхеда. Тоже ресурсов требует.
Очень интересное видео, теоретически насыщенное. Было бы интересно посмотреть на практику проектирования микросервисов, где наглядно было бы показано как они связаны. Не обязательно со сложной логикой, просто 3 микросервиса, которые связаны так "..." через "..." Ведь предыдущие курсы полностью закоывают вопрос с объяснением того, как работает к примеру гит, celery, redis и прочие сервисы и можно сосредоточиться на конкретных вопросах)
Да хотелось бы рассказать в курсе именно про их плюсы, про распределение нагрузки. Не так просто это сделать. Может действительно Azure и Kubernetes использовать.. Что-то мне кажется что не много людей заинтересуется таким (
@@SeniorPomidorDeveloper это однозначно найдёт свою аудиторию! Полезность вашего контента беспретендента и она точно не как не кореллирует с просмотрами на ютубе) Да и я сейчас проектирую достаточно обширную платформу для достаточно узкой аудитории и хотелось бы взглянуть на практическое применение возможностей расширения приложения, а если оно ещё и на джанге))) то это однозначно выстрел в сердечко питонистам ищущим пути к самообразованию...
Спасибо, хорошее видео Есть пара дополнений по монолиту 1. Базы можно делать отдельные для модулей, если нужно 2. Можно делить по репозиториям модули и импортить только конкретные соседние модули как библиотеки, если необходимо взаимодействие с ними 3. В целом можно настпаивать связность внутри монолита как хочется, например, начать можно с одного репозитория и одной бд, а потом постепенно отделять отдельные модули, если возникает такая необходимость по каким-либо причинам. Так или иначе это позволяет делать максимально независимо все, но при этом оставить тестируемость и не добавлять сетевой оверхед и все сложности с этим связанные
Спасибо за комментарий! Да, можно конечно и базы и репозитории делать отдельные на модули. Просто вопрос - зачем. По моему, имеет смысл держать одну реляционную write базу, для удобного проектирования бизнес-логики. И одну NoSQL для скорости, когда связи нас не особо нужны. А именно распиливать код и базу на части, не знаю, если для производительности, то лучше бы другие решения. Для независимости, тоже не очень понимаю что это и зачем коду это. То что сетевое взаимодействие мы уберем, что да, это очень хорошо на мой взгляд. Но вот отсутствие join и трансакций, это не всегда удобно. Но вцелом согласен, если мы все попробовали, и кеширование, и read only базы, и пр, а все ровно не помогает, то наверное лучше несколько баз сделать в одном приложении, и его масштабировать, чем полностью выносить в другой сервис. Надо подумать об этом.
@@SeniorPomidorDeveloperя с вами согласен, просто описал возможности, которые покрывают вопросы о огромных командах, которые друг другу мешают при разработке монолита и пр А то многие считают, что минусы единого репозитория и бд решаются только микросервисами
Вам спасибо. Не материал, а золото. Есть на Ютубе доклад где рассказывается о том, что команда перевела проект с модного fastapi, на "старый" Django и скорость разработки выросла в 2,5 раза. Итог доклада такой, что инструменты необходимо выбирать под задачи, а не на оборот. Огромная благодарность за видео.
Ничего. Если немного поработать с туториалом веб приложений то будет более понятно. Вообще свой курс рекомендую, который оранжевый, там и про кеширование и задачи и тд.
Спасибо. Это видео помогло мне определиться с приоритетом на дальнейшее обучение. Я работаю fullstack react + django в небольшой компании. Хочу расти дальше. Последний год я много изучал фронтенд: верстать хорошо научился, по реакту неплохо прокачался. Но вот как-то обыденно для меня это все. А вот когда я ковыряюсь с django : в shell пишу .explain(analyze=True) и изучаю index scan или seq scan и за сколько м/с что нашлось, то это действительно меня увлекает. Из оптимизации бд я пользовался только дополнительными индексами, в том числе составными и кэшированием. Данное видео открыло для меня новые горизонты и я определился, что более профессионально я хочу развиваться в бэкенде. Спасибо за отличное видео!
Даа, архитектура и производительность это большая и очень интересная тема.Если в эту сторону сторону хорошо копать то можно выгодно выглядеть на собеседованиях. И вообще эти знания ценные, по тому что этому особо нигде не учат. Есть теория. Но все ровно каждая инфраструктура выглядит по своему, имеет свои решения.
Мне кажется, что плюсы микросервисов раскрыты не в полной мере . В целом вывод из видео, что производительность плюс минус такая же. Как и расход ресурсов. Но вот совсем по другому микросервисов начинают играть, когда мы подходим к вопросу надёжности всей системы, отказоустойчивости, кластеризации, географического распределения. Дальше вопрос эксплуатации, т.е. обслуживания и обновления. Обновить модуль на монолите - это зачастую вопрос обновления всего монолита, проблемы отката обновления, совместимости всех модулей и библиотек. Эти сложности приводят к удлинению времени между выходом версий. Это плохо скажется на закрытии багов. Дальше вопрос распространения, если это проект, который имеет много инсталляций. И обслуживание всех инсталляций. Ещё вопрос тестирования разработки, т.е. качество продукта. Быстрее деплоить - быстрее тестировать и т.п. Зачастую вопрос качества кода и скорости исправления багов, доставки исправлений без перерыва работы сервиса в разы ценнее у конечного потребителя, чем не глобальные потери производительности. Я не адепт микросервисов, но указанные выше нюансы неразрывны с итоговой оценкой.
1. Не понимаю что не так с надёжностью, геораспределением и кластеризацией монолита - деплойте столько реплик аппки сколько нужно и где нужно 2. Все проблемы эксплуатации точно такие же как и в микросервисах, если у вас модули нормально отделены друг от друга, то все решается ровно так же (проблемы совместимости вам на билде уже стрельнут тут, а при микросервисах скорее всего уже после выкатки и мб даже будет необратимо подпорчено что-то), а библиотеки можно использовать разные и на уровне каждого модуля 3. Что вы имеете в виду под инсталляциями не понял 4. Тестирование как раз в монолите самое нормальное, все можно поймать на уровне Билда, а то и раньше вам ide подскажет. В случае микросервисов начинается лабуда с моками, контрактами/клиентами (которые тоже надо в актуальном виде держать) - это муть, а не скорость разработки, так ещё и если что-то пойдет не так зачастую узнается это после релиза и грозит последствиями в виде сломанных данных
Отказоустойчивость, кластеризация, географическое распределение - решается на монолите плюс-минус так же: масштабируй и балансируй в горизонт сколько угодно, как угодно и где угодно. Обновление да - МС удобнее, быстрее, "тише". Но про билд и деплой было сказано. По поводу "быстрее тестировать и доставлять". Т.к. один МС быстрее исправить/доработать, протестировать и вынести, чем тот же кусок в монолите - сферически да. Но в жизни, если все очень сильно связано и с исправлением/доработками одного МС могут понадобиться исправления/доработки связанных по бизнес-процессу других МС, то тут уже не всегда все так шоколадно. Я тоже не адепт МС, но чуть их "залошили" как будто, да.
Да, я тоже думаю про "надёжности всей системы, отказоустойчивости, кластеризации, географического распределения", в случае модульного монолита , мы можем для них использовать те же решения что использовали бы для микросервисов. По поводу "выходов версий" и "инсталляций" не очень понял. Это имеет какое-то отношение к тому как компоненты взаимодействуют внутри инфраструктуры? По api или по вызову функций. Доставка исправлений без перерыва работы - ну это же по сути решается скоростью перегрузки веб-сервера. То есть доли секунды обычно. Быстрее деплоить - быстрее тестировать - это правда. В ситуации с отдельным микросервисом - да. Но опять же возникают интеграционные ошибки , которые тоже надо тестировать и отлавливать. Могут и не возникнуть, то есть в чем то быстрее, но при этом опаснее. Обслуживания и обновления - да, мы можем их отдельно обновлять, что конечно плюс. Мы вот в недавно нашем проекте питон обновляли, в нескольких сервисах уже обновили, а в нескольких еще не успели, никак руки не доходят ) Был бы целиком монолит мы бы сразу везде обновили, хоть и времени бы ушло больше. Не знаю, такое ощущение что тут вопрос - "вам торт целиком или по кусочкам?" . Если уж есть разница то она в производительности и бутылочных горлышках. И можно это наращивать через микросервисы , но вопрос какой ценой.
Очень интересное видео, спасибо. Есть вопрос: Сервисы могут обращаются напрямую друг к другу по внутреннему апи или все же должны делать это тоже через gateway?
