Persistent Messaging/Service Bus - ¿Hacer rodar el mío o arriesgar la curva de aprendizaje?

Question

Tenemos una aplicación cliente que necesita enviar mensajes a un servidor para varias notificaciones. Para que el cliente pueda funcionar ocasionalmente conectado, voy a usar un enfoque de cola de mensajes. El procesamiento de colas eliminará los mensajes de la cola y llamará a un servicio web que los colocará en otra cola para finalmente ser procesados. Esta pregunta es sobre el entorno del cliente; el entorno del servidor ya está decidido.

No quiero usar MSMQ porque no tenemos control sobre todas las PC del cliente para instalar/configurar y asegurar MSMQ correctamente, y porque el soporte es más desafiante debido a la calidad de las herramientas para investigar el contenidos de las colas de MSMQ. SQL Server 2005 Express está en todas las máquinas y se usa para almacenar datos para nuestra aplicación.

actualmente lo tengo a dos opciones:

1. Escribe un persistente mensaje en cola bastante básico que almacena los mensajes en una mesa después de serialising ellos, a continuación, utiliza ThreadPool.QueueUserWorkItem que los han procesado por los manejadores configurados uno contra Tipo de mensaje. Todo en un System.Transactions.TransactionScope por lo que solo se eliminan de la cola persistente si se procesan correctamente.
2. Use NServiceBus (este es el bus de servicio con el que hemos trabajado como equipo, por lo que MassTransit, etc. no son opciones) en el cliente, con un transporte de Service Broker que usa la base de datos local.

Tengo poca experiencia con los autobuses de servicio (todavía no recibo la terminología de bus de servicio) así que me preocupa la curva de aprendizaje en comparación con escribir algo mucho más simple que satisfaga mis necesidades del modo que necesito (implementación es una consideración grande).

¿Alguien tiene alguna idea?

Answer 1

Al final escribí un bus de mensajes básico configurado con mi propio SqlTransport para que los mensajes se serialicen y guarden en una tabla de base de datos SQL Server, antes de que se generen eventos y se señale un subproceso diferente para procesar los mensajes.

Answer 2

Bueno, no sé si voy a sugerir MSMQ, pero sugeriré que hay muchos casos extremos en los que hay que pensar para 'enrollar el suyo'.

Incluso con un enfoque de grupo de subprocesos, tenga en cuenta que puede haber problemas de pedido si le interesa - dos artículos publicados en secuencia para enhebrar piscinas pueden no se ejecutan en orden, debido a cómo los grupos de subprocesos manejan elementos de trabajo.

También deberá pensar en la persistencia de los mensajes y su duración, cómo detectar el estado "no válido" de no entrega y qué hacer en ese caso.

También hay una serie de casos extremos potenciales en los escenarios en los que su aplicación se cae al mismo tiempo que está poniendo en cola un mensaje; por ejemplo, puede no reconocer que el mensaje se puso en cola, aunque así fuera. Sí, puede aceptar el reconocimiento de la cola, pero puede ingresar interminablemente en círculos ...

¿Por qué no hacer que la aplicación detecte cuándo se conecta y enviar todos los datos en ese momento?

Answer 3

Al haber escrito nuestro propio bus de servicio, puedo decirle que no es una tarea trivial y que se encontrará con los mismos casos extremos que todos los demás implementadores ya se han topado. kyoryu trae dos muy importantes.

Ya sea que lances la tuya también depende de las habilidades que tengas en casa y tendrás en el futuro para mantener la solución.

Otra consideración es la escala final del sistema y sus requisitos de fiabilidad. ¿Escalará la solución interna lo suficiente?

Nuestro bus de mensajes peer-to-peer, Zebus, basado en ZeroMq (transporte), Cassandra (descubrimiento y persistencia) y Protobuf (serialización).

1. Sin implementación de cliente como en el cliente es sólo una biblioteca
2. Message persistence se proporciona el uso de Cassandra también y maneja muchos casos extremos diferentes (esto se analiza regularmente en nuestro entorno de producción)
3. Se desempeña bien y ya que es una solución brokerless no existe un único cuello de botella
4. no hay puntos únicos de fallo como el Directorio se puede utilizar con un almacén de datos disponibles, tales como Cassandra

Es de código abierto y prueba de producción https://github.com/Abc-Arbitrage/Zebus