Одним из распространенных аргументов в пользу использования микросервисов является лучшая масштабируемость. Но мне интересно, действительно ли этот аргумент верен.
Допустим, у нас было приложение, состоящее из 10 микросервисов, 9 из которых имели по два экземпляра (для избыточности), а одно - с 4 экземплярами для обработки нагрузки (масштабируемость). Аргумент про-микросервиса заключается в том, что вы можете масштабировать этот миросервис независимо от других сервисов.
Однако предположим, что все 10 микросервисов были модулями в одном монолите, и что было развернуто несколько (например, 22, как сумма сверху) экземпляров этого монолита. Система должна быть в состоянии справиться с нагрузкой для одной критической части, потому что для этого достаточно экземпляров. Если экземпляры содержат логику программы, которая не нужна, единственным недостатком будет то, что двоичный файл и объем необходимой оперативной памяти будут немного больше. Но опять же, в большинстве случаев разница не должна быть слишком большой - по крайней мере, по сравнению с остальной частью стека (вспомним Spring Boot). Преимущество масштабируемого монлита было бы более простой системой без (большей части) ошибок распределенной системы.
Я что-то пропустил?
источник
Ответы:
Смысл микросервисов не в том, чтобы снизить нагрузку на процессор. Фактически, из-за накладных расходов на связь и повторение функций, которые раньше были глобальным служебным кодом, это обычно несколько увеличивает нагрузку на процессор.
Смысл отмены монолита - гораздо больше, чтобы иметь возможность поддерживать, развертывать и эксплуатировать сложную систему функций вообще . Как только ваша система достигает определенного размера, компиляции, тестирования, развертывания и т. Д., Монолит становится слишком дорогим, чтобы его можно было реализовать при сохранении достойного времени безотказной работы. С помощью микросервисов вы можете обновить, перезапустить или откатить систему по частям.
Не заблуждайтесь, мы не пишем микросервисы, потому что это, по сути, лучшее решение для слабой связи через удаленные интерфейсы. Фактически, потеря строгого типа и проверка согласованности, которую может обеспечить монолит, часто является серьезным недостатком. Мы делаем это потому, что должны, потому что сложность взяла верх над нами и делает лучшее из неоптимальной ситуации.
источник
Вы в основном правы. Если у вас есть быстрые сервисы, которые загружены одинаково, вы можете также установить их на все коробки. Это не так хорошо, как иметь коробку на услугу, но это экономит деньги.
Тем не мение. как только у вас возникнет дисбаланс, скажем, служба 5 забирает 100% процессорного времени в течение 2 минут, вы захотите переместить эту службу в свою собственную коробку, чтобы она не блокировала все остальные службы, если она работает.
Если из-за нагрузки время ожидания звонков в службу 5 истекло, произойдет сбой только некоторых функций вашего приложения, а не всех.
Теперь вы можете сделать то же самое с хорошо модульным монолитом. Установите все сервисы, но только перенаправьте сервис 5 на один из них. Пока не маршрутизирует сервис 5 трафика на другие ящики.
Но обычно монолиты по своей природе - это не просто набор служб, которые устанавливаются на одном и том же устройстве. В памяти будут вызовы между модулями, что приведет к сбою приложения.
источник
Суть микроуслуг: 1) разделение интересов и 2) распределение нагрузки. По сути, это освобождает нас от создания лучшего сервиса в черной коробке, который мы можем использовать с технологиями, специфичными для этой задачи. Нашими услугами может быть полиглот - это написано на разных языках программирования в разных стеках. Различные команды могут работать над каждым сервисом, не зная, как другие работают, помимо контракта их API. В целом это позволяет создать гораздо более простую кодовую базу для каждого сервиса, которую легче отлаживать, понимать и настраивать для повышения производительности.
источник