NServiceBus Pipeline mit Distributoren

Question

Ich baue eine Verarbeitungspipeline mit NServiceBus aber ich habe Probleme mit der Konfiguration der Verteiler, um jeden Schritt im Prozess skalierbar zu machen. Hier einige Informationen:

• Die Pipeline wird ein Master-Prozess haben, der sagt, für eine WorkItem „OK, Zeit zu starten“, die dann ein Verfahren wie ein Flussdiagramm beginnt.
• Jeder Schritt in dem Flussdiagramm kann rechnerisch teuer, so dass ich die Möglichkeit haben möge, jeden Schritt zu skalieren. Das sagt mir, dass jeder Schritt einen Händler benötigt.
• Ich möchte in der Lage sein, zusätzliche Aktivitäten später auf Ereignisse einzuhaken. Das sagt mir, ich brauche zu veröffentlichen () Nachrichten, wenn es fertig ist, nicht Send () sie.
• Ein Verfahren zur Niederlassung auf der Grundlage einer Bedingung benötigen. Das sagt mir, dass ein Prozess der Lage sein muß, mehr als eine Art von Nachricht zu veröffentlichen.
• Ein Prozess muss möglicherweise Gabeln verbinden. Ich stelle mir vor ich Sagas dafür verwendet werden soll.

Hoffentlich werden diese Annahmen sind gut ich sonst in mehr Schwierigkeiten bin, als ich dachte.

Aus Gründen der Einfachheit, vergessen sie über Forking oder Füge- und eine einfache Pipeline prüfen, mit Schritt A Schritt B gefolgt, und mit Schritt C. endet Jeder Schritt erhält seinen eigenen Verteiler und haben viele Knoten Verarbeitung von Nachrichten.

• NodeA Arbeiter enthalten einen IHandleMessages Prozessor und veröffentlichen Eventa
• NodeB Arbeiter enthalten einen IHandleMessages Prozessor und veröffentlichen Ereignis B
• KnotenC Arbeiter enthalten einen IHandleMessages Prozessor, und dann die Pipeline abgeschlossen ist.

Hier sind die relevanten Teile der Konfigurationsdateien, wobei # die Anzahl der Arbeiter bezeichnet, (das heißt, es sind Eingangswarteschlangen NodeA.1 und NodeA.2):

NodeA:
<MsmqTransportConfig InputQueue="NodeA.#" ErrorQueue="error" NumberOfWorkerThreads="1" MaxRetries="5" />
<UnicastBusConfig DistributorControlAddress="NodeA.Distrib.Control" DistributorDataAddress="NodeA.Distrib.Data" >
    <MessageEndpointMappings>
    </MessageEndpointMappings>
</UnicastBusConfig>

NodeB:
<MsmqTransportConfig InputQueue="NodeB.#" ErrorQueue="error" NumberOfWorkerThreads="1" MaxRetries="5" />
<UnicastBusConfig DistributorControlAddress="NodeB.Distrib.Control" DistributorDataAddress="NodeB.Distrib.Data" >
    <MessageEndpointMappings>
        <add Messages="Messages.EventA, Messages" Endpoint="NodeA.Distrib.Data" />
    </MessageEndpointMappings>
</UnicastBusConfig>

NodeC:
<MsmqTransportConfig InputQueue="NodeC.#" ErrorQueue="error" NumberOfWorkerThreads="1" MaxRetries="5" />
<UnicastBusConfig DistributorControlAddress="NodeC.Distrib.Control" DistributorDataAddress="NodeC.Distrib.Data" >
    <MessageEndpointMappings>
        <add Messages="Messages.EventB, Messages" Endpoint="NodeB.Distrib.Data" />
    </MessageEndpointMappings>
</UnicastBusConfig>

Und hier sind die relevanten Teile der Verteiler configs:

Distributor A:
<add key="DataInputQueue" value="NodeA.Distrib.Data"/>
<add key="ControlInputQueue" value="NodeA.Distrib.Control"/>
<add key="StorageQueue" value="NodeA.Distrib.Storage"/>

Distributor B:
<add key="DataInputQueue" value="NodeB.Distrib.Data"/>
<add key="ControlInputQueue" value="NodeB.Distrib.Control"/>
<add key="StorageQueue" value="NodeB.Distrib.Storage"/>

Distributor C:
<add key="DataInputQueue" value="NodeC.Distrib.Data"/>
<add key="ControlInputQueue" value="NodeC.Distrib.Control"/>
<add key="StorageQueue" value="NodeC.Distrib.Storage"/>

Ich teste mit 2 Instanzen von jedem Knoten, und das Problem scheint in der Mitte auf Knoten B zu kommen Grundsätzlich gibt es zwei Dinge, die passieren könnten:

1. Beide Instanzen von Knoten B berichten, dass es zu Eventa abonniert, und auch, dass NodeC.Distrib.Data@MYCOMPUTER zum EventB abonniert, dass Knoten B veröffentlicht. In diesem Fall funktioniert alles super.
2. Beiden Instanzen von Knoten B berichten, dass es zu Eventa abonniert, jedoch ein Arbeiter sagt NodeC.Distrib.Data@MYCOMPUTER ZWEIMAL abonniert, während die anderen Arbeiter es nicht erwähnt.

Im zweiten Fall, der nur durch die Art und Weise gesteuert werden, scheinen die Verteilerwege die Abonnement-Nachrichten, wenn die „overachiever“ Knoten ein Eventa verarbeitet, ist alles gut. Wenn die „Versager“ Eventa verarbeitet, dann veröffentlichen die von EventB keine Abonnenten hat und die Workflow-Werkzeugen.

Also, meine Fragen:

1. Ist diese Art von Einrichtung möglich?
2. Ist die Konfiguration korrekt? Es ist schwer, alle Beispiele für Konfiguration mit Distributoren über eine einfache One-Ebene Verlag / 2-Arbeiter-Setup zu finden.
3. würde es mehr Sinn, einen zentralen Broker-Prozess zu haben, die alle tun, die nicht rechenintensive Verkehrspolizist Operationen und sendet nur Nachrichten an Prozessen hinter Verteiler, wenn die Aufgabe mit langer Laufzeit und muss Last ausgeglichen sein?
   • Dann wird der Lastenausgleich Knoten könnte einfach antworten auf die zentralen Broker zurück, die einfacher zu sein scheint.
   • Auf der anderen Seite, die im Widerspruch mit der Dezentralisierung scheint die NServiceBus Stärke ist.
   • Und wenn dies die Antwort, und der langen Lauf done Veranstaltung Prozess ist eine Antwort, wie halten Sie das Veröffentlichen, dass auf veröffentlichte Ereignissen später Erweiterbarkeit ermöglicht?

Answer 1

Das Problem, das Sie haben, ist, dass die Knoten nicht jede andere Liste der Teilnehmer sehen. Der Grund, warum Sie dieses Problem sind ist, dass Ihr ein Produktionsszenario auszuprobieren (Scale-out) unter dem Standard NServiceBus Profil (lite), die nicht Scale-Out nicht unterstützt, sondern macht nur mit einem Gerät Entwicklung sehr produktiv.

Um das Problem zu lösen, führen Sie den NServiceBus Host das Produktionsprofil verwendet wie auf dieser Seite beschrieben:

http://docs.particular.net/nservicebus/hosting/nservicebus -host / profiles

Das läßt verschiedene Knoten die gleiche Liste von Teilnehmern teilen.

Other than that, ist Ihre Konfiguration direkt an.