Хорошо, давайте сначала определим масштабируемость. Почти все, что будет масштабироваться : если вам нужно больше емкости, в первом приближении вы можете просто добавить больше оборудования. Но некоторые архитектуры «более масштабируемы» - что это значит? Это связано со стоимостью: архитектура «более масштабируема», если стоимость за единицу добавленной емкости меньше.
Масштабируемость в целом имеет три диапазона в любой архитектуре: для первой части существует фиксированная стоимость, поэтому в течение интервала она линейна с наклоном 0; после этой точки наклон увеличивается, и в какой-то момент добавление мощности обычно очень дорого.
Мы говорим, что система является «линейно масштабируемой», если функция, описывающая стоимость единицы добавленной мощности, является приблизительно линейной в широком диапазоне. Очевидно, что желательно, чтобы этот уклон был меньше.
Итак, теперь, когда кто-то спрашивает о «масштабируемости» SOA, SOAP или REST или чего-то еще, это то, о чем они говорят.
Сервисно-ориентированные архитектуры, как говорят, «более масштабируемы», поскольку добавление большей емкости относительно недорого, хотя, как вы говорите, могут быть накладные расходы, из-за которых вам потребуется больше возможностей для обслуживания одного пользователя. Это связано с тем, что большая часть затрат и сложности управления большой системой обусловлена необходимостью поддерживать состояние сеанса, то есть отслеживать, что происходит между вызовами. Сервисно-ориентированные архитектуры избегают этого, делая каждый вызов относительно независимым от следующего, причем архитектура RESTful является ограничивающим случаем - все состояние сеанса кодируется в представлении, поэтому остальной системе не нужно знать об этом. Когда вы хотите добавить емкость, все, что вам нужно сделать, это добавить другой сервер; простой маршрутизации нагрузки будет достаточно для перенаправления сообщений на новое.
(Обратите внимание, что это также по своей природе более отказоустойчиво: если сервер умирает, другой более или менее автоматически получает запросы, и сеанс терять нельзя.)
Архитектуры, которые требуют большого количества состояний сеанса, как и некоторые системы J2EE, имеют тенденцию к меньшему масштабированию, так как вам нужно много дополнительной сложности для управления состоянием сеанса.
В предельном случае, который вы видели в старых архитектурах на основе CGI, существует тот случай, когда для каждого пользовательского сеанса требуется полный тяжеловесный процесс; Я видел системы в тех местах, где fork / exec составлял 40-50 процентов нагрузки, где требовалась сложная программная установка балансировки нагрузки, чтобы убедиться, что запросы всегда поступали на машину, на которой проходил сеанс, и где просто нехватка слотов процесса была серьезной проблемой. Одна такая система требовала покупки целого нового высококачественного сервера Starfire, чтобы увеличить емкость.