Abrir o menú principal

Patrón de publicación-subscrición

En arquitectura de software, publicar–subscribir é un patrón de mensaxería onde os remitentes de mensaxes, chamados publicadores, non programan as mensaxes para envialas directamente a receptores específicos, chamados subscritores; no seu lugar categorizan as mensaxes publicadas en clases sen saber que subscritores, se os hai, poden existir. De maneira similar, os subscritores expresan interese nunha ou máis clases e só reciben mensaxes que son de interese, sen saber que editores, se os hai, existen.

Publicación: a subscrición é un irmán do paradigma cola de mensaxes, e xeralmente é unha parte dun sistema máis grande middleware orientado a mensaxes. A maioría dos sistemas de mensaxería admiten os modelos de publicación/subscrición e cola de mensaxes na súa API, por exemplo Java Message Service (JMS).

Este patrón proporciona unha maior rede de escalabilidade e unha topoloxía de rede máis dinámica, coa consecuente diminución da flexibilidade para modificar o editor e a estrutura dos datos publicados.

Filtrado de mensaxesEditar

No modelo de publicación-subscrición, os subscritores normalmente reciben só un subconxunto do total de mensaxes publicadas. O proceso de selección de mensaxes para a recepción e o procesamento denomínase "filtrado". Hai dúas formas comúns de filtrado: baseadas en temas e baseadas en contido.

Nun sistema baseado en temas, as mensaxes publícanse en "temas" ou denomínanse canles lóxicas. Os subscritores nun sistema baseado en temas recibirán todas as mensaxes publicadas sobre os temas aos que se subscriben, e todos os subscritores dun tema recibirán as mesmas mensaxes. O editor é responsable de definir as clases de mensaxes ás que se poden subscribir os subscritores.

Nun sistema baseado en contido, as mensaxes só se envían a un subscritor se os atributos ou o contido desas mensaxes coinciden coas restricións definidas polo subscritor. O subscritor é responsable de clasificar as mensaxes.

Algúns sistemas admiten un híbrido dos dous; os editores publican mensaxes sobre un tema mentres os subscritores rexistran subscricións baseadas en contido a un ou máis temas.

TopoloxíasEditar

En moitos sistemas pub/sub, os editores publican mensaxes a un intermediario, o intermediario de mensaxes ou o bus de eventos, e os subscritores rexistran as subscricións a ese intermediario, o que permite que o intermediario realice o filtrado. O axente normalmente realiza unha función almacenar e reenviar para enrutar as mensaxes dos editores aos subscritores. Ademais, o intermediario pode priorizar as mensaxes nunha cola antes do encamiñamento.

Os subscritores poden rexistrarse para mensaxes específicas no momento da compilación, o tempo de inicialización ou o tempo de execución. Nos sistemas GUI, os subscritores poden codificarse para manexar os comandos do usuario (por exemplo, facer clic nun botón), o que corresponde ao rexistro do tempo de construción. Algúns marcos e produtos de software utilizan XML arquivos de configuración para rexistrar subscritores. Estes arquivos de configuración lense no momento da inicialización. A alternativa máis sofisticada é cando os subscritores se poden agregar ou eliminar en tempo de execución. Este último enfoque utilízase, por exemplo, en disparador de base de datos, lista de correo, e RSS.

O middleware Data Distribution Service (DDS) non utiliza un intermediario no medio. No seu lugar, cada editor e subscritor no sistema pub/sub comparte metadatos entre si a través de IP multicast. O editor e os subscritores almacenan en caché esta información localmente e enrutan as mensaxes en función do descubrimento mutuo no coñecemento compartido.

HistoriaEditar

Un dos primeiros sistemas de pub/subs descritos publicamente foi o subsistema de "noticias" de Isis Toolkit, descrito na conferencia de 1987 Association for Computing Machinery (ACM) Symposium on Operating Systems Principles ( SOSP '87), nun documento "Exploiting Virtual Synchrony in Distributed Systems. 123–138".[1]

VantaxesEditar

Axuste soltoEditar

Os editores están axustados libremente aos subscritores, e nin sequera necesitan saber da súa existencia. Como o tema é o tema central, os editores e subscritores poden ignorar a topoloxía do sistema. Cada un pode continuar operando segundo o normal independentemente do outro. No tradicional cliente-servidor paradigma, o cliente non pode publicar mensaxes no servidor mentres o proceso do servidor non se está executando, nin o servidor pode recibir mensaxes a menos que o cliente estea a executarse. Moitos sistemas de pub/subs desacoplan non só as localizacións dos editores e subscritores, senón que tamén os disocian temporalmente. Unha estratexia común utilizada polos analistas de middleware con estes sistemas de pub/subs é eliminar a un editor para permitir que o subscritor traballe a través da acumulación (unha forma de limitación de ancho de banda).

EscalabilidadeEditar

Pub/sub ofrece a oportunidade dunha mellor escalabilidade que o cliente-servidor tradicional, a través de operacións paralelas, almacenamento en caché de mensaxes, encamiñamento baseado en árbore ou en rede etc. Con todo, en certos tipos de gran volume estreitamente axustado ás contornas empresariais, a medida que os sistemas se amplían para converterse en centros de datos con miles de servidores que comparten a infraestrutura de pub/sub, os sistemas de provedores actuais a miúdo perden este beneficio. A escalabilidade para produtos de pub/sub baixo unha gran carga nestes contextos é un desafío de investigación.
Doutra banda, fóra da contorna empresarial, o paradigma pub/sub demostrou a súa escalabilidade a volumes máis aló dos dun só centro de datos, proporcionando mensaxería distribuída a través de Internet a través de protocolos de sindicación web como RSS e Atom. Estes protocolos de sindicación aceptan maior latencia e falta de garantías de entrega a cambio da capacidade de mesmo un servidor web de gama baixa para sindicar mensaxes a (potencialmente) millóns de nodos de subscritores separados.

DesvantaxesEditar

Os problemas máis serios cos sistemas pub/sub son un efecto secundario da súa principal vantaxe: o desacoplamento do editor do subscritor.

Problemas de entrega de mensaxesEditar

Un sistema pub/sub debe deseñarse coidadosamente para poder proporcionar propiedades de sistema máis sólidas que unha aplicación en particular poida requirir, como unha entrega asegurada.

  • O axente nun sistema pub/sub pode ser deseñado para entregar mensaxes durante un tempo específico, pero logo deixa de tentar realizar a entrega, xa sexa que recibise a confirmación da recepción exitosa da mensaxe por parte de todos os subscritores. Un sistema pub/sub deseñado desta maneira non pode garantir a entrega de mensaxes a ningunha aplicación que poida requirir dita entrega asegurada. O axuste máis estrito dos deseños de tal editor e parella de subscritores debe aplicarse fóra da arquitectura pub/sub para lograr a devandita entrega asegurada (por exemplo, ao solicitar ao subscritor que publique mensaxes de recibo).
  • Un editor nun sistema 'pub/sub' pode asumir que un subscritor está a escoitar, cando en realidade non o está. Unha fábrica pode utilizar un sistema pub/sub onde o equipo pode publicar problemas ou fallas nun subscritor que mostra e rexistra eses problemas. Se o rexistrador falla (bloquéase), os editores de problemas do equipo non recibirán necesariamente un aviso de falla do rexistrador, e ningún equipo do sistema pub/sub mostrará nin rexistrará mensaxes de erro. Este é tamén un desafío de deseño para arquitecturas de mensaxería alternativas, como un sistema cliente / servidor. Nun sistema cliente / servidor, cando falla un rexistrador de erros, o sistema recibirá unha indicación de falla do rexistrador de erros (servidor). Con todo, o sistema cliente / servidor terá que lidar con esa falla tendo servidores de rexistro redundantes en liña ou xerando dinamicamente servidores de rexistro de respaldo. Isto agrega complexidade aos deseños de cliente e servidor, así como á arquitectura cliente / servidor no seu conxunto. Con todo, nun sistema pub/sub, os subscritores de rexistro redundantes que son duplicados exactos do rexistrador existente pódense agregar ao sistema para aumentar a fiabilidade do rexistro sen ningún impacto en ningún outro equipo do sistema. Nun sistema pub/sub, a función de rexistro de mensaxes de erro asegurado pódese agregar de maneira incremental, logo de implementar a funcionalidade básica do rexistro de mensaxes de problemas do equipo.

O patrón pub/sub adáptase ben a redes pequenas cun pequeno número de nodos de publicador e subscritor e un volume de mensaxes baixo. Con todo, a medida que aumenta a cantidade de nodos e mensaxes, aumenta a probabilidade de inestabilidades, o que limita a escalabilidade máxima dunha rede pub/sub. Exemplos de inestabilidades de rendemento a gran escala inclúen:

  • Sobrecargas de carga: períodos en que as solicitudes dos subscritores saturan o rendemento da rede seguido de períodos de baixo volume de mensaxes (ancho de banda da rede subutilizado)
  • Retardacións: a medida que máis e máis aplicacións usan o sistema (mesmo se se comunican en canles pub/sub separados), o fluxo do volume de mensaxes a un subscritor individual reducirase.

Para os sistemas pub/sub que usan intermediarios (servidores), o argumento para que un intermediario envíe mensaxes a un subscritor é en banda, e pode estar suxeito a problemas de seguridade. Poderíase enganar aos corredores para que envíen notificacións ao cliente incorrecto, ampliando as solicitudes de denegación de servizo contra o cliente. Os propios corredores poderían estar sobrecargados xa que asignan recursos para rastrexar as subscricións creadas.

Mesmo con sistemas que non dependen de corredores, un subscritor podería recibir datos que non está autorizado a recibir. Un editor non autorizado pode introducir mensaxes incorrectas ou daniñas no sistema pub/sub. Isto é especialmente certo cos sistemas que usan broadcast ou multicast nas súas mensaxes. Cifrado (por exemplo, Seguridade da capa de transporte (SSL/TLS)) pode evitar o acceso non autorizado, pero non pode evitar que os editores autorizados introduzan mensaxes daniñas. As arquitecturas que non sexan pub/sub, como os sistemas cliente / servidor, tamén son vulnerables aos remitentes de mensaxes autorizadas que se comportan de forma maliciosa.

ReferenciasEditar

  1. Birman, K. and Joseph, T. "Exploiting virtual synchrony in distributed systems" in Proceedings of the eleventh ACM Symposium on Operating systems principles (SOSP '87), 1987. pp. 123–138.