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