Skalierbarkeit und Hochverfügbarkeit einer Java-Einzellösung

Question

Wir führen derzeit eine Java-Integrationsanwendung auf einer Linux-Box aus. Zunächst ein Überblick über die Anwendung.

Die Java-Anwendung ist eine eigenständige Anwendung (die nicht auf einem Java EE-Anwendungsserver wie OracleAS, WebLogic, JBOSS usw. bereitgestellt wird). Mit Stand Alone meine ich, dass es sich NICHT um eine DESKTOP-Anwendung handelt. Sie wird jedoch von der Befehlszeile aus einer Hauptklasse ausgeführt. Der Benutzer interagiert überhaupt nicht direkt mit dieser Anwendung. Die Nachrichten werden über eine API in die Warteschlange eingegeben, die dann von meiner Anwendung ausgelesen wird, die rund um die Uhr läuft. Ich würde dies nicht als Desktop-Anwendung bezeichnen, da der Benutzer keine direkte Interaktion mit ihr hat (ich bin mir nicht sicher, ob dies die korrekte Argumentation ist, um sie als solche zu bezeichnen).

Es verwendet Spring und stellt eine Verbindung zu WebSphere MQ und Oracle Database her. Wir verwenden einen Spring Listener (Spring Message Driven POJOs), der auf eine Warteschlange auf WebSphere MQ hört. Sobald sich eine Nachricht in der Warteschlange befindet, liest die Anwendung die Nachricht aus dem MQ und speichert sie in der Datenbank ab (einfügen/aktualisieren).

Nun stellt sich die Frage:

1. Wie können wir diese Anwendung horizontal skalieren? Ich meine, einfach mehr Boxen aufstellen und mehrere Instanzen der gleichen Anwendung laufen lassen, ist das ein praktikabler Ansatz?
2. Sollten wir einen Wechsel von Spring MDPs zu EJB MDBs in Betracht ziehen? Dabei sollten wir sie auf dem Anwendungsserver bereitstellen. Gibt es einen zusätzlichen Nutzen, wenn wir das tun?
3. Es gibt einen Antrag, die Anwendung hochverfügbar (HA) zu machen? Welche Methoden oder Strategien werden vorgeschlagen, um eine eigenständige Anwendung hochverfügbar zu machen?

Answer 1

Eine weitere Möglichkeit ist Terrakotta ein Framework, das genau das tut, was Sie wollen: Ihre Anwendung auf mehreren Rechnern gleichzeitig laufen lassen und die Last auf diese verteilen.

Answer 2

Die horizontale Skalierung stößt bei jeder Anwendung irgendwann an ihre Grenzen, wenn die Nachfrage nach den Daten steigt. Diese Grenzen werden durch die Last und die Server-/Datenbankleistung bestimmt. Wenn Bedarf und Last mit der Skalierung steigen, muss irgendwann auch die Anzahl der Server/Datenbanken erhöht werden. Je nach den gespeicherten Daten müssen die Server/Datenbanken entweder dupliziert und synchronisiert werden, oder es muss eine Art Hashing-Algorithmus verwendet werden, um die Daten auf mehrere Server aufzuteilen. Mit zunehmender Anzahl synchronisierter Datenquellen steigen auch die Kosten für die Replikation/Synchronisation dieser Server. Aus diesem Grund ist der Hash-Ansatz zur Kostenminimierung möglicherweise attraktiver.

Echte Hochverfügbarkeitslösungen sind in der Implementierung sehr teuer. Ich habe auch schon verschiedene Grade von HA gesehen, aber per Definition bedeutet es absolut minimale oder keine Ausfallzeiten oder Verlust des Zugriffs auf die Datenquelle. Um dies zu erreichen, sind eine Menge redundanter Hardware, Netzwerke und Software erforderlich, die in der Lage ist, redundante Hardware zu nutzen, ohne die Möglichkeit zu verlieren, auf die Daten zuzugreifen, wenn eine der Datenquellen ausfällt. Hardwareausfälle sind unvermeidlich, ebenso wie Stromausfälle und andere zufällige Naturereignisse. Je nachdem, wie kritisch diese Daten sind, erfordert eine HA-Lösung auch mehrere Rechenzentren an mehreren unabhängigen Stromnetzen. Das wird natürlich très Es hängt also alles davon ab, wie wichtig diese Daten für den Endnutzer sind.

HA ist also ein extremes Szenario, das eine teure Architektur erfordert. Ich stelle fest, dass die meisten Leute nur daran interessiert sind, die Ausfallzeiten zu minimieren, und je nach Größe der Datenquelle kann dies relativ kostengünstig durch das Hinzufügen von Hot-Spares der Datenquellen erreicht werden.

Answer 3

1. Die horizontale Skalierung einer nachrichtengesteuerten Anwendung ist einfach... die meiste Zeit. Sie können sicherlich einen weiteren Message Listener hinzufügen, der auf dieselbe Warteschlange zugreift. Aber Vorsicht, denn Sie könnten subtile Abhängigkeiten von der Reihenfolge der Nachrichten haben. Mit nur einem Prozessor ist das vielleicht noch kein Problem, aber bei mehr als einem Prozessor werden die Nachrichten garantiert irgendwann "außer der Reihe" verarbeitet.
2. EJB MDPs bieten nichts, was über Spring MDBs hinausgeht. Bleiben Sie bei dem, was funktioniert.
3. Die horizontale Skalierung der Prozessoren ist ein erster Schritt, der jedoch etwas mehr Diskussionsbedarf erfordert.

Für HA müssen Sie die Anforderungen klären. "Hochverfügbarkeit" ist eine interessante Frage für eine Warteschlangen-basierte Anwendung. Wenn Ihre Anwendung für ein paar Minuten ausfällt, stapeln sich die Nachrichten in der Warteschlange. Solange Sie Ihre Anwendung wieder zum Laufen bringen können, werden diese Nachrichten immer noch verarbeitet, nur mit etwas mehr Latenzzeit. Es lohnt sich wahrscheinlich zu fragen: "Was ist die maximal akzeptable Latenzzeit für eine Nachricht?"

Wahrscheinlich besteht eine gewisse Besorgnis über Hardwareausfälle, den Verlust eines Rechenzentrums usw. Diese werden durch eine horizontale Skalierung am gleichen Standort nicht behoben. Sie müssen alle Komponenten auf jeder Ebene replizieren: die Warteschlange selbst, die Prozessoren, die Backend-Datenbank und die gesamte Netzwerkhardware, die sie verbindet.

Es ist ein teures Unterfangen, daher lohnt es sich auch zu fragen: "Wie groß ist das Delta in der jährlichen Verlusterwartung bei Ausfallzeiten zwischen einem HA-Szenario und einem Nicht-HA-Szenario?" ALE umfasst sowohl direkte Verluste als auch regulatorische oder rechtliche Kosten und ist somit eine gute Möglichkeit, die Kosten von Ausfallzeiten zu erfassen.

Answer 4

Ist "Standalone" == "Desktop"?

Wie interagieren die Benutzer mit dem Controller, dem die nachrichtengesteuerten Beans gehören?

Meine Meinung zu Ihren Fragen:

1. Sie können den Listener-Pool durch Hinzufügen weiterer Message-Listener skalieren, da jeder von ihnen in seinem eigenen Thread läuft. Sie sollten die Größe des Datenbankverbindungspools an die Größe der Meldungshörer anpassen, so dass auch diese erhöht werden muss. Tun Sie das, bevor Sie weitere Server hinzufügen. Stellen Sie sicher, dass Sie genügend RAM zur Verfügung haben.
2. Ich weiß nicht, was EJB MDB Ihnen gegenüber Spring MDB bringt. Sie sprechen immer wieder von "App-Servern". Meinen Sie speziell Java EE-App-Server wie WebLogic, WebSphere, JBOSS, Glassfish? Denn wenn Sie Spring auf Tomcat einsetzen, würde ich Tomcat als den "Anwendungsserver" in dieser Diskussion betrachten.
3. HA bedeutet Lastausgleich und Ausfallsicherung. Sie müssen über Datenbanken verfügen, die entweder synchronisiert oder im laufenden Betrieb umverteilt werden können. Dasselbe gilt für Warteschlangen. F5 ist eine großartige Hardwarelösung für den Lastausgleich. Ich würde mit Ihren Infrastruktur-Leuten sprechen, wenn Sie welche haben.

Answer 5

.1. Durch das Anlegen weiterer Zuhörer in der Warteschlange kann die Anzahl der Verbraucher skaliert werden. Wenn ein Verbraucher stirbt, können die verbleibenden Verbraucher weiterlaufen. Hinweis: Ihr MQ und Ihre Datenbank müssen ebenfalls über Hochverfügbarkeitslösungen verfügen.

.2. Ich bin mir nicht sicher, welchen Unterschied ein Anwendungsserver in Ihrem Fall machen würde. Vielleicht könnten Sie erläutern, welche Funktionen Sie zu nutzen beabsichtigen?

.3. Siehe meine Antwort zu 1. für HA.