Hinweise zum Bereitstellen von War-Dateien im Vergleich zu ausführbaren JAR-Dateien mit eingebettetem Container

Question

Es scheint einen aktuellen Trend im Bereich Java= zu geben, der von der Bereitstellung von Java= Webanwendungen in einen Java= Servlet-Container verschoben werden muss (oder Application Server) in Form einer War-Datei (oder Ear-Datei) und packen Sie die Anwendung stattdessen als ausführbare JAR mit einem eingebetteten Servlet/HTTP-Server wie Jetty Neue Anwendungen werden entwickelt und bereitgestellt, anstatt wie Anwendungen an Endbenutzer geliefert werden (weil ich zum Beispiel verstehe, warum Jenkins einen eingebetteten Container verwendet, der sehr einfach zu handhaben ist.) Beispiele für Frameworks, die die ausführbare jar-Option verwenden: Dropwizard , Spring Boot und Play (Nun, es läuft nicht auf einem Servlet-Container, aber der HTTP-Server ist eingebettet).

Meine Frage ist, aus einer Umgebung, in der wir unsere (bis jetzt meistens Struts2) Anwendungen auf einem einzelnen Tomcat-Anwendungsserver bereitgestellt haben, welche Änderungen, Best Practices oder Überlegungen erforderlich sind, wenn wir einen Embedded-Container-Ansatz verwenden möchten ? Gegenwärtig gibt es ungefähr 10 hausgemachte Anwendungen, die auf einem einzelnen Tomcat-Server ausgeführt werden, und für diese kleinen Anwendungen ist die Möglichkeit, Ressourcen gemeinsam zu nutzen und auf einem Server verwaltet zu werden, sehr gut. Unsere Anwendungen dürfen nicht an Endbenutzer verteilt werden, damit sie in ihrer Umgebung ausgeführt werden können. Sollte sich dieser Ansatz jedoch ändern, wenn wir uns für die Nutzung eines neueren Java=) - Frameworks entscheiden? Wird die Verlagerung auf ausführbare Jars durch die zunehmende Verwendung von Cloud-Bereitstellungen (z. B. Heroku) vorangetrieben?

Wenn Sie Erfahrung mit der Verwaltung mehrerer Anwendungen im Bereitstellungsstil "Play" im Vergleich zur herkömmlichen Bereitstellung von War-Dateien auf einem einzelnen Anwendungsserver haben, teilen Sie uns Ihre Erkenntnisse mit.

kapex · Accepted Answer

Eine interessante Frage. Dies ist nur meine Ansicht zum Thema, also nimm alles mit einem Körnchen Salz. Ich habe gelegentlich Anwendungen mit Servlet-Containern und eingebetteten Servern bereitgestellt und verwaltet. Ich bin mir sicher, dass es immer noch viele gute Gründe gibt, Servlet-Container zu verwenden, aber ich werde mich nur darauf konzentrieren, warum sie heute weniger beliebt sind.

Kurzversion: Servlet-Container eignen sich hervorragend zum Verwalten mehrerer Anwendungen auf einem einzelnen Host, scheinen jedoch nicht sehr nützlich zu sein, um nur eine einzelne Anwendung zu verwalten. In Cloud-Umgebungen scheint eine einzige Anwendung pro virtueller Maschine vorzuziehen und üblicher zu sein. Moderne Frameworks wollen Cloud-kompatibel sein, daher die Verlagerung auf Embedded Server.

Ich denke, Cloud-Services sind der Hauptgrund für den Verzicht auf Servlet-Container. So wie Sie mit Servlet-Containern Anwendungen verwalten können, können Sie mit Cloud-Diensten virtuelle Maschinen, Instanzen, Datenspeicher und vieles mehr verwalten. Das klingt komplizierter, aber mit Cloud-Umgebungen hat es eine Verlagerung auf einzelne App-Computer gegeben. Dies bedeutet, dass Sie häufig die gesamte Maschine so behandeln können, als wäre sie die Anwendung. Jede Anwendung läuft auf einem Rechner mit entsprechender Größe. Cloud-Instanzen können jederzeit angezeigt und ausgeblendet werden, was sich hervorragend für die Skalierung eignet. Wenn eine Anwendung mehr Ressourcen benötigt, erstellen Sie mehr Instanzen.

Dedizierte Server hingegen sind in der Regel leistungsstark, haben jedoch eine feste Größe. Sie können also mehrere Anwendungen auf einem einzelnen Computer ausführen, um die Ressourcennutzung zu maximieren. Das Verwalten von Dutzenden von Anwendungen - jede mit ihren eigenen Konfigurationen, Webservern, Routen und Verbindungen usw. - macht keinen Spaß. Die Verwendung eines Servlet-Containers hilft Ihnen, alles handhabbar zu halten und sich selbst in den Griff zu bekommen. Es ist jedoch schwieriger zu skalieren. Servlet-Container in der Cloud scheinen nicht sehr nützlich zu sein. Sie müssten für jede winzige Instanz eingerichtet werden, ohne viel Nutzen zu bringen, da sie nur eine einzige Anwendung verwalten.

Wolken sind auch cool und Nicht-Wolken-Zeug ist langweilig (wenn wir immer noch an den Hype glauben). Viele Frameworks versuchen standardmäßig skalierbar zu sein, sodass sie problemlos in den Clouds bereitgestellt werden können. Eingebettete Server lassen sich schnell bereitstellen und ausführen, sodass sie als vernünftige Lösung erscheinen. Servlet-Container werden normalerweise weiterhin unterstützt, erfordern jedoch eine kompliziertere Einrichtung.

Einige andere Punkte:

Der eingebettete Server könnte für das Framework optimiert sein oder ist besser in das Framework-Tooling integriert (wie zum Beispiel die Spielekonsole).
Nicht alle Cloud-Umgebungen verfügen über anpassbare Computerabbilder. Anstatt Initialisierungsskripts zum Herunterladen und Einrichten von Servlet-Containern zu schreiben, ist die Verwendung von dedizierter Software für Cloud-Anwendungsbereitstellungen viel einfacher.
Ich habe noch kein Tomcat-Setup gefunden, das Sie nicht alle paar Neuinstallationen Ihrer App mit einem perm gen space error begrüßt. Das (erneute) Starten eingebetteter Server dauert etwas länger und ist kein Problem, wenn Sie ohne Ausfallzeit fast sofort zwischen Staging- und Produktionsinstanzen wechseln können.
Wie bereits in der Frage erwähnt, ist es für den Endbenutzer sehr bequem, die Anwendung einfach auszuführen.
Embedded Server sind portabel und praktisch für die Entwicklung. Heute ist alles schnell, Prototypen und MVPs müssen so schnell wie möglich erstellt und ausgeliefert werden. Niemand möchte zu viel Zeit damit verbringen, für jeden Entwickler eine Umgebung einzurichten.