Mensajería persistente / Bus de servicio: ¿rodar la mía o arriesgar la curva de aprendizaje?

Question

Tenemos una aplicación cliente que necesita enviar mensajes a un servidor para recibir varias notificaciones. Para que el cliente pueda ejecutarse ocasionalmente conectado, voy a ir con un enfoque de cola de mensajes. El procesamiento de la cola eliminará los mensajes de la cola y llamará a un servicio web que los colocará en otra cola para que finalmente se procesen. 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 clientes para instalar / configurar y asegurar MSMQ correctamente, y porque el soporte es más difícil debido a la calidad de las herramientas para investigar el contenido de colas MSMQ. SQL Server 2005 Express está en todas las máquinas y se utiliza para almacenar datos para nuestra aplicación.

Actualmente tengo dos opciones:

1. Escriba una cola de mensajes persistente bastante básica que almacene los mensajes en una tabla después de serializarlos, luego use ThreadPool.QueueUserWorkItem para que los manejadores los configuren en cada tipo de mensaje. Todo en un System.Transactions.TransactionScope para que solo se eliminen de la cola persistente si se procesan correctamente.
2. Use NServiceBus (este es el bus de servicio con el que hemos viajado como equipo, por lo que Mass Transit, 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 buses de servicio (todavía no obtengo la terminología del bus de servicio), así que me preocupa la curva de aprendizaje en comparación con escribir algo mucho más simple que cumpla con mis requisitos de la forma en que lo necesito ( la implementación es una gran consideración).

¿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 se guarden en una tabla de base de datos de SQL Server, antes de que se generen eventos y se señale un hilo separado para procesar los mensajes.

Answer 2

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

Incluso con un enfoque de grupo de subprocesos, tenga en cuenta que puede haber problemas de pedido si le importa: dos elementos publicados secuencialmente en grupos de subprocesos pueden no ejecutarse en orden, debido a cómo manejan los grupos de subprocesos elementos de trabajo.

También deberá pensar en la persistencia de los mensajes, y cuánto tiempo deberían existir, cómo detectar el estado de no entrega "fatal" y qué hacer en ese caso.

También hay una serie de posibles casos extremos en escenarios en los que su aplicación deja de funcionar al mismo tiempo que pone en cola un mensaje; por ejemplo, es posible que no reciba el reconocimiento de que el mensaje estaba en cola, aunque lo fuera. Sí, puede confirmar el reconocimiento de la cola, pero puede entrar sin parar en los círculos de confirmación ...

¿Por qué no solo hacer que la aplicación detecte cuándo se conecta y envíe todos los datos en ese punto?

Answer 3

Después de escribir 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 encontrado. Kyoryu trae dos muy importantes.

El hecho de que desarrolle el suyo propio también depende de las habilidades que tenga internamente y de las que tendrá en el futuro para mantener la solución.

Otra consideración es la escala eventual del sistema y sus requisitos de confiabilidad. ¿La solución interna escalará lo suficiente?

Nuestro bus de mensajes punto a punto, Zebus, basado en ZeroMq (transporte), Cassandra (descubrimiento y persistencia de pares) y Protobuf (serialización).

1. Sin despliegue de cliente ya que en el cliente es solo una biblioteca
2. La persistencia de mensajes también se proporciona utilizando Cassandra y maneja muchos casos de borde diferentes (esto se prueba regularmente en nuestro entorno de producción)
3. Funciona bien y, como es una solución sin intermediarios, no hay un cuello de botella en el rendimiento único
4. No hay puntos únicos de falla ya que el Directorio se puede usar con un almacén de datos disponible como Cassandra

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