Внешние против внутренних ресурсов для военных развертываний, например Tomcat - PullRequest
Новая
       14

Внешние против внутренних ресурсов для военных развертываний, например Tomcat

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

У меня есть веб-приложение, которое в настоящее время использует внешний каталог для размещения статических файлов, например css, speed, в веб-приложении Spring. То есть каталог находится внутри каталога webapp tomcat, но не внутри WAR.

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

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

1 Ответ

0 голосов
/ 23 августа 2011

Как правило, веб-сервер перед сервером приложений по-прежнему действует:

  1. веб-сервер для обеспечения терминации TLS / SSL; клиенты общаются с вашим URL через HTTPS, веб-сервер прерывает SSL и пересылает простые HTTP-сообщения на ваш сервер приложений (tomcat). В этом случае веб-сервер может взять на себя нагрузку, вызванную шифрованием (загрузка ЦП)
  2. веб-сервер для обслуживания статического контента; Когда речь идет о сайтах с высоким трафиком или сайтах, обслуживающих большое количество статического контента, веб-сервер может предоставлять статический контент. Подумайте о приложении, предоставляющем каталог продуктов, который содержит изображения с высоким разрешением (скажем,> 1 м). Для загрузки изображений непосредственно с сервера приложений требуется один поток на сервере приложений. Это также уменьшает количество операций ввода-вывода в сети на узле сервера приложений.
  3. веб-сервер в демилитаризованной зоне (DMZ); общий шаблон в развертывании предприятия. Веб-сервер размещен в общедоступной зоне, а сервер приложений - во внутренней зоне, доступной только веб-серверу . Это вводит еще один уровень безопасности.
  4. веб-сервер для обеспечения статического кэширования; веб-серверы как у Apache, когда дело доходит до кэширования, хорошо.

Без вопросов, в зависимости от вашего варианта использования он может выглядеть по-разному:

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

Наличие веб-сервера и сервера приложений на одних и тех же узлах уменьшает преимущества предоставления веб-сервера . Мой опыт показывает, что когда дело доходит до «небольших» внутренних приложений, используемых «несколькими пользователями», веб-сервер не нужен, и tomcat хорошо работает. Это особенно верно, если ваше приложение обслуживает только некоторые статические файлы, такие как icons , css и javascript .

Надеюсь, это поможет ...

...