Apache Camel con ActiveMQ agrupación

Question

Estoy tratando de determinar mis opciones para agrupar mi ServiceMix 3.3.1 / Camel 2.1 / 5.3 AMQ aplicación. Estoy realizando el procesamiento de mensajes de gran volumen y necesito a agruparse para 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 ") .TO ( "activemq: inboundQueue");

de ( "activemq:? InboundQueue maxConcurrentConsumers = 50") .Proceso (decode ()) .Proceso (de transformación ()) .Proceso (validar ()) .Proceso (SaveToDatabase ()) .para ( "activemq: Tema: ouboundTopic");

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

Sé que puedo utilizar un Maestro / Esclavo configuración de HA, pero eso no ayuda con la escalabilidad.

He leído sobre la red de corredores, pero no estoy seguro de cómo se aplica esto. Por ejemplo, si puedo implementar rutas Camel idénticos en múltiples nodos en un cluster, ¿cómo van a "interactuar" exactamente? Si señalo mi productor HTTP en un nodo (NodoA), que mensajes serán enviados al nodo B? ¿Las colas / temas sean compartidos entre el nodo A / B ... si es así cómo, se dividen o mensajes duplicados? Además, ¿cómo sería un cliente externo suscribirse a mi "outboundTopic" exactamente (y recibir todos los mensajes, etc)?

Por otra parte, he estado pensando que yo debería compartir un corredor entre varias instancias ServiceMix. Eso sería más limpia en la que sólo habría un conjunto de colas / temas para gestionar y pude escalar añadiendo más instancias. Sin embargo, ahora estoy limitado a la escalabilidad de un solo agente y estoy de vuelta a un solo punto de fallo ...

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

Answer 1

Hay varias estrategias para avanzar cuando se está utilizando la ServiceMix / Camel / ActiveMQ. Debido a que cada pieza de software ofrece tantas opciones, hay una variedad de caminos que se pueden tomar, dependiendo de qué parte de la aplicación de las necesidades a escala. 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 enviar todas las solicitudes a la misma cola de entrada en ActiveMQ.

• Aumentar el número de casos ActiveMQ - Por puesta en marcha de instancias adicionales ActiveMQ y trabajo en red entre sí, se está creando una red de corredores. En algunos círculos esto se refiere a esto como colas distribuidas porque una cola dada puede estar disponible en todos los corredores en la red. Pero si usted va a poner en marcha varias instancias de ActiveMQ, sólo debe considerar a partir de las instancias adicionales de ServiceMix.

• Aumentar el número de instancias ServiceMix - Cada instancia de ServiceMix incrusta una instancia de ActiveMQ. Al aumentar el número de casos de ServiceMix, no sólo está aumentando el número de casos ActiveMQ (que se puede conectar en red entre sí para formar una red de corredores), pero a continuación, tiene la capacidad de desplegar más copias de su aplicación a través de estas instancias de ServiceMix . Si es necesario aumentar el número de ActiveMQ o instancias ServiceMix, entonces se puede desplegar una aplicación que se consume con la cantidad apropiada de los consumidores simultáneos para cada instancia. Los mensajes no consiguen dividir o duplicado, que se distribuyen en turnos rotativos para todos los consumidores en la cola, no importa dónde se encuentren, en base a la demanda del consumidor. Es decir, si la instancia uno ActiveMQ en la red no tiene los consumidores, no va a tener ningún mensaje en su instancia de la cola para ser consumido. Esto lleva a mi última sugerencia, lo que aumenta el número de consumidores de votación de la cola de entrada.

• Aumentar 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 para aumentar el rendimiento. Es el más fácil, porque va a implementar instancias adicionales de su aplicación que se consume para que compitan por los mensajes de la cola de entrada (no importa si están compitiendo por una cola local o una cola que se distribuye a través de una red de corredores). Esto puede ser tan simple como aumentar el número de consumidores simultáneos o un poco más implicado dividiendo aparte la parte de la aplicación que contiene los consumidores y su despliegue para muchos casos de ServiceMix. Es el más poderoso, porque no es generalmente difícil y escalar aplicaciones accionadas por eventos siempre se realiza mediante el aumento del número de consumidores. Es el más manejable porque tiene la capacidad de cambiar la forma en que sus aplicaciones se empaquetan de manera que la aplicación que se consume es totalmente independiente que tiene la habilidad para ser distribuidos.

Esta última sugerencia es la forma más poderosa para escalar su aplicación. Mientras el extremo HTTP entrante puede manejar una gran cantidad de tráfico, es posible que sólo tenga que aumentar los consumidores en la cola de entrada. La gran razón para hacer esto es que los consumidores o el grano a los que se entregan fuera está haciendo todo el trabajo pesado, la mayor cantidad de procesamiento y validación. Normalmente, es este proceso que en última instancia necesita más recursos.

Esperamos que esto proporciona la información que necesita para comenzar a ir en una dirección, o, posiblemente, unos pocos, dependiendo de qué parte de la aplicación que realmente se necesita para escalar. Si tiene alguna pregunta, por favor hágamelo saber.

Bruce