Traducción
La mensajería es una parte fundamental de cualquier sistema distribuido. Permite a un productor enviar un mensaje a cualquier número de consumidores, y no es necesario conocer ninguna información sobre el consumidor. Esto es de gran ayuda para una comunicación verdaderamente asíncrona y de desacoplamiento.
Cuando usas RabbitMQ, el diagrama anterior muestra una estructura muy básica pero típica. Un productor envía un mensaje al interruptor. Según la lógica de enrutamiento, el switch introduce el mensaje en la cola vinculada al switch. Más concretamente, si es un switch de tipo broadcast, la copia de este mensaje se enviará repetidamente a cada cola. Un consumidor puede entonces recibir y procesar el mensaje.
Una suposición importante para que la estructura anterior funcione con éxito para productores y consumidores es que todos los componentes de RabbitMQ (es decir, colas, switches y bindings) deben crearse con antelación. Un consumidor no puede enviar un mensaje a un conmutador. Si el conmutador no existe, un consumidor no puede procesar mensajes de una cola que no existe.
Por lo tanto, no es difícil entender que antes de que el productor/consumidor envíe/reciba el mensaje, se debe dejar que un valor productor/consumidor cree una cola, un cambio y una relación de enlace. Veamos las ventajas y desventajas de cada forma.
1. Distinguir responsabilidades
Traducción de imágenes (1. El productor crea un switch 2. El consumidor crea una cola y vincula la cola al switch)
Para que productores y consumidores puedan desacoplarse completamente, idealmente, los productores solo conocen la información sobre el interruptor (no la cola), y los consumidores solo conocen la cola (no el interruptor). La relación de enlace indica la relación entre el switch y la cola
Una posible forma es que el productor se encargue de la creación del switch, y el consumidor crea la cola y vincule la cola al switch. La ventaja de este método de desacoplamiento es que, si el consumidor necesita una cola, simplemente es necesario crear una cola y vincularlas según la demanda, y el productor no necesita conocer ninguna información sobre la cola. Pero esto no es un desacoplamiento suficiente: porque el consumidor debe conocer el interruptor para poder vincularlo.
2. Los productores crean todo
Cuando el productor está en ejecución, se puede configurar para crear todos los componentes necesarios (switches, colas y bindings). La ventaja de este enfoque es que no se pierden mensajes (porque la cola ya está creada y vinculada al switch, y ningún consumidor necesita iniciarla primero).
Sin embargo, esto significa que el productor debe conocer todas las colas que deben vincularse al switch. Esta es una forma altamente acoplada. La razón es que cada vez que se necesita añadir una nueva cola, el productor debe reconfigurar y desplegar para crear y vincular colas
3. Los consumidores crean todo
Lo contrario es dejar que el consumidor cree los switches, colas y bindings que necesita cuando está en funcionamiento. Como en el enfoque anterior, este método produce acoplamiento porque el consumidor debe conocer la información sobre el conmutador al que está vinculado a la cola. Cualquier cambio en el switch (como el cambio de nombre) implica que todos los consumidores deben ser reconfigurados y desplegados. Cuando hay colas y consumidores grandes, esta complejidad puede ser prohibitiva.
4. Ninguno de los dos crea nada
Un enfoque completamente diferente es que ni el productor ni el consumidor creen los componentes necesarios. En su lugar, se crea utilizando la interfaz de usuario del plugin de administración o la CLI de administración de antemano. Este método se basa en las siguientes ventajas:
- Productores y consumidores pueden estar completamente desacoplados. Los productores solo conocen el intercambio, y los consumidores solo conocen la cola.
- Esto puede ser fácilmente scriptado y automatizado como parte de la cadena de despliegue
- Cualquier cambio, como nuevas colas, puede añadirse sin afectar a ningún editor o consumidor ya desplegado
resumen
En sistemas distribuidos, los mensajes asíncronos son una forma útil de desacoplar, pero para mantenerlos desacoplados, es necesario mantener una estrategia eficaz para mantener la estructura de mensajería subyacente (en RabbitMQ, estos son colas, switches y bindings).
Aunque los servicios de editores y consumidores pueden ser responsables de crear lo que necesitan por sí mismos, pueden ser costosos en términos de pérdida inicial de mensajes, acoplamiento y mantenimiento operativo (en términos de configuración y despliegue).
Probablemente la mejor manera de gestionar la configuración del sistema de mensajería donde debe estar: escribir scripts fuera de la aplicación. Esto garantiza que los servicios permanezcan desacoplados y que el sistema de colas pueda cambiar dinámicamente según sea necesario sin afectar a un gran número de servicios existentes.
Texto original en:El inicio de sesión del hipervínculo es visible.
Inglés original:El inicio de sesión del hipervínculo es visible.
|
Publicado en 3/5/2023 22:31:59
|
|
|
|
