Как структурированы очень большие веб-сайты Java EE?

Question

Лучший практический вопрос - как очень большие сайты лучше всего структурированы с помощью Java.

Мне интересно знать, как устроены сами развертывания -

Некоторые возможные ответы:

• Одно ухо - с / без сессии разделение между учредительными войны?
• Несколько войн - с / без сеанс обмена?
• несколько модулей которые собраны в одну большую войну во время развертывания?

Есть ли документированная лучшая практика для этого?

Answer 1

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

Я не знаю, что существует "лучшая практика", которая соблюдается единообразно.

Ваша самая большая проблема - совместное использование и развертывание сеанса. Независимо от того, как это делается, я бы сказал, что данные сеанса должны быть сведены к минимуму и разделены между WARs? Один владелец для данных, пожалуйста. Совместное использование предполагает, что вы распределили функциональность для одного варианта использования по модулям. Это когда-нибудь приведет к горе.

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

Answer 2

Когда вы говорите «очень большие веб-сайты», я предполагаю, что у веб-сайта слишком много модулей и субмодулей. Не сайт с большим трафиком. Если вас интересует сайт с большим трафиком, перефразируйте и оставьте другой вопрос или обновите его.

Держите его модульным с несколькими EAR / WAR. Модульность дает возможность каждому модулю развиваться независимо от других, если не происходит изменение интерфейса модуля. Если в интерфейсе есть изменения, зависимый модуль также должен быть обновлен. Хотя это и не веб-сайт, одним из таких примеров является Eclipse IDE. Каждый из его модулей разрабатывается и поддерживается независимо и имеет свои версии. Модульность веб-сайта также дает возможность развертывать отдельные модули на отдельных машинах / серверах и, следовательно, может масштабироваться индивидуально.

Совместное использование сеансов между EAR / WAR будет считаться плохой идеей. Это слишком большая работа для сервера. Кроме того, он может содержать ошибки, которые будет трудно отлаживать, как и глобальные переменные. Но иметь пользователя, чтобы войти снова и снова для каждого модуля тоже очень плохо. Для этого вам необходимо реализовать какое-либо решение «Единый вход (SSO)». Что касается примера, то www.google.com, www.gmail.com, www.orkut.com и т. Д. - все это службы Google, и каждая служба представляет собой отдельный модуль. Но если вы войдете в один из сервисов, а затем откроете другой без выхода, вы автоматически войдете в систему.

Хотя модули модулей, которые собраны в одну большую войну, - плохая идея, один раз в год вы можете развернуть все модули вместе (не как одну WAR, а по отдельности) и назвать это как-нибудь. Подобную вещь можно увидеть с затмением. Eclipse имеет время от времени обновления для каждого отдельного модуля, но один раз в год у них выпускается основная версия, где обновляются все модули (Europa, Ganymede, Galileo ...).

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