czy naprawdę konieczne jest uruchomienie Apache jako interfejsu do Glassfish / JBoss / Tomcat?

Jestem przede wszystkim programistą Java i przychodzę do ciebie z pytaniem, które łączy przepaść między programistami i administratorami.

Wiele lat temu, kiedy nowością było uruchamianie Tomcat jako serwera aplikacji, zwykle stosowano go w Apache. Jak rozumiem, zrobiono to, ponieważ:

1. Java została uznana za „powolną” i pomocne było bezpośrednie udostępnianie przez Apache zawartości statycznej.
2. Tomcat nie mógł nasłuchiwać portów 80/443, chyba że działałby jako root, co było niebezpieczne.

Java nie jest już uważana za powolną i wątpię, aby dodanie Apache do tego miksu faktycznie przyspieszyło.

Jeśli chodzi o problem z portami, obecnie prawdopodobnie istnieją prostsze sposoby łączenia serwerów aplikacji z portami 80/443.

Więc moje pytanie brzmi - czy naprawdę jest jakaś korzyść z przestawiania Java Webapps na Apache? Jeśli tak, to czy Apache wciąż jest do zrobienia? Czy powinienem spojrzeć na Nginx? Zamiast Tomcat używam Glassfish, jeśli to ma znaczenie.

Większość ludzi mówi, że potrzebujesz czegoś z przodu z powodu plików statycznych.

Jest to trochę głupie, ponieważ:

• Możesz skonfigurować Tomcat, aby używał tego samego We / Wy jako apache z APR
• Tak czy inaczej powinieneś korzystać z sieci CDN (Content Delivery Network).

Prawdziwy powód, dla którego potrzebujesz czegoś przed tomcat / jetty / jboss, aby uzyskać równoważenie obciążenia i obsługę trybu failover.

Polecam, aby nie słuchać „ ... Silnik Tomcat jest piętą achillesową całej ekosfery ... ”, ponieważ wszyscy wiemy, że to nieprawda ... twoja baza danych i pula połączeń będą takie.

To zależy od ekosystemu wokół Twojej aplikacji. W środowisku intranetowym - prawdopodobnie nie potrzebujesz niczego przed Tomcat.

Jeśli sam w Internecie jako usługa publiczna, to zależy. Apache jest fajny, ponieważ zapewnia moduły, takie jak mod_security. Ale jeśli nie znasz się na konfiguracji apache (lub ngix) - możesz narazić się na WIĘCEJ ataków lub punktów awarii z powodu błędnej konfiguracji.

Apache z przodu przydaje się do wyświetlania stron wyłączających w przypadkach, gdy musisz zaktualizować aplikację internetową i poczekać na ponowne uruchomienie. Ale jeśli ponowne uruchomienia są rzadkie lub są ustawione w odpowiednim czasie - to kolejny powód, aby przejść do Tomcat samodzielnie.

Tomcat FAQ również o tym mówi, co dotyczy kilku dodatkowych punktów: http://wiki.apache.org/tomcat/FAQ/Connectors#Q3

Apache nie jest dobrym kandydatem do udostępniania treści statycznych ze względu na jego wieloprocesowy charakter. Nginx lepiej pasuje, ponieważ wykorzystuje asynchroniczne operacje we / wy do przetwarzania żądań. Nowoczesne Tomcats mogą również wykorzystywać asynchroniczne operacje we / wy (NIO w terminologii Java). Na przykład powinieneś zainstalować tomcat-nativepakiet w Fedorze, aby Tomcat używał asynchronicznego We / Wy.

Niesamowite, niektóre z tych odpowiedzi - czy któryś z was faktycznie prowadzi wysokowydajne, wielopoziomowe i wspierane przez wiele serwerów strony Tomcat? OP, twoje oryginalne przypuszczenie, że Tomcat nie jest „wolny” ... wow. Silnik Tomcat to pięta achillesowa całej ekosfery.

Tak, chcesz Apache z przodu - zapewnia on przede wszystkim mod_rewrite (czy już zaimplementowałeś UrlRewriteFilter w swoim Tomcat?), A także pliki htaccess, które sprawiają, że ochrona serwera WWW jest tak ważna. Apache umożliwia ładowanie równoważących węzłów Tomcat za nim, szybsze dostarczanie zawartości statycznej i uzyskanie lepszej wydajności z Tomcat, ponieważ nie przeciążasz potoku żądań innymi niż Java (js / css / html / jpg / etc.) rzeczy Możesz z łatwością rozładować swój SSL w Apache (jeśli nie odciążasz sprzętowego LB) z łatwością i nawet nie musisz radzić sobie z tą parodią zwaną Java Keystore. Jest tyle zwycięstw - możesz dostroić mod_jk do swoich węzłów zaplecza, aby nie dopuścić do przekroczenia słabego mózgu Javy, ponieważ zazwyczaj nie jest w stanie obsłużyć ogromnego ruchu za pomocą przeciętnego programisty Java ”

Uważaj na każdego, kto powie ci, że Apache (lub nginx itp. - ale wydajność Apache'a i tak przewyższy Tomcata, więc to nie ma znaczenia) nie jest dobrym pomysłem przed Tomcat.

Jeśli jest to tylko kwestia powiązania portu uprawnień bez konieczności rootowania podczas korzystania z Tomcat, nie trzeba go przestawiać za pomocą Apache httpd. Tomcat domyślnie jest dostarczany z jsvctym, co musisz skompilować.

jsvcto opakowanie usługi Java do uruchamiania usługi Tomcat jako usługi. Ta usługa zaczyna się jako root, ale uruchamia Tomcat jako zwykły użytkownik. Możesz więc powiązać urządzenie Tomcat z uprzywilejowanymi portami.

Nie wiem o Glassfish, ale upewnij się, że istnieją rozwiązania, a jeśli nie, z pewnością możesz użyć technik przekierowania portów (iptables itp.)

Myślę, że wybór frontowania serwera aplikacji za pomocą serwera WWW (na przykład Apache httpd) dotyczy równoważenia obciążenia, klastrowania lub udostępniania zasobów statycznych tylko za pomocą serwera WWW i zasobów dynamicznych za pomocą serwera aplikacji.