Este blog es parte de la serie donde discutimos 101 conceptos de Ground Zero para una audiencia que tiene un conocimiento inicial limitado. Este artículo pertenece a la serie de nivel intermedio, ya que implica la comprensión de los conceptos básicos de los principios de diseño de mensajería, principalmente el caso de uso de la arquitectura basada en editor-suscriptor utilizada en la comunicación asíncrona.

Algunos de los blogs anteriores de la Serie 101 son los siguientes:

API 101
Comunicación asíncrona 101 Bases de datos 101 Diseño de bases de datos 101

¿Qué es Pub-Sub?

En el caso de la arquitectura distribuida, para desacoplar la fuente de generación de eventos de la fuente de recepción de eventos y para desbloquear los sistemas de extremo a extremo que se ejecutan a escala, se diseñó el patrón de mensajería editor-suscriptor . El remitente, también denominado editor, transmite los mensajes como eventos en un formato de mensaje predefinido a un intermediario de capa intermedia ( Kafka, EventHub, Service Bus, etc. ) al que pueden escuchar suscriptores individuales o múltiples según la política de suscripción elegida.

El modelo Pub-Sub es compatible con los casos de uso Unicast y Broadcast , a diferencia de un patrón de cola de mensajes que solo admite casos de uso basados ​​en Unicast .

Términos comunes

• Publicador : clientes que generan el mensaje y lo ponen en cola en la infraestructura de mensajería.
• Suscriptor : clientes que reciben el mensaje y lo eliminan de la cola en la infraestructura de mensajería.
• Message Broker: la capa intermedia que maneja las solicitudes de publicación y lectura de mensajes de diversos clientes. Mantiene los datos replicados dentro de un clúster en forma de temas entre réplicas y particiones.
• Tema: categorías lógicas únicas dentro del intermediario que sirve mensajes/eventos relacionados con una aplicación/caso de uso comercial en particular.
• Partición: los temas se pueden dividir en unidades lógicas llamadas particiones para permitir el procesamiento paralelo de mensajes. Cada partición contiene registros únicos identificados por compensaciones.
• QOS: un acuerdo entre el editor y el suscriptor que indica cuántas veces se debe entregar un mensaje real: al menos una vez, como máximo una vez, exactamente una vez.

El modelo Publisher-Subscriber se utiliza para casos de uso de aplicaciones que requieren un gran volumen de eventos generados y la garantía inmediata de los mensajes no es de suma importancia. Las aplicaciones que caen en los cubos dados son buenas candidatas para este patrón.

• Las aplicaciones en las que no se necesita una consistencia fuerte para los eventos entre el remitente y el receptor y la ordenación de datos/eventos no tiene un impacto comercial. Este es un patrón de diseño eventualmente consistente.
• Aplicaciones donde la respuesta en tiempo real de los suscriptores no tiene un impacto en el flujo comercial real.
• Los suscriptores que pertenecen a diferentes temas son independientes y pueden tener diferentes métricas de disponibilidad y tiempo de actividad.

Para escalar un editor-suscriptor a los SLA correctos de confiabilidad y disponibilidad para atender los casos de uso comercial extremo-2-extremo, se recomiendan las siguientes consideraciones de diseño.

• Suscriptores idempotentes: según el conjunto de QOS general y en casos de fallas, varios suscriptores pueden enviar el mismo mensaje más de una vez. Por lo tanto, los suscriptores tienen la obligación de mantener la idempotencia , es decir, no procesar mensajes repetidos más de una vez y tener manejo de mensajes duplicados.
• Ordenación y prioridad de mensajes: los mensajes se pueden procesar en una línea de tiempo diferente a la de su creación, dependiendo de múltiples factores, como particiones, grupos de consumidores. Por lo tanto, cada mensaje debe ser independiente en el flujo general de negocios/aplicaciones.
• Cola de mensajes fallidos: según la configuración de TTL en los mensajes y la disponibilidad/manejo de errores de los consumidores, algunos de los mensajes pueden terminar en la cola de mensajes fallidos . Los editores deben volver a procesar estos mensajes para evitar cualquier impacto comercial.
• Seguridad: los diferentes temas en los intermediarios de mensajes deben ser políticas de autorización independientes para garantizar que los clientes no intercambien accidentalmente información de un tema diferente. Los certificados de cliente y TLS mutuo son algunas buenas políticas de seguridad.

Resumen

Pub-Sub es un patrón de diseño sencillo y común que se utiliza en los sistemas distribuidos basados ​​en Aysnc, ya que ayuda a escalar para millones de clientes sin necesidad de mantener una semántica de entrega compleja. Sin embargo, para casos de uso complejos en los que los mensajes/eventos deben tener patrones de enrutamiento dinámicos, se pueden utilizar otros patrones de diseño, como prioridad basada en cola, solicitud-respuesta, nivelación de carga basada en cola, etc. Intentaremos cubrirlos en los próximos 101 blogs sobre el aprendizaje de la arquitectura funcional.

Para recibir comentarios, envíe un mensaje a amit[dot]894[at]gmail[dot]com o comuníquese con cualquiera de los enlaces en https://about.me/amit_raj .