Я в первую очередь Java-разработчик, и я обращаюсь к вам с вопросом, который разделяет различия между разработчиками и системными администраторами.
Несколько лет назад, когда запускать Tomcat в качестве сервера приложений было новшеством, было принято ставить перед ним Apache. Насколько я понимаю, это было сделано потому, что:
- Java считалась «медленной», и было полезно, чтобы Apache напрямую обслуживал статический контент.
- Tomcat не может прослушивать порты 80/443, если не работает от имени пользователя root, что было опасно.
Java больше не считается медленной, и я сомневаюсь, что добавление Apache в микшер поможет ускорить процесс.
Что касается проблемы с портами, то в наши дни, возможно, существуют более простые способы подключения серверов приложений к портам 80/443.
Итак, мой вопрос: есть ли какая-то польза от создания веб-приложений Java с Apache в наши дни? Если так, Apache - все еще путь? Стоит ли смотреть на Nginx? Вместо Tomcat я использую Glassfish, если это имеет значение.
источник
Это зависит от экосистемы вокруг вашего приложения. В среде интрасети - вам, вероятно, ничего не нужно перед Tomcat.
Если один в Интернете, как публичная услуга, это зависит. Apache хорош из-за модулей, таких как mod_security. Но если вы не знакомы с конфигурацией apache (или ngix) - тогда вы можете подвергнуть себя даже БОЛЕЕ атакам или ошибкам из-за неправильной настройки.
Apache впереди пригодится для обслуживания страниц с перебоями в тех случаях, когда вам необходимо обновить веб-приложение и дождаться перезапуска. Но если перезапуски происходят редко или они рассчитаны правильно - это еще одна причина, по которой Tomcat может работать автономно.
Часто задаваемые вопросы Tomcat также говорят об этом, что касается некоторых дополнительных моментов: http://wiki.apache.org/tomcat/FAQ/Connectors#Q3
источник
Apache не является хорошим кандидатом для обслуживания статического контента из-за его многопроцессности. Nginx подходит лучше, так как он использует асинхронный ввод-вывод для обработки запросов. Современные Tomcats также могут использовать асинхронный ввод-вывод (NIO в терминологии Java). Например, вы должны установить
tomcat-nativeпакет в Fedora, чтобы Tomcat использовал асинхронный ввод-вывод.источник
Удивительно, некоторые из этих ответов - кто-нибудь из вас на самом деле работает на высокопроизводительных многоуровневых и много-серверных сайтах с поддержкой 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.
источник
Если это просто вопрос привязки привилегированных портов без использования root при использовании Tomcat, вам не нужно использовать его с Apache httpd. Tomcat по умолчанию поставляется с тем,
jsvcчто вам нужно скомпилировать.jsvcявляется оболочкой Java-сервиса для запуска Tomcat как сервиса Эта служба запускается от имени пользователя root, но запускает Tomcat от имени обычного пользователя. Таким образом, вы можете привязать ваш Tomcat к привилегированным портам.Я не знаю о Glassfish, но будьте уверены, что решения существуют, а если нет, вы наверняка можете использовать методы переадресации портов (iptables и т. Д.)
Я думаю, что выбор сервера приложений с веб-сервером (например, Apache httpd) для балансировки нагрузки, кластеризации или обслуживания статических ресурсов только с веб-сервером и динамических ресурсов с сервером приложений.
источник