Scalabilità ed elevata disponibilità di un'applicazione Java standalone

Question

Attualmente stiamo eseguendo un'applicazione di integrazione Java su una macchina Linux.Innanzitutto una panoramica dell'applicazione.

L'applicazione Java è un'applicazione autonoma (non distribuita su alcun server di applicazioni Java EE come OracleAS, WebLogic, JBOSS ecc.).Per Stand Alone intendo NON un'applicazione DESKTOP.Tuttavia viene eseguito dalla riga di comando da una classe Main.L'utente non interagisce affatto direttamente con questa applicazione.I messaggi vengono inseriti nella coda utilizzando un'API che viene poi letta dalla mia applicazione che è costantemente in esecuzione 24 ore su 24, 7 giorni su 7.Non la qualificherei come app desktop poiché l'utente non ha alcuna interazione diretta con essa (non sono sicuro che questo sia il ragionamento corretto per qualificarsi come tale).

Utilizza Spring e si collega al database WebSphere MQ e Oracle Usiamo un ascoltatore Spring (POJOS guidato da Spring Messages) che ascolta una coda su WebSphere MQ.Una volta che c'è un messaggio in coda, l'applicazione legge il messaggio da MQ e lo scarica (inserisce/aggiorna) nel database.

Ora la domanda è:

1. Come possiamo scalare orizzontalmente questa applicazione?Voglio dire semplicemente mettere più scatole ed eseguire più istanze della stessa applicazione, è un approccio praticabile?
2. Dovremmo considerare il passaggio dagli MDP Spring agli MDB EJB?Distribuendolo quindi sul server delle applicazioni.C'è qualche vantaggio aggiuntivo nel farlo?
3. C'è una richiesta per rendere l'applicazione High Available(HA)?Quali sono le metodologie o strategie suggerite che possono essere messe in atto per realizzare un'applicazione autonoma HA?

Answer 1

Lo "stand-alone" == "desktop"?

Come fanno gli utenti interagiscono con il controller che possiede i bean basati sui messaggi?

Le mie opinioni sulle tue domande:

1. È possibile scalare con l'aggiunta di più ascoltatori di messaggi al pool di chi ascolta, dal momento che ciascuno di essi viene eseguito nel proprio thread. Si dovrebbe corrispondere alla dimensione del pool di connessione al database di ascoltatori di messaggi, in modo che avrebbe dovuto aumentare pure. Non che prima di aggiungere più server. Assicurarsi di avere abbastanza RAM a portata di mano.
2. Non vedo che cosa EJB MDB si acquista oltre lo Spring MDB. Continui riferimento a "app server". Vuoi dire specificamente app server Java EE come WebLogic, WebSphere, JBoss, Glassfish? Perché se si sta distribuendo primavera su Tomcat mi piacerebbe prendere in considerazione Tomcat di essere il "application server" in questa conversazione.
3. HA significa load balancing e failover. Avrete bisogno di avere banche dati che sono o sincronizzati o caldo ridistribuibili. Stessa cosa con le code. F5 è una grande soluzione hardware per il bilanciamento del carico. Mi piacerebbe parlare con i tuoi genitori di infrastrutture, se avete qualche.

Answer 2

Un'altra opzione è Terracotta , un quadro che fa esattamente ciò che si vuole ; in esecuzione la vostra applicazione su più macchine contemporaneamente e bilanciare il carico tra loro.

Answer 3

La scalabilità orizzontale per qualsiasi applicazione finirà per incontrare dei limiti man mano che la domanda di dati aumenta.Tali limiti sono determinati dal carico e dalle prestazioni del server/database.Ad un certo punto, se la domanda e il carico aumentano con il ridimensionamento, anche il numero di server/database dovrà aumentare.A seconda dei dati archiviati, i server/database dovranno essere duplicati e sincronizzati oppure sarà necessario utilizzare una sorta di algoritmo di hashing per suddividere i dati su più server.Aumentando il numero di origini dati sincronizzate, aumenta anche il costo di replica/sincronizzazione di tali server.Questo è il motivo per cui l’approccio hash potrebbe essere più interessante per ridurre al minimo i costi.

Le vere soluzioni ad alta disponibilità sono molto costose da implementare.Ho visto anche vari gradi di HA, ma per definizione significa tempi di inattività assolutamente minimi o assenti o perdita di accesso all'origine dati.Per raggiungere questo obiettivo è necessario molto hardware, rete e software ridondanti in grado di utilizzare hardware ridondante senza perdere la capacità di accedere ai dati quando una delle origini dati si guasta.Il guasto dell'hardware è inevitabile e accadrà, così come le interruzioni di corrente e altri atti naturali casuali.A seconda della criticità di questi dati, una soluzione HA richiederà anche più data center su più reti elettriche indipendenti.E questo ovviamente accadrà molto costosi, quindi tutto dipende da quanto siano critici questi dati per l'utente finale.

Pertanto, l'alta disponibilità è uno scenario estremo che richiede un'architettura costosa.Trovo che la maggior parte delle volte le persone siano interessate semplicemente a ridurre al minimo i tempi di inattività e, a seconda delle dimensioni dell'origine dati, ciò può essere ottenuto in modo abbastanza economico aggiungendo hot-spare delle origini dati.

Answer 4

1. ridimensionamento orizzontale un messaggio guidato applicazione è facile ... la maggior parte del tempo. Si può certamente aggiungere un altro messaggio ascoltatore che operano sulla stessa coda. Attenzione, però, perché si potrebbe avere dipendenze sottili sul ordinamento dei messaggi. Potrebbero non essere un problema ora, con un solo processore, ma con più di quello che si ha la garanzia che i messaggi verranno trattati "fuori servizio" a un certo punto.
2. EJB MDP non offre nulla al di là di primavera MDB. Bastone con ciò che funziona.
3. orizzontalmente scalare i processori è un inizio, ma questo richiede un po 'più di discussione.

Per HA, è necessario chiarire i requisiti. "L'alta disponibilità" è una domanda interessante per un'applicazione basata su coda. Se la vostra applicazione va giù per qualche minuto, i messaggi si accumulano nella coda. Finché è possibile ottenere la vostra applicazione sostegno e funzionamento, quei messaggi saranno ancora vengono elaborati, solo con un po 'più di latenza. E 'probabilmente la pena di chiedere: "Qual è la latenza massimo accettabile per un messaggio?"

C'è probabilmente qualche componente di preoccupazione per guasti hardware, la perdita di un data center, ecc Questi non saranno affrontate dal ridimensionamento orizzontale nella stessa posizione. Avrete bisogno di replicare tutti i componenti ad ogni livello:. Coda stessa, i processori, il database back-end, e tutto l'hardware di rete che li collega

E 'un pò costosa, quindi è anche la pena di chiedere, "Qual è il delta in previsione di perdita annua di tempi morti tra uno scenario HA e uno scenario di non-HA?" ALE comprende sia i danni diretti e costi normativi o legali, quindi è un buon modo per catturare il costo dei tempi di inattività.

Answer 5

0,1. La creazione di più ascoltatori sulla coda può scalare il numero di consumatori. Come consumatore muore, gli altri consumatori possono continuare a correre. Nota:. Il tuo MQ e il database necessario disporre di soluzioni di alta disponibilità e

0,2. Non sono sicuro che differenza un server di applicazione renderebbe nel tuo caso. Forse si potrebbe spiegare le funzioni che si intende utilizzare?

0,3. Vedere la mia risposta a 1. per HA.

Answer 6

Hai provato a rendere più caselle? Penso che si può vedere il doc del MQ? l'esecuzione di più scatole potrebbero aver bisogno di configuartion in MQ, ma verrà eseguito ISA