действительно ли необходимо запускать Apache в качестве внешнего интерфейса для Glassfish / JBoss / Tomcat?

14

Я в первую очередь Java-разработчик, и я обращаюсь к вам с вопросом, который разделяет различия между разработчиками и системными администраторами.

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

Java считалась «медленной», и было полезно, чтобы Apache напрямую обслуживал статический контент.
Tomcat не может прослушивать порты 80/443, если не работает от имени пользователя root, что было опасно.

Java больше не считается медленной, и я сомневаюсь, что добавление Apache в микшер поможет ускорить процесс.

Что касается проблемы с портами, то в наши дни, возможно, существуют более простые способы подключения серверов приложений к портам 80/443.

Итак, мой вопрос: есть ли какая-то польза от создания веб-приложений Java с Apache в наши дни? Если так, Apache - все еще путь? Стоит ли смотреть на Nginx? Вместо Tomcat я использую Glassfish, если это имеет значение.

apache-2.2 glassfish tomcat

— Кофеин Кома
источник

8

Большинство людей скажут, что вам нужно что-то впереди из-за статических файлов.

Это несколько глупо, потому что:

Вы можете настроить Tomcat на использование того же ввода-вывода, что и Apache с APR.
В любом случае вы должны использовать CDN (сеть доставки контента).

Реальная причина, по которой вам нужно что-то перед tomcat / jetty / jboss для балансировки нагрузки и обработки отказа.

Я рекомендую вам не слушать " ... движок Tomcat - это ахиллесова пята всей экосферы ... ", поскольку все мы знаем, что это неправда ... ваша база данных и ее пул соединений будут такими.

— Адам Гент
источник

Адам, ты преследуешь меня из StackOverflow в Serverfault? :-) Я согласен с вашим ответом. Оглядываясь назад, мне следовало бы сформулировать вопрос лучше, чтобы отразить реальную ситуацию: на самом деле очень мало статического контента, о котором можно говорить, поскольку БД участвует практически в любом обращении к странице. В настоящее время (очень раннее исследование стартапа) нам не нужно балансировать нагрузку, но, если повезет, она понадобится нам в будущем.

— Кофеин Кома

@Caffeine Coma Я нахожусь в одной лодке, и, похоже, мы используем одну и ту же технологию, поэтому вполне вероятно, что мы работаем над одними и теми же потоками на Stackexchanges (клянусь, я не преследую :)). Кстати, мы используем Nginx + Tomcat.

— Адам Гент

5

Это зависит от экосистемы вокруг вашего приложения. В среде интрасети - вам, вероятно, ничего не нужно перед Tomcat.

Если один в Интернете, как публичная услуга, это зависит. Apache хорош из-за модулей, таких как mod_security. Но если вы не знакомы с конфигурацией apache (или ngix) - тогда вы можете подвергнуть себя даже БОЛЕЕ атакам или ошибкам из-за неправильной настройки.

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

Часто задаваемые вопросы Tomcat также говорят об этом, что касается некоторых дополнительных моментов: http://wiki.apache.org/tomcat/FAQ/Connectors#Q3

— Тим Функ
источник

1

Apache не является хорошим кандидатом для обслуживания статического контента из-за его многопроцессности. Nginx подходит лучше, так как он использует асинхронный ввод-вывод для обработки запросов. Современные Tomcats также могут использовать асинхронный ввод-вывод (NIO в терминологии Java). Например, вы должны установить tomcat-nativeпакет в Fedora, чтобы Tomcat использовал асинхронный ввод-вывод.

— Alex
источник

Во всяком случае, я не очень много показываю статического контента. Мой вопрос на самом деле: мне нужно беспокоиться о внешнем интерфейсе Apache / Nginx, или просто пойти с прямым Glassfish? Благодарю.

— Кофеин Кома

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

— Алекс

apache не обязательно многопроцессный. В течение некоторого времени работника mpm не было httpd.apache.org/docs/2.2/mod/worker.html, и мы используем его в производственной среде для многопоточного веб-сервера.

— dialt0ne

Ну, многопоточный Apache все еще использует синхронный ввод-вывод. Я не вижу большой разницы, если медленные клиенты будут блокировать потоки, а не процессы на сокете. Nginx спроектирован как однопоточный однопроцессный конечный автомат (ну, не обязательно однопроцессный, количество процессов должно быть установлено равным количеству ядер ЦП в многоядерной системе).

— Alex

1

Удивительно, некоторые из этих ответов - кто-нибудь из вас на самом деле работает на высокопроизводительных многоуровневых и много-серверных сайтах с поддержкой Tomcat? OP, ваше первоначальное предположение, что Tomcat не "медленный" ... вау. Двигатель Tomcat - это ахиллесова пята всей экосферы.

Да, вам нужен Apache впереди - он в первую очередь предоставляет mod_rewrite (вы уже реализовали UrlRewriteFilter в вашем Tomcat?), А также файлы htaccess, которые делают защиту веб-сервера настолько важной. Apache может позволить вам балансировать нагрузку на узлы Tomcat, расположенные за ним, гораздо быстрее обслуживать статический контент и получать лучшую производительность от Tomcat, потому что вы не перегружаете его канал запросов не-Java (js / css / html / jpg / и т.д.). вещи. Вы можете с легкостью разгрузить ваш SSL в Apache (если не разгрузить на аппаратном LB), и вам даже не придется иметь дело с этой пародией, называемой Java Keystore. Выигрывает так много побед - вы можете настроить mod_jk на свои внутренние узлы, чтобы избежать переполнения слабого мозга Java, потому что он обычно не может обрабатывать большой трафик с помощью обычного Java-кодера ».

Остерегайтесь любого, кто скажет вам, что Apache (или nginx и т. Д. - но производительность Apache в любом случае превзойдет Tomcat, так что это не имеет значения) не является хорошей идеей перед Tomcat.

4

Вы звучите очень обиженным.

— Кофеин Кома

Просто противно, что люди предлагают такой плохой совет по ServerFault.

Остерегайтесь тех, кто без каких-либо цифр поддерживает эти заявления. Если ваш сайт в основном динамический, то прямой кот будет быстрее. Большинство сайтов с большим трафиком в наши дни используют CDN (сеть доставки контента) для своего статического контента, поэтому нет никаких оснований использовать Apache для обслуживания вашего статического контента. При этом у вас должно быть что-то еще для балансировки нагрузки / ssl.

— Адам Гент

0

Если это просто вопрос привязки привилегированных портов без использования root при использовании Tomcat, вам не нужно использовать его с Apache httpd. Tomcat по умолчанию поставляется с тем, jsvcчто вам нужно скомпилировать.

jsvcявляется оболочкой Java-сервиса для запуска Tomcat как сервиса Эта служба запускается от имени пользователя root, но запускает Tomcat от имени обычного пользователя. Таким образом, вы можете привязать ваш Tomcat к привилегированным портам.

Я не знаю о Glassfish, но будьте уверены, что решения существуют, а если нет, вы наверняка можете использовать методы переадресации портов (iptables и т. Д.)

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

— Лоран Т
источник