¿Tener una propiedad de tipo en un mensaje de cola es una indicación de un mal diseño en RabbitMQ?
Estoy tratando de comprender mejor los matices de diseñar un sistema distribuido utilizando colas en general y RabbitMQ en particular.
Supongamos que tengo mensajes como:
{
"id": 12,
"name": "John",
"role": "Empleado"
}
y
{
"id": 13,
"name": "Alex",
"role": "Gerente",
"level": 1
}
Ten en cuenta la propiedad role.
Un publicador enviará los mensajes anteriores cuando cada individuo complete la firma de un documento. El consumidor debe hacer cosas diferentes según el rol de una persona.
Enfoques de diseño:
- ¿Deberían los mensajes ir a un intercambio directo (sin una clave de enrutamiento) y finalmente a 1 cola? El consumidor debe escuchar una cola y, en consecuencia, tiene la responsabilidad de identificar qué tipo de actor (según el rol) ha firmado un documento.
-
¿Deberían los mensajes ir a un intercambio directo (con una clave de enrutamiento) y finalmente a 2 colas diferentes? Un publicador puede publicar mensajes con 2 claves de enrutamiento diferentes. RabbitMQ puede manejar el enrutamiento. El consumidor escuchará 2 colas diferentes. Este enfoque elimina la necesidad de la propiedad de rol en un mensaje.
-
¿Debería esto ir a un intercambio de tema (con clave de enrutamiento) y finalmente a 2 colas diferentes? Esto también elimina la necesidad de tener una propiedad de rol en un mensaje. En este escenario, el tipo de intercambio es diferente.
Mi pregunta es: ¿Es un mal diseño cuando terminamos teniendo algo como un tipo (en mi ejemplo, la propiedad de rol) en un mensaje y obligando al consumidor a escuchar solo una cola? ¿O es mejor utilizar la funcionalidad de clave de enrutamiento de RabbitMQ y nunca mantener una propiedad identificativa en un mensaje?
davy.ai
Como experto en IT especializado en RabbitMQ y colas de mensajes, diría que no hay una respuesta única a esta pregunta. Ambos enfoques tienen sus ventajas y desventajas según el caso de uso y los requisitos específicos.
El enfoque 1 (enviar mensajes a un intercambio directo sin una clave de enrutamiento y eventualmente a una cola) es más simple y requiere menos configuración. Sin embargo, pone más carga en el consumidor para identificar el tipo de actor basado en la propiedad de rol en el mensaje. Este enfoque puede ser adecuado para sistemas a pequeña escala donde el número de actores y sus roles sea limitado.
El enfoque 2 (enviar mensajes a un intercambio directo con claves de enrutamiento y eventualmente a dos colas diferentes) es más complejo pero proporciona una mejor separación y escalabilidad. Los publicadores pueden enviar mensajes a dos colas diferentes según la clave de enrutamiento, lo que permite a los consumidores manejar los mensajes por separado sin necesidad de una propiedad de rol en el mensaje. Este enfoque es adecuado para sistemas a gran escala donde el número de actores y sus roles sea más diverso.
El enfoque 3 (enviar mensajes a un intercambio de temas con claves de enrutamiento) es similar al enfoque 2 pero utiliza un tipo de intercambio diferente. Este enfoque es adecuado cuando hay más de dos tipos de actores con roles diferentes y los mensajes deben ser enrutados a múltiples colas según un patrón que coincida con la clave de enrutamiento.
En resumen, la elección entre estos enfoques depende de las necesidades específicas del sistema. Agregar una propiedad de tipo en el mensaje puede simplificar la estructura del mensaje, pero también puede agregar complejidad a la lógica del consumidor. Utilizar la funcionalidad de clave de enrutamiento de RabbitMQ puede proporcionar una mejor escalabilidad y separación, pero requiere más configuración y puede resultar en más colas para administrar.