Масштабирование монолитов против масштабирования микросервисов

15

Одним из распространенных аргументов в пользу использования микросервисов является лучшая масштабируемость. Но мне интересно, действительно ли этот аргумент верен.

Допустим, у нас было приложение, состоящее из 10 микросервисов, 9 из которых имели по два экземпляра (для избыточности), а одно - с 4 экземплярами для обработки нагрузки (масштабируемость). Аргумент про-микросервиса заключается в том, что вы можете масштабировать этот миросервис независимо от других сервисов.

Однако предположим, что все 10 микросервисов были модулями в одном монолите, и что было развернуто несколько (например, 22, как сумма сверху) экземпляров этого монолита. Система должна быть в состоянии справиться с нагрузкой для одной критической части, потому что для этого достаточно экземпляров. Если экземпляры содержат логику программы, которая не нужна, единственным недостатком будет то, что двоичный файл и объем необходимой оперативной памяти будут немного больше. Но опять же, в большинстве случаев разница не должна быть слишком большой - по крайней мере, по сравнению с остальной частью стека (вспомним Spring Boot). Преимущество масштабируемого монлита было бы более простой системой без (большей части) ошибок распределенной системы.

Я что-то пропустил?

Deamon
источник
3
Какого размера монолита ты говоришь? Потому что я думаю, что это может быть больше, чем «немного больший» объем оперативной памяти. Не говоря уже о времени развертывания - исправление ошибки может занять 22 развертывания вместо 4. Но, возможно, ваш монолит мал и развертывания не занимают много времени, миграция базы данных не занимает много времени и так далее.
Томас Оуэнс
Я не посчитал строки кода, но у монолита было бы несколько тысяч строк кода (не гигантская система). Отправной точкой моего рассмотрения было то, что размер реального кода приложения крошечный по сравнению с большими фреймворками, такими как Spring и Hibernate. Количество развертываний на самом деле может быть меньше, чем на микросервисах, потому что если бы у вас было 2 экземпляра, у вас уже была бы базовая избыточность, а больше экземпляров было бы для масштабируемости.
Deamon
@deamon Имейте в виду, что при монолитном подходе нет частей кода, которые бы были абсолютно мертвыми в каждом экземпляре, просто редко используемый код. Теперь сам код может потреблять только небольшой объем памяти, но если он использует много объектов, связанных в памяти, этот объем может существенно возрасти.
Фрэнк Хопкинс
Обратите внимание, что накладные расходы на базовый «запуск кода» не обязательно так велики, как вы могли бы знать из ваших Java-приложений, где часто весь jvm является частью образа службы.
Фрэнк Хопкинс

Ответы:

21

Смысл микросервисов не в том, чтобы снизить нагрузку на процессор. Фактически, из-за накладных расходов на связь и повторение функций, которые раньше были глобальным служебным кодом, это обычно несколько увеличивает нагрузку на процессор.

Смысл отмены монолита - гораздо больше, чтобы иметь возможность поддерживать, развертывать и эксплуатировать сложную систему функций вообще . Как только ваша система достигает определенного размера, компиляции, тестирования, развертывания и т. Д., Монолит становится слишком дорогим, чтобы его можно было реализовать при сохранении достойного времени безотказной работы. С помощью микросервисов вы можете обновить, перезапустить или откатить систему по частям.

Не заблуждайтесь, мы не пишем микросервисы, потому что это, по сути, лучшее решение для слабой связи через удаленные интерфейсы. Фактически, потеря строгого типа и проверка согласованности, которую может обеспечить монолит, часто является серьезным недостатком. Мы делаем это потому, что должны, потому что сложность взяла верх над нами и делает лучшее из неоптимальной ситуации.

Килиан Фот
источник
2
Согласовано. Причина перехода к микросервисной архитектуре в основном политическая. Распределенная нагрузка, развязка - это последствия, а не причины. Настоящая выгода микросервисов заключается в SDLC и управлении. Кроме того, архитектура является логическим ответом на потребность, которая в большинстве случаев исходит из рыночной стратегии компании. Время выхода на рынок короче, чем у монолитных архитектур, поэтому компании разрешено принимать новые стратегии, плавно и быстро переходить от одной к другой
Laiv
6
Вот почему кто-то не должен переходить прямо к микросервисам для средних и малых приложений. Дополнительные затраты и сложность системы могут в конечном итоге стоить больше времени, денег и качества, чем монолитная система, в таких масштабах.
Т. Сар
«Мы делаем это потому, что должны, потому что сложность взяла верх над нами и делает лучшее из неоптимальной ситуации.« Да. Для меня это гвозди!
Томас Джанк
Я должен не согласиться с последней частью ответа.
Эван
1
@ewan Вы также можете использовать более одного компьютера с монолитами.
Deamon
3

Вы в основном правы. Если у вас есть быстрые сервисы, которые загружены одинаково, вы можете также установить их на все коробки. Это не так хорошо, как иметь коробку на услугу, но это экономит деньги.

Тем не мение. как только у вас возникнет дисбаланс, скажем, служба 5 забирает 100% процессорного времени в течение 2 минут, вы захотите переместить эту службу в свою собственную коробку, чтобы она не блокировала все остальные службы, если она работает.

Если из-за нагрузки время ожидания звонков в службу 5 истекло, произойдет сбой только некоторых функций вашего приложения, а не всех.

Теперь вы можете сделать то же самое с хорошо модульным монолитом. Установите все сервисы, но только перенаправьте сервис 5 на один из них. Пока не маршрутизирует сервис 5 трафика на другие ящики.

Но обычно монолиты по своей природе - это не просто набор служб, которые устанавливаются на одном и том же устройстве. В памяти будут вызовы между модулями, что приведет к сбою приложения.

Ewan
источник
1

Суть микроуслуг: 1) разделение интересов и 2) распределение нагрузки. По сути, это освобождает нас от создания лучшего сервиса в черной коробке, который мы можем использовать с технологиями, специфичными для этой задачи. Нашими услугами может быть полиглот - это написано на разных языках программирования в разных стеках. Различные команды могут работать над каждым сервисом, не зная, как другие работают, помимо контракта их API. В целом это позволяет создать гораздо более простую кодовую базу для каждого сервиса, которую легче отлаживать, понимать и настраивать для повышения производительности.

Льюис А Селлерс
источник
Я согласен частично. Я имел в виду не аргументы в пользу микросервисов в целом, а масштабируемость. В моем конкретном случае, например, все микросервисы написаны по одной технологии. Так что, хотя можно было бы использовать разные технологии для каждого, это просто не тот случай. Я хотел убедиться, что я не пропускаю важный момент о масштабируемости.
Deamon