Comments 23
Может стоит убрать один из двух завершающих абзацев?
А по теме - то, скорее всего, речь идёт о переезде на архитектуру modular Monolith. Это я сужу по тексту, но и на практике именно эта архитектура является логичным звено эволюции монолита.
Ответа на вопрос, вынесенный в заголовок, к сожалению нет :)
Все что я нашел, так это
Объективно оценить свой проект сложно, но начать можно с вопроса с капелькой синдрома самозванца «а вырос ли мой проект до микросервисов? как понять, что нужно переходить на них?»
В общем-то все. Дальше стандартная "муть", которая как по мне, никакого отношения к вопросу не имеет
Начнем с того, что перейти на них быстро не получится, скорее всего, вначале вы разгрузите наиболее загруженный модуль, например, на который приходят заявки.
Вы сначала поймите для себя, что такое "самый загруженный модуль" и что вообще в реальности загружается. А то выглядит так, что загрузка == это просто программный код. которому просто надоело работать. Вроде, один метод вызывается 1000 раз, а другой - 2. Вот первому и обидно стало :)
Посередине пути ваша архитектура будет походить на минисервисы, пока каждый модуль не будет вынесен отдельно и связан между собой. Напомню, что если их не «подружить» между собой, вся ваша работа не будет иметь смысла.
Куда дружить, с кем дружить, против кого дружить? Реально о чем все это?
Небольшие модули легче контролировать, несколько точек отказа дают большую надежность, это основное преимущество микросервистной архитектуры, ее поэтому все и хотят. Например, у вас большой интернет-магазин, в минуту больше тысячи заказов, страшно хранить эту структуру в монолите, отключится один элемент — прекратит работу весь магазин до решения проблемы, а значит, большая потеря прибыли и лояльности к бизнесу.
В этот момент хочется спросить, а монолитное приложение, которое с точки зрения деплоя ничем не отличается от условного микросервиса не масштабируется горизонтально? Я открою секрет, схеме деплоя в многонодовом варианте с условным nginx/haproxy уже 100 лет в обед, и схожим решениям тоже.
Если же у вас есть баг, нет не так, БАГ - то он, если он к примеру в методе регистрации, то даже в монолите он никак не будет мешать работе других методов :)
Если грамотно распределить нагрузку, за каждым модулем закрепить минимум по три специалиста, можно сохранить работу сервиса даже с обработкой большого количества данных.
Лучше конечно 5 специалистов, но боюсь вы отсылку не поймете :)
Еще микросервис удобно обновлять, не нужно перешивать все, добавляешь/убираешь/обновляешь только требуемый модуль, работа остальных в это время не страдает.
Ага, особенно если он другим тоже нужен. Да и то полезное, что он предоставляет пользователям тоже желательно не прерывать. Хотя - боюсь вы наверное думаете, що обновление монолита без прерывания сервиса является неподъемной задачей
Как много токсичности ))
Ну давайте по порядку.
НО самое главное что статья не была расчитана на технически подкованных людей, а больше для людей кому пытаются "впарить" на этапе продажи то что ему не нужно.
Вы сначала поймите для себя, что такое "самый загруженный модуль" и что вообще в реальности загружается. А то выглядит так, что загрузка == это просто программный код. которому просто надоело работать. Вроде, один метод вызывается 1000 раз, а другой - 2. Вот первому и обидно стало :)
Я думал что оставляя такой комментарий, человек должен понимать что такое самый загруженный модуль. Описывать каждое предложение, что я имел ввиду будет не правильно, выйдет слишком много воды.
Куда дружить, с кем дружить, против кого дружить? Реально о чем все это?
Вот тут уровень токсичности возрастает. Вам все сложнее понимать о чем речь, ведь вы считаете себя сверхумным и готовы оспорить все что угодо.
В этот момент хочется спросить, а монолитное приложение, которое с точки зрения деплоя ничем не отличается от условного микросервиса не масштабируется горизонтально? Я открою секрет, схеме деплоя в многонодовом варианте с условным nginx/haproxy уже 100 лет в обед, и схожим решениям тоже.
Если же у вас есть баг, нет не так, БАГ - то он, если он к примеру в методе регистрации, то даже в монолите он никак не будет мешать работе других методов :)
Тут что-то на умном получилось сказать про nginx/haproxy. Можно конечно такой подход использовать. Остаться с голой жопой правда за оплату серверов, но вам то откуда это знать, я думаю вы за них не платите )) Не думаю что вы это поймете =)
Ну и статья все таки про микросервисы
Лучше конечно 5 специалистов, но боюсь вы отсылку не поймете :)
Косяк, Каюсь перед вами. там должно было быть написано по 1 человеку на сервис. Но вы не могли пропустить такое, понимаю )
Ага, особенно если он другим тоже нужен. Да и то полезное, что он предоставляет пользователям тоже желательно не прерывать. Хотя - боюсь вы наверное думаете, що обновление монолита без прерывания сервиса является неподъемной задачей
Вы не поверите, но мы все раскатываем без прерываний, оказалась подъемной. А еще раскатывать можно не на всех, есть еще версии Api, и фронт можно и апки не на всех а на процент юзеров катать, но вот тут я думаю уже вы про такое не слышали, раз такую глупость написали.
P.S.
Засадить можно кого и что угодно, а вот помочь может не каждый.
У нас есть отличный сервис с психологической поддержкой. Обращайтесь и я помогу оформить скидку.
Я думал что оставляя такой комментарий, человек должен понимать что такое самый загруженный модуль. Описывать каждое предложение, что я имел ввиду будет не правильно, выйдет слишком много воды
Сорян, совершенно не очевидно, если это все монолит. Вас не затруднит расписать? Мне правда интересно
Вам все сложнее понимать о чем речь, ведь вы считаете себя сверхумным и готовы оспорить все что угодо.
Распишите технически понятие "дружить". Сразу возникнет много всего интересного.
Остаться с голой жопой правда за оплату серверов, но вам то откуда это знать, я думаю вы за них не платите )) Не думаю что вы это поймете =)
Не плачу, но рассчитываю. Так все таки, рсскажите, в чем сложность горизонтального мсштабирования монолита в сравнении с микросервисами
НО самое главное что статья не была расчитана на технически подкованных людей, а больше для людей кому пытаются "впарить" на этапе продажи то что ему не нужно.
Обратитесь к тех. спецу, чтобы он вам помог тогда написать статью :)
Сорян, совершенно не очевидно, если это все монолит. Вас не затруднит расписать? Мне правда интересно
Из жизни. Мы пишем много на ноде использую NestJs. На нем же у нас все разбито на модули. Вот есть проект Онлайн-школы, на нем есть чаты и вот люди много пишут, мы отпочковали этот модуль и вытащили его на отдельную машину с отдельной БД, редисом, очередью и тд.
Еще из жизни. Есть ИМ(интернет магазин), там есть интеграции которые каждые несколько минут сканит базу цен, этот модуль будет дико нагружать основное приложение, соот-но его вынесли в отдельный сервис на отдельную машинку.
Распишите технически понятие "дружить". Сразу возникнет много всего интересного.
Сервисы же между собой как-то должны общаться. Очереди/Http/Tcp/GRpc и др.
Не плачу, но рассчитываю. Так все таки, рсскажите, в чем сложность горизонтального мсштабирования монолита в сравнении с микросервисами
Если примеры выше положить в горизонталь то машинки вам потребуются все довольно мощные чтобы держать такой монолит, в то время при разбивки на сервисы вы можете сами выбирать, какие лучше мощностя, выставлять лимиты на ресурсы. Плюс есть автоскейлинг который мы юзаем когда отдельный сервис нагружается.
Обратитесь к тех. спецу, чтобы он вам помог тогда написать статью :)
Так задачи не было техническую статью писать. Цель была донести до людей, НЕ технических, которые так же читают хабр, что не всегда им нужны микросервисы.
У нас за последнее время было много заявок из разряда сделать лендос на мироксервисах, потому что клиент где-то прочитал что это круто, так и родилась идея статьи.
Еще из жизни. Есть ИМ(интернет магазин), там есть интеграции которые каждые несколько минут сканит базу цен, этот модуль будет дико нагружать основное приложение, соот-но его вынесли в отдельный сервис на отдельную машинку.
Вы никак не дойдете до момента, что именно нагружается. Проц, пул соединений ... :)
Сервисы же между собой как-то должны общаться. Очереди/Http/Tcp/GRpc и др.
Что есть доп. нагрузка, задержки, проблема N+1 запроса ... не всегда, но с этим надо бороться :)
Если примеры выше положить в горизонталь то машинки вам потребуются все довольно мощные чтобы держать такой монолит
Смотри, берем БОЛЬШОЙ ПРЕБОЛЬШОЙ монолит и деплоим. нагрузку пока не даем. Вы удивитесь, кроме чутка памяти он не берет вообще ничего :) Код сам по себе много каши не просит, а вот вся нагрузка на ресурсы прямо зависит от собственно нагрузки. Монолитность ее никак не увеличивает, даже может чуток уменьшать :)
Плюс есть автоскейлинг который мы юзаем когда отдельный сервис нагружается.
Как вы понимаете, если совместить знание о том, что монолит есть ресурсов ровно столько, сколкьо есть нагрузки + автоскейлингу тоже все равно, то легко понять что разницы нет
Цель была донести до людей, НЕ технических, которые так же читают хабр, что не всегда им нужны микросервисы.
:)
Автору статьи пока точно рано куда-то переходить.
Если у вас интернет магазин, можно смело оставаться на монолите. И если у вас CRM платформа на пол миллиона строк кода, тоже можно не париться, если монолит вменяемый пусть будет монолит. Вот если у вас проект на десяток миллионов строк кода, который пилят больше сотни человек, тут без микросервисов будет туго. Тут пожалуй пора.
Спасибо за статью!
Хорошее краткое объяснение, когда нужно задуматься и взвесить все за и против при принятии решения перехода на микросервисы.
Рад, что оживил дискуссию по теме микросервисов, но не очень радует качество этой дискуссии.
«Когда нужно переходить на микросервисы?»
начать можно с вопроса с капелькой синдрома самозванца «а вырос ли мой проект до микросервисов? как понять, что нужно переходить на них?»
Не понял, так как понять?
от того, насколько хорошо все настроено в архитектуре,
Если грамотно распределить нагрузку
Здесь встает вопрос о смене архитектуры, когда чувствуете, что монолитная уже не работает на вас
Главное — не забыть все грамотно связать
Как правило, когда нужно обновить систему, выбора переходить или нет не остается
В правильно настроенном, амбициозном проекте, все само приведет к переходу на микросервисы
Главное — золотая середина: не слишком рано, когда для этого не будет команды с высокой квалификацией и денег, и не слишком поздно, когда от высокой нагрузки ничего уже не работает.
В статье какой-то набор из чувств, ощущений и рекомендаций делать "грамотно" и "правильно", а "неграмотно" и "неправильно" видимо не делать. И ещё соблюдать золотую середину.
Какая польза от таких пространных рассуждений, мне вообще непонятно. Вот прочитал я это, и что дальше? Как мне ваши чувства и рекомендации делать "правильно" конвертировать в оценки и действия? Они субъективны, и в статье просто налита вода к сожалению.
Если вы технический специалист, а судя по вашим статьям это так то статья не для вас, а для людей кто не имеет никакого технического бэкграунда
Я выше в комментах это уже написал по какой причине вообще родилась идея написать такой пост
Да и я думаю что вы согласитесь со мной что в разработке много чего субъективного.
Не, ну я так не играю. "Молодой человек, это не для вас написано!"
Вы тогда в статью так и напишите, а то на хабре писать статью для людей без технического бэкграунда и не упомянуть об этом - это интересный подход :)
Много в разработке субъективного или мало, а лить воду пользы всё равно нет.
"Зависит от потребностей" и субъективно - это не одно и то же если что.
- Вася, твои 20 микросервисов не влазят в нашу оперативку и прод не работает!
- Я думаю, что вы согласитесь со мной что в разработке много чего субъективного
Ну не знаю, не знаю что там субъективного.
«Когда нужно переходить на микросервисы?»