NServiceBus tubería con Distribuidores

Question

Estoy construyendo una canalización de procesamiento con NServiceBus pero estoy teniendo problemas con la configuración de los distribuidores con el fin de hacer que cada paso en el proceso escalable. Aquí hay algo de información:

• El gasoducto tendrá un proceso maestro que dice "OK, el tiempo para iniciar" un WorkItem, que a su vez iniciar un proceso como un diagrama de flujo.
• Cada paso en el diagrama de flujo puede ser computacionalmente caro, así que quiero la capacidad de escalar a cabo cada paso. Esto me dice que cada paso requiere un Distribuidor.
• Quiero ser capaz de conectar las actividades adicionales en los eventos más tarde. Esto me necesito publicar () mensajes cuando se hace, no Send () les dice.
• Un proceso puede necesitar la rama sobre la base de una condición. Esto me dice que un proceso debe ser capaz de publicar más de un tipo de mensaje.
• Un proceso puede tener que unirse a las horquillas. Me imagino que debe utilizar para este Sagas.

Esperamos que estos supuestos son buenas por lo demás estoy en más problemas de lo que pensaba.

En aras de la simplicidad, vamos a olvidarnos de que se bifurcan o unirse y considerar una tubería sencilla, con la etapa A seguida por la etapa B, y terminando con la etapa C. Cada paso tiene su propio distribuidor y puede tener muchos nodos de procesamiento de mensajes.

• trabajadores NODEA contienen un procesador IHandleMessages, y publican Eventa
• trabajadores NodoB contienen un procesador IHandleMessages, y publican Evento B
• trabajadores NODEC contienen un procesador IHandleMessages, y luego la tubería es completa.

Estas son las partes pertinentes de los archivos de configuración, donde # indica el número del trabajador, (es decir, hay colas de entrada y NodeA.1 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>

Y aquí están las partes pertinentes de las configuraciones del distribuidor:

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"/>

Estoy probando el uso de 2 casos de cada nodo, y el problema parece venir en el medio en el Nodo B. Hay básicamente 2 cosas que podrían ocurrir:

1. Ambos casos de informe Nodo B que está suscribiendo a Eventa, y también que NodeC.Distrib.Data@MYCOMPUTER está suscribiendo al EventB que Nodo B publica. En este caso, todo funciona muy bien.
2. Las dos instancias de informe Nodo B que está suscribiendo a Eventa, Sin embargo, un trabajador dice NodeC.Distrib.Data@MYCOMPUTER está suscribiendo dos veces, mientras que el otro trabajador no lo menciona.

En el segundo caso, lo que parece estar controlada sólo por la forma en que las rutas de los distribuidores los mensajes de suscripción, si el nodo "mérito adicional" procesa un Eventa, todo está bien. Si el "bajo rendimiento" procesa Eventa, entonces la publicación de EventB no tiene suscriptores y las matrices de flujo de trabajo.

Por lo tanto, mis preguntas:

1. ¿Es este tipo de configuración es posible?
2. ¿Es correcta la configuración? Es difícil encontrar ejemplos de configuración con los distribuidores más allá de una sencilla configuración de un nivel editor / 2 de trabajo.
3. tendría más sentido tener un proceso de agente central que hace todas las operaciones no computacionalmente intensivas de policía de tráfico, y sólo envía mensajes a los procesos detrás de los distribuidores cuando la tarea es de larga duración y debe ser equilibrado de carga?
   • A continuación, los nodos de carga equilibrada simplemente podría responder de nuevo al corredor central, que parece más fácil.
   • Por otro lado, que parece estar en desacuerdo con la descentralización que es la fuerza de NServiceBus.
   • Y si esta es la respuesta, y el evento de hecho el proceso de larga duración es una respuesta, ¿cómo se mantiene la Publish que permite la extensibilidad más adelante eventos publicados?

Answer 1

El problema que tiene es que sus nodos no ven cada lista de otros abonados. La razón por la que está teniendo el problema es que su probar un escenario de producción (scale-out) bajo el perfil predeterminado NServiceBus (lite) que no soporta la escala de salida, pero hace que el desarrollo de una sola máquina muy productiva.

Para resolver el problema, ejecute el anfitrión NServiceBus utilizando el perfil de producción tal como se describe en esta página:

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

Esto permitirá que diferentes nodos comparten la misma lista de suscriptores.

Aparte de eso, la configuración es correcto.