ich auf der Bereitstellung von mehreren denke (und anderen) Web-Anwendungen auf demselben Server das folgende Schema verwendet:Bereitstellen von mehreren Web-Anwendungen in demselben Server
www.mydomain.com/app1
www.mydomain. com/app2
Ist das eine gute Praxis? Irgendwelche Empfehlungen?
Ich sehe keine eklatanten Gründe, warum Sie sollten nicht tun Sie es so. Schließlich ist nicht jede Website nur einer einzelnen Aufgabe oder Anwendung gewidmet. Ein anderer Ansatz wäre Subdomains zu verwenden, wie:
app1.mydomain.com
app2.mydomain.com
Yahoo und Google diese beiden verwenden, zum Beispiel. Der Ordner-Ansatz ist ein guter Weg, um Dinge zum Testen in Gang zu bringen.
Wenn die Anwendungen alle auf die Domäne bezogen sind, sehe ich kein Problem damit auf diese Weise.
Der einzige Nachteil dieses Ansatzes ist, dass Sie eine Umleitung oder Reverse-Proxying durchführen müssen, wenn eine der Apps auf einen anderen Server wechselt, während Sie bei einer Subdomain nur den A-Record für movedapp ändern müssten .domain.com.
Also, um es zukunftssicher zu machen, würde ich die Subdomains erstellen.
Sie erwähnen keine Technologie, aber wenn Sie Java dafür verwenden, teilen die Web-Apps (standardmäßig) keine Sitzungsinformationen. Dies kann insbesondere dann ein Problem darstellen, wenn sich ein Benutzer bei einer Webanwendung anmelden und auch bei der anderen Webanwendung angemeldet sein soll.
Bei einigen Containern (Tomcat, Glassfish) ist Single Sign On als implementierungsspezifisches Feature verfügbar.
Nur ein Vorwort von einigen der Auswirkungen der Entscheidung.
Mein üblicher Ansatz wäre, eine Website als einen einzelnen Zweck zu behandeln. "Single" definiert hier ein breites Ziel- und Nutzungsmuster. Wenn die mehreren Anwendungen alle zusammen passen und synergetisch auf den Zweck der Website hin arbeiten, dann ist
mydomain.com/app1 und mydomain.com/app2 ziemlich gut.
Es bedeutet, dass sie existieren und leben, um die Hauptseite zu erweitern.
Wenn die Anwendungen nichts miteinander zu tun haben und ziemlich in ihrer "eigenen Welt" leben, dann sollten sie wahrscheinlich als eigene Subdomains existieren.
app1.mydomain.com und app2.mydomain.com
dies ermöglicht die Einrichtung auf verschiedene IP-Adressen Ihrer DNS-Strategie (Web-Server/Farmen), anstatt sie zusammen im gleichen Pool bunching.
Ein Grund ist, wenn Sie SSL-Verbindungen zu Ihrem Webserver unterstützen wollten.
Wenn Sie den ordnerbasierten Ansatz verwenden, haben Sie kein Problem mit SSL-Zertifikaten.
Wenn Sie für die Subdomänenmethode (app1.mydomain.com, app2.mydomain.com, etc.) gehen, werden Sie wahrscheinlich ein Wildcard-SSL-Zertifikat benötigen, das teurer sein wird, oder mehrere Zertifikate.
Kein Problem, wenn Sie kein SSL benötigen oder nur wenige Anwendungen benötigen.