En arquitectura de software , el patrón de publicación-suscripción ( pub/sub ) es un patrón de mensajería en el que los emisores de mensajes, llamados publicadores , clasifican los mensajes en clases (o temas ) y los envían sin necesidad de saber qué componentes los recibirán. Los receptores de mensajes, llamados suscriptores , expresan interés en una o más clases y solo reciben mensajes de esas clases, sin necesidad de conocer la identidad de los publicadores.
Este patrón desacopla los componentes que producen mensajes de aquellos que los consumen, y admite la comunicación asíncrona de muchos a muchos. El modelo de publicación-suscripción se suele contrastar con los modelos de mensajería basados en colas de mensajes y de punto a punto , donde los productores envían mensajes directamente a los consumidores.
El modelo de publicación-suscripción es similar al paradigma de colas de mensajes y suele formar parte de sistemas de middleware orientados a mensajes de mayor envergadura . Muchos marcos y protocolos de mensajería modernos, como Java Message Service (JMS), Apache Kafka y MQTT , admiten tanto el modelo de publicación-suscripción como el basado en colas.
Este patrón proporciona una mayor escalabilidad de red y admite topologías más dinámicas , pero puede dificultar la modificación de la lógica del publicador o la estructura de los datos publicados. En comparación con patrones síncronos como RPC y la mensajería punto a punto, el modelo de publicación-suscripción ofrece el mayor grado de desacoplamiento entre los componentes arquitectónicos. Sin embargo, también puede generar acoplamiento semántico o de formato entre publicadores y suscriptores, lo que puede provocar que los sistemas se enreden o se vuelvan frágiles con el tiempo. [ 1 ]
Filtrado de mensajes
En los sistemas de publicación-suscripción, los suscriptores suelen recibir solo un subconjunto de mensajes. El proceso de selección de mensajes relevantes se denomina filtrado y puede implementarse de varias maneras:
- Filtrado basado en temas : Los mensajes se publican en temas o canales con nombre . Los suscriptores se registran para recibir mensajes sobre temas específicos y reciben todos los mensajes publicados en ellos.
- Filtrado basado en contenido : Los suscriptores definen restricciones basadas en los atributos o el contenido de los mensajes. Los mensajes se entregan solo si coinciden con los criterios del suscriptor.
- Sistemas híbridos : Algunas implementaciones combinan el filtrado basado en temas y en contenido. Los mensajes se clasifican por tema y los suscriptores aplican filtros basados en contenido a los mensajes dentro de esos temas.
Topologías
En la mayoría de los sistemas pub/sub, los publicadores y los suscriptores se comunican a través de un intermediario central, como un gestor de mensajes o un bus de eventos. El gestor recibe los mensajes de los publicadores y los reenvía a los suscriptores correspondientes, pudiendo realizar opcionalmente almacenamiento y reenvío , colas de prioridad u otra lógica de enrutamiento.
El registro de suscriptores puede producirse en diferentes momentos:
- Tiempo de compilación : Los suscriptores están programados para manejar mensajes o eventos específicos (por ejemplo, controladores de eventos de la interfaz gráfica de usuario).
- Tiempo de inicialización : Las suscripciones se definen en archivos de configuración XML o metadatos.
- Tiempo de ejecución : Las suscripciones se pueden agregar o eliminar dinámicamente (por ejemplo, mediante activadores de bases de datos o lectores RSS ).
Algunos sistemas pub/sub utilizan arquitecturas sin intermediarios , en las que publicadores y suscriptores se descubren mutuamente e intercambian mensajes directamente. Por ejemplo, el middleware del Servicio de Distribución de Datos (DDS) utiliza multidifusión IP y compartición de metadatos para establecer rutas de comunicación. Los sistemas sin intermediarios requieren la construcción de redes superpuestas, a menudo utilizando topologías de mundo pequeño para permitir un enrutamiento eficiente.
Jon Kleinberg demostró que el enrutamiento descentralizado eficiente requiere topologías de mundo pequeño navegables , que se emplean en sistemas pub/sub federados o peer-to-peer . [ 2 ] Las redes pub/sub conscientes de la localidad utilizan enlaces de baja latencia para reducir el tiempo de propagación de mensajes. [ 3 ]
Historia
Uno de los primeros sistemas pub/sub descritos públicamente fue el subsistema de "noticias" del Isis Toolkit , presentado en el Simposio ACM de 1987 sobre Principios de Sistemas Operativos (SOSP '87). [ 4 ]
Aunque el patrón de publicación-suscripción ahora se distingue típicamente del patrón de observador debido a su énfasis en el desacoplamiento y la comunicación distribuida, en el uso inicial en la literatura y los sistemas a veces usaban los términos indistintamente, especialmente en el contexto del manejo de eventos dentro del proceso o marcos de GUI. [ 5 ] A medida que los sistemas distribuidos se hicieron más comunes, el modelo de publicación-suscripción evolucionó para enfatizar la mensajería asíncrona y la comunicación mediada por un intermediario, diferenciándolo del patrón de observador, que está más estrechamente acoplado.
Ventajas
Acoplamiento suelto
Los publicadores están débilmente acoplados a los suscriptores y ni siquiera necesitan saber de su existencia. Al ser el tema el foco, se permite que publicadores y suscriptores ignoren la topología del sistema. Cada uno puede seguir operando con normalidad independientemente del otro. En el paradigma tradicional de acoplamiento estrecho cliente-servidor , el cliente no puede enviar mensajes al servidor mientras el proceso del servidor no se esté ejecutando, ni el servidor puede recibir mensajes a menos que el cliente esté en ejecución. Muchos sistemas pub/sub desacoplan no solo la ubicación de los publicadores y suscriptores, sino también temporalmente. Una estrategia común utilizada por los analistas de middleware con dichos sistemas pub/sub es desactivar un publicador para permitir que el suscriptor procese la cola de mensajes (una forma de limitación de ancho de banda ).
Escalabilidad
El modelo pub/sub ofrece la oportunidad de lograr una mayor escalabilidad que el modelo cliente-servidor tradicional, mediante el funcionamiento en paralelo, el almacenamiento en caché de mensajes, el enrutamiento basado en árboles o en red, etc. Sin embargo, en ciertos tipos de entornos empresariales de alto volumen y estrechamente acoplados, a medida que los sistemas se escalan hasta convertirse en centros de datos con miles de servidores que comparten la infraestructura pub/sub, los sistemas de los proveedores actuales a menudo pierden esta ventaja; la escalabilidad de los productos pub/sub bajo alta carga en estos contextos representa un desafío de investigación.
Fuera del entorno empresarial, por otro lado, el paradigma pub/sub ha demostrado su escalabilidad a volúmenes muy superiores a los de un único centro de datos, proporcionando mensajería distribuida a nivel de Internet mediante protocolos de sindicación web como RSS y Atom . Estos protocolos de sindicación aceptan una mayor latencia y la falta de garantías de entrega a cambio de la capacidad de incluso un servidor web de gama baja para sindicar mensajes a (potencialmente) millones de nodos suscriptores independientes.
Problemas de entrega de mensajes
En un sistema de publicación/suscripción (pub/sub), los suscriptores redundantes pueden garantizar la entrega de mensajes con una complejidad adicional mínima. Por ejemplo, una fábrica puede utilizar un sistema pub/sub donde los equipos publican problemas o fallos a un suscriptor que los muestra y registra. Si el registrador falla (se bloquea), los equipos que publican problemas no necesariamente recibirán una notificación del fallo, y los mensajes de error no se mostrarán ni registrarán en ningún equipo del sistema pub/sub. En un sistema cliente/servidor, cuando falla un registrador de errores, el sistema recibe una indicación del fallo del registrador (servidor). Sin embargo, el sistema cliente/servidor debe gestionar dicho fallo mediante servidores de registro redundantes en línea o mediante la creación dinámica de servidores de registro de reserva. Esto añade complejidad al diseño del cliente y del servidor, así como a la arquitectura cliente/servidor en su conjunto. En un sistema pub/sub, se pueden añadir suscriptores de registro redundantes que sean duplicados exactos del registrador existente para aumentar la fiabilidad del registro sin afectar a ningún otro equipo del sistema. La función de registro garantizado de mensajes de error también se puede añadir de forma incremental, tras implementar la funcionalidad básica de registro de mensajes de problemas del equipo.
Desventajas
Los problemas más graves de los sistemas pub/sub son un efecto secundario de su principal ventaja: la separación entre el publicador y el suscriptor.
Problemas de entrega de mensajes
Un sistema de publicación/suscripción debe diseñarse cuidadosamente para poder proporcionar propiedades de sistema más robustas que una aplicación particular pueda requerir, como la entrega garantizada.
- En un sistema de publicación/suscripción, el intermediario puede diseñarse para entregar mensajes durante un tiempo determinado, pero luego dejar de intentarlo, independientemente de si ha recibido o no la confirmación de recepción por parte de todos los suscriptores. Un sistema de publicación/suscripción diseñado de esta manera no puede garantizar la entrega de mensajes a ninguna aplicación que requiera dicha garantía. Para lograr esta garantía de entrega, es necesario reforzar el acoplamiento entre el diseño del publicador y el suscriptor fuera de la arquitectura de publicación/suscripción (por ejemplo, exigiendo al suscriptor que publique mensajes de confirmación).
- En un sistema de publicación/suscripción, un editor puede suponer que un suscriptor está escuchando, cuando en realidad no lo está.
El modelo pub/sub funciona bien en redes pequeñas con un número reducido de nodos publicadores y suscriptores, y un bajo volumen de mensajes. Sin embargo, a medida que aumenta el número de nodos y mensajes, se incrementa la probabilidad de inestabilidades, lo que limita la escalabilidad máxima de una red pub/sub. Algunos ejemplos de inestabilidades en el rendimiento a gran escala incluyen:
- Picos de carga: períodos en los que las solicitudes de los suscriptores saturan el rendimiento de la red, seguidos de períodos de bajo volumen de mensajes (ancho de banda de red subutilizado).
- Ralentizaciones: a medida que más y más aplicaciones utilizan el sistema (incluso si se comunican en canales pub/sub separados), el flujo de volumen de mensajes a un suscriptor individual se ralentizará.
En los sistemas de publicación/suscripción que utilizan intermediarios (servidores), el envío de mensajes a un suscriptor por parte de un intermediario es interno y puede presentar problemas de seguridad. Los intermediarios podrían ser engañados y enviar notificaciones al cliente equivocado, lo que amplificaría las solicitudes de denegación de servicio contra dicho cliente. Además, los propios intermediarios podrían sobrecargarse al asignar recursos para gestionar las suscripciones creadas.
Incluso en sistemas que no dependen de intermediarios, un suscriptor podría recibir datos a los que no está autorizado. Un publicador no autorizado podría introducir mensajes incorrectos o dañinos en el sistema de publicación/suscripción. Esto es especialmente cierto en sistemas que transmiten sus mensajes mediante difusión o multidifusión . El cifrado (por ejemplo, Seguridad de la Capa de Transporte (SSL/TLS)) puede impedir el acceso no autorizado, pero no puede evitar que los publicadores autorizados introduzcan mensajes dañinos. Otras arquitecturas, como los sistemas cliente/servidor, también son vulnerables a remitentes de mensajes autorizados que actúan con malas intenciones.
Véase también
- Atom , otro protocolo de sindicación web altamente escalable
- Servicio de Distribución de Datos (DDS)
- Programación basada en eventos
- Arquitectura de alto nivel
- Protocolo de gestión de grupos de Internet (IGMP)
- intermediarios de mensajes
- Cola de mensajes
- Patrón del observador
- Problema productor-consumidor
- Tecnología de empuje [ 2 ]
- RSS , un protocolo de sindicación web altamente escalable
- Usenet
- WebSub , una implementación de pub/sub
Referencias
- ↑ Hohpe, Gregor (2003). Patrones de integración empresarial: diseño, construcción e implementación de soluciones de mensajería . Addison-Wesley Professional. ISBN 978-0321200686.
- 1 2 Chen, Chen; Tock, Yoav; Girdzijauskas, Sarunas (2018). "BeaConvey" . Actas de la 12.ª Conferencia Internacional ACM sobre Sistemas Distribuidos y Basados en Eventos . Hamilton, Nueva Zelanda: ACM Press. págs. 64–75 . doi : 10.1145/3210284.3210287 . ISBN 9781450357821. S2CID 43929719 .
- ↑ Rahimian, Fatemeh; Le Nguyen Huu, Thinh; Girdzijauskas, Sarunas (2012), "Conciencia de la localidad en una red de publicación/suscripción peer-to-peer", en Göschka, Karl Michael; Haridi, Seif (eds.), Aplicaciones distribuidas y sistemas interoperables , vol. 7272, Springer Berlin Heidelberg, pp. 45–58 , doi : 10.1007/978-3-642-30823-9_4 , ISBN 9783642308222
- ↑ Birman, K.; Joseph, T. (1987). «Aprovechamiento de la sincronía virtual en sistemas distribuidos». Actas del Undécimo Simposio ACM sobre Principios de Sistemas Operativos - SOSP '87 . págs. 123–138 . doi : 10.1145/41457.37515 . ISBN 089791242X. S2CID 7739589 .
- ↑ La experiencia de programación en Windows , Charles Petzold , 10 de noviembre de 1992, PC Magazine ( Google Books )
- Patrón arquitectónico (informática)
- Arquitectura de computación distribuida
- Middleware orientado a mensajes
- patrones de diseño de software