Насколько масштабируемой на самом деле является архитектура, основанная на веб-сервисах?

Question

Всякий раз, когда кто-то говорит об архитектуре, основанной на сервисах, он часто упоминает масштабируемость, часто на одном дыхании.Однако, похоже, что использование сервисов увеличивает накладные расходы, а не уменьшает их, поскольку теперь задействован протокол, такой как SOAP или REST.Итак, действительно ли архитектура, основанная на веб-сервисах, повышает производительность, поскольку число пользователей, скажем, веб-приложения, увеличивается, возможно, на порядок?Или требования к масштабируемости просто переносятся на сервисы, а не на основное приложение?

Answer 1

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

Если нагрузка на сеть мешает работе системы, которую вы хотите построить, то, разумеется, SOA - неправильный выбор для вас. Помните, что никогда не нужно обращаться к сервису через HTTP. Я думаю, вы будете удивлены, насколько быстрыми могут быть некоторые протоколы (например, net.tcp ).

Answer 2

Помните, что вы можете масштабировать веб-сервис для работы на нескольких серверах, не затрагивая клиентов. Это не очень хорошо работает с тесно связанной системой.

Answer 3

Правильно спроектированная SOA позволяет каждому компоненту в системе работать независимо от всех остальных и работать асинхронно параллельно, поэтому производительность и масштабируемость (две разные вещи) ограничиваются только самой медленной / наименее масштабируемой частью в вашей системе. , а не общее время, необходимое для выполнения всех компонентов в последовательном режиме.

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

Answer 4

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

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

Важно не забывать «A» в «SOA». Вы можете создать беспорядок, просто создавая кучу сервисов. Убедитесь, что у вас есть архитектура.

Одним из огромных шагов к масштабируемости является переход от базовых синхронных служб типа запрос / ответ (например, SOAP RPC) к асинхронным службам. См. «Образцы корпоративной интеграции» Хоупа и Вульфа

Answer 5

Любители ресторанов напомнят вам, что REST - это не прототип, это архитектурный стиль.REST - это способ использовать HTTP напрямую, без оболочек, которые использует SOAP, для предоставления модели сервисов.ОСТАЛЬНОЕ гораздо ближе к проводу, который МЫЛЬНЫЙ.Само по себе это не делает одного лучше другого, у них обоих есть свое место.

Масштабируемость модели сервисов напрямую связана не столько с "сервисами" (как в веб-сервисах с большой буквы W и с заглавной буквы S), сколько с апатридным характером этих сервисов.Хорошо построенные веб-приложения также масштабируемы, и можно утверждать, что они такие же масштабируемые, как и любая архитектура, основанная на сервисах.

Одно из различий между двумя моделями заключается в том, что веб-приложение без "сервисов" взаимодействует со ссылочными модулями, живущими в одном и том же процессе, на двоичном уровне - сериализация не требуется.Веб-сервисы (SOAP или REST) вводят некоторый уровень сериализации, который увеличивает накладные расходы.Однако эти накладные расходы часто считаются значимыми, учитывая их повторное использование (т. Е. те же веб-сервисы, которые управляют вашими приложениями внутри компании, также могут использоваться для того, чтобы сделать деловых партнеров счастливыми).

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

Answer 6

Итак, давайте сначала определим "масштабируемость".Почти все, что угодно будет масштаб:если вам нужна большая мощность, в первом приближении вы можете просто добавить к ней больше оборудования.Но некоторые архитектуры "более масштабируемы" — что это значит?Это связано со стоимостью:архитектура является "более масштабируемой", если затраты на единицу добавленной мощности меньше.

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

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

Итак, теперь, когда кто-то спрашивает о "масштабируемости" SOA, SOAP, REST или чего-то еще, это то, о чем они говорят.

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

(Обратите внимание, что это также по своей сути более отказоустойчиво:если сервер умирает, другой более или менее автоматически получает запросы, и нет сеанса, который можно было бы потерять.)

Архитектуры, требующие большого количества состояний сеанса, такие как некоторые системы J2EE, как правило, хуже масштабируются, поскольку для управления состоянием сеанса требуется большая сложность.

Своего рода ограничивающий случай, который вы видели в старых архитектурах, основанных на CGI, - это тот, когда для каждого сеанса пользователя требуется полноценный процесс с большим весом;Я видел системы в полевых условиях, где загрузка fork / exec составляла 40-50 процентов, где требовалась сложная программная система балансировки нагрузки, чтобы гарантировать, что запросы всегда доходили до машины, на которой проводился сеанс, и где серьезной проблемой было простое исчерпание слотов процесса.Одна из таких систем потребовала покупки совершенно нового высокопроизводительного сервера Starfire для увеличения пропускной способности.