Классное видео, спасибо. Давно тебя не было. По поводу проблем с микросервисами: мой опыт показывает, что все беды из-за человеческого фактора. Основная проблема большинства это создание микросервисов ради создания микросервисов (что прослеживается и по примерам в видео). В этом случае почти любая новая фича выносится в отдельный сервис особо не задумываясь, а надо ли ее выносить в отдельный сервис. На моей практике микросервисы далеко не всегда такие микро, как все думают. И кстати RPC или REST далеко не самые хорошие способы коммуникации между сервисами. Вообще тема огромная конечно, могу говорить о ней бесконечно :D Я бы еще добавил, что у идеальных микросервисов довольно высокий порог входа для бизнеса: 1. Нужны инженеры, которые в теме про всякие саги, транзакционность, брокеры сообщений и так далее 2. Нужна devops культура в компании и штат devops инженеров 3. Нужен сильный архитектор, который будет в состоянии за этим следить 4. Критически важно иметь хороших product managers особенно для проработки спецификаций Для небольших компаний, увы, этот подход чаще всего не является выгодным.
@НикитаГлухов-п5ю
3 жыл бұрын
Микросервисы редко пилят с 0, обычно либо команда готовая есть, которая на кафках/кассандрах/тарантулах собаку съела, а также реактивщине и обычной асинхронщине уровня узла через блокирующую многопоточку с мутексами-семафорами. Либо это легаси, проекту от 5-7 до 10-15 лет, и он либо монолит, который внезапно наконец дорос до клиентской базы, раздавливающей любое вертикальное масштабирование, либо монолит в свое время распилили в SOA с SOAP-контрактами и система тоже перестала справляться с нагрузкой, т.к. топология "звезда" и ESB-шина стала точкой отказа, т.к. в единственном экземпляре, в кластер не засунешь. Здравстуй новый раунд хантинга и просьба рекрутерам искать кандидатов с "MSA-архитектурой" в резюме, дабы всё попилить.
@andreysakharov6210
3 жыл бұрын
@@НикитаГлухов-п5ю пилят пилят(
@AndreySvyat
2 жыл бұрын
@@НикитаГлухов-п5ю Наивный, в одном из проектов архитектор, ради удовлетворения своей течки на МС с ходу нарисовал схему из 4-х бэкхенд микросервисов, и 3-х фронтов, мы ох***, но его было не переубедить
@AndreySvyat
2 жыл бұрын
На мой взгляд самая большая проблема в том, что иногда, до решения задач допускаются люди совершенно в них не компетентные. И тогда мы имеем наносервисы из говна и веток и мегалиты с неподдерживаемым кодом.
@НикитаГлухов-п5ю
2 жыл бұрын
@@AndreySvyat ну в отдельно взятой компании может быть че угодно, речь была о том как переходят на MSA в большинстве случаев, так как стрёмно, если куча бабла вылетит в трубу из-за необоснованных ожиданий и непонимания уместности подхода.
@AlexanderKurguzkin
2 жыл бұрын
Спасибо, очень интересно.
@user-zd7oo3vf5c
3 жыл бұрын
лайк но книга для девопсов, я так понял в основном. Ждем обзор на хорошую книгу(адвансед) по архитектуре микро-сервисов. Если такие есть :) на 2 апреля, как-раз выходной.
@tumenit
3 жыл бұрын
Как всегда, топ-контент
@ахуец
2 жыл бұрын
У вас кабачок выпал на 2.13)
@SerZab80
2 жыл бұрын
1) монолит лучше микросервиса 2) в микросервисе упрощается обслуживание гита 3) правильно распиленный по ddd микросервис отлично борется с техдолгом 4) микросервисы - это от безысходности, а не от того, что лучше
@egorkomarov4719
3 жыл бұрын
Спасибо. Я не согласен
@victorchilari
3 жыл бұрын
Расскажешь что не так?
@magneat
3 жыл бұрын
Да. Взять всё и поделить :))
@mikeshapovalov2459
3 жыл бұрын
Отличный анализ, поддерживаю идею о том что начинать нужно с монолита, а микросервисы внедрять по мере необходимости. Да и приставка микро мне кажется тут лишняя. Я считаю что бить приложения на части нужно в двух случаях, о первом вы рассказали в видео, когда растет нагрузка на какую-то часть и ее нужно срочно масштабировать, второй когда над приложением работает большая команда, тогда можно вынести часть бизнес контекстов в отдельное приложение и разделить команду. Что касается баз данных то я считаю что крупный монолит тоже должен работать на нескольких базах данных, отдельная база данных для каждого boundary context (DDD). Проблему кучи мелких запросов может решить паттерн CQRS. Коммуникацию между контекстами лучше изначально делать асинхронной используя event driven архитектуру. Монолит спроектированный таким образом очень легко разбивается на сервисы по границам бизнес-контекстов.
@alexeypashchenko
3 жыл бұрын
Отличный комментарий!
@catalinstratu6135
3 жыл бұрын
С праздником! Мне очень нравится твой видео, я на втором курсе в Румынии и мне твой видео очень помогают. Можешь сделать и видео про алгоритмы и структуры данных? Спасибо!
@victorchilari
3 жыл бұрын
Salut, sunt din Moldova. Tu cu ce te ocupi?
@kamilmodest
3 жыл бұрын
У меня пока, к сожалению, не было реального опыта работы с микросервивасами, но у меня о микросервисах сложилось впечатление, что из-за тренда их неправильно воспринимают, и во многом, мне кажется, это вина маркетологов, которые продвигают технологию просто ради технологии. В реальности, часть проблем, которые были освящены в видео объеденяются под одним названием: "Распределённый монолит". И на хороших курсах по микросервисам рассказывают, что "Распределённый монолит" != "Микросервисы". По хорошему, любую книгу надо начинать со слов "Плохая идея начинать писать приложение сразу на микросервисной архитектуре. Правильный подход - это пилить монолит." Т.е. сначала вы пишете хороший модульный монолит (в иделе, возможно, следуя DDD, ведь в последствии bounded context'ы помогут вам проще вытащить сервис из монолита и посадить на отдельную инфраструктуру), а затем уже смотрите на узкие места в вашем приложении и выделяетет их в микросервис. И да, вы не обязаны "когда-нибудь в будущем" целиком переходить полностью на микросервисы, распилив весь монолит. Часто это не нужно, ведь приложение отлично работает и в формате монолита с выделенными на отдельные машины и замасштабированными парочкой микросервисов, которые ГРАМОТНО изолированы, чтобы была честная отказоустойчивость. Т.е. к микросервисам, как и к любой другой технологии в принципе, надо подходить исходя из потребности, а не из трендов. Тогда польза микросервисов будет уже более явной. По поводу разных языков, тот же Amazon, на сколько я слышал, все микросервисы пишет на Java и запрещает использовать другие языки. Т.е. не нужно следовать тренду, а просто исходить из потребностей бизнеса (:
@dmitriyobidin6049
2 жыл бұрын
Касательно разных языков - это больше маркетинговая уловка. Ни одна компания не будет пилить микросервисы на чем попало(всмысле отдавать выбор языка на откуп программисту/команде). А если придется писать свои собственные решения для какой-то узкой области? Как потом его переиспользовать в своей же системе, если изначально это решение писалось на Go, а соседний микросервис где мы хотим это решение заюзать написан на Java? Поэтому зачастую в компаниях с большой микросервисной архитектурой есть списки разрешенных языков для использования. Шаг влево - надо согласовывать.
@dagaz7960
2 жыл бұрын
Девушка, твои родители случайно не пираты? А почему ты такое сокровище? Парень есть у тебя? Свяжись со мной!
@dmitriyobidin6049
2 жыл бұрын
Сопоставление микросервисов и монолита всегда обречено на провал... Микросервисы это почти всегда следующая стадия развития монолита, а не его альтернатива. Я бы сказал что цепочка такая: монолит -> SOA -> микросервисы. Если ваша система не может быть поделена на высокоуровневые сервисы в SOA, то и в микросервисы соваться не стоит. Касательно плюсов микросервисов - один из самых главных это возможность разделить ответственность по командам. Если у вас такого нет, и разрабы не ноют "да нам надоело ждать, пока они там свой спринт подготовят в своем команде Х" - то почти наверняка вам не нужны микросервисы. SOA - почти всегда золотая середина, к которой стоит стремиться.
@JohnKoepi
3 жыл бұрын
Спасибо за обзор книги!, - теперь точно читать не буду. Про рост сложности там даже без дополнительных балансеров хватает - нужно собирать логи, метрики, обеспечивать распределенную трассировку, дебаг, зависимости, преемственность изменений апи, tail latency становится хуже просто за счет большего колва вызовов внутри системы, аутентификация, авторизация, шифрование трафика и тд.
@professorpirog8862
3 жыл бұрын
Спасибо за видос по архитектуре! Хорошо, что такие люди как ты бесплатно делятся своим опытом в таком понятном формате
@slavapinchuk4829
5 ай бұрын
Спасибо большое, пересматриваю спустя несколько лет, а если пересматриваю, значит ценно =)
@Sokolyuk
3 жыл бұрын
Приятно слушать думающего человека. Спасибо и удачи! Абсолютно так и есть, и честно говоря, все еще хуже, и просвет не намечается. Какую технологию не возьми, монолит, трехзвенку, микросервесы и т.п., если критическое количество разработчиков с кривыми ручками превосходит порог выносливости системы, то никакая архитектура не спасет. Программер должен всю жизнь учиться, иначе выходит только г**нокод. Я сам программер 25+ лет, и все встречавшиеся проблемы были только в квалификации и прилежности программеров, не в архитектуре. Один раз правильно написанный код работает десятилетиями.
@molokooooo
3 жыл бұрын
погоди но ты же баба)
@nafisaisrail8633
3 жыл бұрын
Был опыт не совсем микросервис, но делили написание функционала по языкам: На golang стримили видео, а взаимодействие с базой полностью на python. Такой вот микро-микро сервис был. Спасибо за интересный разбор интересной темы.
@la_elena
3 ай бұрын
Было интересно послушать, но как человек, который работал с огромным старым монолитом на одном проекте и с полностью микросервисной архитектурой на другом, я абсолютно с вами не согласна и абсолютно согласна с автором книги.
@qrocq
3 жыл бұрын
Привет. Вы правильно сказали что микросервис рассчитан на "задачу", а точней контекст. При таком подходе мы не должны смотреть что написано в том микросервисе, мы специалисты в своём контексте. В целом вся суть в том, что команда работает над одним или несколькими контекстами, но не наоборот. Команды изолированы друг от друга, и нет универсальных разработчиков. Конечно у микросервисов очень много минусов, и самая основная это в понимании разделения - в большинстве случаев это монолит(в класическом понимании) с удалённый вызовом процедур, а приставку "микро" рассматривают как "микросервис должен делать что-то одно и максимально простое". Из-за этого и получается что нужно постоянно смотреть код другого микросервиса, а решение той или иной задачи сводится к редактированию N микросервисов.
@Petyaumniy
Жыл бұрын
Самый главный вопрос для оголтелых любителей микросервисов - как в вашей фигне сделать консистентный дамп всей системы? И я даже не про теоритическую протребность восстановления из бекапа, когда стало все совсем плохо. А как банально сделать дамп, чтобы потом его почистить и запустить на стейдже? Ну и сказки про то как уменьшаются накладные расходы просто убивают. Вот был у меня раньше 1 репозиторий: 1 конфиг ci (очень глубоко переиспользуемый), 1 "конфиг" сборки "docker'а", 1 helm chart... Теперь у меня 30 копий этого... В это невозможно вносить изменения руками, оно постоянно подвержено дрейфу конфигурации (разработчики лезут в ci/docker/хелмы). В среднесрочной перспективе выделение в микросервисы с выделением в отдельные репозитории приводит, ВНЕЗАПНО, к появлению в отдельных репозиториях отдельно живущих сущностей с точки зрения инфраструктуры. Которые опять же, ВНЕЗАПНО, нужно отдельным образом, вникая в контекст, сопровождать. Микросервисы, имхо, эта такая вирусная теория в духе современного эффективного менеджмента. А что, давайте возьмем и скинем с плечей разработчиков 5% проблем (честно говоря так до сих пор не понимаю механизм, как это помогает вообще), за счет создания +50% проблем у инфраструктуры (тут полностью понимаю на своей шкуре). И тогда на краткосрочном этапе на запасе прочности инфраструктуры и еще не удрейфовавших конфигурациях мы сможем некоторое время "ехать" быстрее. Ну а что будет через несколько лет... А какая мне разница, что у них будет через несколько лет. Вот мои показатели - я ускорил, вот график, это объективно! Я пошел на повышение в другую компанию.
@yurim7756
2 жыл бұрын
Да ногами бить надо любителей микросервисов )) У меня опыт 18 лет работы. И почему люди уверены, что это г надо использовать??? Я видел два погибших проекта, из-за этого подхода. Точно так же умники думали разгрузить нагрузку, на несколько серверов, а потом оказалось, что вся производительность уходит на общение между ними. И что-то сделать с этим УЖЕ невозможно было. Если при монолите в этих проектах или бы не было общения, или можно было бы поднять несколько серверов, и разделить их по данным. Но когда есть сервисы, отвечающие за задачи, уже всё. А всё из-за просто неправильных представлений о кодировании. Это философская бага в мозгах. Написание кода - это НЕ конструирование конструкций, а лингвистическое описание задачи. Должно быть, по крайней мере. Когда вы представляете свой код как книгу, в которой описана задача, а не конструкции, которые решают задачу, всё становится на свои места. (если не понятно, как это, советую изучить какой-либо функциональный язык и проникнуться парадигмой). Теперь представляем код, как некоторое смысловое пространство, в котором всё описывается. Вот скажите, где-то в задачах от заказчика существовало слово «микросервис»? То с чего вдруг такая неважная, сорокастепенная вещь должна быть на языке и ставиться во главу угла в архитектуре? Ведь нормальный язык программирования сам предоставляет по себе уже все нужные вещи для описания задачи, включая даже разделения ответственности, инкапсуляция. Т.е. в самом языке лингвистически уже есть всё что надо, чтобы изъясниться с компилятором, что вы хотите. Так вот и описывайте задачу, пользуясь языком. Вот представьте художественную книгу, в ней что-то описано языком. Про горы, реки, воображаемых героев. И вдруг пишут, «следующую главу найдете во второй части книги в синем переплете, в библиотеке им. кого-то там на улице пушкина дом номер ушкина». Глупо, верно? В пространство языка описаний вмешались физические границы. Не думайте о том, что это, монолит или нет. Разные части, модули, развязывайте через интерфейсы, а не конкретные классы. И тогда, вдруг, окажется, что пользование интерфейсом никак не привязывает вас к какому-то способу взаимодействия. Вы потом, когда понадобится, сможете вынести код в другое место и общаться через сеть. Т.е. сделать сервис. Заметьте, у вас взгляд на код не транспонирован, вы смотрите на код, как на код, как на описание задачи, а как порождается реализация интерфейса, как общается оно - в памяти в этом же процессе, или уже через сеть с сервисом, это вообще не главное стоящее внимания дело. Мало того, вы можете решить, что это будет синглтон, а может быть и нет, может на каждый запрос порождаться экземпляр. А может их несколько, балансированных. Вашему вызывающему коду по боку. Поэтому не надо вообще строить архитектуру, рассматривая ее изначально как сервисы или как монолит. Скорее всего, монолит будет лучшим решением, с него лучше и начать. А потом можно, если код грамотно пишется, на ходу его разбивать и раскладывать. Это если надо. Не надо делать сразу, из тюбика зубную пасту легко выдавить, назад не зальешь. С чего вдруг монолит для маленьких только продуктов, понятия не имею. Вроде если монолит, то это только один проект, одна либа и никак нельзя код кусками писать или куски разными командами. Чем микросервис поможет, вообще не ясно.
@antons6335
2 жыл бұрын
Видео вводит в заблуждение по многим пунктам. Навигация как раз легче в микросервисах, потому что всегда знаешь какой из них за что отвечает и где искать классы. Это не монолит с 800 пакетами, где хрен что найдешь. А если найдешь, то потом замучаешься отслеживать цепочку бесконечных зависимостей бинов и что каждый делает и куда свой код впихнуть. Использование микросервисам как раз более надежно, потому что если монолит упадет, то хана всему. А падение одного микросервиса - это просто падение одного микросервиса и зачастую предусмотрен обход. И никакие данные запросов, ответов не потеряются при общении, если есть брокер и очередь. Видос вообще так себе, перечислены только минусы микросервисов, половина из которых - заблуждение. Когда речь идет о сравнении чего-то с чем-то нужно говорить о всех прос и коинс, и в каких ситуациях.
@inilim
Жыл бұрын
Вопрос знатокам, как компоновать(JOIN) данные из разных баз данных? на уровне приложения!
@Trecoolerok
3 жыл бұрын
Хороший видос. Вчера как раз слушал стрим об этом
@sergejdobryak4713
3 жыл бұрын
Все правильно, микросервисная архитектура это очень не просто. Distributed transactions, eventual consistency, resilience: retries и timeouts - это все не бесплатно, только вот звучит как решение всех проблем. Да, уже есть много инструментария и он довольно неплохой, но он однозначно увеличивает сложность приложения.
@ДенисМишарин-р3н
10 ай бұрын
а почему речь идет только о ресурсах? почему не смотрим со стороны именно бизнеса?
@Cre0w
3 жыл бұрын
Возможно в книге шла речь о крупных монолитах где сложная беспорядочно переплетающая инфраструктура только для одного узла, во внутрь обеспечивая сильную связанность. Поддержка таких систем сильно сложна и не поддается какому-то быстрому анализу. По поводу кода, в больших монолитах нельзя так просто взять и найти что-то, они операются только на программную архитектуру, только знание программной архитектуры помогает хоть как-то понять как это все работает) Я думаю автор книги не достаточно раскрыл тему, чтобы донести мысль.
@Cre0w
3 жыл бұрын
Да с микросервисами все так, там много кода и все сложно. Но поверьте есть монолиты, в которых есть тупиковые ситуации и они как неповоротливые гиганты, с ними сложно (не подходящее слово) работать. Если с микросервисами сложно то с монолитом тупик, костыли, нереально, невозможно... Такие фразы там норма
@ascar66
Жыл бұрын
Красавица ты как там? Хоть короткий видос закинь мол все хоккей жива здорова
@grigorii9019
2 жыл бұрын
Ой. Как это похоже на мужика, у которого в руках молоток и он на все смотрит, как на гвоздь.
@nickett
2 жыл бұрын
Привет. А что за читалка? Какую посоветуешь купить??
@olgatres7888
3 жыл бұрын
Ксения, здравствуйте. Спасибо за ролик! Я совсем новичок и мне интересна тема микросервисов. Но я сильно путаюсь в понятиях микросервисов/веб-сервисов и API. Может быть, вы бы смогли грамотно объяснить разницу? Я так понимаю, что микросервисы это именно архитектурный стиль, то есть у нас есть много разных веб-сервисов под каждую задачу. Например, user service, payment service, и тд. Но в свою очередь, веб сервисы являются web API. Правильно ли я понимаю, что микросервисы это и есть APIs, которые представляют собой список эндпоинтов, методов (get, post, etc)? Или же есть API как входная точка, и он в свою очередь перенаправляет реквест на какой-то микросервис? Буду очень благодарна за ответ!
@OverEngineer
3 жыл бұрын
коротко - оба описанных вами варианта возможны)
@cb2_2cb
3 жыл бұрын
сторейдж - это хранилище, а не база данных... Ну да ладно
@alexeymezenin
3 жыл бұрын
"Нужно решать проблемы по мере их поступления" - именно этого не понимают команды, которые используют микросервисную архитектуру при создании нового приложения. В большинстве случаев - это следование моде.
@directorys
3 жыл бұрын
Комментарий для интересного канала и человека 👍
@SheremetRuslan
3 жыл бұрын
Сложилось впечатление, что ни автор книги, ни автор видео не работали с современными большими продакшен проектами, где сотни микросервисов и микрофункций! Если архитектор не рукожоп, то унифицирует всю структуру микросервисов, микрофункций в генераторе кода. В этом коде будет все необходимое для Test, CI/CD, разработки. Т.е. по факту разработчики будут только писать его логику, Unit/E2E/Integration тесты. Код группы микросервисов может быть организован в mono-repo и не нужно будет бегать по другим репам. Контракт по public API должен быть в OpenAPI 3.0+. Спеки по внутренней коммуникации в JSON Schema, AsyncAPI. Чтобы не было complexity - организовать коммуникацию через Events через Event Broker(Kafka, NATS Streaming, Apache Pulsar) с Event Registry. Это даст возможность соединить логику приложения в BPMN 2.0 и видеть всю картину реалтайм. Что касается uptime, то canary deployment никто не отменял, Istio, может обеспичить 100% uptime.
@OverEngineer
3 жыл бұрын
Сюзан Фаулер выстроила микросервисный продакшн убера и написала книгу об этом, про себя скромно промолчу, но у меня достаточно опыта (3 больших проекта на микросервисах), чтобы говорить то, о чем я говорю в видео. Так что спасибо за mansplaining, noname комментатор ютуба.
@SheremetRuslan
3 жыл бұрын
@@OverEngineer Архитектура Uber не следует современным Best practices. Архитекторы Uber не смогли мигрировать Postgres 9.6 на новую версию и решили перейти на MySQL(facepalm), что еще раз подтвержает их рукожопость. Она только описала их начальную архитектуру, а не то, что реально было на тот момент времени в проде. Архитектура проекта организована через задницу, было несколько утечек пользовательских данных...
@SheremetRuslan
3 жыл бұрын
@@OverEngineer что касается вашего опыта в MSA, то так и говорите, что вы не смогли решить те проблемы, которые упомянули в видео, а не высказываться о MSA как о бесполезной архитектуре. Не зря все IT гиганты мигрируют свои монолиты в MSA или FaaS, так, что за этими архитектурами будущее.
@niklkelbon3662
3 жыл бұрын
Жду тренда на микромикросервисы, каждую функцию пишем в отдельном репозитории и общаемся с ней по интернету, неплохая идея. Жду книг по этой тематике
@OverEngineer
3 жыл бұрын
так чего его (тренд) ждать, он уже лет 6-7 как тут)
@niklkelbon3662
3 жыл бұрын
@@OverEngineer я придумал гениальную идею,... Ну такое я себе сохраню мб реализую(хотя в вебе и мобильных приложениях вообще не копаюсь, чисто С++), но идея прикольная...(в личку могу кинуть как идею для видео хД)
@ColdBanehallow
3 жыл бұрын
Serverless computing / FaaS это примерно оно.
@ColdBanehallow
3 жыл бұрын
@@niklkelbon3662 C++ есть в вебе, правда в основном в гигантах вроде aws/google/yandex
@niklkelbon3662
3 жыл бұрын
@@ColdBanehallow есть, но я просто этим не занимался, об этом говорю
@donutduck9769
3 жыл бұрын
Привет, большое спасибо за видео, посмотрел почти все взахлеб, не пропадай надолго!
@DmitryDolganov
3 жыл бұрын
По ходу следуюший твой ролик выйдет 1 мая. А еще следующий - 9 мая!)))
@OverEngineer
3 жыл бұрын
да, ты угадал. по ролику на каждый социалистический праздник
@DmitryDolganov
3 жыл бұрын
@@OverEngineer можешь как - нибудь осветить свое видение книги Рихтера по С#? Очень интересно услышать твое мнение!
@olekspin
3 жыл бұрын
сначала микросервисы, после - микрокредиты
@deniszavarzin2768
2 жыл бұрын
Все не так как говорят в рекламе...
@maxforest7133
2 жыл бұрын
полезная инфа однако...
@hanzo_process
2 жыл бұрын
красивая блузка :)
@inikiforov
3 жыл бұрын
Привет, подскажи, а какому уровню специалистов можно почитать? Нужно ли глубоко знать программирование?
@OverEngineer
3 жыл бұрын
нет, не нужно. там вообще ни одного куска кода нет)
@aliramazanov848
3 жыл бұрын
Если сомневаетесь - делайте монолит, его потом будет проще разбить на отдельные сервисы. Соединить отдельные сервисы в монолит будет гораздо сложнее
@tony_reinhart
3 жыл бұрын
Почему у вас всегда такой уставший вид? Моргните 3 раза правым глазом, если вас держат в заложниках в Германии и заставляют писать код 24/7 за 2 сосиски в пивом.
@OverEngineer
3 жыл бұрын
наоборот, чувствую себя как нельзя лучше)
@АндрейМорозов-ю2х
3 жыл бұрын
@@OverEngineer Если это ваше хорошее настроение, то страшно увидеть вас уставшую и грустную, но надеюсь этого не произойдет)
@caffeinejavacode1475
3 жыл бұрын
Прикольная бутолочка, которая не мотивирует встать и сходить за водичкой на кухню если она на рабочем столе )
@OverEngineer
3 жыл бұрын
зато меньше дневной дозы не выпьешь)
@artimetix5598
3 жыл бұрын
@@OverEngineer что там между drink more и almost there написано ?)
@АмирГумеров-в7з
3 жыл бұрын
Познавательно, спасибо. С праздником
@ivanlo1805
3 жыл бұрын
Мнение однобоке получилось. В целом ок, что не понравилось/не согласен. 1. Можно взять монолит и hot spot функциональность завернуть в отдельные инстансы и сконфигурировать load balancer. Нет нельзя, если возьмем ту же Java на старте приложение не делая ничего ~150MB, когда взять тот же Go/Rust и там будет 10MB, второй момент это база данных, если весь этот зоопарк будет писать в одну БД то начнутся проблемы с deadlock'ми и консистентностью. Поэтому правило один сервис одна БД. 2. Команда должна работать над одним микросервисом, если нужна какая - то функциональность то организуешь митинг и ставишь фичу в роадмап. 3. Латенси тут нужно организовывать асинхронную коммуникацию, это делает код сложнее, еше надо впиливать паттенр ака Circuit Breaker что бы избежать Cascading failure. Могу статью в коментах написать, как надо и не надо, но лень увы.
@ivanlo1805
3 жыл бұрын
как больно это не было в распределенных системах есть только eventual consistency и про strong consistency и ACID можно в каком-то смысле забыть (CAP theorem все дела).
@stalker2k4
3 жыл бұрын
Проблемы с дедлоками в БД - это почти всегда кривой код, который эту БД использует, плюс дополнительно возможные проблемы на стороне БД (типа индексов, блокирующих всю таблицу даже при обращении к одной записи) или технологии, используемой для доступа к данным. Если всё написано и настроено правильно, то к одной БД можно подключать любое количество микросервисов, и никаких дедлоков не будет. Просто БД будет тормозить всё больше и больше, вот и всё. В своё время два месяца чинил дедлоки на одном проекте, который представлял собой десктопное приложение, стоящее на рабочих местах, и одну БД на сервере. Никакого зоопарка, просто 50-70 инстансов одного и того же приложения. Но код был плохой, и дедлоки сыпались как из рога изобилия. С тем же успехом можно получить дедлоки имея одну БД на микросервис и 50 инстансов этого самого микросервиса. Правило "один сервис-одна БД" возникло из-за того, что очень проблематично делать миграции БД, если эту БД используют несколько сервисов - нужно синхронизировать код в одном микросервисе с обновлением структуры БД в другом, плюс нужно синхронизировать сами файлы миграций БД между разными сервисами.
@ivanlo1805
3 жыл бұрын
@@stalker2k4 а в чем предложение то? Нанимать суперменов кто не пишет плохой код? Или нарушайте правило один сервис одна БД, но нанимайте суперменов?
@stalker2k4
3 жыл бұрын
@@ivanlo1805 так я не делал никаких предложений, просто поправку сделал про дедлоки. При чём тут нарушение правила "один сервис-одна БД"? Дедлоки к этому правилу отношения никакого не имеют. На моём текущем проекте недавно, где это правило выполняется, была проблема с дедлоками в БД. Никто, кроме этого сервиса, с данной БД не работает. Были проблемы в коде сервиса.
@ivanlo1805
3 жыл бұрын
@@stalker2k4 к этому правилу имеет отношение дедлоки в том числе. Если у тебя десктопное приложение куда пишут полтора человека, то там можно поправить код и будет работать и никаких дедлоков. Если у тебя сложное приложение работающее под нагрузкой, то на одном сервисе может все ок, а стоит их отскейлить 2+ и начинаются проблемы.
@alex4everyours
3 жыл бұрын
Благодарю за интересное и полезное видео! С праздником!
@alexei3366
3 жыл бұрын
микросервисы можно деплоить независимо. Это плюс.
@bubblesort6368
3 жыл бұрын
Можно, но могут быть зависимости между этими микросервисами и тогда независимый деплой становится неявно зависимым, что еще хуже) Но если у вас микросервисы никак не завязаны друг на друга, а еще и две разные команды это разрабатывают, тогда это действительно плюс.
@bubblesort6368
3 жыл бұрын
@@SuperHyuta Естественно версионирование делать нужно. Это актуально не только для микросервисов но и для монолитов. Но как это отменяет то что микросервисы завязаны друг на друга? А если надо откатить какой-то из них в критическую минуту? То без сложной системы оркестрации сделать это сложно. Тут проблема в сложности инфраструктуры и поддержке этого.
@MaximRovinsky
3 жыл бұрын
Хей бэкендерша) А можно видосик по архитектуре (если это к тому относится конечно)? Как создавать правильные методы /не городить огороды без спагетти кода, вот это вотвсё /Что бы взрастить в себе чувство прекрасного и делать элегантные решения в коде
@romanke9706
3 жыл бұрын
Раскрыты далеко не все аспекты микросервисов
@OverEngineer
3 жыл бұрын
не претендовала на раскрытие всех аспектов)
@roman.chudov
Жыл бұрын
Вроде микросервисы для двух вещей: во-первых, если кодовая база большая и разрастается еще больше, в этом случае поддерживать микросервисный код в перспективе будет проще (но не сразу); во-вторых, это точечное масштабирование. Еще небольшая причина - это когда команды разные и на разных языках пишут, но это редкость.
@barma1309
2 жыл бұрын
Согласен! Этот фапинг на микросервисы создаёт не менее стремную головную боль.
@pro100DooMka
2 жыл бұрын
мне кажется, что большинство описанных минусов связаны с неправильным разделением приложения на ограниченные контексты. Если у вас группка микросервисов, которые работают всегда вместе, это очевидно должен быть 1 микросервис.
@Igor-tn7mq
Жыл бұрын
Согласен с тобой. Из моей практики, писал и монолит очень большой и микросервисы. И в монолите люди творили такое, что на голову не одеть. Но все решалось жесткими ревью и автоматизацией проверками. А вот с микросервисами беда, не все видели очевидных проблем, типа ретраев, таймаутов, идемпотентности api, транзакционности процессов и почему нужно делать саги и тд. Микросервисы это намного сложнее и требует понимания распределенных систем, и хорошей квалификации разработчиков.
@AndreySvyat
2 жыл бұрын
Мой опыт показывает, что обе эти архитектуры страдают из-за того, что инженерам приходит толпа менджерья без намёков на технические знания и начинают толка хайповые решения. А на каком-то этапе развития IT микросервисы именно такими и являлись. Из личного могу сказать, что поддерживать монолит в компании типа банка федерального значения или международной транспортной компании тупо нереально, начиная с того, что для локализации не редко приходится писать отдельные приложения и в монолите это просто невозможно хотя бы из-за языкового барьера и, как следствие, резко возрастающих входных порогов для подбора локальных кадров и заканчивая локальными сервисами той же оплаты, которую нужно будет поддерживать везде и как итог куча ненужной лапши будет таскаться по всему миру, или эффективности инструментов которые нужны для решения той или иной задачи, так, например, проще найти питонистов для решения ML задач, как следствие имеем более развитый набор средств для решения задач на питоне, и как нам теперь в жаба монолит вкручивать ML? Либо из жарового говна и веток, либо отбиваем микросервис и пилим там на питоне и все довольны. Как по мне, любые решения не идеальны, ну хотя бы потому, что есть масса противоречивых требований к системам, которые нужно удовляворять в большей или меньшей степени в каждом отдельном случае. И для этого нужны различные инженеры специализирующиеся на различных технологиях и в различных областях. И когда каждый будет делать свою работу хорошо и не совать свой нос в работу, которая не его, тогда, возможно случится идеальная вселенная. Но это моя больная большая фантазия, а пока мы имеем что имеем и сношаемся с наносервисами и мегалитами. Бум. Рррраунд)))
@codingfox
3 жыл бұрын
Лучшее решение в большинстве случаев - это модульный монолит.
@by_gomel
3 жыл бұрын
Благодарю за ревью книги!
@Rash3851
3 жыл бұрын
На самом деле, достаточно уверенные аргументы в пользу сторонников монолитной архитектуры. Хотелось бы чего-то добавить, но особо и нечего. В принципе соглашусь с аргументами, но по масштабируемости, я все таки не уверен - учитывая добавление новой функциональности, вы можете обновить один сервис, не затрагивая функциональность основных в глобальном смысле. Как по мне основная проблемы подобных решений: 1) обеспечение корректного взаимодействия между сервисами (делаете вы это посредством REST-протоколов, месседж-брокеров и пр.), 2) Конечно же отказоустойчивость, но тут обоюдоострый клинок (возможно вы знаете больше и скажете, что я не прав) и полностью согласен с обработкой таймаутов, но тут можно постараться корректное время выставить. 3) Ну и слишком сильное дробление логики и рост числа этих самых микросервисов.
@Qnoize
2 жыл бұрын
Ну насчет того, что новый микросервис - новая задача, тут я не согласен. Сам Рачардсон(отец микросервисов) говорил, что их не должно быть прям мега много. Стоит только системы которые будут работать изолировано выносить в микросервиссы. Те не злоупотреблять, тут как и паттерны, главное не навредить и использовать с умом
@КоляГал-з2у
3 жыл бұрын
Актуально теперь переходит с php на rails, заранее спасибо
@wce-tube
Жыл бұрын
Отдельный респект за "функциональность" 👍
@evgenysinyakov8893
3 жыл бұрын
Привет, досмотрел до горизонтального масштабирования, не очень понял как можно горизонтально масштабировать монолит, что делать с базой данных, предпологается что бд должна поддерживать шардирование или как?
@FroL_Onn
2 жыл бұрын
Посмотрел залпом несколько Ваших видео. Класс! Спасибо большое!
@BohdanUdovychenko
2 жыл бұрын
Исходя из моего опыта одним из весомых плюсов разработки проекта, размазанного на микросервисы заключается в том, что значительно сокращается время на мерж конфликтов в гит. Потому что если человек 20 чёт одновременно пилит в монолит это просто трындец.
@Art-ub1sg
Жыл бұрын
Очень интересно! ждем вашего возвращения.
@johny_doe
3 жыл бұрын
Лайк за помытые волосы)
@pavelmihailov9901
3 жыл бұрын
6 минут видео и я уже несколько раз сказал "аминь". Микросервисы требуют очень хорошего ДевОпса, без него это будет не очень просто.
Я раньше думал что монолит это словная и не поворотливая штука, но сейчас я смотрю на проект на микросервисах и понимаю что не всё так плохо, особенно напрягает, не структурированные связи (с одного сервиса мы получаем одно с другово другое )
@Kostya2218
3 жыл бұрын
Поддерживаю, не всегда нужно стрелять из пушки по воробьям
@kairgeldi
2 жыл бұрын
Благодарю вас Ксения за такое видео! впервые слушаю и все понимаю, очень хорошо ложится ваше изложение :) У вас отличный канал!
@A11ez
3 жыл бұрын
1. По мне так микросервисы -- это в основном способ организовать команды разработки так, чтобы они не мешали друг другу. Когда в компании 200+ человек, не представляю как можно катать один монолит с правками от всей этой кучи людей. 2. Если появляется необходимость делать некие join'ы между сервисами, то возможны два варианта -- либо не нужно эти сервисы разбивать в отдельные приложения (ошибка проектирования), либо второй вариант -- можно подтягивать часть нужных данных в локальную базку, используя например кафку или даже можно делать синхронные запросы в фоне на апишку другого сервиса.
@TheNo0ker
3 жыл бұрын
дихотомИя - ставим ударение правильно.
@user-mt2if1ht8n
3 жыл бұрын
Пора! Пора уже раскрыть тему многопоточки
@nikolayserdyuk9753
3 жыл бұрын
Такое впечатление, что автор рассказывает про некий неудачно распиленный монолит.
@vh5360
3 жыл бұрын
хорошее видео для начинающих что за модель клавиатуры у тебя? все время на нее взгляд сходил)
@OverEngineer
3 жыл бұрын
Вот эта: www.amazon.com/Keyboard-TedGem-All-Metal-Spill-Resistant-Backlit/dp/B07RL7R55S
@worddoc4322
3 жыл бұрын
Такая компиляция инфы впечатляет) Спасибо за очень полезный контент
@digital_ninja
3 жыл бұрын
Пишу бэкенд банка. У нас 500 микросервисов и только разработчиков порядка 250 человек. Можно было бы слепить монолит из всех микросервисов, но нет железки, в которую бы мы могли запихать этот монолит. Так что микросервисы - неизбежное зло при достижении системой определённого размера. Видео - отличное, Ксения, спасибо огромное.
@dmitri679
3 жыл бұрын
В качестве ментора ты не пробовала себя ?
@serhiyokhrimenko2622
3 жыл бұрын
С праздником !!! Информация четкая, разложенная по полочкам. Спасибо
@maksimus.ssirotkin1124
2 жыл бұрын
Отличная блузка!)
@ongrustit
3 жыл бұрын
А видео по Ruby on Rails будет ?
@vitamin2845
3 жыл бұрын
Привет, Ксюша. Давно же тебя не было) С праздником) Надеюсь видеть тебя почаще
@НикитаЛяпин-ь5ц
3 жыл бұрын
Сложно, конечно, согласиться с аргументом про тех. долг. Особенность мозга человека такова, что он воспринимает ограниченное число обьектов 7 или 9 по разным оценком. Поэтому, кстати, функция с 9ю аргументами это предел... 20, 30 аргументов в методе это уже code smell и нужно рефакторить. Приблизительно также работает и схема с микросервисами. В монолите сложно уследить за всеми связями... С маленькими микросервисами гораздо проще... В целом по отношению к микросервисам применили все тот же трюк, что и при введении ООП в противовес процедурнуму программированию. Вы вводите классы и так группируете сложность на порции. Все что вы говорите это распространенное заблуждение. Оно называется Entity Service. Кратко говоря - микросервисы реализуют часто неправильно. Когда вы отлаживаете свой микросервис вы не должны лазить в другие сервисы чтобы дебажиться. Т.е. микросервисы делаются вовсе не так как вы предполагаете... Подробнее я описал здесь: architecture-cleaning.ru/2021/05/03/entity-service-antipattern/ Из того что вы рассказали - по всей видимости у вас крайне неудачное было разбиение на микросервисы...
@OverEngineer
3 жыл бұрын
в монолите не нужно следить за всеми связями. монолит разбит логически на подсистемы, контроллеры, библиотеки итп. Я работаю над одной частью монолита и могу не знать ничего про другую. Такое впечатление, что те кто приводит подобные аргументы никогда не работали с нормальным монолитом. Что касается моих "предположений" насчет микросервисов - это не предположения, а факты из реального мира, и я озвучиваю свой опыт, а не теорию, придуманную адептами микросервисов, не нашедшую воплощения в реальности
@proprosh
3 жыл бұрын
Видосик пока не смотрел, чисто лайчик пока поставил
@ilnurgabitov3264
3 жыл бұрын
Привет моему любимому айтиблогеру! Хочу в свои почти под 26 в айти) Я ex фин.аналитик( pro excel user, и не могу видеть эти таблицы) Знаком немного с пайтоном и умею делать data extract по sql. В виду того, что рынок по пайтону переполнен, а js является для меня высоким барьером, хотел бы узнать ваше мнение по golang-у. Перед написанием коммента, я мало что знал об этом языке и предпочту учесть ваши соображения по golang-у, а также перспективы переезда с этим, допустим в Норвегию. Стоит ли игра этих свеч?!!!
@OverEngineer
3 жыл бұрын
я всегда говорю в видео, что язык не важен, а перспективы есть всегда, все зависит не от языка, а от усилий, приложенных к поиску работы и удачного стечения обстоятельств. нужно позиционировать себя не как программиста на каком-то языке, а как бэкендера, фронтендера, специалиста по платежам, гейм девелопера итп. со знанием каких-то технологий в тч языков.
Пікірлер: 242