Почему Java EE масштабируемо?
Я слышал из разных источников, что Java EE очень масштабируема, но для меня кажется, что вы никогда не сможете масштабировать приложение Java EE до уровня поисковой системы Google или любого другого крупного сайта.
Я хотел бы услышать технические причины, по которым он настолько масштабируемо.
Ответы
Ответ 1
Java EE считается масштабируемым, поскольку, если вы рассматриваете архитектуру EJB и запускаете ее на соответствующем сервере приложений, она включает средства для прозрачного кластера и позволяет использовать несколько экземпляров EJB для обслуживания запросов.
Если вы управляете вещами вручную в plain-old-java, вам придется все это выяснить самостоятельно, например, открыв порты, синхронизирующие состояния и т.д.
Я не уверен, что вы можете определить Google как "большой сайт". Это было бы похоже на то, чтобы упомянуть Интернет в локальной сети вашего офиса. Java EE не предназначалась для масштабирования на глобальном уровне, поэтому сайты, такие как Amazon и Google, используют свои собственные технологии (например, с использованием MapReduce).
В работе много обсуждений эффективности масштабируемости Java EE.
Например this
Ответ 2
Что делает Java EE масштабируемым, что делает что-то масштабируемым: разделение проблем. По мере увеличения вашей обработки или ввода-вывода вы можете добавить новое оборудование и перераспределить нагрузку полупрозрачно (в основном прозрачно для приложения, что явно меньше для обезьян конфигурации), поскольку разделенные изолированные проблемы не знают и не заботятся, re на одном физическом оборудовании или на разных процессорах в кластере.
Вы можете создавать масштабируемые приложения на любом языке или платформе исполнения. (Да, даже COBOL на старых мэйнфреймах System 370.) Какие платформы приложений, такие как Java EE (и другие, естественно, Java EE вряд ли уникальны в этом отношении!) Дают вам возможность легко ( относительно говоря) делают это, делая большую часть тяжелой работы для вас.
Когда мое веб-приложение использует, скажем, EJB для выполнения некоторой бизнес-логики, EJB может находиться на одном ядре ЦП, на другом ядре в одном CPU, на другом ЦП полностью или, в крайнем случае, возможно даже по всей планете. Я не знаю и, по большей части, при условии, что здесь есть работа, мне все равно. Аналогично, когда я отправляю сообщение на шине сообщений для обработки, я не знаю и не забочусь о том, куда это сообщение идет, какой компонент выполняет обработку и где происходит эта обработка, еще раз, пока производительность попадает в мою необходимо. Это все, что нужно для настройки обезьян. Технология позволяет это, и инструменты на месте, чтобы оценить, какие части должны идти туда, где можно получить приемлемую производительность, поскольку система масштабируется по размеру.
Теперь, когда я пытаюсь рулить все это, я начинаю с проблем сразу. Если я не буду думать обо всех проксингах, планировании и распространении, и так заранее, когда мое приложение будет расширяться за пределы одной машинной обработки, теперь у меня есть серьезные перезаписи, когда я переношу часть приложения в другой. И каждый раз, когда мои способности растут, я должен делать это снова и снова.
Если я все время задумываюсь обо всем этом, я пишу много шаблонов для каждого приложения, которое делает незначительные вариации всех тех же вещей. Я могу кодировать вещи масштабируемым образом, но хочу ли я делать это каждый раз. проклятый. время. Я пишу приложение?
Итак, что Java EE (и другие структуры) приносит в таблицу, является предварительно написанным шаблоном для общих требований к созданию масштабируемых приложений. Написание моих приложений на них не гарантирует их масштабируемость, конечно, но фреймворки значительно упрощают запись масштабируемых приложений.
Ответ 3
Можно рассматривать масштабируемую архитектуру с точки зрения того, что обеспечивает базовая инфраструктура (например, Java EE). Но это только начало.
Проектирование для масштабируемой инфраструктуры - это архитектурное искусство. Это похоже на искусство проецирования... как он будет себя вести, когда он взорвется на самом деле. Основные вопросы:
- Где я обычно использую доступ к материалам, чтобы, когда столько людей просят об этом, мне не нужно так много времени (кеш)?
- Где я храню каждый отдельный материал, чтобы, когда столько людей нуждаются в вещи, я не буду иметь проблемы с их управлением.
- Как я помню, что сделал человек здесь в последний раз, когда они пришли сюда, так как они не могут вернуться к тому же самому определенному node, который они посетили в последний раз.
- Как долго мне придется ждать (блокировать) длительную процедуру, если так много людей запрашивают ее?
...
такая вещь выходит за рамки рамки, которую можно обернуть. Другими словами, структура может быть масштабируемой, но продукт подключен слишком сильно для масштабирования.
Java EE, как структура, достаточно масштабируема, как и большинство современных корпоративных инфраструктур, ориентированных на микропроцессор. Но я видел потрясающие (не в хорошем смысле) вещи, созданные даже из лучших из них.
Для множества ссылок, пожалуйста, найдите Google для "Проектирование для масштабируемости"
Ответ 4
"Масштабируемость" говорит о том, "что вы будете делать, когда ваше приложение больше не будет входить в один компьютер?".
Масштабируемые приложения могут вырасти более чем на нескольких компьютерах.
Обратите внимание: большие серверы могут иметь ОЧЕНЬ большие приложения с большим количеством памяти и большим количеством процессора - см. http://www.sun.com/servers/highend/m9000/ или http://www-03.ibm.com/systems/i/hardware/595/index.html - но он обычно дороже, чем наличие большого количества небольших серверов с распространяемым над ними приложением.