Про микросервисы
Вставка
- Опубліковано 20 тра 2024
- 00:00 О книге Production Ready Microservices
02:00 Что такое микросервисы и монолит
03:00 Рост операционных расходов
04:58 Увеличение количества кода и технического долга
06:53 Масштабирование
09:41 Производительность
10:47 Доступность
11:09 Service Level Agreement
12:53 Timeouts
15:14 База данных
Спасибо большое, пересматриваю спустя несколько лет, а если пересматриваю, значит ценно =)
Спасибо за видос по архитектуре!
Хорошо, что такие люди как ты бесплатно делятся своим опытом в таком понятном формате
1) монолит лучше микросервиса
2) в микросервисе упрощается обслуживание гита
3) правильно распиленный по ddd микросервис отлично борется с техдолгом
4) микросервисы - это от безысходности, а не от того, что лучше
Спасибо за видео. Всегда рад вашим видео
Привет, большое спасибо за видео, посмотрел почти все взахлеб, не пропадай надолго!
Благодарю за ревью книги!
Отличный анализ, поддерживаю идею о том что начинать нужно с монолита, а микросервисы внедрять по мере необходимости. Да и приставка микро мне кажется тут лишняя. Я считаю что бить приложения на части нужно в двух случаях, о первом вы рассказали в видео, когда растет нагрузка на какую-то часть и ее нужно срочно масштабировать, второй когда над приложением работает большая команда, тогда можно вынести часть бизнес контекстов в отдельное приложение и разделить команду. Что касается баз данных то я считаю что крупный монолит тоже должен работать на нескольких базах данных, отдельная база данных для каждого boundary context (DDD). Проблему кучи мелких запросов может решить паттерн CQRS. Коммуникацию между контекстами лучше изначально делать асинхронной используя event driven архитектуру. Монолит спроектированный таким образом очень легко разбивается на сервисы по границам бизнес-контекстов.
Отличный комментарий!
Посмотрел залпом несколько Ваших видео. Класс! Спасибо большое!
Благодарю за интересное и полезное видео! С праздником!
Благодарю вас Ксения за такое видео! впервые слушаю и все понимаю, очень хорошо ложится ваше изложение :) У вас отличный канал!
Какая вы классная) я в восторге! Спасибо за труд.
Хороший видос. Вчера как раз слушал стрим об этом
Спасибо за интересные видео
Здравствуйте. Обожаю ваши видео. Продолжайте пожалуйста.
Спасибо! Классное видео. Было полезно
спасибо за видео, было интересно
Был опыт не совсем микросервис, но делили написание функционала по языкам: На golang стримили видео, а взаимодействие с базой полностью на python. Такой вот микро-микро сервис был. Спасибо за интересный разбор интересной темы.
Спасибо, очень интересно.
Очень классное видео! 👍
Познавательно, спасибо. С праздником
О какие люди! С праздником!
С праздником XO
Классное видео, спасибо. Давно тебя не было.
По поводу проблем с микросервисами: мой опыт показывает, что все беды из-за человеческого фактора.
Основная проблема большинства это создание микросервисов ради создания микросервисов (что прослеживается и по примерам в видео).
В этом случае почти любая новая фича выносится в отдельный сервис особо не задумываясь, а надо ли ее выносить в отдельный сервис.
На моей практике микросервисы далеко не всегда такие микро, как все думают. И кстати RPC или REST далеко не самые хорошие способы коммуникации между сервисами. Вообще тема огромная конечно, могу говорить о ней бесконечно :D
Я бы еще добавил, что у идеальных микросервисов довольно высокий порог входа для бизнеса:
1. Нужны инженеры, которые в теме про всякие саги, транзакционность, брокеры сообщений и так далее
2. Нужна devops культура в компании и штат devops инженеров
3. Нужен сильный архитектор, который будет в состоянии за этим следить
4. Критически важно иметь хороших product managers особенно для проработки спецификаций
Для небольших компаний, увы, этот подход чаще всего не является выгодным.
Микросервисы редко пилят с 0, обычно либо команда готовая есть, которая на кафках/кассандрах/тарантулах собаку съела, а также реактивщине и обычной асинхронщине уровня узла через блокирующую многопоточку с мутексами-семафорами. Либо это легаси, проекту от 5-7 до 10-15 лет, и он либо монолит, который внезапно наконец дорос до клиентской базы, раздавливающей любое вертикальное масштабирование, либо монолит в свое время распилили в SOA с SOAP-контрактами и система тоже перестала справляться с нагрузкой, т.к. топология "звезда" и ESB-шина стала точкой отказа, т.к. в единственном экземпляре, в кластер не засунешь. Здравстуй новый раунд хантинга и просьба рекрутерам искать кандидатов с "MSA-архитектурой" в резюме, дабы всё попилить.
@@user-gh8sg8nr4w пилят пилят(
@@user-gh8sg8nr4w Наивный, в одном из проектов архитектор, ради удовлетворения своей течки на МС с ходу нарисовал схему из 4-х бэкхенд микросервисов, и 3-х фронтов, мы ох***, но его было не переубедить
На мой взгляд самая большая проблема в том, что иногда, до решения задач допускаются люди совершенно в них не компетентные. И тогда мы имеем наносервисы из говна и веток и мегалиты с неподдерживаемым кодом.
@@AndreySvyat ну в отдельно взятой компании может быть че угодно, речь была о том как переходят на MSA в большинстве случаев, так как стрёмно, если куча бабла вылетит в трубу из-за необоснованных ожиданий и непонимания уместности подхода.
Очень интересно! ждем вашего возвращения.
Спасибо 👍
Приятно слушать думающего человека. Спасибо и удачи! Абсолютно так и есть, и честно говоря, все еще хуже, и просвет не намечается. Какую технологию не возьми, монолит, трехзвенку, микросервесы и т.п., если критическое количество разработчиков с кривыми ручками превосходит порог выносливости системы, то никакая архитектура не спасет. Программер должен всю жизнь учиться, иначе выходит только г**нокод. Я сам программер 25+ лет, и все встречавшиеся проблемы были только в квалификации и прилежности программеров, не в архитектуре. Один раз правильно написанный код работает десятилетиями.
С праздником !!! Информация четкая, разложенная по полочкам. Спасибо
Отдельный респект за "функциональность" 👍
Видосик пока не смотрел, чисто лайчик пока поставил
спасибо большое за видел
Такая компиляция инфы впечатляет)
Спасибо за очень полезный контент
Спасибо за видео, спасибо за то, что делишься опытом!
С праздником! Мне очень нравится твой видео, я на втором курсе в Румынии и мне твой видео очень помогают. Можешь сделать и видео про алгоритмы и структуры данных? Спасибо!
Salut, sunt din Moldova. Tu cu ce te ocupi?
Отличное видео
Отличная блузка!)
классное видео!
Комментарий для интересного канала и человека 👍
Спасибо, интересное видео)
Привет, Ксюша. Давно же тебя не было) С праздником) Надеюсь видеть тебя почаще
Спасибо! Видео прям в точку, очень актуальное для меня. Как раз к нам недавно пришел новый архитектор со стороны заказчика, и хочет всё перефигачить на микросервисы. Моя аргументация, почему это лучше не делать, очень похожа на ту, что в этом видео.
Грамотно
Спасибо за видео!
Вы вернулись, очень рад видеть!
Поддерживаю, не всегда нужно стрелять из пушки по воробьям
Крутой обзор, больше таких видео.
Ох, только вчера заинтересовался микросервисами, читал про это, а сегодня целое видео в рекомендациях.
С праздником и с возвращением!!
Привет.
Вы правильно сказали что микросервис рассчитан на "задачу", а точней контекст.
При таком подходе мы не должны смотреть что написано в том микросервисе, мы специалисты в своём контексте.
В целом вся суть в том, что команда работает над одним или несколькими контекстами, но не наоборот. Команды изолированы друг от друга, и нет универсальных разработчиков.
Конечно у микросервисов очень много минусов, и самая основная это в понимании разделения - в большинстве случаев это монолит(в класическом понимании) с удалённый вызовом процедур, а приставку "микро" рассматривают как "микросервис должен делать что-то одно и максимально простое". Из-за этого и получается что нужно постоянно смотреть код другого микросервиса, а решение той или иной задачи сводится к редактированию N микросервисов.
Все правильно, микросервисная архитектура это очень не просто. Distributed transactions, eventual consistency, resilience: retries и timeouts - это все не бесплатно, только вот звучит как решение всех проблем. Да, уже есть много инструментария и он довольно неплохой, но он однозначно увеличивает сложность приложения.
Спасибо за обзор книги!, - теперь точно читать не буду. Про рост сложности там даже без дополнительных балансеров хватает - нужно собирать логи, метрики, обеспечивать распределенную трассировку, дебаг, зависимости, преемственность изменений апи, tail latency становится хуже просто за счет большего колва вызовов внутри системы, аутентификация, авторизация, шифрование трафика и тд.
У меня пока, к сожалению, не было реального опыта работы с микросервивасами, но у меня о микросервисах сложилось впечатление, что из-за тренда их неправильно воспринимают, и во многом, мне кажется, это вина маркетологов, которые продвигают технологию просто ради технологии.
В реальности, часть проблем, которые были освящены в видео объеденяются под одним названием: "Распределённый монолит". И на хороших курсах по микросервисам рассказывают, что "Распределённый монолит" != "Микросервисы".
По хорошему, любую книгу надо начинать со слов "Плохая идея начинать писать приложение сразу на микросервисной архитектуре. Правильный подход - это пилить монолит." Т.е. сначала вы пишете хороший модульный монолит (в иделе, возможно, следуя DDD, ведь в последствии bounded context'ы помогут вам проще вытащить сервис из монолита и посадить на отдельную инфраструктуру), а затем уже смотрите на узкие места в вашем приложении и выделяетет их в микросервис. И да, вы не обязаны "когда-нибудь в будущем" целиком переходить полностью на микросервисы, распилив весь монолит. Часто это не нужно, ведь приложение отлично работает и в формате монолита с выделенными на отдельные машины и замасштабированными парочкой микросервисов, которые ГРАМОТНО изолированы, чтобы была честная отказоустойчивость.
Т.е. к микросервисам, как и к любой другой технологии в принципе, надо подходить исходя из потребности, а не из трендов. Тогда польза микросервисов будет уже более явной.
По поводу разных языков, тот же Amazon, на сколько я слышал, все микросервисы пишет на Java и запрещает использовать другие языки. Т.е. не нужно следовать тренду, а просто исходить из потребностей бизнеса (:
Касательно разных языков - это больше маркетинговая уловка. Ни одна компания не будет пилить микросервисы на чем попало(всмысле отдавать выбор языка на откуп программисту/команде). А если придется писать свои собственные решения для какой-то узкой области? Как потом его переиспользовать в своей же системе, если изначально это решение писалось на Go, а соседний микросервис где мы хотим это решение заюзать написан на Java? Поэтому зачастую в компаниях с большой микросервисной архитектурой есть списки разрешенных языков для использования. Шаг влево - надо согласовывать.
Еее! Давно не видели! Хорошо что всё хорошо) С праздником!
С праздником! Скучал, обрадовал новый видос! :)
Очень круто разъяснила!! Лайк подписка!!!
полезная инфа однако...
Хей бэкендерша) А можно видосик по архитектуре (если это к тому относится конечно)? Как создавать правильные методы /не городить огороды без спагетти кода, вот это вотвсё /Что бы взрастить в себе чувство прекрасного и делать элегантные решения в коде
Я раньше думал что монолит это словная и не поворотливая штука, но сейчас я смотрю на проект на микросервисах и понимаю что не всё так плохо, особенно напрягает, не структурированные связи (с одного сервиса мы получаем одно с другово другое )
красивая блузка :)
Как всегда, топ-контент
Спасибо! Наконец, поняла, что такое микросервисы )
Незнаю как, но ютуб мне порекомендовал очень годный канал! Спасибо тебе Ксения за интересный контент!
"Нужно решать проблемы по мере их поступления" - именно этого не понимают команды, которые используют микросервисную архитектуру при создании нового приложения. В большинстве случаев - это следование моде.
Привет, досмотрел до горизонтального масштабирования, не очень понял как можно горизонтально масштабировать монолит, что делать с базой данных, предпологается что бд должна поддерживать шардирование или как?
👍
Отличное видео, полезное, спасибо!
С праздником, умница Ксюша💐
Ксения, здравствуйте. Спасибо за ролик! Я совсем новичок и мне интересна тема микросервисов. Но я сильно путаюсь в понятиях микросервисов/веб-сервисов и API. Может быть, вы бы смогли грамотно объяснить разницу? Я так понимаю, что микросервисы это именно архитектурный стиль, то есть у нас есть много разных веб-сервисов под каждую задачу. Например, user service, payment service, и тд. Но в свою очередь, веб сервисы являются web API. Правильно ли я понимаю, что микросервисы это и есть APIs, которые представляют собой список эндпоинтов, методов (get, post, etc)?
Или же есть API как входная точка, и он в свою очередь перенаправляет реквест на какой-то микросервис? Буду очень благодарна за ответ!
коротко - оба описанных вами варианта возможны)
Ждал твоё видео больше чем новую (старую) Diablo.
Согласен с тобой. Из моей практики, писал и монолит очень большой и микросервисы. И в монолите люди творили такое, что на голову не одеть. Но все решалось жесткими ревью и автоматизацией проверками.
А вот с микросервисами беда, не все видели очевидных проблем, типа ретраев, таймаутов, идемпотентности api, транзакционности процессов и почему нужно делать саги и тд.
Микросервисы это намного сложнее и требует понимания распределенных систем, и хорошей квалификации разработчиков.
Жду тренда на микромикросервисы, каждую функцию пишем в отдельном репозитории и общаемся с ней по интернету, неплохая идея. Жду книг по этой тематике
так чего его (тренд) ждать, он уже лет 6-7 как тут)
@@OverEngineer я придумал гениальную идею,... Ну такое я себе сохраню мб реализую(хотя в вебе и мобильных приложениях вообще не копаюсь, чисто С++), но идея прикольная...(в личку могу кинуть как идею для видео хД)
Serverless computing / FaaS это примерно оно.
@@niklkelbon3662 C++ есть в вебе, правда в основном в гигантах вроде aws/google/yandex
@@ColdBanehallow есть, но я просто этим не занимался, об этом говорю
Привет, подскажи, а какому уровню специалистов можно почитать? Нужно ли глубоко знать программирование?
нет, не нужно. там вообще ни одного куска кода нет)
Пора! Пора уже раскрыть тему многопоточки
Привет. А что за читалка?
Какую посоветуешь купить??
А видео по Ruby on Rails будет ?
🔝 1
Спасибо за интересное видео. Хотелось бы услышать ваше мнение по поводу книги Release It
Привет! Рад тебя видеть! 😍
По ходу следуюший твой ролик выйдет 1 мая.
А еще следующий - 9 мая!)))
да, ты угадал. по ролику на каждый социалистический праздник
@@OverEngineer можешь как - нибудь осветить свое видение книги Рихтера по С#? Очень интересно услышать твое мнение!
Не пропадай! 8-ми мартовский видос:))) Ксения, с праздником! Желаю тебе всех благ и с нетерпением жду новые видео!
Сопоставление микросервисов и монолита всегда обречено на провал...
Микросервисы это почти всегда следующая стадия развития монолита, а не его альтернатива.
Я бы сказал что цепочка такая: монолит -> SOA -> микросервисы.
Если ваша система не может быть поделена на высокоуровневые сервисы в SOA, то и в микросервисы соваться не стоит.
Касательно плюсов микросервисов - один из самых главных это возможность разделить ответственность по командам. Если у вас такого нет, и разрабы не ноют "да нам надоело ждать, пока они там свой спринт подготовят в своем команде Х" - то почти наверняка вам не нужны микросервисы. SOA - почти всегда золотая середина, к которой стоит стремиться.
Ксения, с 8 Марта! Счастья!!! Во всех его смыслах
Спасибо за видео, на часто встретишь по Ruby, да еще и интересно, легко и понятно)
Нормальная такая запивачка
лайк но книга для девопсов, я так понял в основном. Ждем обзор на хорошую книгу(адвансед) по архитектуре микро-сервисов. Если такие есть :) на 2 апреля, как-раз выходной.
Давно вас не было :) с праздником
Вроде микросервисы для двух вещей:
во-первых, если кодовая база большая и разрастается еще больше, в этом случае поддерживать микросервисный код в перспективе будет проще (но не сразу);
во-вторых, это точечное масштабирование.
Еще небольшая причина - это когда команды разные и на разных языках пишут, но это редкость.
Спасибо алгоритмы ютуба, ничего не понял, но было очень интересно!
С прошедшим праздником!
Спасибо за видео, натолкнуло на разные мысли и, да, понимаю что тема очень обширная и имеет множество вариаций.
Не уверен что такие термины как монолитная и микросервисная архитектура можно применять для сайтов которые чуть больше чем простой блог, но я попробую :)
На моем опыте были два сайта что имели схожий функционал, но бек энд одного был в рамках одного фреймворка что стал CMS'кой этого сайта, а у второго бек поделили на несколько частей.
Оба этих сайта имели страницы со "статичным" контентом, новостные ленты, интернет магазин и личный кабинет пользователя.
И во втором случае за интернет магазин отвечал свой бек, за личный кабинет свой, а все остальное ушло в третью часть бека.
И, как по мне, работать с этим вариантом было куда удобней чем когда все крутится в одном месте.
Эти "сервисы" были, почти полностью, независимы друг от друга (разве что айдишниками перекидываются если контент одного таки был связан с контентом другого сервиса), результат которых приходил на фронт, где по rest api, где через graphql.
И если надо что то доделать на стороне, например на стороне интернет магазина, то ты попадаешь в проект который только этим и занимается, что было удобней чем лавировать по беку одной CMS'ки где все, очень грубо говоря, в одной куче, особенно когда это касается вьюшек с html кодом.
Понимаю что по микросервисам можно упоротся так что каждая кнопочка станет отдельным микросервисом внутри которого ещё десяток наплодить можно, и вся эта вакханалия запросов летит с разных серверов, и тогда получается как пример с "плохим" ООП - чтобы получить банан надо и обезьяну сделать и джунгли посадить. Но это я утрирую :)
В этих вещах все таки должен быть здравый смысл и если работая с микросервисами половина работы это перекидывать данные между всеми ними, вместо того чтобы с джойнами поработать, то этот здравый смысл похоже ушел куда то не туда.
Когда же каждый отдельный микросервис максимально монолитен относительно своей задачи, то это уже куча лучше.
Или это противоречит самой логике микросервисной архитектуры?
как всегда круто .с праздником
На самом деле, достаточно уверенные аргументы в пользу сторонников монолитной архитектуры. Хотелось бы чего-то добавить, но особо и нечего.
В принципе соглашусь с аргументами, но по масштабируемости, я все таки не уверен - учитывая добавление новой функциональности, вы можете обновить один сервис, не затрагивая функциональность основных в глобальном смысле.
Как по мне основная проблемы подобных решений: 1) обеспечение корректного взаимодействия между сервисами (делаете вы это посредством REST-протоколов, месседж-брокеров и пр.), 2) Конечно же отказоустойчивость, но тут обоюдоострый клинок (возможно вы знаете больше и скажете, что я не прав) и полностью согласен с обработкой таймаутов, но тут можно постараться корректное время выставить. 3) Ну и слишком сильное дробление логики и рост числа этих самых микросервисов.
хорошее видео для начинающих
что за модель клавиатуры у тебя?
все время на нее взгляд сходил)
Вот эта: www.amazon.com/Keyboard-TedGem-All-Metal-Spill-Resistant-Backlit/dp/B07RL7R55S
Привет моему любимому айтиблогеру!
Хочу в свои почти под 26 в айти) Я ex фин.аналитик( pro excel user, и не могу видеть эти таблицы)
Знаком немного с пайтоном и умею делать data extract по sql. В виду того, что рынок по пайтону переполнен, а js является для меня высоким барьером, хотел бы узнать ваше мнение по golang-у. Перед написанием коммента, я мало что знал об этом языке и предпочту учесть ваши соображения по golang-у, а также перспективы переезда с этим, допустим в Норвегию. Стоит ли игра этих свеч?!!!
я всегда говорю в видео, что язык не важен, а перспективы есть всегда, все зависит не от языка, а от усилий, приложенных к поиску работы и удачного стечения обстоятельств. нужно позиционировать себя не как программиста на каком-то языке, а как бэкендера, фронтендера, специалиста по платежам, гейм девелопера итп. со знанием каких-то технологий в тч языков.
Если сомневаетесь - делайте монолит, его потом будет проще разбить на отдельные сервисы. Соединить отдельные сервисы в монолит будет гораздо сложнее
Возможно в книге шла речь о крупных монолитах где сложная беспорядочно переплетающая инфраструктура только для одного узла, во внутрь обеспечивая сильную связанность. Поддержка таких систем сильно сложна и не поддается какому-то быстрому анализу. По поводу кода, в больших монолитах нельзя так просто взять и найти что-то, они операются только на программную архитектуру, только знание программной архитектуры помогает хоть как-то понять как это все работает) Я думаю автор книги не достаточно раскрыл тему, чтобы донести мысль.
Да с микросервисами все так, там много кода и все сложно. Но поверьте есть монолиты, в которых есть тупиковые ситуации и они как неповоротливые гиганты, с ними сложно (не подходящее слово) работать. Если с микросервисами сложно то с монолитом тупик, костыли, нереально, невозможно... Такие фразы там норма
еее пупсик,новое виео!!
Спасибо за видео, очень интересно! Сейчас как раз на проекте происходит распил монолита на кучу микросервисов, причем с изменением стека .net -> java. И с моей точки зрения это только усложняет поддержку и увеличивает расходы. По крайней мере уже много раз сталкивались, что каждый микросервис реализует все по своему и приходится по несколько раз все согласовывать в плане интерфейса взаимодействия и тд.
Спасибо за видео, подскажите, Ксения, какая у вас клавиатура?
Еще можно добавить в минус, что для такого зоопарка микросервисов надо как то поддерживать тестовые среды в актуальном состоянии.
Юху!
Вопрос знатокам, как компоновать(JOIN) данные из разных баз данных? на уровне приложения!
Согласен! Этот фапинг на микросервисы создаёт не менее стремную головную боль.
Привет, с прошедшим праздником чудесный программист 🥳🥳🥳