Einzel EAR? Oder mehrere EARs?

Question

Wir entwickeln gerade eine JavaEE 6-basierte Anwendung, die auf JBoss EAP 6.1 implementiert werden soll. Die App verfügt über zwei primäre Präsentationsmechanismen: Eine Web-Admin-Konsole und eine RESTful-Service-API. Im Backend basieren sowohl die Verwaltungskonsole als auch die RESTful-Service-API auf einer Reihe von EJBs zum Ausführen von Transaktionslogik- und POJO-Diensten zum Abrufen von Daten.

Es ist durchaus möglich, dass die Leistungs- und Ressourcenanforderungen für alle diese verschiedenen Schichten unterschiedlich sein können. Die RESTful-Dienste sind eher dünn und vollständig zustandslos, wohingegen die Admin-Konsole zustandsbehaftet ist und mehr interaktive Funktionalität aufweist (und daher mehr Speicher und Verarbeitung erforderlich ist). Da unsere EJBs unsere primäre transaktionale Geschäftslogik ausführen, benötigen sie mehr Verarbeitungsleistung als unsere POJO-Datendienste, die einfach die Datenbank abfragen.

Wäre es bei einer solchen Konfiguration sinnvoller, ein einzelnes EAR (in mehreren Appservers in einer Clusterkonfiguration) mit all diesen Komponenten bereitzustellen oder die einzelnen Komponenten in separate EARs aufzuteilen? Ich denke mit separaten EARs, dass ich zum Beispiel mehr Instanzen der EJB-Dienste bereitstellen könnte, wenn ich Probleme mit der Skalierbarkeit feststellen kann, obwohl die Webkonsole (z. B.) problemlos skaliert.

Angesichts der Tatsache, dass die Skalierbarkeit jeder Schicht/Komponente unterschiedlich ist, welchen Ansatz sollte ich nehmen? Ist der Aufwand, entfernte EJB-Aufrufe über EARs hinweg durchführen zu müssen, um ein solches Modell zu berücksichtigen? Jeder Rat wird sehr geschätzt!

Answer 1

Der "Java EE" Weg wäre, Anwendung als einzelne EAR auf dem Cluster bereitzustellen. Ich nehme an, dass Sie lokale Schnittstellenaufrufe von REST/Admin-Konsole zu EJB-s verwenden. Die Bereitstellung wäre einfach, wenn Sie keine Sitzungsreplikation benötigen (Sie können sticky-Sitzungen verwenden), dann ist die Skalierbarkeit sehr gut. Das einzige zusätzliche Element, das Sie benötigen, ist Load Balancer für die Web-Anwendungen (zum Beispiel Apache Server, der sich auch um die SSL-Dekodierung kümmern würde, die Bereitstellung statischer Ressourcen und möglicherweise Zwischenspeicherungsanforderungen, die zwischengespeichert werden können).

Das einzige Problem mit einem solchen Setup kann für schwere Lasten auftreten, zum Beispiel EJBs essen eine Menge Serverressourcen, so dass der Durchsatz der Webanwendungen schwer zu kontrollieren ist und durch EJBs stark beeinträchtigt werden kann. Wenn Sie sticky-Sitzungen verwenden, wird der Benutzer immer auf denselben Server umgeleitet. Es besteht also keine Möglichkeit, einige Benutzer auf einen weniger ausgelasteten Server zu verschieben, solange die Benutzersitzung dauert.

Wenn Sie also hohe Lasten planen, wäre es sinnvoll, Webanwendungen und EJBs auf separaten Boxen (oder virtuellen Maschinen) zu belassen, damit Engpässe einfacher erkannt und die Ebene, die diese benötigt, leichter skaliert werden kann.

Die Strafe dafür wäre:

1. Ferngespräche zu EJBs. JBoss 6 verfügt jedoch über eine ziemlich fortschrittliche EJBs-Pooling-Konfiguration, daher ist es möglicherweise kein so großes Problem.
2. Netzwerkverkehr verursacht durch diese Remote-Aufrufe (wenn Sie also zwischen EJBs und Web-Layer eine Menge Daten übergeben, könnte es ein Problem sein).

Answer 2

Zur Unterstützung der großen Kommentare Piotr:

sie jetzt Bundle zusammen, und spaltete nur wenn ein echter Bedarf in der Zukunft entsteht.

Betrachten Sie die First Law of Distributed Object Design: Don’t distribute your objects! von Martin Fowler als eine gute Richtlinie - wenn Sie es brechen, tun Sie es zumindest bewusst und für echte geschäftliche Bedürfnisse.