Jul 22, 2021 ‧ 14 min estimados ‧ #amqp #queue #broker #oasis
Introducción al protocolo AMQP
Jul 22, 2021 ‧ 14 min estimados ‧ #amqp #queue #broker #oasis |
Contenido |
AMQP es un protocolo de mensajería avanzado que permite la comunicación entre servicios y aplicaciones. Lo que vas a ver en este documento son los siguientes temas:
AMQP (Advanced Message Queuing Protocol) es un protocolo abierto que funciona a nivel de capa de aplicación. Sus características definen la creación de mensajes, encolamiento, enrutamiento de los mensajes producidos y exactitud para entregar los mensajes a los consumidores.
Se compone de un broker de mensajería que internamente posee exchanges, donde se conectan los productores de mensajes, y las colas, que se vinculan a los exchanges a través de diferentes criterios. Los consumidores de los datos se conectan a las colas para extraer los mensajes que producen los publicadores. En esta figura podemos ver un diagrama de la arquitectura usando este protocolo.
El protocolo establece el comportamiento tanto del servidor de mensajería como de los clientes que se conectan al broker, de manera tal que las implementaciones de diferentes proveedores son interoperables. Con AMQP se pueden implementar aplicaciones multiplataforma utilizando agentes, bibliotecas y frameworks heterogéneos, todos independientes del proveedor. Esto se debe a que el formato del mensaje AMQP proporciona la unidad de trabajo necesaria para intercambiar información.
Es un protocolo orientado a crear un "cable" entre las aplicaciones conectadas. Incluye funcionalidad para entregar mensajes de manera fiable, representar los datos a través de diferentes formatos, flexibilidad para definir los datos, preparado para escalabilidad, y capacidad de definir varias topologías en un mismo sistema.
Estas características la vuelven un buen protocolo para IoT, ya que se puede implementar en dispositivos edge, cloud, en infraestructuras on-premise y que puede ser ejecutado a través de contenedores de software. |
El protocolo AMQP fue definido entre 2004-2006 por el banco JP Morgan Chase e iMatix Corporation, quienes también desarrollaron implementaciones en C/C++ y Java. Luego de crear la primera versión, la documentaron y la entregaron a un grupo de trabajo que incluía a varias empresas como Red Hat, Cisco e iMatix. Con el paso del tiempo se sumaron distintas entidades importantes que le dieron mayor seriedad aún al protocolo. En esta imagen podemos ver los logos de algunas empresas.
Un objetivo importante del diseño de AMQP era conseguir la creación de un protocolo que permita interoperar mediante mensajes, tanto dentro de la misma organización como entre organizaciones, mediante la creación de un mensaje con estándar abierto para realizar transacciones de negocio.
Si bien AMQP tiene sus orígenes en la industria financiera, es aplicable a una amplia gama de problemas de middleware, y tiene gran relevancia a la hora de diseñar aplicaciones multiplataforma y multiservicio.
Para realizar la comunicación AMQP define las siguientes entidades:
Las entidades utilizadas para la transferencia de mensajes entre aplicaciones son declaradas dentro de un canal, que garantiza la creación lógica de los elementos necesarios para la comunicación, como la creación de un exchange, una cola a la cual enviar mensajes y la vinculación entre las entidades. En esta figura podés ver un diagrama de comunicación de las entidades.
Veamos en detalle las entidades que definen el protocolo para la creación y consumo de mensajes mediante AMQP.
Los exchanges son las entidades a las que los productores envían los mensajes, y desde donde se envían los datos a las diferentes colas. Los mensajes se envían a una o más colas según el exchange y la clave de enrutamiento (routing_key) con que se publican. Para establecer una analogía con el envío de mails podemos definir que un mensaje se publica en una dirección como routing_key@exchange. Veamos los tipos de exchange que existen.
Topic exchange
El topic exchange es el más general. Cuando se publica un mensaje, el exchange determina qué colas lo recibirán comparando la routing_key del mensaje con el patrón de enrutamiento (binding) que vinculan la cola con el exchange.
Direct exchange
Un direct exchange envía mensajes a un receptor concreto y para ello los productores publican los mensajes en los exchanges con una routing_key específica. Por otro lado, los consumidores crean colas que se vinculan con el exchange mediante una vinculación (binding) que debe contener la misma routing_key. Si la routing_key con la que se publica el mensaje y la routing_key del binding son iguales, el mensaje se envía a la cola y luego es recibido por el consumidor. Es posible que una cola tenga varios routing_keys, y por lo tanto, conectarse a diferentes exchanges. Así mismo, varias colas pueden compartir una routing_key. En esos casos, el exchange multiplica el mensaje y lo envía a varios destinatarios.
Fanout exchange
El fanout exchange es muy simple. Las claves de enrutamiento no se tienen en cuenta, por lo que solo hay un punto final al que se publican todos los mensajes y se pueden vincular las colas. Todos los mensajes publicados en el exchange se transmitirán a todas las colas vinculadas al mismo.
Header exchange
El header exchange el header de un mensaje para enrutar mensajes hacia diferentes colas. A diferencia de los exchanges anteriores, con el header exchange se pueden lograr combinaciones de enrutamiento más complejas que solo utilizando una única routing_key.
Cada cola tiene su propio nombre, que la identifica entre las demás entidades. El nombre puede ser definido por un cliente o por el broker de manera automática. Una cola es un fragmento de memoria que puede estar asociada con almacenamiento no volátil o en la memoria RAM del sistema. La versión no volátil asegura que, incluso después de reiniciar el broker, la cola persiste. Sin embargo, no garantiza que los mensajes se guarden de forma permanente, ya que depende de la configuración de los mensajes cómo serán tratados.
El mecanismo intrínseco de AMQP permite enviar mensajes a las colas y garantizar su procesamiento, ya que tiene un mecanismo de ACK - acuse de recibo - con el que es posible confirmar la recepción y procesamiento adecuado del mismo. Si un mensaje que tiene asociado un ACK no es confirmado por un consumidor - ya sea porque se perdió la conexión, porque se produjo un fallo de la aplicación al procesar, o cualquier otro problema - el broker vuelve a encolar el mensaje nuevamente, de manera tal que pueda ser consumido y procesado nuevamente.
También es posible rechazar la aceptación de un mensaje - conocida como NACK - conscientemente. Esto puede ser útil cuando el procesamiento del mensaje no funciona. La respuesta del consumidor implica que el broker pueda borrar el mensaje o bien enviarlo a otras colas.
Los mensajes son publicados a un exchange y consisten en un header y un cuerpo o payload. El cuerpo del mensaje no es tomado en cuenta por el broker, ya que contiene la información que intercambian las aplicaciones. El broker sólo toma los datos del header, que contiene estas propiedades:
En esta imagen podemos ver un formato genérico de mensaje AMQP donde se ven sus datos asociados.
Una vinculación (binding) es una relación entre una cola y un exchange, que especifica cómo fluyen los mensajes. Para ello, una vez que están creados un exchange y una cola, es necesario indicarle al broker que vincule estas dos entidades mediante un binding. Dentro de las propiedades del binding se debe especificar una routing_key, que, según el tipo de exchange, realizará el enrutamiento adecuado a las colas.
Un exchange entregará como máximo una copia de un mensaje a una cola si hay correspondencia entre las propiedades del mensaje y las propiedades con la que se realizó el binding. Para cada exchange hay interpretaciones específicas que vemos a continuación.
El concepto de vincular colas con exchanges tiene propiedades poderosas, ya que mantiene las aplicaciones que producen aisladas de las aplicaciones que consumen. Luego, se pueden realizar las configuraciones dentro del broker que permiten enrutar los mensajes adecuadamente sin necesidad de cambiar las aplicaciones productoras o consumidoras.
Es posible realizar configuraciones para vincular una única cola a múltiples exchanges, o varias colas a un mismo exchange. Esto en la práctica resulta muy flexible y permite implementarlo a nivel de protocolo y no de aplicación, liberando así de parte de desarrollo de código.
Como vimos, el protocolo fue definido entre 2004-2006 por un conjunto de compañías asociadas al sector financiero, y que luego fue sumando diferentes entidades. A continuación podemos ver la cronología de las versiones publicadas hasta el momento.:
AMQP 1.0 vs. 0-9-1
En la actualidad existen dos versiones completamente independientes de AMQP. El grupo OASIS fue el encargado de desarrollar y definir la versión 1.0 más reciente del protocolo. Así mismo, RabbitMQ - un broker AMQP muy completo y utilizado - implementa la versión 0-9-1. Ambas versiones no son compatibles entre sí, por lo que es necesario tener en cuenta este detalle antes de implementar alguna de las dos versiones del protocolo.
Para el protocolo AMQP existen diferentes implementaciones que están adaptadas a versiones específicas, como así también a entornos específicos broker o clientes. A continuación podés ver las implementaciones públicas de AMQP.
AMQP es un protocolo muy completo, y resulta muy conveniente su utilización en proyectos con arquitecturas distribuidas, para microservicios, y para intercambiar información entre distintas aplicaciones - tanto internas como externas - a través de un lenguaje común que es un mensaje AMQP. Para hacer un resumen, en este artículo vimos los siguientes temas.
Este material es distribuido bajo licencia Creative Commons BY-SA 4.0. Podés encontrar detalles sobre el uso del material en este link.
