Skalierbarkeit und hohe Verfügbarkeit einer Java-Standalone-Anwendung

StackOverflow https://stackoverflow.com/questions/561188

Frage

Wir laufen derzeit eine Java-Integration-Anwendung auf einer Linux-Box. Zunächst wird ein Überblick über die Anwendung.

Die Java-Anwendung ist eine eigenständige Anwendung (nicht im Einsatz auf jedem Java EE-Anwendungsserver wie Oracle Application Server, WebLogic, JBOSS usw.). Mit dem Stand Alone ich meine es ist nicht eine Desktop-Anwendung. Allerdings ist es von der Kommandozeile aus einer Hauptklasse ausgeführt. Der Benutzer nicht direkt auf alle mit dieser Anwendung interagieren. Die Nachrichten werden in die Warteschlange abgeladen eine API verwendet, die dann durch meine Anwendung ausgelesen werden, die ständig 24/7 läuft. Ich würde dies als eine Desktop-Anwendung nicht in Frage kommen, da der Benutzer mit ihm keine direkten Interaktion hat. (Nicht sicher, ob dies die richtige Argumentation ist, als ein zu qualifizieren).

Es nutzt Frühling und verbindet sich mit WebSphere MQ und Oracle Database Wir verwenden einen Frühling Listener (Frühling Message Driven POJOs), die auf WebSphere MQ zu einer Warteschlange wartet. Sobald es eine Nachricht in der Warteschlange ist, die Anwendung die Nachricht aus dem MQ lesen und Dumps (insert / update) in die Datenbank.

Nun ist die Frage:

  1. Wie können wir horizontal diese Anwendung skalieren? Ich meine nur mehr Boxen setzen und mehrere Instanzen derselben Anwendung ausgeführt wird, ist, dass ein gangbarer Weg?
  2. Sollte man bedenkt, von Spring MDP bewegen MEB EJB? Bereitstellung es dabei auf dem Anwendungsserver. Gibt es einen zusätzlichen Vorteil von so tun?
  3. Es ist eine Anforderung der Anwendung High Available (HA) zu machen? Was sind die vorgeschlagenen Methoden oder Strategien, die dazu eingesetzt werden können, um eine eigenständige Anwendung HA zu machen?
War es hilfreich?

Lösung

Ist "standalone" == "Desktop"?

Wie interagieren Benutzer mit dem Controller, der die Message-Driven Beans besitzt?

Meine Meinung auf Ihre Fragen:

  1. Sie können skalieren, indem mehrere Nachrichten Zuhörer zum Hörer Pool hinzufügen, da jeder in einem eigenen Thread ausgeführt wird. Sie sollten die Größe der Datenbankverbindung Pool Nachricht Hörer entsprechen, so dass würde auch erhöhen haben. Tun Sie das, bevor weitere Server hinzugefügt werden. Stellen Sie sicher, dass Sie genug RAM zur Hand haben.
  2. Ich sehe nicht, was EJB MDB Sie über Frühling MDB kauft. Sie halten die sich auf „App-Server“. Wollen Sie damit sagen App Java EE speziell Servern wie WebLogic, WebSphere, JBOSS, Glassfish? Denn wenn Sie den Einsatz Frühling auf Tomcat würde ich prüfen, Tomcat der „App-Server“ in diesem Gespräch sein.
  3. HA bedeutet, Load Balancing und Failover. Sie müssen Datenbanken haben, die entweder synchronisiert oder heiße redeployable werden. Das Gleiche gilt für Warteschlangen. F5 ist eine große Hardware-Lösung für den Lastenausgleich. Ich würde an Ihrer Infrastruktur Leute sprechen, wenn Sie einige haben.

Andere Tipps

Eine weitere Option ist Terracotta , ein Framework, das genau das tut, was Sie wollen ; läuft Ihre Anwendung auf mehreren Maschinen gleichzeitig und die Last unter ihnen balanciert.

Horizontale Skalierung für jede Anwendung wird schließlich in Grenzen, da die Nachfrage für die Daten erhöht laufen. Diese Grenzen werden durch Belastung und Server / Datenbankleistung bestimmt. An einem gewissen Punkt, wenn die Nachfrage und Lasterhöhung mit Skalierung, die Anzahl der Server / Datenbanken haben auch zu erhöhen. In Abhängigkeit von den Daten, die gespeichert werden, die Server / Datenbanken müssen entweder dupliziert werden und synchronisiert werden, oder irgendeine Art von Algorithmus-Hashing müssen eingesetzt werden, um Daten auf mehrere Server zu verteilen. Wie Sie erhöhen die Anzahl der synchronisierten Datenquellen, die Kosten für die Replikation / Synchronisation als auch die Server erhöht. Deshalb ist der gehasht Ansatz attraktiver sein kann, um Kosten zu minimieren.

True High Availability-Lösungen sind sehr teuer zu implementieren. Ich habe auch verschiedene Grade von HA gesehen, aber per Definition bedeutet es absolut minimale oder gar keine Ausfallzeiten oder den Zugriff auf die Datenquelle verlieren. Um dies zu erreichen viel redundante Hardware erfordert, Netzwerk- und Software in der Lage ist, redundante Hardware zu nutzen, ohne die Fähigkeit zu verlieren, um die Daten zu erhalten, wenn eine der Datenquellen ausfällt. Hardwarefehler ist unvermeidlich, es wird passieren, sowie Stromausfälle und andere zufällige Handlungen der Natur. Je nachdem, wie kritisch diese Daten sind eine HA-Lösung wird auch mehrere Rechenzentren auf mehreren unabhängigen Stromnetzen erfordern. Welche sein wird zu offensichtlich sehr teuer, so dass es hängt alles davon ab, wie wichtig diese Daten an den Endbenutzer.

So, HA ist ein extremes Szenario eine teure Architektur erfordern. Ich finde, dass die meisten der Zeit, die Menschen daran interessiert sind nur Ausfallzeiten zu minimieren und in Abhängigkeit von der Größe der Datenquelle dieses ziemlich kostengünstig erreicht werden kann Heißersatzteile der Datenquellen mit dem Hinzufügen.

  1. Horizontale Skalierung eine Nachricht angetrieben App ist einfach ... die meiste Zeit. Sie können natürlich auch eine andere Nachricht Hörer hinzufügen auf der gleichen Warteschlange arbeitet. Aber Vorsicht, da Sie subtile Abhängigkeiten von der Reihenfolge der Nachrichten haben könnten. Sie könnten kein Problem jetzt sein, mit nur einem Prozessor, aber mit mehr als einer sind Sie garantiert, dass die Nachrichten verarbeitet „out of order“ irgendwann werden.
  2. EJB MDP bieten nichts über Frühling MEB. Mit dem, was funktioniert.
  3. Horizontal die Prozessor Skalierung ist ein Anfang, aber dies erfordert ein wenig mehr Diskussion.

Für HA, müssen Sie die Anforderungen klären. „Hohe Verfügbarkeit“ ist eine interessante Frage für eine Warteschlange-basierte Anwendung. Wenn Ihre App für einige Minuten untergeht, Nachrichten stapeln sich in der Warteschlange. Solange Sie Ihre App wieder zum Laufen zu bekommen, werden diese Nachrichten noch bearbeitet bekommen, nur mit einem bisschen mehr Latenz. Es ist wahrscheinlich lohnt sich zu fragen: „Was ist die maximal zulässige Latenz für eine Nachricht ist?“

Es gibt wahrscheinlich einige Komponenten der Besorgnis über Hardwareausfälle, Verlust von einem Rechenzentrum, usw. Diese werden nicht durch horizontale Skalierung an der gleichen Stelle zu richten. Sie werden alle Komponenten auf jeder Ebene replizieren müssen. Die Warteschlange selbst, die Prozessoren, die Back-End-Datenbank und alle Netzwerk-Hardware die sie verbinden

Es ist eine teuere Angelegenheit, so ist es auch wert ist, zu fragen: „Was ist das Delta der annualisierten Verlust Erwartung von Ausfallzeiten zwischen einem HA-Szenario ist und ein Nicht-HA-Szenario?“ ALE umfasst sowohl direkte Verluste und regulatorischen oder rechtlich Kosten, so ist es eine gute Möglichkeit, die Kosten für Ausfallzeiten zu erfassen.

0,1. mehr Hörer in der Warteschlange Erstellen kann die Anzahl der Verbraucher skalieren. Als Verbraucher stirbt, können die übrigen Verbraucher am Laufen halten. . Hinweis: Ihre MQ und Datenbank müssen auch Lösungen mit hohen Verfügbarkeit haben

0,2. Nicht sicher, was für einen Unterschied ein Anwendungsserver in Ihrem Fall machen würde. Vielleicht könnten Sie erklären, welche Funktionen Sie verwenden möchten?

0,3. Siehe meine Antwort auf 1 für HA.

Versuchen Sie mehrere Boxen zu machen? Ich glaube, Sie können das Dokument Ihrer MQ sehen? mehrere Boxen laufen kann einige Configuartion in Ihrem MQ müssen, aber es wird ISA ausführen

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top