Что является масштабируемым? Простой веб-приложение CRUD против веб-приложения, говорящего со службой REST - PullRequest
6 голосов
/ 12 июля 2011

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

MongoDB - это хранилище данных, и я разрываюсь между написанием простого Play! веб-приложения, говорящего с MongoDB против Play!, говорящего с сервисным приложением REST (в Scala), которое выполняет тяжелую работу всего бизнеса логика и настойчивость.

Часть меня считает, что завершение бизнес-логики в качестве службы является перспективой на будущее и позволяет развертывать только веб-приложение на нескольких узлах (масштабирование). Я пришел из стека Java EE и играть! бунтарь в веб-фреймворках Java. Такой подход уверяет меня, что я могу отойти от Play! если нужно.

Часть меня тоже считает, что Play! Приложение + сервисное приложение Scala представляет собой дополнительную сложность и в долгосрочной перспективе может оказаться бесполезным.

Любые предложения приветствуются.

ПРИМЕЧАНИЕ: я новичок в Scala, MongoDB и Play !. Простите, если мой вопрос был глупым.

Ответы [ 4 ]

5 голосов
/ 12 июля 2011

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

Сказав это, исходя из опыта, некоторые общие советы:

  • Держите ваше приложение максимально чистым и простым. Это позволяет вам держать ваши варианты открытыми. В вашем случае начните с простого приложения Play. Сконцентрируйтесь на чистом коде, чтобы вы могли легко переделать то, что у вас есть, в другую архитектурную модель (с чистым кодом это проще, чем вы думаете: -))
  • Измерь, не угадай, где узкие места. Достаточно просто залить сервер запросами. Используйте профилирование, дампы памяти, что угодно, чтобы определить узкое место в масштабируемости.

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

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

2 голосов
/ 12 июля 2011

Вопрос не выглядит глупым. Для меня инкапсуляция вашего доступа к данным за остальным уровнем напрямую не улучшает масштабируемость приложения. (Конечно, есть сервер, который может выполнять http-кэширование и обрабатывать очереди запросов и т. Д., Но из вашего описания ваше приложение выглядит достаточно мал). Вы можете достичь подобной масштабируемости без слоя Rest. Но, сказав это, уровень обслуживания может оказать косвенное влияние.

Сначала это делает ваше приложение чище. (UI Разговор с БД грязный.) Это помогает сделать приложение поддерживаемым. (Многократные складки). Слой отдыха может предоставить вам средний уровень, который вам может понадобиться в вашем приложении. Также правильно спроектированный Rest Layer должен быть управляемым ресурсами. По моему опыту, архитектура, управляемая ресурсами, является хорошим промежуточным звеном между простотой реализации и масштабируемым дизайном.

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

1 голос
/ 12 июля 2011

Ответ, как обычно, таков. Это зависит. Если в этом есть какая-то тяжелая работа и какая-то бизнес-логика: да, это лучше всего поместить на свой собственный уровень, и если вы добавите к нему интерфейс RESTful, вы сможете использовать его для любой интерфейсной технологии, которую захотите.

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

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

Не просто добавляйте слои ради сложности.

Могу добавить, что вы должны попытаться использовать принцип HATEOAS. Это значительно облегчит работу при масштабировании решения.

1 голос
/ 12 июля 2011

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

Недостатком является небольшой скачок скорости для приложения.

Я бы сказал, что добавлениеСервис имеет небольшую стоимость и большой потенциал роста.Я бы за это проголосовал.

...