Почему Java EE масштабируется? - PullRequest
16 голосов
/ 21 февраля 2009

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

Я хотел бы услышать технические причины, по которым он так масштабируем.

Ответы [ 4 ]

24 голосов
/ 21 февраля 2009

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

Если бы вы управляли вещами вручную в plain-old-java, вам пришлось бы самостоятельно все это выяснить, например, открыв порты, синхронизировав состояния и т. Д.

Я не уверен, что вы могли бы определить Google как "большой веб-сайт". Это все равно что сравнивать интернет с локальной сетью вашего офиса. Java EE не предназначалось для масштабирования до глобального уровня, поэтому такие сайты, как Amazon и Google, используют свои собственные технологии (например, с использованием MapReduce).

Существует множество работ, в которых обсуждается эффективность масштабируемости Java EE. Например это

6 голосов
/ 09 июня 2010

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

Вы можете создавать масштабируемые приложения на любом языке или платформе исполнения. (Да, даже COBOL на древних мэйнфреймах System 370.) То, что фреймворки приложений, такие как Java EE (и другие, естественно, Java EE вряд ли уникальны в этом отношении!), Дает вам способность легко (относительно говоря) сделайте это, выполнив большую часть тяжелой работы за вас.

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

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

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

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

4 голосов
/ 21 февраля 2009

Можно взглянуть на масштабируемую архитектуру с точки зрения того, что обеспечивает базовая структура (например, Java EE). Но это только начало.

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

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

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

Java EE, как фреймворк, достаточно масштабируем, как и большинство современных корпоративных фреймворков, ориентированных на микропроцессоры. Но я видел удивительные (не очень хорошие) вещи, созданные даже из лучших из них.

Чтобы найти множество ссылок, поищите в Google «Проектирование для масштабируемости»

1 голос
/ 21 февраля 2009

«Масштабируемость» говорит о том, «что вы будете делать, когда ваше приложение больше не помещается на одном компьютере?».

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

Обратите внимание, что на больших серверах могут быть ОЧЕНЬ большие приложения с большим объемом памяти и большим количеством процессоров - см. http://www.sun.com/servers/highend/m9000/ или http://www -03.ibm.com / systems / i / hardware / 595 / index.html - но обычно это дороже, чем иметь множество небольших серверов с распространяющимся на них приложением.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...