¿Es realmente necesario ejecutar Apache como front-end para Glassfish / JBoss / Tomcat?

14

Soy principalmente un desarrollador de Java, y llego a usted con una pregunta que se extiende entre la división entre los desarrolladores y los administradores de sistemas.

Hace años, cuando era algo novedoso ejecutar Tomcat como servidor de aplicaciones, era habitual enfrentarlo con Apache. Según tengo entendido, esto se hizo porque:

  1. Java se consideró "lento", y fue útil que Apache sirviera contenido estático directamente.
  2. Tomcat no podía escuchar los puertos 80/443 a menos que se ejecutara como root, lo cual era peligroso.

Java ya no se considera lento, y dudo que agregar Apache a la mezcla realmente ayude a acelerar las cosas.

En cuanto a la cuestión de los puertos, es probable que haya formas más sencillas de conectar servidores de aplicaciones a los puertos 80/443 en estos días.

Entonces mi pregunta es: ¿hay realmente algún beneficio al enfrentar Java Webapps con Apache en estos días? Si es así, ¿Apache sigue siendo el camino a seguir? ¿Debo mirar a Nginx? En lugar de Tomcat estoy usando Glassfish, si eso importa.

apache-2.2 glassfish tomcat Coma de cafeína
fuente

Respuestas:

8

La mayoría de la gente va a decir que necesitas algo por adelantado debido a los archivos estáticos.

Esto es algo tonto porque:

  • Puede configurar Tomcat para usar el mismo IO que apache con APR
  • De todos modos, debe utilizar una CDN (red de entrega de contenido).

La verdadera razón por la que necesita algo delante de tomcat / jetty / jboss para cargar el equilibrio y manejar la conmutación por error.

Le recomiendo que no escuche " ... El motor Tomcat es el talón de Aquiles de toda la ecosfera ... " ya que todos sabemos que eso no es cierto ... su base de datos y su agrupación de conexiones será eso.

Adam Gent
fuente
Adam, ¿me estás acosando de StackOverflow a Serverfault? :-) Estoy de acuerdo con tu respuesta. En retrospectiva, debería haber formulado la pregunta mejor para reflejar la situación real: realmente hay muy poco contenido estático para hablar, ya que la base de datos está involucrada en casi cualquier visita a la página. En este momento (exploración de inicio muy temprana) no necesitamos equilibrio de carga, pero con suerte lo necesitaremos en el futuro.
Cafeína Coma
@Caffeine Coma Estoy en el mismo barco y parece que estamos usando la misma tecnología, de ahí la casualidad de estar en los mismos hilos a través de Stackexchanges (juro que no estoy acechando :)). Por cierto, estamos usando Nginx + Tomcat.
Adam Gent
5

Depende del ecosistema alrededor de su aplicación. En un entorno de intranet, probablemente no necesite nada frente a Tomcat.

Si está solo en Internet como un servicio público, depende. Apache es bueno debido a los módulos que proporciona, como mod_security. Pero si no conoce la configuración de apache (o ngix), entonces podría exponerse a MÁS ataques o puntos de falla debido a una configuración incorrecta.

Apache en el frente es útil para servir páginas de interrupción en caso de que necesite actualizar la aplicación web y esperar un reinicio. Pero si los reinicios son raros o están sincronizados correctamente, entonces es otra razón para ir a Tomcat de forma independiente.

Las preguntas frecuentes de Tomcat también se refieren a esto, que aborda algunos puntos adicionales: http://wiki.apache.org/tomcat/FAQ/Connectors#Q3

Tim Funk
fuente
1

Apache no es un buen candidato para servir contenido estático debido a su naturaleza multiproceso. Nginx se adapta mejor ya que usa E / S asíncronas para procesar solicitudes. Los Tomcats modernos también pueden usar E / S asíncronas (NIO en terminología de Java). Por ejemplo, debe instalar el tomcat-nativepaquete en Fedora para que Tomcat use E / S asíncrona.

Alex
fuente
Realmente no estoy sirviendo mucho contenido estático de todos modos. Mi pregunta es realmente: ¿tengo que molestarme con un front-end de Apache / Nginx o simplemente con Glassfish? Gracias.
Cafeína Coma
En realidad, el problema es más amplio que simplemente servir contenido estático porque si su servidor no usa clientes de E / S asíncronas con conexiones lentas, bloqueará los hilos de ejecución del servidor hasta que tengan el contenido completo. Por lo tanto, tener un frontend alimentado por AIO es un beneficio en cualquier caso. Pero, como ya mencioné, Tomcat tiene capacidades AIO. Creo que el paquete estándar de Glassfish ya incluye la biblioteca AIO, por lo que probablemente no debería molestarse.
Alex
Apache no es necesariamente multiproceso. mpm worker ha estado fuera por algún tiempo httpd.apache.org/docs/2.2/mod/worker.html y lo estamos utilizando en un entorno de producción para un servidor web multiproceso.
dialt0ne
Bueno, Apache multiproceso todavía usa E / S sincrónica. No veo una gran diferencia si los procesos lentos bloquean los hilos no los procesos en un socket. Nginx está diseñado como máquina de estado finito de un solo proceso de un solo subproceso (bueno, no es necesario un solo proceso, el número de procesos debe establecerse en el número de núcleos de CPU en un sistema de múltiples núcleos).
Alex
1

Sorprendente, algunas de estas respuestas: ¿alguna de ustedes maneja sitios web respaldados por Tomcat de múltiples niveles y múltiples servidores de alto rendimiento? OP, su suposición original de que Tomcat no es "lento" ... wow. El motor Tomcat es el talón de Aquiles de toda la ecosfera.

Sí, quiere Apache al frente: proporciona en primer lugar mod_rewrite (¿ya implementó UrlRewriteFilter en su Tomcat?), Así como los archivos htaccess que hacen que proteger un servidor web sea tan importante. Apache puede permitirle equilibrar la carga de los nodos de Tomcat detrás de él, servir su contenido estático mucho más rápido y obtener un mejor rendimiento de Tomcat porque no está sobrecargando su canal de solicitud con no Java (js / css / html / jpg / etc.) cosas. Puede descargar su SSL en Apache (si no está descargando en un LB de hardware) con facilidad y ni siquiera tiene que lidiar con esa parodia llamada Java Keystore. Hay tantas victorias: puede sintonizar mod_jk en sus nodos de back-end para evitar invadir el pobre cerebro de Java porque normalmente no puede manejar el tráfico masivo con el codificador promedio de Java '

Tenga cuidado con cualquiera que le diga que Apache (o nginx, etc., pero el rendimiento de Apache eclipsará a Tomcat de todos modos, así que no importa) no es una buena idea delante de Tomcat.


fuente
44
Suenas muy ofendido.
Cafeína Coma
Simplemente disgustado porque la gente ofrece tan malos consejos sobre ServerFault.
Tenga cuidado con cualquiera que grite sin ningún número para respaldar tales afirmaciones. Si su sitio es principalmente dinámico, Tomcat directo será más rápido. La mayoría de los sitios de tráfico pesado en estos días usan CDN (red de entrega de contenido) para su contenido estático, por lo que no hay razón para usar Apache para servir su contenido estático. Dicho esto, aún debe tener algo por delante para el equilibrio de carga / ssl.
Adam Gent
0

Si solo se trata de vincular el puerto de privilegios sin ser root cuando se usa Tomcat, no es necesario que lo enfrente con Apache httpd. Tomcat viene por defecto con lo jsvcque necesita compilar.

jsvces un contenedor de servicios de Java para lanzar Tomcat como servicio. Este servicio comienza como root pero inicia Tomcat como un usuario normal. Para que pueda vincular su Tomcat a puertos privilegiados.

No sé acerca de Glassfish, pero asegúrese de que existan soluciones y si no, seguramente puede usar técnicas de reenvío de puertos (iptables, etc.)

Creo que la elección de enfrentar un servidor de aplicaciones con un servidor web (Apache httpd, por ejemplo) es para equilibrar la carga, agrupar o servir recursos estáticos solo con un servidor web y recursos dinámicos con un servidor de aplicaciones.

Laurent T
fuente