Apache Camel mit ActiveMQ-Clustering

Question

Ich versuche, meine Optionen für das Clustering meiner ServiceMix 3.3.1/Camel 2.1/AMQ 5.3-Anwendung zu ermitteln.Ich führe eine große Nachrichtenverarbeitung durch und benötige Cluster für hohe Verfügbarkeit und horizontale Skalierbarkeit.

Hier ist im Grunde, was meine Anwendung tut: HTTP->QUEUE->PROCESS->DATABASE->TOPIC

from("Steg:http://0.0.0.0/inbound") .to (" Activemq: InboundQueue ");

von ("activeMQ: InboundQueue? MaxConcurrentConsumers = 50") .Process (decode ()) .Process (Transformation ()) .Process (validate ()) .PROCESS (Savetodatabase ()) .to ("Activemq: Thema: Ouboundtopic" );

Ich habe also alle Clustering-Seiten von ServiceMix und AcitveMQ gelesen, bin mir aber immer noch nicht sicher, welchen Weg ich einschlagen soll.

Ich weiß, dass ich für HA ein Master/Slave-Setup verwenden kann, aber das trägt nicht zur Skalierbarkeit bei.

Ich habe über ein Maklernetzwerk gelesen, bin mir aber nicht sicher, wie das zutrifft.Wenn ich beispielsweise identische Camel-Routen auf mehreren Knoten in einem Cluster bereitstelle, wie „interagieren“ sie dann genau?Welche Nachrichten werden an NodeB gesendet, wenn ich meinen HTTP-Produzenten auf einen Knoten (NodeA) verweise?Werden die Warteschlangen/Themen zwischen Knoten A/B gemeinsam genutzt? Wenn ja, wie werden Nachrichten aufgeteilt oder dupliziert?Und wie würde ein externer Client mein „outboundTopic“ genau abonnieren (und alle Nachrichten usw. erhalten)?

Alternativ habe ich darüber nachgedacht, dass ich einfach einen Broker zwischen mehreren ServiceMix-Instanzen teilen sollte.Das wäre sauberer, da nur ein Satz von Warteschlangen/Themen verwaltet werden müsste und ich durch das Hinzufügen weiterer Instanzen skalieren könnte.Aber jetzt bin ich auf die Skalierbarkeit eines einzelnen Brokers beschränkt und stehe wieder vor einem Single Point of Failure ...

Wenn mir jemand die Kompromisse erklären kann, wäre ich dankbar.

Answer 1

Es gibt mehrere Strategien zur Skalierung, wenn Sie ServiceMix/Camel/ActiveMQ verwenden.Da jede Software so viele Optionen bietet, können Sie unterschiedliche Wege einschlagen, je nachdem, welcher Teil der App skaliert werden muss.Nachfolgend finden Sie eine allgemeine Liste einiger Strategien:

• Erhöhen Sie die Anzahl der eingehenden Jetty-Instanzen – Dies erfordert das Starten weiterer Instanzen des Webservers und entweder die Lastverteilung der Anforderungen auf mehrere Instanzen oder die Offenlegung mehrerer URLs und das Senden aller Anforderungen an dieselbe Eingangswarteschlange in ActiveMQ.

• Erhöhen Sie die Anzahl der ActiveMQ-Instanzen – Indem Sie zusätzliche ActiveMQ-Instanzen starten und diese miteinander vernetzen, erstellen Sie ein Netzwerk von Brokern.In manchen Kreisen wird dies als verteilte Warteschlangen bezeichnet, da eine bestimmte Warteschlange allen Brokern im Netzwerk zur Verfügung gestellt werden kann.Wenn Sie jedoch mehrere Instanzen von ActiveMQ starten möchten, sollten Sie einfach darüber nachdenken, zusätzliche Instanzen von ServiceMix zu starten.

• Erhöhen Sie die Anzahl der ServiceMix-Instanzen – Jede Instanz von ServiceMix bettet eine Instanz von ActiveMQ ein.Indem Sie die Anzahl der Instanzen von ServiceMix erhöhen, erhöhen Sie nicht nur die Anzahl der ActiveMQ-Instanzen (die zu einem Netzwerk von Brokern vernetzt werden können), sondern Sie haben auch die Möglichkeit, mehr Kopien Ihrer Anwendung auf diesen Instanzen von ServiceMix bereitzustellen .Wenn Sie die Anzahl der ActiveMQ- oder ServiceMix-Instanzen erhöhen müssen, können Sie eine verbrauchende Anwendung mit der entsprechenden Anzahl gleichzeitiger Verbraucher für jede Instanz bereitstellen.Nachrichten werden nicht geteilt oder dupliziert, sondern im Round-Robin-Verfahren an alle Verbraucher in der Warteschlange verteilt, unabhängig davon, wo sie sich befinden, je nach Verbrauchernachfrage.Das heißt, wenn eine ActiveMQ-Instanz im Netzwerk keine Verbraucher hat, werden in ihrer Instanz der Warteschlange keine Nachrichten konsumiert.Dies führt zu meinem letzten Vorschlag, die Anzahl der Verbraucher zu erhöhen, die die Eingangswarteschlange abfragen.

• Erhöhen Sie die Anzahl der JMS-Konsumenten in der Eingangswarteschlange – Dies ist wahrscheinlich die einfachste, leistungsfähigste und am besten verwaltbare Möglichkeit, den Durchsatz zu erhöhen.Dies ist am einfachsten, da Sie zusätzliche Instanzen Ihrer verbrauchenden Anwendung bereitstellen, sodass diese um Nachrichten aus der Eingangswarteschlange konkurrieren (unabhängig davon, ob sie um eine lokale Warteschlange oder eine Warteschlange konkurrieren, die über ein Netzwerk von Brokern verteilt wird).Dies kann so einfach sein wie die Erhöhung der Anzahl gleichzeitiger Verbraucher oder etwas komplizierter, indem der Teil der Anwendung, der die Verbraucher enthält, aufgeteilt und auf vielen Instanzen von ServiceMix bereitgestellt wird.Es ist am leistungsstärksten, da es normalerweise nicht schwierig ist und die Skalierung ereignisgesteuerter Anwendungen immer durch die Erhöhung der Anzahl der Verbraucher erfolgt.Dies ist am einfachsten zu verwalten, da Sie die Möglichkeit haben, die Art und Weise, wie Ihre Anwendungen gepackt werden, so zu ändern, dass die verbrauchende Anwendung vollständig getrennt ist und somit verteilt werden kann.

Dieser letzte Vorschlag ist die leistungsstärkste Möglichkeit, Ihre Anwendung zu skalieren.Solange der eingehende HTTP-Endpunkt eine große Menge an Datenverkehr verarbeiten kann, müssen Sie möglicherweise nur die Verbraucher in der Eingangswarteschlange erhöhen.Der Hauptgrund dafür ist, dass entweder die Verbraucher oder die Bean, an die sie übergeben, die ganze schwere Arbeit, den Großteil der Verarbeitung und Validierung, übernehmen.Typischerweise ist es dieser Prozess, der letztendlich die meisten Ressourcen benötigt.

Hoffentlich liefert dies die Informationen, die Sie benötigen, um in eine oder möglicherweise mehrere Richtungen zu gehen, je nachdem, welchen Teil Ihrer App Sie tatsächlich skalieren müssen.Wenn Sie Fragen haben, lassen Sie es mich bitte wissen.

Bruce