Patrón de puente de mensajería

En este artículo se describe el patrón de puente de mensajería, que es una técnica que puede usar para integrar sistemas dispares basados en diferentes infraestructuras de mensajería.

Contexto y problema

Muchas organizaciones y cargas de trabajo pueden tener sin darse cuenta sistemas de TI que usan varias infraestructuras de mensajería, como Microsoft Message Queuing (MSMQ), RabbitMQ, Azure Service Bus y Amazon SQS. Este problema puede producirse debido a fusiones, adquisiciones o a la ampliación de los sistemas locales actuales con componentes hospedados en la nube porque son más rentables y fáciles de mantener.

Los desarrolladores pueden abordar este desafío modificando los sistemas que se integran para comunicarse mediante servicios web basados en HTTP. Sin embargo, este enfoque tiene inconvenientes como los siguientes:

• Los sistemas deben modificarse agregando un cliente HTTP en un lado y un controlador de solicitudes HTTP en el otro. Los sistemas deben volver a probarse e implementarse.
• Los puntos de conexión HTTP deben hospedarse, lo que agrega complejidad al hacer que los servicios web sean seguros y tengan una alta disponibilidad.
• Problemas frecuentes de conectividad de red que requieren mecanismos de reintento integrados personalizados.

Solución

Si los sistemas que se integran constan de componentes que se comunican intercambiando mensajes, el patrón de puente de mensajería mejora la integración y mitiga los inconvenientes.

En este escenario, cada sistema se conecta a una infraestructura de mensajería. Para integrar en diferentes infraestructuras de mensajería, introduzca un componente de puente que se conecte a dos o más infraestructuras de mensajería al mismo tiempo. El puente extrae mensajes de uno y los inserta en el otro sin cambiar la carga.

Los sistemas que se integran no necesitan reconocer a los demás ni al puente. El sistema remitente está configurado para enviar mensajes específicos a una cola designada en su infraestructura de mensajería nativa. El puente recoge esos mensajes y los reenvía a otra cola de otra infraestructura de mensajería donde el sistema receptor los recoge.

Ventajas

• Los sistemas que se integran a través del puente de mensajería no tienen que modificarse. Lo ideal es que los puntos finales no sepan que los mensajes están puenteados.
• La integración es más confiable en comparación con la alternativa HTTP debido a la garantía del mecanismo de entrega de mensajes al menos una vez.
• Los escenarios de migración pueden ser más flexibles. Por ejemplo, los puntos de conexión pueden migrarse de una infraestructura de mensajería a otra según lo permita el calendario, en lugar de hacerlo todos a la vez.

Inconvenientes

• Es posible que las características avanzadas de una o ambas tecnologías de mensajería no estén disponibles en la ruta puenteada.
• La ruta puenteada debe tener en cuenta las limitaciones de ambas tecnologías. Por ejemplo, el tamaño máximo del mensaje puede ser de 4 MB en MSMQ, pero solo de 64 KB en colas de Azure Storage.

Problemas y consideraciones

Tenga en cuenta los puntos siguientes al implementar el patrón de puente de mensajería:

• Si uno de los sistemas integrados depende de transacciones distribuidas, por ejemplo, del Coordinador de transacciones distribuidas de Microsoft (DTC), para su corrección, debe implementar un mecanismo de desduplicación en el puente.

• Si uno de los sistemas que se integran no usa ninguna infraestructura de mensajería y no se puede modificar, puede crear el puente de mensajería entre la infraestructura que usa el otro sistema y una cola emulada de SQL Server. El sistema heredado puede enviar mensajes mediante la característica de captura de datos modificados para que SQL Server inserte sus cambios en una tabla de colas dedicada. El puente puede reenviar estos mensajes a la infraestructura de mensajería real.

• Puede usar una sola cola en cada infraestructura de mensajería, designada como cola de puente. En esta topología, configure el sistema de envío para que use esa cola específica como destino de los tipos de mensaje que se envían al otro sistema. También puede usar varios pares de colas en cada infraestructura de mensajería, para que el remitente no conozca el puente. Se crea una cola paralela para cada cola de destino de la infraestructura de mensajería del sistema de destino. El puente reenvía los mensajes entre las colas paralelas y sus homólogas.

• Para cumplir los Acuerdos de Nivel de Servicio (SLA) de disponibilidad deseados, es posible que tenga que escalar horizontalmente el puente de mensajería mediante el enfoque de consumidores paralelos.

• Los componentes de procesamiento de mensajes normales usan el patrón de reintento para controlar errores transitorios. El límite de contadores de reintentos permite a los componentes detectar mensajes dudosos y quitarlos de la cola para desbloquear el procesamiento. El puente puede requerir una directiva de reintento diferente para evitar que se identifiquen falsamente los mensajes como dudosos si se produce un error de infraestructura. Puede usar el patrón de interruptor para pausar el reenvío.

Cuándo usar este patrón

Use el patrón de puente de mensajería cuando necesite:

• Integrar los sistemas existentes sin apenas tener que modificarlos.
• Integrar las aplicaciones heredadas que no puedan usar otras tecnologías de mensajería.
• Ampliar las aplicaciones locales existentes con componentes hospedados en la nube.
• Conectar sistemas distribuidos geográficamente cuando la conexión a Internet no sea estable.
• Migrar un único sistema distribuido de una infraestructura de mensajería a otra de forma incremental sin necesidad de migrar todo el sistema de una sola vez.

Este patrón podría no ser útil en los siguientes casos:

• Al menos uno de los sistemas implicados se basa en una característica de una infraestructura de mensajería que no está presente en la otra.
• La integración es sincrónica por naturaleza y el sistema que la inicia requiere una respuesta inmediata.
• La integración tiene requisitos funcionales o no funcionales específicos, como problemas de seguridad o privacidad.
• El volumen de datos de la integración supera la capacidad del sistema de mensajería o hace que la mensajería sea una solución al problema costosa.

Diseño de cargas de trabajo

Un arquitecto debe evaluar cómo se puede usar el patrón Messaging Bridge en el diseño de su carga de trabajo para abordar los objetivos y principios descritos en los pilares del Marco de buena arquitectura de Azure. Por ejemplo:

Al igual que con cualquier decisión de diseño, hay que tener en cuenta las ventajas y desventajas con respecto a los objetivos de los otros pilares que podrían introducirse con este patrón.

Ejemplo

Hay una aplicación escrita en un marco de .NET para administrar la programación de empleados hospedada en el entorno local. La aplicación está bien estructurada con componentes independientes que se comunican a través de MSMQ. La aplicación funciona y el equipo de carga de trabajo no tiene intención de volver a escribirla. Es necesario crear un nuevo consumidor de los datos de programación para satisfacer una necesidad empresarial, y la estrategia de TI exige crear nuevo software como aplicaciones nativas en la nube para optimizar los costos y el plazo de entrega.

La arquitectura asincrónica basada en colas funcionó para el equipo de cargas de trabajo en el pasado, por lo que el equipo va a utilizar el mismo enfoque arquitectónico pero con la tecnología moderna, Service Bus. El equipo de cargas de trabajo no quiere introducir una comunicación sincrónica entre la nube y la implementación local para mitigar la latencia o que la falta de disponibilidad de una afecte a la otra.

El equipo decide usar el patrón de puente de mensajería para conectar los dos sistemas. El patrón consta de dos partes: Una parte recibe mensajes de la cola de MSMQ existente y los reenvía a Service Bus. La otra parte toma mensajes de Service Bus y los reenvía a la cola de MSMQ existente.

Cuando el equipo de implementación usa este enfoque, emplean la infraestructura existente en la aplicación existente para integrarla con los nuevos componentes. La aplicación existente no sabe que los nuevos componentes se hospedan en Azure. Del mismo modo, los nuevos componentes se comunican con la aplicación heredada de la misma manera que lo hacen entre sí mediante el envío de mensajes de Service Bus. El puente reenvía los mensajes entre los dos sistemas.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

• Rob Bagby | Director jefe de contenido de arquitectura
• Kyle Baley | Ingeniero de software
• Udi Dahan | Fundador y CEO de Particular Software
• Chad Kittel | Ingeniero principal de software
• Bryan Lamos | Relaciones con desarrolladores
• Szymon Pobiega | Ingeniero

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

• Descripción del patrón de puente de mensajería de la comunidad de patrones de integración empresariales.
• Aprenda a implementar un puente de mensajería en el marco de Spring Java.
• Se puede usar el puente QPid para puentear las tecnologías de mensajería habilitadas para AMQP.
• El puente de mensajería NServiceBus es una implementación de .NET de un puente de cola a cola que admite una variedad de infraestructuras de mensajería, como MSMQ, Service Bus y Azure Queue Storage.
• NServiceBus.Router es un proyecto de código abierto que implementa el patrón de puente de mensajería. También permite puentear más de dos tecnologías en una sola instancia y tiene funcionalidades avanzadas de enrutamiento de mensajes.

Recursos relacionados

• El patrón de consumidores paralelos garantiza que la implementación del puente de mensajería pueda controlar la carga.
• El patrón de reintento permite que el puente de mensajería controle los errores transitorios.
• El patrón de interruptor conserva los recursos cuando cualquiera de los lados del puente experimenta tiempo de inactividad.