¿Alguien puede explicar para qué sirven los intermediarios de mensajes?

Question

En mi trabajo es difícil pasar cinco minutos sin que alguien ensalce las virtudes de MQ Series o MSMQ o similares, y siempre me pregunto, después de que ha pasado el brillo de las palabras de moda, cuáles son algunos ejemplos reales de de estos maravillosos dispositivos en el mundo real.

Lo que estoy buscando es algo que podría inspirarme a encontrar un uso para uno de estos o darme algún tipo de métrica que pueda usar para evaluar un mensaje bus/mensaje corredor/cola de mensajes - diablos, incluso algo que explicará cuáles son las diferencias entre el mensaje * antes mencionado.

Answer 1

Las soluciones de Message Queuing como MQ Series o MSMQ se utilizan ampliamente para integrar aplicaciones empresariales distribuidas, especialmente en plataformas diferentes. Hecho a la derecha (con colas persistentes, diseño asincrónico en lugar de 'RPC sobre MQ' y atención a los requisitos operativos), esto le da alta disponibilidad en comparación con las integraciones síncronas de solicitud/respuesta como RPC o servicios web estándar (cuya disponibilidad es el producto de las respectivas disponibilidades: la integración de diez sistemas con un 99% de disponibilidad de forma síncrona le ofrece una disponibilidad combinada de no más del 90% - o peor si solo hay un enlace débil). Eso sí, esto requiere que las colas de mensajes tengan alta disponibilidad en sí mismas: utilizamos nuestro mainframe para ese fin (¡adivine qué producto estamos usando!).

Los corredores de mensaje (o integración) y los "autobuses" son una olla de pescado más compleja. Estas pueden añadir

• traducción entre las diferentes representaciones de contenido (codificaciones de texto y páginas de códigos)
• supervisión, detectando cuando un sistema de destino no recoge mensajes en cola y el aumento de las alarmas o reinicie automáticamente
• transformación, cuando los sistemas no "hablan el mismo idioma" y representan, por ejemplo el cliente o producto registra de manera diferente: esto en principio puede ayudarlo a implementar nuevas versiones a diferentes tasas
• enrutando (hasta e incluyendo publicación/suscripción) para desacoplar un sistema de envío del conocimiento de los detalles de los destinatarios, reduciendo así el impacto de cambios en los sistemas de destino
• orchestration, donde puede coordinar mensajes entre una serie de sistemas para rastrear un proceso comercial más real (por ejemplo, desde la orden del cliente hasta la entrega y la facturación).

He enumerado estas funcionalidades en orden de dificultad cada vez mayor (y posible recompensa). Cuanto más alto se obtiene, más madura debe ser su organización (incluida la parte comercial) para obtener las ventajas.

Answer 2

Sin entrar en detalles sobre productos específicos, puedo darle algunos de los beneficios de utilizar un sistema típico de cola de mensajes.

Normalmente son una buena infraestructura para simular el patrón del editor/suscriptor. Piensa en un gran sistema de eventos donde no estés limitado a un ejecutable, o incluso a una máquina. Pones información en estas colas, de modo que cualquier aplicación que esté escuchándola puede recoger los datos.

La mayoría de los sistemas de cola de mensajes permiten colas persistentes. Piensa en un sistema típico de eventos. Si el oyente está desconectado o no responde en el momento del evento, entonces el evento se pierde. Con una cola de mensajes persistente, el mensaje permanecerá en la cola hasta que el oyente se vuelva a conectar. No se pierden datos/eventos de esta manera.

No conozco los productos que enumeró, pero sé que con JMS puede tener un control detallado sobre el enhebrado a medida que se extraen los mensajes de la cola. En teoría, podría tener un hilo por cola, realizando acciones en ese hilo, en los mensajes a medida que se quitan. Alternativamente, tiene la capacidad de extraer mensajes de múltiples colas y realizar acciones en ellos, todo dentro de un hilo compartido.

Answer 3

Si bien tuve una experiencia muy amarga con la serie MQ debido a que la empresa asociada nos presionó (una tienda de Microsoft), el uso de la serie MQ (o cualquier sistema de mensajería) fue integral parte de la aplicación.

Básicamente, estábamos creando un proceso que manejaba el cumplimiento de la cadena de suministro para los artículos en espera. Si nuestro socio, un distribuidor, no tuviera los artículos que sus clientes querían, enviarían un mensaje a un sitio B2B, que estaría dirigido a posibles compañías que podrían cumplir con el pedido.

Construimos dos sabores diferentes de integración. El primero fue un enfoque ftp en el que los archivos de ancho fijo se enviaban de ida y vuelta a intervalos regulares, y habíamos añadido todo tipo de reglas para ayudar a garantizar que no omitíamos ningún dato.

El segundo fue el uso de la serie MQ donde los mensajes se colocaron en una cola con entrega garantizada. Luego, extraeríamos la cola y procesamos los mensajes. El sistema de búsqueda fue un gran beneficio aquí ya que nos permitió una manera confiable de transmitir mensajes críticos que dieron como resultado que se moviera dinero real.

Por otro lado con la misma serie MQ tuvimos que implementar una consulta sincrónica para obtener información. Queríamos que fuera sincrónico porque nuestros usuarios que acceden a este a través de la web esperarían para obtener la información. Hacer esto durante la serie MQ fue un desafío muy interesante y doloroso. La única razón por la que MQ se usó aquí fue porque era una línea de comunicación existente y la funcionalidad de consulta ya existía.

Un segundo ejemplo y esta vez fue el uso de MSMQ fue un sitio que recopiló información del código del dialhome inyectado en las aplicaciones del cliente. El código dialhome recolectaría estadísticas de uso de características como el programa SQM de Microsoft.Cuando llegaban los mensajes al servicio web, los soltábamos en una cola. Luego, podíamos tener cualquier cantidad de servidores de aplicaciones mostrando los mensajes y llevándolos a la base de datos para que se transfirieran al almacén.

MSMQ aquí garantizado que podríamos manejar ráfagas de mensajes colocándolos rápidamente en la cola. Esto ayuda a la escalabilidad y confiabilidad del sistema.

Answer 4

Una cola de mensajes es útil para implementar el equilibrio de carga. Por ejemplo, el servidor recibe mensajes de "trabajo" (pedidos, mensajes de estado ...) y los distribuye a todos los clientes que están escuchando.

La cola de mensajes garantiza que un mensaje se entregará exactamente a un cliente.

Si los clientes se ejecutan en computadoras diferentes, la carga total se distribuirá y será fácil enviar otro cliente a la carga del mensaje cuando sea necesario, el cliente solo tiene que conectarse a la cola y recibirá (algunos) los mensajes.

Answer 5

Un buen sistema de colas hace que sea más fácil hacer computación distribuida en múltiples hilos, procesadores, máquinas, (& incluso organizaciones).

Hace un tiempo (10 años) he usado una metáfora de envío de mensajes para implementar un sistema de valoración de opciones de front-office para un corredor de interdealer. Hemos implementado servicios en C++, VB6 y Excel/VBA (¡incluso utilizando el solucionador de Excel!), Almacenamiento de datos como archivos planos y sql, aplicaciones de usuario final escritas en Excel y VB6, con un modelo de datos complejo (datos de mercado, rendimiento curvas y superficies vol). La mensajería asincrónica (con mensajes persistentes/confiables y pub/sub) hizo que todo funcionara de manera muy efectiva y escalable: pudimos agregar oficinas de Tokio y Nueva York a la infraestructura de Londres sin siquiera visitar el sitio remoto, solo una instalación estándar de pantano.

Soy un gran fan aunque estoy sorprendido por lo lejos que no han llegado en los últimos 10 años más o menos.

Answer 6

Una muy "cerca de requierement" exemple de proyecto real. Quién huye de varios años. En ActiveMQ

1) centro comercial de mercado del transporte marítimo.

• compagny envío tienen sistema, quien sabe cuántos paquetes se pueda enviar en tiempo real.

• Cada sistema es diferente (lengua, diseño ...)

• que escribió un adaptador para cada compañia "sistema informático muy especial para ActiveMQ"

• Cada adaptador tiene un trabajo fácil de hacer : publicar cuando la compañía tiene espacio libre, y a qué precio. (Una "propuesta de transporte")

• Nos escribió un cliente que se reúnen todos "proposición de transporte", y los muestra muy bien.

=> Ta-da. usted tiene un sistema multiplataforma/lenguaje/proceso, para la compañía que no quiere hablar entre ellos

=> Ta-da 2: Si una nueva compañía quiere entrar en su sistema comercial, solo tienen que escribir el adaptador.