Комментарии 34
Может быть в момент появления микросервисов была единственная цель - горизонтальное масштабирование. Но сейчас вертикально мощности выросли раз в 10-20 и приоритет этой цели снижен.
Недостатки никуда не делись.
Но достоинства в виде кардинальной изоляции критичных модулей и их данных (платежный или с перс данными), организационной и технологической изоляции команд остались. Ну и ещё по мелочи...
Но сейчас вертикально мощности выросли раз в 10-20 и приоритет этой цели снижен.
Тем не менее. Языки с GC не очень любят много памяти. Им приходится много работать, иногда даже "останавливать мир" на секунды чтобы почистить мусор.
Тот же популярный Opensearch рекомендует делать несколько узлов, а не один большой именно по этой причине.
Спасибо, зашёл написать этот же коммент.
Кроме этого, есть гибридный вариант с монолитным основным приложением и ограниченным числом микросервисов, потребовавших масштабирования или другого уровня доступа, например.
Мне кажется автор не удачный пример показал так как по моему пилить под каждого провайдера отдельный микросервис не всегда целесообразно так как провайдер обычно изначально как внешний сервис служит.
В монолите можно просто перейти на 4ую нормальную форму или ещё проще разбить на партиции и каждую партицию в отдельной реплике запустить + микрофреймворк написать по кругу читать с реплик а писать и обновлять на мастере вот вам и не только вертикальное масштабирование.
Много как минимум спорных утверждений.
❌ Сложнее масштабировать. Монолитная архитектура масштабируется вертикально
Что мне мешает добавить нужное количество нод на монолите? В том числе, динамически, по необходимости. Всё, что требуется – это поставить перед ними балансировщик нагрузки – который в высоконагруженных системах и так всегда уже есть.
❌ Сложнее обновлять и поддерживать. Любые изменения в монолитной архитектуре нужно вносить во все приложение сразу. Это может приводить к заторам в разработке — если одна команда не готова к релизу, все должны ждать, пока она закончит.
Допустим, у меня есть команда, которая реализует обработку платежей, и ещё одна, которая занимается рассылкой мэйлов. Почему они должны ждать друг друга? Абсолютно несвязанный код, который можно релизить независимо. Если речь о бэке и фронте – так для того и придумали версионирование API, обратную совместимость и прочие техники, облегчающие независимую разработку модулей системы. Просто это должно быть продумано ещё на этапе проектирования.
✅Гибкость разработки. Элементы приложения можно разрабатывать, тестировать и деплоить независимо друг от друга. Команды могут использовать разные технологии и подходы для каждого сервиса и не конфликтовать друг с другом.
Зоопарк технологий в одном проекте - скорее минус, нежели плюс.
____
А вот с перечисленными минусами микросервисов согласен абсолютно. И они настолько серьёзны, что переход на МС архитектуру должен быть очень хорошо обоснован, чтобы вообще в эту историю ввязываться.
А читая о том, что
В реальности же таких микросервисов будет сотни, а то и тысячи.
никак не удаётся избавиться от ощущения, что система попросту плохо спроектирована. О чём тут речь, о типах сервисов или об инстансах? Второй случай ещё как-то можно понять – хотя боюсь, накладные расходы на запуск такого количества процессов и управление ими сами по себе съедят до фига ресурсов, и потребуют того самого горизонтального масштабирования гораздо раньше, чем в случае с монолитом. Тысячи типов объяснить не могу никак, не бывает систем такой сложности – если не лепить по 4 сервиса на каждую CRUD сущность.
Итого: думаю, что повальное увлечение микросервисами вряд ли обосновано. Есть случаи, когда они нужны – но это действительно очень большие, многофункциональные и высоконагруженные системы. Для абсолютного же большинства это ведет лишь к огромному усложнению инфраструктуры, сложность реализации которой и поддержания её в рабочем состоянии может значительно превышать выигрыш в сравнении с хорошо спроектированным монолитом.
Готов к приёму пинков от церкви свидетелей микросервисной архитектуры 😁
Что мне мешает добавить нужное количество нод на монолите?
Если упирается в ЦП сервера приложений то в общем ничего не мешает. Если в БД, то можно шардирование, репликацию, кеш.
Но если надо в 10+ раз повысить нагрузку, то эти методы могут не справиться
Но если надо в 10+ раз повысить нагрузку, то эти методы могут не справиться
Да, я не отрицаю, что в каких-то случаях МС могут быть правильным решением. Просто это крайне редкие случаи – мне, например, пока сталкиваться не приходилось.
Есть база данных. Там всё хранится, там выполняются все SQL запросы. Как микросервисы помогут с нагрузкой на эту базу данных?
Может быть, вам сначала узнать что такое микросервисы? Иначе бы не было такого вопроса.
Микросервис подразумевает отдельные базы данных для каждого сервиса. "Есть база данных" это не микросервисы.
Ну вот я читаю разные статьи на эту тему, и задаю вопросы. Т.к. нигде не встречал такого, что "Микросервис подразумевает отдельные базы данных для каждого сервиса". Т.е. 5 микросервисов, 5 баз данных mysql? И они должны быть расположены на разных серверах, верно? А то одна база может положить 1 сервер точно.
Микросервис подразумевает отдельные базы данных для каждого сервиса.
И это на самом деле серьёзный аргумент против их использования. Хотя бы потому, что неизбежно возникает дополнительный слой для обмена данными между сервисами/базами – что столь же неизбежно усложняет систему и не лучшим образом сказывается на её производительности.
Плюс ещё всякий дополнительный геморрой со скоростью этой синхронизации: например, данные об успешном платеже должны тут же менять пермиссии юзера, а если обмен между сервисами платежей и аутентификации задержался, этого не произойдёт и юзер будет огорчён.
Ну и всё же разговоры о преимуществах изоляции тоже верны лишь до определённого предела. Многие сервисы всё равно зависят друг от друга, и если один из них ляжет, то скорее всего, и другие нормально работать не будут. Да, юзер не увидит "экран смерти" – но и сделать то, за чем пришёл, тоже не сможет. Та же аутентификация легла – что там будет работать? Да ничего.
корзинка будет работать, а заказ временно не будет или отслеживание доставки временно не будет - терпимо
Если речь о магазине, то не очень-то терпимо: всё время, пока заказ не работает, магазин теряет деньги. Да и репутацию тоже.
И сфера применения отнюдь не исчерпывается магазинами – есть множество приложений, где неаутентифицированный юзер не может вообще ничего. Даже глазками посмотреть, не говоря уж о ручками потрогать.
Адепты микросервисов ещё не вымерли?
Микросервисов должно быть не больше чем доменов, а сотни доменов мне трудно представить: один домен это один отдел у бизнеса. Что это за бизнес такой?
Повышенная отказоустойчивость. В микросервисной архитектуре как максимум из строя может выйти шлюз, отвечающий за несколько сервисов. Его можно починить и протестировать отдельно от других функций приложения. В монолите если ломается что-то одно, то ломается все приложение.
Вот это вызывает сильные сомнения. Не бывает таких монолитов, которые из за одного исключения в одной функции ломались бы полностью. Во всяком случая сейчас.
Что касается починки, то любой продукт состоит из модулей, классов, функций которые чинятся "отдельно" в том смысле, что когда мы их чиним мы думаем только о том чтобы их логика была верной и проверяем эту логику используя изолированные тесты или просто эксперименты со всем приложением в разных условиях. Если же изъян заключен в логике взаимодействия модулей или сервисов, то опять особо разницы нет.
Монолитная архитектура масштабируется вертикально, и это может вызывать проблемы при резком увеличении нагрузки и необходимости масштабироваться горизонтально (например, сезонных продажах или событийных всплесках трафика на сайт).
Где-то есть самый медленный сервис, наверняка он будет связан с активной работой с базой и наверняка масштабирование работы с базой будет примерно одинаковой головной болью для монолита или одного сервиса. Хотя, если честно я в этом не разбираюсь. Поправьте кто знает.
Любые изменения в монолитной архитектуре нужно вносить во все приложение сразу. Это может приводить к заторам в разработке — если одна команда не готова к релизу, все должны ждать, пока она закончит. Любую отладку и тестирование тоже нужно проводить по всей кодовой базе — это более затратно, и не всегда дает точные результаты.
Собственно единственная реальная разница между микросервисами и монолитом здесь заключается в наличии отдельной базы у каждого сервиса. Это усиливает изолированность сервисов, но только в части данных. Но все же если изменения сквозные, они все равно затрагивают API множества сервисов и тестировать надо все вместе. А если они локальные в одном сервисе, то аналогичные изменения в монолите тоже будут локальными.
Отказоустойчивость там странная
Одно лечим, другое калечим
Не бывает таких монолитов, которые из за одного исключения в одной функции ломались бы полностью.
Да. Тоже собирался об этом написать, но пропустил. Точнее, у меня, например, есть некое общее ядро, неудачные изменения в котором теоретически могут вообще всё положить. Но такие вещи невозможно не заметить при тестировании, да и с микросервисами в этом случае произойдёт ровно то же самое. Если, разумеется, каждая МС команда не пишет его весь от начала до конца сама, изолированно – что свидетельствовало бы о крайне нерациональном использовании ресурсов.
Собственно единственная реальная разница между микросервисами и монолитом здесь заключается в наличии отдельной базы у каждого сервиса
Не, ну можем сервис запускать на разных серверах, нодах, подах... То есть утилизировать много железа и работать ближе к телу.
Автор выбрал животрепещущую тему, который каждый воспринимает по-своему и в меру своих сил)
Помимо вышеперечисленного хочу предложить вам пересмотреть подход к декомпозиции на микросервисы.
Декомпозировать на микросервисы с точки зрения технологий/механизмов реализации функционала является наименее устойчивой с течением времени: сегодня появился СБП, а завтра возвращаются «x»Pay и большинство потребителей в секунду забудут про QR.
По итогу ваша команда потратит огромные деньги на вывод «платежей по СБП» в отдельный микросервис в пустую.
А домен «совершение платежа» как существовал, так и продолжит своё существование до тех пор, пока не перейдём на другой процесс обмена
Аргумент что монолит горизонтально не масштабируется, а микросервисы да — не валиден. Никто не мешает горизонтально смасштабировать монолитное приложение ровно так же как вы масштабируете микросервисы
Аргумент что монолит горизонтально не масштабируется, а микросервисы да — не валиден. Никто не мешает горизонтально смасштабировать монолитное приложение ровно так же как вы масштабируете микросервисы
Как то не понятно о чём статья. Если кратко:
Рассмотрим различие между монолитом и микросервисом, а тут мы вот такой используем шлюз, вообщем в одном хорошо монолит, в другом микросервисы. Но если не готовы, лучше в микросервисы не лезьте.
Ладно, последнее предложение достаточно ценное.
С заголовком статьи не бъётся. В итоге не понятно как превратить монолит в микросервис. Если скопипастить в 3 разных микросервиса исходный функционал, это будет распределенный монолит и его сложность, вместо уменьшения, возрастет в 3 раза, потому что подозреваю, процессы платежей совпадают чуть меньше чем полностью и надо будет одновременно поддерживать один и тот же функционал в разных кодовых базах.
Как отметили выше, неплохо делить по доменам. И домен это не только данные но и правила работы с ними.
P.S. про шлюз можно было бы отдельную статью написать.
Как превратить монолитную архитектуру в микросервисную — и зачем