Ich habe mich gefragt, ob es in Ordnung wäre, Tomcat sowohl als Webserver als auch als Container zu betreiben. Auf der anderen Seite scheint es, dass der richtige Weg zur Skalierung Ihrer Webapp ist, Apache HTTP zu verwenden, der auf Port 80 hört und diesen mit Tomcat verbindet, der auf einem anderen Port hört? Sind beide Wege akzeptabel? Was wird heute gebraucht? Was ist der Hauptunterschied? Wie gehen die meisten großen Websites damit um?
Danke.
Das Platzieren eines Apache (oder eines anderen Webservers) vor Ihrem Anwendungsserver (Tomcat) ist aus mehreren Gründen eine gute Sache.
Die erste Überlegung betrifft statische Ressourcen und Caching.
Tomcat wird wahrscheinlich auch eine Menge statischen Inhalt liefern, oder sogar bei dynamischen Inhalten werden einige Caching-Anweisungen an Browser gesendet. Jeder Browser, der Ihren Tomcat zum ersten Mal anspricht, wird Tomcat jedoch veranlassen, die statische Datei zu senden. Da die Verarbeitung einer Anfrage in Tomcat ein wenig teurer ist als in Apache (weil Apache superoptimiert ist und sehr wenig Material ausnutzt, das Tomcat nicht immer zur Verfügung stellt, weil Tomcat viel mehr Informationen aus der Anfrage extrahiert als Apache usw.) ..), es könnte besser sein, dass die statischen Dateien Server von Apache sind.
Da jedoch die Konfiguration von Apache für die Bereitstellung eines Teils des Inhalts und von Tomcat für den Rest oder den URL-Platz eine entmutigende Aufgabe ist, ist es in der Regel einfacher, Tomcat alles mit den richtigen Cache-Headern und Apache vor dem Capturing zu bedienen Inhalt, der dem benötigten Browser zur Verfügung gestellt wird und zwischengespeichert wird, so dass andere Browser, die die gleiche Datei treffen, direkt von Apache bedient werden, ohne Tomcat zu stören.
Abgesehen von statischen Dateien müssen auch viele dynamische Daten nicht alle Millisekunden aktualisiert werden. Ein von der Homepage geladener JSON, der dem Benutzer mitteilt, wie viel Zeugs sich in Ihrer Datenbank befindet, ist beispielsweise eine teure Abfrage, die tausende Male ausgeführt wird und ungefähr jede Stunde ausgeführt werden kann, ohne dass Ihre Benutzer verärgert sind. So kann Tomcat den JSON mit der richtigen 1-Stunden-Caching-Direktive bedienen, Apache wird das JSON-Fragment zwischenspeichern und es für jeden Browser bereitstellen, der es für eine Stunde benötigt. Es gibt natürlich eine Menge anderer Möglichkeiten, es zu implementieren (ein Caching-Filter, ein JPA-Cache, der die Abfrage zwischenspeichert usw.), aber das Senden korrekter Cache-Header und die Verwendung von Apache als Reverse-Proxy ist relativ einfach, REST-konform und skalierbar .
Eine weitere Überlegung ist der Lastenausgleich. Apache verfügt über ein schönes Lastenausgleichsmodul, mit dem Sie Ihre Anwendung auf eine Reihe von Tomcat-Instanzen skalieren können, vorausgesetzt, Ihre Anwendung kann horizontal skaliert oder auf einem Cluster ausgeführt werden.
Eine dritte Überlegung betrifft ulrs, header etc .. Von Zeit zu Zeit müssen Sie möglicherweise einige URLs ändern oder einige Header entfernen oder überschreiben. Vor einem größeren Update sollten Sie beispielsweise das Caching in Browsern für einige Stunden deaktivieren, um zu vermeiden, dass Browser veraltete Daten verwenden (ebenso wie die DNS-TTL vor dem Serverwechsel verringern) oder die alte Anwendung auf einen anderen URL-Platz verschieben oder neu schreiben URLs zu neuen wenn möglich. Das Rekonfigurieren der Servlets innerhalb Ihrer web.xml-Dateien ist möglich, und Filter können Wunder bewirken, wenn Sie ein Framework verwenden, das die URLs interpretiert, die Sie möglicherweise für Ihre Sitemap-Dateien oder ähnliches benötigen.
Wenn Apache oder ein anderer Webserver vor Tomcat installiert ist, kann es sehr hilfreich sein, nur Apache-Konfigurationsdateien mit Modulen wie mod_rewrite zu ändern.
Also, ich empfehle immer Apache httpd vor Tomcat. Der kleine Overhead bei der Verbindungsbearbeitung wird normalerweise durch das Zwischenspeichern von Ressourcen wiederhergestellt, und die zusätzlichen Konfigurationsarbeiten werden beim ersten Mal, wenn Sie URLs verschieben oder einige Header verarbeiten müssen, wiederhergestellt.
Es hängt von Ihrem Netzwerk ab und davon, wie Sie die Sicherheit eingerichtet haben möchten.
Wenn Sie über eine DMZ mit zwei Firewalls verfügen und Anwendungen innerhalb der zweiten Firewall bereitgestellt werden, ist es sinnvoll, eine Apache- oder IIS-Instanz zwischen den beiden Firewalls zu haben, um Sicherheits- und Proxy-Aufrufe auf dem Anwendungsserver auszuführen. Wenn es akzeptabel ist, die Tomcat-Instanz in die DMZ zu legen, können Sie dies tun. Der einzige Nachteil, den ich sehe, ist, dass Sie einen Port in der zweiten Firewall öffnen müssen, um auf eine Datenbank im Inneren zugreifen zu können. Das könnte die Datenbank gefährden.
Eine weitere Überlegung ist der Verkehr. Sie sagen nichts über Traffic, Dimensionierung von Servern und möglichen Lastenausgleich und Clustering. Ein Load Balancer vor einem Cluster von Anwendungsservern ist eher in der zweiten Firewall enthalten. Die Tomcat-Instanz ist in der Lage, den Datenverkehr eigenständig zu verarbeiten, es gibt jedoch immer Volumenbeschränkungen, abhängig von der Hardware, auf der sie bereitgestellt wird und was die Anwendung mit jeder Anforderung macht. Es ist fast unmöglich, ohne detaillierte, anwendungsspezifische Informationen eine Ja- oder Nein-Antwort zu geben.
Suche die Seite nach "Tomcat ohne Apache" - es wurde schon einmal gefragt. Ich habe gewählt zu schließen, bevor Duplikate gefunden.