Назад | Перейти на главную страницу

Есть ли причина использовать Apache в качестве прокси между моими пользователями и Glassfish?

Я видел много дискуссий о том, как лучше всего использовать Apache в качестве прокси (mod_proxy или mod_jk) с Glassfish (и другими серверами приложений Java), но я не видел, чтобы кто-нибудь действительно объяснял почему.

Моя установка прямо сейчас - это один VPS под управлением Ubuntu Server с Glassfish, принимающим HTTP-запросы на порт 8080 (iptables перенаправляет запросы порта 80 на порт 8080, поэтому мне не нужно запускать Glassfish как root). У меня есть несколько небольших сайтов.

Мой сайт разделен на две основные части: статическую и динамическую. Каждый из них находится в отдельном субдомене. Было бы легко обрабатывать статический контент с помощью Apache (или другого веб-сервера), а затем использовать Apache в качестве прокси для динамического контента, но есть ли причина для этого?

Если бы я использовал Apache, в идеале ему пришлось бы использовать менее 100 МБ памяти, чтобы освободить место для всего остального.

Используя последний сервер приложений (Glassfish 3), получу ли я какое-либо повышение производительности, используя Apache в качестве прокси?

Насколько хорошо Glassfish обслуживает статический контент? Виртуальный хостинг на основе имени? Перенаправления? Готов поспорить, что у Apache все это лучше. Однако, если вас особенно интересует небольшой внешний веб-сервер, обратите внимание на nginx вместо Apache.

Существует множество причин, по которым вам следует рассмотреть возможность использования обратного прокси перед сервером приложений Java:

  • В Linux вы не должны запускать GlassFish с правами root, но вы не можете использовать порт 80 или 443, если вы не являетесь пользователем root. Обратный прокси - это один из способов решения этой проблемы. Другие способы решения этой проблемы включают xinetd и iptables. В качестве альтернативы вы можете просто не использовать стандартные веб-порты (не удобные для пользователей или SEO).
  • Если у вас уже есть существующий веб-сервер, закрепленный на нужном вам порту, вы можете «поделиться» им через обратный прокси. Например, поместите приложения PHP и Java на порт 80 одного и того же веб-сервера.
  • Apache лучше протестирован (часто используется) и более безопасен, чем GlassFish (используется не часто), поэтому он может защитить его от прямого доступа. Например, эксперты по безопасности (SANS) советуют использовать трехуровневую архитектуру, в которой передний веб-сервер находится в DMZ, а сервер приложений находится на среднем уровне безопасности (а база данных находится в третьей, даже более безопасной сети).
  • Вы можете вносить изменения в сервер приложений без ведома пользователей (например, переименовывать его или разделять с одного на несколько).
  • Может иметь лучшую производительность со статическим контентом (может использовать собственный доступ к файлам ОС, но GlassFish может кэшировать статический контент в памяти, если вы сообщите об этом, поэтому это может быть незначительным)
  • Более знакомые переопределение URL-адресов, перенаправления, настраиваемые заголовки, кеширование, виртуальный хостинг (примечание: GlassFish выполняет все эти действия или может делать их с помощью настраиваемых фильтров сервлетов или сторонних фильтров сервлетов, таких как Tuckey URLRewrite).