Apache Camel avec le clustering ActiveMQ

Question

J'essaye de déterminer mes options pour grouper mon application ServiceMix 3.3.1/Camel 2.1/AMQ 5.3. J'effectue un traitement des messages à volume élevé et j'ai besoin de cluster pour une haute disponibilité et une évolutivité horizontale.

Voici essentiellement ce que fait ma demande ... de type HTTP> sur file d'attente> DES PROCEDES> Database-> SUJET

de ("jetée: http://0.0.0.0/inbound ") .à (" ActiveMQ: inboundQueue");

de ("ActiveMQ: inboundQueue maxConcurrentConsumers = 50") poids.Procédé (decode()) poids.Procédé (transform()) poids.Procédé (valider()) poids.Procédé (SaveToDatabase()) . à ("activemq: topic: ouboundTopic");

Alors, je l'ai lu toutes les pages de regroupement ServiceMix et AcitveMQ, mais je ne suis toujours pas sûr de chemin à parcourir.

Je sais que je peux utiliser une configuration maître/esclave pour HA, mais cela ne suffit pas avec l'évolutivité. J'ai lu sur le réseau de courtiers, mais je ne suis pas sûr de savoir comment cela s'applique. Par exemple, si je déploie des routes Camel identiques sur plusieurs nœuds d'un cluster, comment vont-ils interagir exactement? Si je pointe mon producteur HTTP sur un nœud (NodeA), quels messages seront envoyés à NodeB? Les files d'attente/sujets seront-ils partagés entre les nœuds A/B ... si oui, comment les messages sont-ils partagés ou dupliqués? De même, comment un client externe peut-il s'abonner à mon "outboundTopic" exactement (et recevoir tous les messages, etc.)?

Sinon, j'ai pensé que je devrais partager un courtier entre plusieurs instances de ServiceMix. Ce serait plus propre, car il n'y aurait qu'un seul ensemble de files d'attente/sujets à gérer et je pourrais redimensionner en ajoutant plus d'instances. Mais, maintenant je suis limité à l'évolutivité d'un courtier unique et je suis de retour à un seul point de défaillance ...

Si quelqu'un peut clarifier les compromis pour moi ... J'apprécierais .

Answer 1

Il existe plusieurs stratégies pour augmenter l'échelle lorsque vous utilisez ServiceMix/Camel/ActiveMQ. Étant donné que chaque logiciel offre autant d'options, il existe une variété de chemins que vous pouvez suivre en fonction de la partie de l'application qui doit évoluer. Voici une liste de haut niveau de quelques stratégies:

• Augmenter le nombre d'instances de Jetty entrants - Cela nécessite de commencer plusieurs instances du serveur Web et soit des requêtes d'équilibrage de charge entre les multiples instances ou d'exposer plusieurs URL et envoyer toutes les demandes à la même file d'attente entrante dans ActiveMQ. Augmenter le nombre d'instances ActiveMQ - En démarrant des instances ActiveMQ supplémentaires et en les mettant en réseau, vous créez un réseau de courtiers. Dans certains cercles, il s'agit de files d'attente distribuées car une file d'attente donnée peut être mise à disposition de tous les courtiers du réseau. Mais si vous voulez démarrer plusieurs instances d'ActiveMQ, vous devriez simplement envisager de démarrer des instances supplémentaires de ServiceMix.

• Augmenter le nombre d'instances ServiceMix - Chaque instance de ServiceMix intègre une instance de ActiveMQ. En augmentant le nombre d'instances de ServiceMix, non seulement vous augmentez le nombre d'instances ActiveMQ (qui peuvent être mises en réseau pour former un réseau de courtiers), mais vous avez également la possibilité de déployer plus de copies de votre application sur ces instances de ServiceMix .Si vous devez augmenter le nombre d'instances ActiveMQ ou ServiceMix, vous pouvez déployer une application consommatrice avec le nombre approprié de consommateurs simultanés pour chaque instance. Les messages ne sont ni divisés ni dupliqués, ils sont distribués à tous les consommateurs dans la file d'attente, peu importe où ils se trouvent, en fonction de la demande des consommateurs. C'est-à-dire que si une instance ActiveMQ du réseau n'a pas de consommateurs, elle n'aura aucun message sur l'instance de la file à consommer. Cela conduit à ma dernière suggestion, augmentant le nombre de consommateurs interrogeant la file d'attente entrante. Augmenter le nombre de consommateurs JMS dans la file d'attente entrante - C'est probablement le moyen le plus simple, le plus puissant et le plus facile d'augmenter le débit. C'est le plus simple car vous déployez des instances supplémentaires de votre application consommatrice afin qu'elles soient en concurrence pour les messages de la file d'attente entrante (peu importe si elles sont en concurrence pour une file locale ou une file distribuée via un réseau de courtiers). Cela peut être aussi simple que d'augmenter le nombre de consommateurs simultanés ou un peu plus impliqué en séparant la partie de l'application qui contient les consommateurs et en la déployant sur plusieurs instances de ServiceMix. C'est le plus puissant car ce n'est généralement pas difficile et les applications pilotées par les événements sont toujours réalisées en augmentant le nombre de consommateurs. C'est le plus gérable parce que vous avez la possibilité de changer la façon dont vos applications sont empaquetées de sorte que l'application consommatrice soit complètement séparée, ce qui lui donne la possibilité d'être distribuée.

Cette dernière suggestion est le moyen le plus puissant à l'échelle de votre application. Tant que le point de terminaison HTTP entrant peut gérer une grande quantité de trafic, il se peut que vous n'ayez besoin que d'augmenter le nombre de consommateurs dans la file d'attente entrante. La principale raison de faire cela est que les consommateurs ou le haricot à qui ils remettent font le gros du travail, la majeure partie du traitement et de la validation. Généralement, c'est ce processus qui nécessite le plus de ressources.

Espérons que cela fournit les informations dont vous avez besoin pour commencer à aller dans un sens, ou peut-être quelques-uns, selon la partie de votre application que vous avez réellement besoin de mettre à l'échelle. Si vous avez des questions, s'il vous plaît faites le moi savoir.

Bruce