Apache Camel con cluster ActiveMQ

Question

Sto cercando di determinare le opzioni per il clustering dell'applicazione ServiceMix 3.3.1/Camel 2.1/AMQ 5.3. Sto eseguendo l'elaborazione dei messaggi ad alto volume e ho bisogno di cluster per alta disponibilità e scalabilità orizzontale.

Qui è fondamentalmente ciò che fa la mia domanda ... HTTP> QUEUE-> processo-> Database-> TOPIC

da ("pontile: http://0.0.0.0/inbound ") .to (" activemq: inboundQueue");

da ("activemq:? InboundQueue maxConcurrentConsumers = 50") .process (decode()) .process (transform()) .process (validate()) .process (SaveToDatabase()) . a ("ActiveMQ: argomento: ouboundTopic");

Quindi, ho letto tutte le pagine di clustering ServiceMix e AcitveMQ, ma non sono ancora sicuro su quale direzione andare.

So che posso utilizzare un'impostazione Master/Slave per HA, ma questo non aiuta con la scalabilità.

Ho letto sulla rete di broker, ma non sono sicuro di come si applica. Ad esempio, se distribuisco percorsi Camel identici su più nodi in un cluster, in che modo "interagiranno" esattamente? Se punto il mio produttore HTTP su un nodo (NodeA), quali messaggi verranno inviati a NodeB? Le code/argomenti saranno condivise tra il nodo A/B ... se sì, come sono i messaggi suddivisi o duplicati? Inoltre, in che modo un client esterno si iscriverebbe al mio "outboundTopic" esattamente (e otterrà tutti i messaggi, ecc.)?

In alternativa, stavo pensando che dovrei solo condividere un broker tra più istanze di ServiceMix. Sarebbe più pulito in quanto ci sarebbe solo una serie di code/argomenti da gestire e potrei scalare aggiungendo più istanze. Ma ora sono limitato alla scalabilità di un singolo broker e torno a un singolo punto di errore ...

Se qualcuno può chiarire i compromessi per me ... Lo apprezzerei .

Answer 1

Ci sono strategie multiple per scalare quando si utilizza ServiceMix/Camel/ActiveMQ. Poiché ogni parte del software offre così tante opzioni, ci sono una varietà di percorsi che puoi intraprendere in base a quale porzione dell'app deve ridimensionare. Di seguito è riportato un elenco alto livello di alcune strategie:

• aumentare il numero di casi Jetty in entrata - Questo richiede di partenza più istanze di server web e sia le richieste di bilanciamento del carico tra i più istanze o di esporre più URL e l'invio tutte le richieste alla stessa coda in entrata in ActiveMQ.

• Aumentare il numero di istanze di ActiveMQ: avviando istanze di ActiveMQ aggiuntive e collegandole in rete, si crea una rete di broker. In alcune cerchie si parla di code distribuite perché una determinata coda può essere resa disponibile su tutti i broker della rete. Ma se hai intenzione di avviare più istanze di ActiveMQ, dovresti semplicemente considerare l'avvio di istanze aggiuntive di ServiceMix.

• Aumentare il numero di istanze di ServiceMix - Ogni istanza di ServiceMix incorpora un'istanza di ActiveMQ. Aumentando il numero di istanze di ServiceMix, non solo si aumenta il numero di istanze di ActiveMQ (che possono essere collegate in rete per formare una rete di broker) ma si ha la possibilità di distribuire più copie della propria applicazione in queste istanze di ServiceMix .Se è necessario aumentare il numero di istanze di ActiveMQ o ServiceMix, è possibile distribuire un'applicazione consumata con la quantità appropriata di utenti concorrenti per ogni istanza. I messaggi non vengono divisi o duplicati, vengono distribuiti in modo round robin a tutti i consumatori in coda, indipendentemente da dove si trovano, in base alla domanda dei consumatori. Ad esempio, se un'istanza di ActiveMQ nella rete non ha utenti, non avrà alcun messaggio sull'istanza della coda da utilizzare. Ciò porta al mio ultimo suggerimento, aumentando il numero di consumatori che interrogano la coda in entrata.

• Aumentare il numero di utenti JMS sulla coda in ingresso. Questo è probabilmente il modo più semplice, più potente e più gestibile per aumentare il throughput. È la soluzione più semplice perché distribuisci istanze aggiuntive dell'applicabile in modo che competano per i messaggi provenienti dalla coda in entrata (indipendentemente dal fatto che siano in competizione per una coda locale o una coda distribuita attraverso una rete di broker). Questo può essere semplice come aumentare il numero di utenti concorrenti o un po 'più coinvolto dividendo la parte dell'applicazione che contiene i consumatori e distribuendola in molte istanze di ServiceMix. È il più potente perché non è solitamente difficile e il ridimensionamento delle applicazioni guidate dagli eventi viene sempre fatto aumentando il numero di consumatori. È il più gestibile in quanto si ha la possibilità di cambiare il modo in cui le applicazioni vengono impacchettate in modo tale che l'applicazione che consuma sia completamente separata, dandole la possibilità di essere distribuita.

Quest'ultimo suggerimento è il modo più efficace per ridimensionare l'applicazione. Finché l'endpoint HTTP in arrivo può gestire una grande quantità di traffico, potrebbe essere solo necessario aumentare i consumatori nella coda in entrata. Il motivo principale per cui ciò avviene è che i consumatori o il bean a cui passano stanno facendo tutto il lavoro pesante, la maggior quantità di elaborazione e convalida. Tipicamente è questo processo che alla fine ha bisogno della maggior parte delle risorse.

Speriamo che questo fornisca le informazioni necessarie per iniziare ad andare in una direzione, o forse a pochi, a seconda di quale parte della tua app hai effettivamente bisogno di ridimensionare. Se avete domande, per favore fatemelo sapere.

Bruce