¿Buena estrategia para Message Queue Server?

Question

Actualmente estoy diseñando una aplicación que en última instancia querré mover a Windows Azure. A corto plazo, sin embargo, se ejecutará en un servidor que alojaré yo mismo.

La aplicación implica una serie de aplicaciones web separadas, algunas de ellas son esencialmente servicios de WCF que reciben datos, y algunas son sitios para que los usuarios administren datos. Además, deberá haber un servicio de trabajador ejecutándose en segundo plano que procesará los datos de varias maneras.

Estoy muy interesado en utilizar una arquitectura desacoplada para esto. Lo ideal es que desee que los componentes (es decir, las aplicaciones web y el servicio de los trabajadores) sepan lo menos posible el uno del otro. Parece que usar una cola de mensajes será la mejor solución aquí: las aplicaciones web pueden enrutar mensajes con unidades de trabajo en la cola y el servicio de trabajadores puede seleccionarlos y procesarlos según sea necesario.

Sin embargo, quiero elaborar un buen conjunto de tecnologías para hacer esto, teniendo en cuenta que en última instancia me mudaré a Azure y quiero minimizar la cantidad de trabajo que tendré que hacer cuando migrar a la nube Azure tiene un componente Queue incorporado que parece ideal para mis necesidades. Lo que me gustaría hacer es crear algo yo mismo que lo imite lo más posible.

Parece que hay varias opciones (estoy usando .NET en Windows, con un back-end de SQL Server 2005) - los que he encontrado hasta ahora son:

• MSMQ
• corredor de servicio de SQL Server
• Rodando mi propia utilizando una tabla de base de datos y algunos procedimientos almacenados

me preguntaba si alguien tiene alguna sugerencia para esto - o si alguien ha hecho algo similar y tiene consejos sobre cosas que hacer/evitar Me doy cuenta de que cada situación es diferente, pero en este caso creo que mis requisitos de colas son bastante genéricos, así que me encantaría escuchar los pensamientos de otras personas sobre la mejor manera de hacerlo.

Gracias de antemano,

John

Answer 1

Si tiene Azure en mente, tal vez debería empezar recto Azure como las API y semnatics son significativamente diferentes entre colas de Azure y cualquiera de MSMQ o SSB.

Una rápida comparación de 3048 metros de MSMQ vs SSB (Voy a dejar una costumbre mesa-como-cola de comparación, ya que realmente depende de cómo ponerlo en práctica ...)

• despliegue : MSMQ es un componente de Windows, SSB es un componente de SQL. SSB requiere una instancia de SQL para almacenar cualquier mensaje, por lo que los clientes no conectados necesitan acceso a una instancia (puede ser Express). MSMQ requiere la implementación de MSMQ en el cliente (parte del sistema operativo, pero instalación opcional).
• Programabilidad: MSMQ ofrece un canal WCF completamente desarrollado y compatible. SSB ofrece solo un canal WCF experimental en http://ssbwcf.codeplex.com
• Rendimiento: SSB será significativamente más rápido que MSMQ en el modo de transacción.MSMQ será más rápido si lo dejo operar en modo sin transacción (mejor esfuerzo, desordenado, entrega)
• Queriabilidad: Las colas SSB se pueden SELECCIONAR hacia arriba (ver cualquier mensaje, completo JOIN/WHERE/ORDER/GROUP de SQL), Las colas MSMQ se pueden consultar (solo el siguiente mensaje)
• Recuperación: Las colas SSB están integradas en la base de datos por lo que se respaldan y restauran con la base de datos, manteniendo un estado obligatorio con el estado de la aplicación. Las colas MSMQ están respaldadas en el subsistema de copia de seguridad de archivos NT, por lo que para mantener la copia de seguridad sincronizada (coherente), se deben suspender las bases de datos de la cola y.
• Transacciones (ya que cada puesta en cola/retirada de cola es siempre acompañada de una actualización de base de datos): SSB está totalmente integrado en SQL para desencolado y encolamos son operaciones de transacciones locales. MSMQ es una TM separada (Administrador de transacciones) por lo que la cola/dequeue debe ser una operación de Transacción distribuida para inscribir tanto SQL como MSMQ en la transacción.
• Gestión y supervisión: both equalty bad. Sin herramientas de ningún tipo.
• Mensajes correlacionados procesamiento: SSB puede bloquear el procesamiento del mensaje correlacionado por hilos concurent a través del Conversation Group Locking incorporado.
• Evento controlado: SSB tiene Activation para iniciar procedimientos almacenados, MSMQ usa el servicio Windows Activation. Similar. Sin embargo, SSB tiene capacidad de equilibrio de carga automática debido a la forma en que interactúan WAITFOR (RECEIVE) y MAX_QUEUE_READERS.
• Disponibilidad: SSB a cuestas en la historia de alta disponibilidad de SQL Server, puede funcionar en clústeres o en el entorno de creación de la base de datos. MSMQ solo utiliza la historia de clústeres de Windows. La creación de reflejo de la base de datos es mucho más económica que la agrupación en clúster como una solución HA.

Además me gustaría añadir que la SSB y MSMQ difieren significativamente al nivel deEl primitiva que ofrecen: SSB primitiva es una conversación , mientras que MSMQ primitiva es un mensaje . Piensa en la semántica TCP vs. UDP.

Answer 2

Elija una cola que sea adecuada para usted o que se adapte mejor a su entorno. @Remus ha dado una gran comparación entre MSMQ y SSB. MSMQ va a ser más fácil de implementar, pero tiene algunas limitaciones notables, mientras que SSB se va a sentir muy pesado ya que está en el otro extremo del espectro.

hacerlo a tu manera
Para minimizar el reproceso de tus aplicaciones, abstractas las colas de acceso detrás de una interfaz, y luego proporcionar una implementación para el transporte de cola que en última instancia decide ir con. Cuando es hora de pasar a Azure u otro transporte de cola, solo proporciona una nueva implementación de su interfaz.

Tienes la posibilidad de controlar la semántica de cómo quieres interactuar con la cola para obtener una API usable consistente de tus aplicaciones.

una idea aproximada podría ser:

interface IQueuedTransport 
{ 
    void SendMessage(XmlDocument); 
    XmlDocument ReceiveMessage(); 
} 

public class MSMQTransport : IQueuedTransport {} 
public class AzureQueueTransport : IQueuedTransport {} 

El usuario no puede ser la construcción del todo el transporte cola, justo lo que se adapte a sus necesidades. Si trabajas con Xml, pasa xml. Si trabajas en matrices de bytes, pasa las matrices de bytes.:)

¡Buena suerte!
Z

Answer 3

Use Win32 Mailslots. Serán confiables en un único servidor, son fáciles de implementar y no requieren ningún software adicional.