Микросервисы Простыми Словами за 1 Час
Vložit
- čas přidán 23. 07. 2024
- Шпаргалка "Микросервисы: вопросы с собеседований": www.faang.school/java-junior-...
Микросервисы стали незаменимым стеком в IT. Умение с ними работать - необходимый навык любого современного программиста. И в этом ролике я подробно расскажу о микросервисной архитектуре простыми словами и покажу, чем она лучше традиционного монолита. Гарантирую, что к концу видео вы будете прекрасно понимать, что такое микросервисы, для чего они нужны, а главное, как с их помощью получить крутой оффер.
Таймкоды:
00:00:00 - Вступление
00:01:11 - Что такое монолит?
00:05:56 - Проблемы монолита: жесткое связывание
00:08:28 - Проблемы монолита: ответственность
00:09:44 - Проблемы монолита: надежность
00:13:37 - Проблемы монолита: деплой
00:17:32 - Проблемы монолита: масштабирование
00:21:09 - Что такое микросервисы?
00:24:25 - Преимущества: гибкость
00:27:48 - Преимущества: изоляция
00:31:06 - Преимущества: масштабирование
00:33:37 - Преимущества: ответственность
00:34:50 - Преимущества: надежность
00:36:39 - Что мне выбрать: монолит или микросервисы?
00:39:38 - Проблемы микросервисов: сложность
00:41:36 - Проблемы микросервисов: коммуникация
00:43:06 - Проблемы микросервисов: согласованность данных
00:46:06 - Проблемы микросервисов: дебаг
Обучение:
Java Буткемп: www.faang.school/java-bootcam...
Java Magics. Бесплатный курс для начинающих: www.faang.school/java-magics?...
Бесплатные материалы для подготовки к собесам:
www.faang.school/java-junior-...
Социальные сети:
Instagram: / faang.school
LinkedIn: / vlad-mishustin
ТГ-канал “Road to FAANG”: t.me/fakng_eng
ТГ-сообщество FAANG School - t.me/+fgoLmBk0B1EyODk0
ДИСКЛЕЙМЕР
Любая информация, высказанная в данном видео является моим личным мнением и никак не относится и не отражает позиции моего работодателя или любых связанных со мной организаций.
Любой код, документация, логи или диаграммы, показанные в видео, являются моими личными макетами, написанными/созданными в мое свободное время на своей собственной машине, конкретно для демонстрации в роликах, никак не относясь и не используя интеллектуальную собственность моего работодателя или любых связанных со мной организаций.
Шпаргалка по Микросервисам: www.faang.school/java-junior-library?
Мой Java Буткемп: www.faang.school/?
Java Magics. Курс для начинающих: www.faang.school/java-magics?
Можешь дать топ 10 тулзов спринга которые ты юзаешь на проектах и которые востребованы
Бро, сделай подобное видео про Kubernetes. Лайк, кто за)
Да зачем он нужен, этим девопс занимается, программисту это не к чему
@@user-jw7tj1mp6o не совсем согласен. Всё чаще и чаще от девелоперов требуют разбираться в оркестраторах. Не везде есть штатные девопсы.
@@user-jw7tj1mp6o супер супер спорно. Многим разработчикам очень нужны знание кубера
@@user-jw7tj1mp6o чтобы пет-проекты в соло поднимать хотя бы)
@@user-jw7tj1mp6o с таким мышлением ты ограничиваешь свое развитие и как следствие доходы
ждём про кафку всей маршруткой
Влад, ждём кафку, спасибо за видосы!
Ждём разбор Кафки. А ещё лучше её заменитель - Redpanda. А ещё лучше сравнение обоих
Как же приятно тебя слушать, когда ты не транслируешь свой (надеюсь - временный) нарциссизм.
Великолепное видео.
Слушал полутарочасовые лекции по Кафке - не понял, зачем нужна Кафка. А ты так запросто объяснил, даже не акцентируя на этом! Теперь абсолютно ясно. Супер!
12:48 боже, Леонардо ДиКаприо в лучшие годы...
Влад, спасибо тебе безграничное. Очень важная, базовая тема для всех, кто в айти.
Спасибо, Влад. Очень полезное видео!
Спасибо, Влад! Я благодаря твоим видосам начинаю понимать, что у меня на работе происходит ))
Очень крутое видео, классный автор канала, так легко все объясняет, что даже мне стало понятно! Отдельное спасибо за прекрасную инфографику, представляю сколько труда в нее вложено! Вы большой молодец!
Спасибо вам огромное! , очень наглядное и познавательное видео!
Спасибо за видос!Доступно, красиво!
Спасибо! Кратко, понятно, полезно!!!
Крутой видик, спасибо большое за труд
Можно также монолит пилить в разных репозиториях. Делаешь артифакт, через зависимость подключаешь к основному ппроекту
Таня привет! Очень интересный влог, здорово, что у вас много разных мероприятий, которые собирают людей для общения, да ещё такое разнообразие по интересам. Покупки супер! Правильно, себя надо тоже баловать❤
Спасибо и от тестировщиков!)
Про брокера Kafka прям очень жду. Сейчас актуально - устроился в сопровождение внедрения ПО, много вопросов. По большей части сам разбираюсь в архитектурных схемах, свои проекты ещё не начались.Подписался!
Это было очень интересно!
Благодарю за видео. Очень полезно.
Вы так круто и понятно рассказываете, респект 😊
Сделайте, пожалуйста, про REST подобное видео
Let'sss gooo!🔥🔥🔥
24:30 преимущества по сравнению с монолитом, оговорочка
Хорошо рассказываешь, анимации достойные. Не торопливо, подробно, по несколько раз с разных сторон, но не скучно. Лайк поставил, подписался.
Можно было ещё упомянуть про то. что когда на микросервисы делишь апу, то приходится выделять общие либы, которые тоже кто-то должен поддерживать. И самое херовое, когда в этих либах появляются долгоиграющие баги. Плюс проблемы подключения плагинов через позднее связывание, из-за которых приходится писать обвязку адаптеров, что увеличивает вложенность кода. А в случае работы с нескольими сторонними сервисами, у которых схожее, но всё же отличное апи, в адаптеры приходится вставлять костыли.
Молодец. Разжевываешь очень хорошо. Спасибо тебе за это. Лайк и подписка
Оооо да ждал такое видео
Огонь, жду видео про service discovery, service registry, service mesh, saga, kubernets...
Очень классное объяснение, молодец !👍
Ура! Микросервисы!!!
Очень кстати!
Крутой и очень понятный разбор. Жду теперь ролик про Kafka
Хотелось бы видео про load balancer. Спасибо за труд!
Спасибо Влад, топ
видос лютая имба, автору +rep
Поинт про масштабирование монолита и нагрузку на железо неверный.
В микросервисах нагрузка на CPU, память и особенно сеть в разы выше и затраты на железо куда больше.
Связано это с тем, что в микросервисах очень много сетевой активности, и вместо того чтобы дешево вызвать метод в монолите, в микросервисах нужно делать RPC запросы либо через gRPC, что менее накладно, либо через http. Плюс появляется нехилый оверхед из-за latency.
Также по памяти требования намного выше, если раньше у вас было 10 инстансов монолита и они жрали по 500мб памяти, то после распила на микросервисы это будет 100 инстансов по 200-300мб, потому что оверхед на рантайм всегда есть, глупо его игнорировать.
как думаешь, компании будут продолжать переходить на микросервисы или возвращаться обратно к монолитам?
Ляяяяяяяяяяяяя Пушка бомба аллигатор Жирный плюс за то что он поясняет что сервак это отдельный комп Как я раннее писал под одним видосом Что так же при введений нового слова Диплойд ( так же объяснил и рассказал что это такое и с чем его едят) Так же очень круто что он не забывает показывать все это дело в картинках ( в схемах) , а так же что бы все двигалось Так же круто он ввел новую фичу с ценником 1000$ или же 3000$ ( новые пользователи лучше усваивают и понимают , для чего и за чем Так как на деньгах тоже проще объяснить ) Не забывает повторять и объяснять все те же слова что были в предыдущих видео (повторение мать учения) Что подчеркивает , внимательность Влада , а так же понимание и улучшения скила в учительском понимание Что бы донести информацию до любого человека и без разницы чем он занимается или же кем работает Работа учитель донести информацию до любого человека хоть сантехник, хоть бухгалтер, хоть парикмахер Монолит и микро -сервис знал чем отличаются Больше всего я смотрел как он работает над собой и как он качественно доносит информацию до зрителя И это просто пушка А не как у меня на курсах , ментор знает за программирование, но ни черта толком не может объяснить порой на человеческом - колхозном языке Что бы людям было понятно Программист который способен объяснить и разжевать на простом человеческом языке Это прям высший пилотаж ® ► ♫ ☼ ◄ Зачет √
Привет, очень жду docker compose))) логичное продолжение docker
Имхо, применение мс архитектуры зависит от потребностей проекта. Развертка и настройка не из самых простых. Следовательно выбор зависит от бюджета проекта и временных рамок...
Офигенно
Про ТУЗы интересно,сам процесс подключения к БД, к Кафке и т.д. Про установку SSL сертов. Много в общем вопросов по инфраструктуре во всех контурах.
Это же "чистая архитектура"! Привет дяде Бобу!
Анимации и правда помогают)
Привет из Воронежа)))
прикольная прическа на 12:48
ждем видео про кафку и спринг
Ох уж эти игры-сервисы, достали...
Влад опять радует своих подписчиков топовым контентом, спасибо)
(Опоздал на премьеру 😢)
Привет! Что думаешь про копилот в VS Code?
Надо видео, как на практике можно реализовать Сагу)
Для новичков видео будет полезным. Но про то что микросервисная архитектура значительно сложнее тут можно подискутировать. Если каждый микросервис написан грамотно и предоставляет апишку т.е. чёткую систему для взаимодействия с ним, а так же отслеживает успешное получение данных другим микросервисом то разработка такого приложения просто в кайф. И да у каждого микросервиса обязательна своя отдельная база данных, а если от неё что-то нужно другим микросервисам апишка в помощь.
и это ничем не будет отличаться от связанности между компонентами в монолите
Влад, спасибо. Кафка, редис, GRPC были бы интересны.
отличная прическа🔥
За монолит!
Молодец
Было бы славно посмотреть про Spring
Да. тоже бы посмотрел бы про него. Надеялся что следующий видос за это будет. Так как вроде понимаю. а вроде нет(
А что именно не понимаете? Там же не так сложно, у Алишера есть хороший гайд @@StellaDemchenko
документацию открой да почитай
@@user-lv4tr2yx6wна душничах
Влад, привет! Куда тебе по поводу сотрудничества написать? (Криптопроект Blum)
го видос по кафке:)
Спасибо, Влад, очень интересно рассказываешь. За*6иcь 👍
Короче: Микросервисы это не про экономию вот вообще, обычно это сильно дороже монолита, так как 1) сервера под них в расширении буду сильно дороже на операцию, 2) команды работающие на разных стеках делают команды разрабов очень немутабельными, чаще всего спеца из одной команды нельзя заменить на спеца из другой, надо искать нового человека, 3) нужны спецы с высоким уровнем компетенции, и их нужно много, сильно больше чем на монолит, 4) Нужно бОльшее количество девопс/админов, так как структура сильно сложнее в плане построения железной инфраструктуры, и софта там больше, и софт со своей спецификой, короче и стоить эти спецы будут сильно больше. Кроме того, не забываем, что для запуска микросервиса и монолита в общем случае нужно не сильно разное количество ресурсов, так как есть общие обязательные накладные расходы, как уже было сказано - сервис это небольшой монолит, в них всех будет инициализация бд, запросы в редис, пользователи и прочие повторяющиеся сущности, на которое сжирается нехилая часть ресурсов машины, которые в микросервисах каждый раз дублируются в каждом инстансе.
С другой стороны, чуть выше отказоустойчивость, там есть нюансы, но в целом разнесенные по разным серверам монолиты с балансером наверно более устойчивы чем 20 отдельных серверов, чисто статистически, в то же время потеря 2 серверов из 20 это просадка на 10%, в то время из 3 монолитов 1 выпавший - сразу 30% просадки... Ну и опять же - чаще все упирается в бд, чем в код, по этому все еще сильно зависит от архитектуры хранения и синхронизации... Ну и основной плюс - возможность бесшовно использовать разные стеки в одном проекте.
Влад, привет! Хотелось бы узнать, как программисты в бигтех компаниях используют ИИ для разработки?
1. Разработчик ленты сальтерил в бд таблицу изменив колонку с varchar2 на clob, а остальные сервисы ожидают тот же varchar2 - куда пойдут все микросерсисы?
2. Масштабирование - как правило это все на ВМ и гипервизор становится тем что ранее был монолит и т.о. только усложняется все , без полезного выхлопа.
3. Обмен между сервисами очень неприятен для отделов безопасности и доставляет проблемы при работе, т.к. могут вводиться правила-запреты которые сведут на нет работоспособность.
На счет первого. На примере . net если разраб поменял колонку то он скорее всего и модель на которую маппит таблицу тоже обновил и тогда апи модель поменяется и можно обновить нугет пакет нашего сервиса. И все проблемы нет все остальные сервисы обновят нугет пакет и будут ждать уже новый тип
Очень понятно, даже для полных нулей)
Не кажется ли что проблема жесткого связывания, это чисто архитектурная проблема монолита? И просто замена локальных вызов на вызовы по сети никак проблему не решает, кроме как заставляет программистов вязаться по веб интефейсам, и тем самым косвенно лечит архитектурные проблемы. Так почему же просто изначально не лечить архитектурные проблемы, а не городить костыль в виде микросервисов которые используют вызовы по сети вместо локальных вызовов из одной код бейз, тем самым существенно замедляя работу приложения, +ряд других проблем микросервисов
шш! тише ты, нельзя такое говорить еще :)
В чем разница между микросервисами и СОА (сервисно ориентированная архитектура) ? Если можно - пример СОА. Спасибо
Ооо, надеюсь будет топчик
Влад, выхожу на маркет через пару месяцев, обучаюсь в буткемпе уже 8 й месяц. Интересно, можно ли с тобой провести пару индивидуальных курсов? За видео огромное спасибо, просто нереально, тебе нужно на английском выпускать тоже, уверен аудитория увеличится в разы.
Влад, а где тут место для Desktop интерфейса 3:00?
Объясните про денежные затраты используя микросервисы и монолит. Разве нельзя было купить на такие же деньги серверы при монолите, как при микросервисах ? По сути вычислительная мощность та же и при равных нагрузках будет работать одинаково. Спасибо за видео!
Вопрос о монолите. Так разве принципы SOLID они не об этом в том числе говорят, чтобы не связывать компоненты? Абстракция, инкапсуляция, внедрение зависимостей... Всё что ты перечислил в недостатках монолита скорее выглядит как кривая архиктерура, или я что-то не так понял? My bad, разобрался. Архитектура это только одна проблема, куда важнее возможность масштабирования при развертывании. Тем не менее, думаю, стоит упомянуть, что в идеале, даже разрабатывая монолит, лучше заранее планировать архиктуру так, чтобы компоненты были минимально связанны друг с другом. И единственная разница, которая должна быть в этом случае -- что данные передаются через внешний источник, а не внутри приложения. И тогда будет удобнее поддерживать и удобнее расширять и при необходимости сделать компоненты внешними, просто изменив каналы получения и отправки данных.
Сделай рум тур квартиры
Лол, всё думал, что там за микросервисы эти прекрасные существа придумали, а оно вон чё) То, что можно решать в отдельном классе делать отдельной прогой... ихи-хиыы
Я вот чего не понимаю. У меня 100 микросервисов, и все допустим должны отправлять информацию в микрсоервис с уведомлениями после операций. По хорошему у меня должен быть отдельный компонент с DTO для передачи данных. Но тогда вроде как теряется смысл этих микросервисов, ведь все зависит от одного комонента. А с другой стороны пилить 100 а может и 1000 одинаковый дто, а потом когда вдруг надо туда что-то добавить. Заходить в каждый микросервис и изменять. Объясните плиз этот момент.
Kafka этим занимается
"отдельный компонент с DTO для передачи данных"
Теряется смысл микросервисов из-за жесткого свзяывания, каждый микросервис должен иметь свое DTO
"А с другой стороны пилить 100 а может и 1000 одинаковый дто, а потом когда вдруг надо туда что-то добавить. Заходить в каждый микросервис и изменять."
Микросервис иметь возможность изменять свои DTO без необходимости одновременного изменения других микросервисов. Сервисы должны быть толерантными к читателям, толерантным писателям и отказоустойчивыми. В противном случае они вызывают такое связывание, которое делает архитектуру сервиса бессмысленной. Если трем микросервисам нужны одни и те же DTO, вероятно, что-то пошло не так во время декомпозиции на микросервисы.
@@woogie7961 При чем здесь кафка?
@@Andrew_Hales Так по итогу, если вам необходимо в ваших 10 сервисах обращаться к сервису с уведомлениями. Вы будете в каждом сервисе создавать модель для отправки данных в сервис уведомлений ? Разве это не перечит DRY ?
@@reform3831 придется решать нужна ли нам независимость микросервисов и слабое связывание, но будет дубликация кода. Или же мы можем позволить себе сильно связать эти 10 микросервисов каким-то модулем с общими дто, который будет шариться межу ними, но тогда теряется смысл микросервисов как идеи
Кроме всех спасибо. Не забуду процитировать красное слово с одного из последних слайдов: "ОШЫБКА!", все Gramma Nazi снимают шляпу))
1) а у микросервисов нет такого же жесткого связывания? Например, я поменял систему нотификации так, что ожидаю от сервиса немного другой http запрос. Получается, что мне нужно лезть в сервис постов и менять отправку http запроса. И, в теории, кол-во таких связей будет столько же, сколько и в монолите. То есть, где в монолите я вызывал функции, в микросервисе я ожидаю http запрос.
2) если у коллеги случился баг при разработке в монолите, то его гит ветку можно просто откатить, оставив всё остальное, не? А если он менял http запрос в микросервисе, то опять же нужно выкатывать два сервиса разом без возможности отката только одного.
3) по масштрабирование. Очень непонятно по поводу нового железа для монолита. Из рассказа получается так, что для поддержания ленты новостей мы покупаем новый сервер, но используем только часть производительности. Но это же не так. Если нагрузка на остальные части монолита небольшие, то вся оперативка уйдет на ленту новостей. Не может же оперативка уходить в "никуда", само устройство пк вполне справляется с распределением на задачи. У микросервисов появятся дополнительные траты на ту же кафку/передачу http запросов.
4) Мне нравится, что в "Преимущества: надежность" показан отказ именно нотификации. А если откажет лента новостей? В любом случае большая часть функциональности ляжет. Как-будто был выбран самый удобный пример для автора. В случае монолита придется конечно перезапускать всё приложение, но хотя бы можно удобно отдебажить и найти ошибку, что как-будто более важно при отключении важных сервисов (например ленты новостей).
Я чувствую, что тупенький, но как-будто из перечисленных преимуществ только разработка на разных языках отдельных микросервисов является неоспоримым баффом.
Ответ почти на каждый вопрос - оркестрация. С помощью нее можно подключать, отключать, расширять и менеджить нагрузку на микросервисы. И она кстати и в монолите применяется не хуже.
Ты все верно понял, многие минусы притянуты за уши, думай своей головой, почитай аргументы в спорах микросервисы vs модульный монолит и принимай собственное решение что когда лучше подходит. Я же лично за последние пару лет вижу много критики микросервисов и не за горами уже спираль истории где все будут микросервисы собирать в модульный монолит (мб термин только другой придумают) чтобы снизить цену эксплуатации
Получается, микросервисы это типа ООП в программировании. Где один класс, одна функция, универсальный интерфейс и тд.
А как это все связывать? например сервис отправки уведомлений, нужно с сервиса какого то отправить увед, что http запрос что ли делать? я правда не пойму этого..
По сети. К примеру, Kafka?
Этим же вроде занимается Kafka, парень это в ролике и объяснил. Не нужно ничего в ручную отправлять.
я тупой забейте я тупой забейте я тупой забейте я тупой забейте я тупой забейте я тупой забейте
Фига постригся )
Изучаю, фронт, но ваше объяснение очень понравилось и затянуло. Спасибо за подробное и емкое разъяснение довольно непростой темы
Лучше с ходу определиться, быть фронтендером или бекендером, а то можно стать как я, недофронтендером и недобекендером)
Да есть понимание как работает все вместе, фронт и бек, запросы какой путь проходят, но рынку и хорошим надежным фирмам редко нужны такие...
@@Pahan282 Мне больше фронт нравится. Люблю визуализацию своей работы. Да и попроще будет. Но минус в том что во фронте все гораздо более динамично развивается и то что ты учил год-два назад, уже недостаточно.
А почему нельзя написать монолит в котором нету жесткого связывания, в котором каждий сервис не зависит друг от друга насколько это возможно?
Потому-что можно :-) Но да, надо следить за этим конечно.
Кстати если оно так сделано, то потом при необходимости будет проще выносить некоторые куски в отдельные микросервисы.
Можно и нужно 👍 и правда при необходимости легче будет вынести в микросервисы. А необходимость может возникнуть, когда обнаружится, что одна часть приложения нагружена сильнее остальных, а тратить кучу ресурсов для развертывания этого большого монолита не захочется, инфраструктура все таки вещь дорогая. И захочется отмасштабировать только этот кусок приложения - и вот для этого уже и нужно будет выносить этот кусок в отдельное приложение
коротко про монолит "один за всех, все за одного"
А почему каждый микросервис должен использовать свой сервер?
Я думал всегда, что например Web-Server для фронтенд используется кластер с нодами. И там весь фронтенд
А для микросервисов используется свой кластер, там бекенд и могут быть запущены 10+ микрсоервисов. Но перед ними стоит некий шлюз API
А для база данных, используется свой кластер с настроенными репликациями и шардирование.
У кафки тоеж свой кластер со своими нодами.
Если не трудно, сделай видео про инфраструктуру
Я думаю подразумевается любой агент носитель в качестве независимой еденицы, которую можно скейлить, сервер тут как собирательное понятие
@@Andrew_Hales А понял)
Картинки клевые, но объяснение уж очень поверхностное.
Не надо было мне гуглить жесткое связывание ...
😀
😂😂
Как хорошо, что на php нету компиляции и при деплое монолита не нужно второй сервак запускать для деплоя
В пхп своих проблем хватает
зато нужно запускать веб сервер который проксит запросы, а если надо еще и сервить статику из пхп контейнера то там вообще швах :)
@@realcnbs типа на других языка не нужно ставить веб сервер, который будет обрабатывать входящие запросы?
Я не защищаю php, хоть сам на нем пишу (с каждым годом склоняюсь к Java из-за вакансий, т.к топ фирмы на нем пишут).
Каждый инструмент хорош по своему. Какой-то за счет компиляции выигрывает в скорости, какой-то язык за счет строгой типизации позволяет создать меньше багов...
Просто в шутку написал что "Второй сервак не нужен для деплоя на пхп", просто на горячую через git pull или CI/CD файлы меняешь и кеш сбрасываешь.
@@Pahan282 Это я из опыта, спринговые приложения сильно легче деплоить, прям сильно. Деплой пхп в контейнере - это всегда боль, особенно легаси.
@@realcnbs а в чем сложность то? Зашел по ssh, выкачал с гита изменения и пересобрал контейнер, иной раз даже перезапускать его не нужно, если изменения только в коде.
С CI/CD просто запушить в гит нужно, он сам все сделает это...
Я конкретно про Docker говорю и про монолит. Не знаю как с микросервисами там дела обстоят, но не думаю что сложнее... Инструменты те же, они не привязаны к языку, суть везде одна, закинуть изменения на сервер и почистить кеш и перезапустить.
24:25 Ляп вроде?) бывает
да, и еще правило не писать на яве и питоне. ну фронтовики ладно, но бек то программисты пишут
Сохранишь видео?
Да, это ведь премьера, а не трансляция
Да, сохраню
ну не совсем верно на 17 минуте, что если какой-то баг у другой фичи другого разраба, то твою новую фичу с новыми изменениями тоже откатим. Все разрабы в команде на одной ветке разрабатывают что ли все?)тогда это проблема гитфлоу, а не монолита)
Вы же знаете чей это баг, поэтому ветку фичи с багом, которую смержили мастер нужно просто ревертнуть. Тогда другие новые фичи останутся, т.к. откатили только одну.
Наверное стоит вопрос в Availability системы, что при баге в каком-то компоненте придется откатиться назад все приложение, а не сам компонент независимо от приложения - это может занять время простоя всей системы, что принесет убытки и нарушит допусти sla
Также если баг уже давний, то поверх него могли произойти другие изменения, что задевает тот же исходный код и тогда придется откатывать не одну фичу а целый ряд и это сложнее. Я не говорю что в микросервисе такое не может произойти, просто в монолите это будет сложнее решить из-за tight coupling дугих компенентов
@@Andrew_Hales эта проблема есть и в микросервисаах, для этого придумали канарейки, а откат сделать в обоих случаях не проблема
у нас в РФ вилка 100-200 ниочём!
под каждый сервис, отдельный сервер? огромная экономия? 500$ получилось экономии, но теперь нужен devops - но на 500$ devops вы не найдете
микросервисов больше чем пользователей этого приложения
МИХЪХАСЕХЪВИСЫ
Если коротко, то вместо одного большого монолита делаем много маленьких независимых монолитов - это и есть микросервисы. Ну и еще 48 минут воды.
Монолит топ!!!!!!!!
Блин, ты вводишь в заблуждение относительно монолита.
Скейлить и балансировать можно и монолит, а вот ревьювить и сотни контрибьютеров нереальная задача.
Проблем с серверами меньше чем с людьми.
Нуууу...такое. Надо уметь писать код так, чтобы ты не лазил по всем другим компонентам. Работаем 10 лет с монолитом, не было никаких проблем с сильной связанностью. То есть, сильная связность это не проблема монолита, это проблема архитектуры кода, др. словами уровня кривизны рук. Получается, что микросервисы -- это костыль, чтобы не учиться писать код правильно. 😂
наааес
TL;DR: Очень притянуто за уши и местами выводы весьма странные, местами вообще противоречивые.
1) Изолированность. То что преподносится как "отличие" монолитов - жесткое связывание, на самом деле проблема кода и (не)соблюдения SOLID, хотя на самом деле при верном проектировании мы получаем абсолютно тот же обмен данными как в монолите (мы передаем данные через DTO, либо четко следуем интерфейсам и используем геттеры и сеттеры), но передача данных осуществляется внутри приложения, а не на разных серверах, что сильно быстрее и не имеет тех проблем обмена данными, имеющихся в МС.
2) Ответственность. Ну и деплой сразу. В любом случае - монолит или МС - вы должны знать что делают другие части, по сути в обоих случаях вы используете АПИ другого объекта. Так что все равно надо понимать как работают другие части, как бы не хотелось ограничиться чисто своим кусочком кода. И не знаю как в "больших компаниях", но в тех где я работал обычно есть правило - один комит по задачам не деплоится с другим. Все идут в своем порядке. Тогда откат одной фичи не ломает остальной рабочий функционал. Ну и это более актуально для компилируемых приложений, для условного пхп фикс не требует отдельного сервера и прочих танцев для замены 1 файла.
3) Надежность. В принципе, обсуждаются те же проблемы что и с остальным - связанность, которая как бы не проблема монолита, а проблема кода. И проблема сложных зависимостей и связанных с ней багов так же остается в МС (компоненты так же обмениваются данными, просто это происходит чуть сложнее), теперь ее просто сложнее отследить. К слову, при "отваливании" каких-нибудь нотификаций, монолит абсолютно так же не развалится и не пойдет в разнос, просто пропадут нотификации. А при отваливании авторизации проблемы будут при любой архитектуре во всем приложении.
4) Масштабирование. Тут немного странно это подается, так как нагрузка в современных приложениях это не "код ленты не вывозит", а в 99% случаев это либо нагрузка на бд, либо запросы с внешних апи, которые имеют свою пропускную способность и лимиты/квоты. И тут как бы вы не масштабировали сервера ленты, база быстрее не заработает. Предположим, что у ленты свои сервера бд, которые имеют чисто свои данные по ленте, и больше ничего, все остальное что напрямую не относится к новостям. Тогда мы разворачиваем кластер и добавляем пару серверов для бд ленты... Беда в том, что как и говорил автор, все компоненты связаны, не напрямую, но запрос ленты тянет за собой запрос на рекомендации, на пользовательские данные, на еще кучу всего, и при этом все это не бегает внутри приложения, а бегает по внешним сервисам, которые в итоге получают практически такую же нагрузку, но все это еще накладывается на накладные расходы промежуточных линкующих сервисов/сетей... Молчу о том что есть "небольшой" нюанс - в итоге будет дешевле поставить +пару серверов для монолита, чем расставлять на каждом поднагруженном сервере по паре серверов послабее, так как чем мощнее сервер, тем дешевле он выходит на условное количество операций/сек.
5) Гибкость/изоляция МС как преимущества: Две основные фичи - изоляция (о чем я выше говорил) и разные стеки для разных микросервисов. С изоляцией спорно, "но окэй", а вот зоопарк стеков технологий это прям киллер фича микросервисов. Собсно рождение МС как концепции начиналось именно с выноса кусков монолита в отдельный сервис, так как этот кусок на текущем стеке "не вывозит". Дальше эксперименты по разбивке всего на все и вот эти все попытки связать кучу всего в одно работающее распределенное приложение. На сегодня это уже +-отлаженный процесс, так что особо прям фантазии для построения МС архитектуры много ума не надо, читаем доки, настраиваем, профит. И по скилам - особо от монолита не отличается (так как по сути мы и пишем маленький монолит), проблемы начинаются на этапе связывания, синхронизации, проверки консистентности и кучи бд, состоящих из частично надцать раз дублирующихся данных, что больше задача для архитекторов и сеньоров. То есть реально спецов там нужно мизер, но это именно "сливки" сообщества, которых и так нифига нет и охота за ними идет похлеще чем за синей птицей. Что создает определенные проблемы, особенно в свете последних событий. Вывод в отдельном коменте.
15 хвилин води, але може так і потрібно, може комусь так краще заппм'ятати. Інколи щоб довести до іншого виконавця суть завдання потрібно набагато більше часу і одних і тих самих пояснень.
Почему Gradle, а не Maven?
Может я пропустил какую-то суть повествования, но зачем объяснять как делали монолит лет 10 назад, а не то как пишут сейчас?
В бэке уже давно не Java а тот же js в виде node либо python. Или например что nginx занимается оркестрацией и в принципе существует оркестрация в монолитных платформах. Ну и то же современный монолит это не один большой кусок мы тоже выкинем из понятий. ИМХО если уж объяснять то в текущих реалиях, а не как когда-то давно было. Вот)
Почему на бэке не Java? В больших энтерпрайзах C# или Java
"ли например что nginx занимается оркестрацией и в принципе существует оркестрация в монолитных платформах" Не совсем понимаю ответ, о какой оркестрации идет речь? Можете дополнить пожалуйста?
@@Andrew_Hales C#, Go, Python, Ruby используются, но Java за последние лет 10 видел раза 2. Энтерпрайз тема настолько далекая (и что вообще есть Энтерпрайз если это не Гугл, Амазон, Фб), что новичку это точно не понадобится, даже работая в крупном банке.
Оркестрация так как она есть - распределение нагрузки, отключение нерабочих механизмов, масштабирование итд.
@@kitchenanykey маштабировать монолит можно горизонтально, только если он stateless и не имеет сессий. Отключение механизмов - не совсем понял что вы имеете в виду
@@Andrew_Hales если стала интересна эта тема - советую почитать Нила Форда - паттерны проектирования. А кто Вам наплел в комментах что масштабировать можно только горизонтально - влепите дизлайк)
@@kitchenanykey Гляну, спасибо.
Про маштабирование - наверное Вы меня не верно поняли - я не говорил что ТОЛЬКО горизонтально, я подразумевал что горизонтально он маштабируется как микросервисы ТОЛЬКО в случае если он stateless, т.е не иммет сессий пользователей на L5 OSI, Если все же он как "обычный" монолит и имеет сессии скажем пользователей, то нам нужно выносить аутентификацию в какой-нибудь gateway/proxy выше и тогда можно будет машатибровать горизонтально.