масштабируемость и производительность в Java-приложениях - PullRequest
2 голосов
/ 06 марта 2011

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

Существуют ли фреймворки, которые заставляют вас писать масштабируемый код?Вы могли бы рассмотреть php как внешний интерфейс, а Java как бэкэнд-технологию?Или допустим, что JSF также разумен и все дело в вашей архитектуре?И как хорошо с Grails развивается в этом контексте?

Надеюсь, эта тема не слишком субъективна, но я хотел бы поделиться с вами некоторыми впечатлениями: -)

Ответы [ 3 ]

2 голосов
/ 12 августа 2011

Если вы хотите создать хорошо масштабируемое приложение, оно должно быть без учета состояния и максимально использовать архитектуру без совместного использования. Если вы ничего не разделяете между узлами, а узел не имеет состояния, то синхронизация минимальна. Есть несколько хороших веб-фреймворков, подходящих для ваших требований (Play Framework и Lift for Java, Django для Python, Ruby on Rails для Ruby).

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

1 голос
/ 12 августа 2011

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

0 голосов
/ 06 марта 2011

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

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

Итак, я бы выбрал архитектуру, в которой вам не нужно слишком много состояний на сервере. ИМХО, основанная на действии инфраструктура больше подходит для этого типа архитектуры, чем основанная на компонентах архитектура, если состояние не обрабатывается на стороне клиента с богатыми компонентами JavaScript.

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