Apache Camel con clúster ActiveMQ

Question

Estoy intentando determinar mis opciones para agrupar mi aplicación ServiceMix 3.3.1/Camel 2.1/AMQ 5.3. Estoy realizando un procesamiento de mensajes de gran volumen y necesito clúster para obtener una alta disponibilidad y escalabilidad horizontal.

Aquí es básicamente lo que hace mi aplicación ... HTTP-> QUEUE-> proceso-> base de datos-> tema

a partir de ("amarre: http://0.0.0.0/inbound ") .para (" activemq: inboundQueue");

a partir de ("activemq:? InboundQueue maxConcurrentConsumers = 50") .Proceso (decode()) .Proceso (transformar()) .Proceso (validar()) .Proceso (SaveToDatabase()) . a ("activemq: topic: ouboundTopic");

lo tanto, he leído todos los ServiceMix y páginas de agrupación AcitveMQ, pero todavía no estoy seguro de qué camino tomar.

Sé que puedo usar una configuración Maestro/Esclavo para HA, pero eso no ayuda con la escalabilidad.

He leído acerca de la red de corredores, pero no estoy seguro de cómo se aplica. Por ejemplo, si despliego rutas Camel idénticas en múltiples nodos en un clúster, ¿cómo "interactuarán" exactamente? Si señalo mi productor HTTP en un nodo (NodeA), ¿qué mensajes se enviarán a NodeB? ¿Se compartirán las colas/temas entre el Nodo A/B ... en caso afirmativo, cómo se dividen o duplican los mensajes? Además, ¿cómo se suscribiría un cliente externo a mi "outboundTopic" exactamente (y obtendría todos los mensajes, etc.)?

O bien, he estado pensando que debería compartir un intermediario entre varias instancias de ServiceMix. Eso sería más claro en el sentido de que solo habría un conjunto de colas/temas para gestionar y podría escalar agregando más instancias. Pero, ahora estoy limitado a la escalabilidad de un solo corredor y estoy de vuelta en un solo punto de falla ...

Si alguien puede aclarar las concesiones para mí ... lo agradecería .

Answer 1

Existen múltiples estrategias para ampliar cuando usa ServiceMix/Camel/ActiveMQ. Debido a que cada pieza de software ofrece tantas opciones, hay una variedad de caminos que puede tomar dependiendo de qué parte de la aplicación necesita escalar. A continuación se muestra una lista de alto nivel de algunas estrategias:

• aumentar el número de casos Jetty entrantes - Para ello es necesario iniciar más instancias del servidor web y cualquiera de las solicitudes de equilibrio de carga a través de las múltiples instancias o exponer varias direcciones URL y el envío todas las solicitudes a la misma cola de entrada en ActiveMQ.

• Aumente el número de instancias de ActiveMQ: al iniciar instancias adicionales de ActiveMQ y al establecer una red en conjunto, está creando una red de intermediarios. En algunos círculos, esto se denomina colas distribuidas porque una cola determinada puede estar disponible en todos los intermediarios de la red. Pero si va a iniciar varias instancias de ActiveMQ, debería considerar la posibilidad de iniciar instancias adicionales de ServiceMix.

• Aumentar el número de instancias ServiceMix - Cada instancia de ServiceMix incrusta una instancia de ActiveMQ. Al aumentar la cantidad de instancias de ServiceMix, no solo aumenta la cantidad de instancias de ActiveMQ (que pueden conectarse en red para formar una red de intermediarios), sino que también tiene la capacidad de implementar más copias de su aplicación en estas instancias de ServiceMix. .Si necesita aumentar el número de instancias de ActiveMQ o ServiceMix, puede implementar una aplicación de consumo con la cantidad apropiada de consumidores simultáneos para cada instancia. Los mensajes no se dividen ni se duplican, sino que se distribuyen de forma rutinaria a todos los consumidores en la cola, sin importar dónde se encuentren, en función de la demanda del consumidor. Es decir, si una instancia de ActiveMQ en la red no tiene consumidores, no tendrá ningún mensaje en su instancia de la cola para ser consumida. Esto lleva a mi última sugerencia, aumentando la cantidad de consumidores que consultan la cola de entrada.

• Aumente el número de consumidores JMS en la cola de entrada: esta es probablemente la forma más fácil, más potente y más manejable de aumentar el rendimiento. Es el más fácil porque está implementando instancias adicionales de su aplicación de consumo para que compitan por los mensajes de la cola de entrada (sin importar si están compitiendo por una cola local o una cola que se distribuye a través de una red de intermediarios). Esto puede ser tan simple como aumentar el número de consumidores simultáneos o un poco más complicado dividiendo la parte de la aplicación que contiene los consumidores y desplegándola en muchas instancias de ServiceMix. Es el más poderoso porque no suele ser difícil y las aplicaciones basadas en eventos de escalado siempre se hacen aumentando el número de consumidores. Es la más manejable porque tiene la capacidad de cambiar la forma en que se empaquetan sus aplicaciones para que la aplicación consumidora esté completamente separada, lo que le da la posibilidad de ser distribuida.

Esta última sugerencia es la forma más eficaz de escalar su aplicación. Siempre que el punto final HTTP entrante pueda manejar una gran cantidad de tráfico, es posible que solo necesite aumentar los consumidores en la cola de entrada. La razón principal para hacer esto es que los consumidores o el frijol al que envían están haciendo todo el trabajo pesado, la mayor cantidad de procesamiento y validación. Normalmente, este proceso es el que necesita más recursos.

Esperemos que esto proporcione la información que necesita para comenzar a ir en una dirección, o posiblemente unas pocas, dependiendo de qué parte de su aplicación realmente necesita escalar. Si tiene alguna pregunta, por favor hágamelo saber.

Bruce