Conectores cola, repositorio y pub/sub

Curso Profesional de Arquitectura de Software

Contenido del curso

Introducción al curso

1
Curso Profesional de Arquitectura de Software
02:36 min

Atributos de calidad

Patrones de arquitectura

Diseño de una arquitectura

Modelado y documentación de arquitectura

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:003:52

Conectores cola, repositorio y pub/sub

Curso Profesional de Arquitectura de Software

Clase 29 de 43

Clase 29 / 43

Recursos

Elegir el conector correcto acelera el desarrollo y evita cuellos de botella. Aquí se explica, con ejemplos claros, cómo funcionan los conectores de tipo cola, repositorio o pizarra, y publicar/suscribir. Se destacan conceptos como productor, consumidor, transaccionalidad, consistencia y desacoplar componentes, tal como se describe en el material.

¿Por qué usar un conector de tipo cola?

Cuando el productor genera mensajes más rápido que el consumidor, una cola permite compatibilizar velocidades. Se encolan mensajes para que el consumidor los procese a su ritmo, sin perder datos ni bloquear al productor.

Encolar es agendar procesamiento. Cada mensaje espera hasta que el consumidor esté listo.
Evita saturación del consumidor. Procesa según su capacidad real.
Aísla picos de carga. El productor sigue trabajando sin fricción.

¿Qué problema resuelve?

Diferencias de velocidad entre componentes.
Costos de comunicación o ejecución más altos que la lectura en memoria.

¿Ejemplo práctico?

Se lee un fichero a memoria línea por línea.
Por cada línea, se requiere una comunicación de red o una ejecución compleja en otro componente.
Solución: se agenda cada línea en una cola de trabajo y otro componente la consume cuando puede.

¿Qué habilidades se ejercitan?

Diseñar flujos con productor/consumidor desacoplados.
Priorizar agendamiento y procesamiento asíncrono.
Identificar cuándo una cola optimiza rendimiento.

¿Cómo funciona un conector repositorio o pizarra?

Este conector lee y escribe en un componente que actúa como base de datos. Prioriza la integridad del dato y cómo impacta el estado del sistema. Ofrece transaccionalidad y consistencia en las operaciones.

Transacciones atómicas. Todo o nada en una misma transacción.
Estado consistente. Al finalizar la escritura, el sistema queda actualizado.
Lecturas confiables. La lectura puede ser consistente respecto al momento de inicio.

¿Qué garantiza?

Un driver de conexión (el conector) asegura que múltiples escrituras en una misma transacción sean atómicas y consistentes.
Al terminar, “ha escrito todo”, y el estado del sistema refleja los cambios.

¿Cómo se lee y escribe de forma consistente?

Es posible leer en medio de una transacción.
Se puede escribir, leer y volver a escribir dentro de una misma comunicación con la base de datos, manteniendo la coherencia.

¿Qué habilidades se ejercitan?

Modelar operaciones con transaccionalidad.
Usar consistencia para lecturas y escrituras seguras.
Evaluar cuándo un conector repositorio/pizarra es la vía adecuada.

¿Qué resuelve un conector publicar/suscribir en microservicios?

El conector de publicar/suscribir (también pub/sub) distribuye eventos desde un componente publicador hacia componentes suscriptores, sin que tengan que conocerse entre sí. Así se logra desacoplar y escalar sistemas distribuidos.

El conector recibe eventos del publicador.
El suscriptor indica qué eventos le interesan.
Cuando ocurre un evento, el conector lo entrega a los suscriptores relevantes.

¿Cómo desacopla componentes?

Ningún componente depende de la identidad o detalles del otro.
Los cambios en un componente no obligan a cambiar el resto.
Ideal para aplicaciones distribuidas y microservicios.

¿Qué casos ilustra el ejemplo?

Un componente con una aplicación web o una API publica eventos.
Otros componentes, como reportes o notificaciones a usuarios, reaccionan a esos eventos.
Resultado: se mantienen independientes, sin acoplarse a la fuente del evento.

¿Qué habilidades se ejercitan?

Diseñar flujos orientados a eventos.
Definir suscripciones por interés.
Mantener independencia entre publicadores y suscriptores.

¿Quieres profundizar en un caso concreto? Cuéntame tu escenario: volumen de mensajes, tipo de transacciones o eventos que necesitas distribuir.

William Schnaider Torres Bermon

Hace 2 años

1. Conectores de tipo Cola (Queue):

Profundización en beneficios:
- Desacoplamiento: Las colas desacoplan productores y consumidores, lo que mejora la resiliencia del sistema. Si un consumidor falla, los productores pueden seguir enviando mensajes sin interrupción.
- Escalabilidad: Facilitan la escalabilidad horizontal, ya que puedes añadir más consumidores para procesar la cola cuando la carga aumenta.
- Control de flujo: Permiten regular el flujo de datos, evitando que un productor abrumador sature a los consumidores.
- Asincronía: Promueven el procesamiento asíncrono, mejorando la respuesta del sistema al usuario.
Tecnologías comunes:
- Apache Kafka: Ideal para flujos de datos de alto volumen y en tiempo real.
- RabbitMQ: Un bróker de mensajes versátil que admite varios patrones de enrutamiento.
- Amazon SQS (Simple Queue Service): Un servicio de colas totalmente gestionado en la nube de AWS.
Consideraciones de diseño:
- Garantías de entrega: Debes decidir si necesitas "al menos una vez", "como máximo una vez" o "exactamente una vez" la entrega de mensajes.
- Orden de los mensajes: Algunas colas garantizan el orden de los mensajes, mientras que otras no.
- Persistencia: Determina si los mensajes deben persistir en disco o pueden almacenarse solo en memoria.

2. Conectores de tipo Repositorio o Pizarra (Repository/Blackboard):

Detalles adicionales:
- Estos conectores son cruciales para la gestión del estado compartido en aplicaciones complejas.
- El patrón de "pizarra" se utiliza en sistemas de inteligencia artificial y expertos, donde múltiples agentes colaboran para resolver un problema.
- Aparte de las bases de datos relacionales, los sistemas de caché distribuidos (como Redis o Memcached) también pueden actuar como repositorios.
Aspectos clave:
- Control de concurrencia: Es vital implementar mecanismos para evitar conflictos cuando múltiples componentes acceden y modifican los datos simultáneamente.
- Esquemas de datos: La definición clara de esquemas de datos garantiza la coherencia y facilita la interoperabilidad entre componentes.
- Seguridad: Deben aplicarse medidas de seguridad adecuadas para proteger los datos almacenados.
Casos de uso:
- Sistemas de gestión de contenido (CMS).
- Aplicaciones de comercio electrónico.
- Sistemas de procesamiento de transacciones.

3. Conectores de tipo Pub/Sub (Publish/Subscribe):

Expandiendo la funcionalidad:
- Facilitan la implementación de patrones de "difusión" (broadcast) y "multidifusión" (multicast).
- Permiten la creación de arquitecturas basadas en eventos, donde los componentes reaccionan a los cambios en el sistema.
- Ayudan a crear sistemas mas flexibles, dado que los publicadores no necesitan estar configurados para enviar eventos a suscriptores especificos, sino que los envian a un tema, del cual los suscriptores recibiran los eventos que le interesen.
Tecnologías relevantes:
- MQTT: Un protocolo ligero ideal para dispositivos IoT.
- WebSocket: Permite la comunicación bidireccional en tiempo real entre un cliente y un servidor.
- Servicios en la nube: AWS SNS (Simple Notification Service), Google Cloud Pub/Sub, Azure Service Bus.
Consideraciones de diseño:
- Filtrado de mensajes: Los suscriptores a menudo necesitan filtrar los mensajes para recibir solo los que les interesan.
- Gestión de errores: Deben implementarse estrategias para manejar fallos en la entrega de mensajes.
- Escalabilidad: El sistema Pub/Sub debe ser capaz de manejar un gran número de publicadores y suscriptores.

Recomendaciones Adicionales:

Selección del conector adecuado: La elección del conector depende de los requisitos específicos del sistema, como el volumen de datos, la latencia, la consistencia y la escalabilidad.
Patrones de integración: Familiarízate con patrones de integración comunes, como la integración basada en mensajes, la integración basada en archivos y la integración basada en servicios.
Documentación: Documenta claramente los conectores utilizados en tu arquitectura, incluyendo su propósito, configuración y dependencias.

Comentarios (16)16 comentarios

Carlos Eduardo Diaz Polanco

Hace 8 años

Conectores Pizarra, repositorio, colas, modelo PUBSUB

• Colas: Sirve cuando tenemos un productor tiene mas velocidad que un consumidor, para eso se agenda el procesamiento de cada mensaje, por lo que el consumidor va leyendo los mensajes a la velocidad que él se lo permite.
• Pizarra/repositorio: Está orientado a escribir o leer datos de un componente que funciona como base de datos.
• Modelo PUBSUB (Publicar-Suscribir):
Permite mandar mensaje de un componente que publica eventos a otro que se suscriba a esos eventos, sin que estos componentes se conozcan entre sí.

Carlos Ariel Chávez Maciel

Buenas anotaciones. Gracias.

Abril Darynka Tapia Sosa

Hace 7 años

Conectores.

Cola. Cuando se tiene un productor que tiene mas velocidad que el consumidos. Para conectarlos, se debe compatibilizar su velocidad. Para eso se debe encolar/agendar el procesamiento de los mensajes. y por eso el consumidor puede ir leyendo esos mensajes a medida que su velocidad se lo permita.
Repositorio / pizarra. Orientado a escribir o leer datos de un componente que funciona como base de datos
Publicar suscribir (PUBSUB). Permite mandar mensajes desde un componente que publica eventos a uno que se suscriba a esos eventos sin necesidad que se conozcan.

Guadalupe Monge Barale

Muchas gracias Tus apuntes me encantan

Antonio Rafael González Ferrer

Apuntes:

Pizarra, repositorio, cola, modelo PUBSUB

Cola. Necesitamos utilizarlo cuando tenemos un productor que tiene más velocidad que un consumidor, para conectarlos, necesitamos encolar el procesamiento de cada uno de esos mensajes, así el consumidor puede leerlos a medida que puede hacerlo.

Repositorio / Pizarra. Es un conector que está orientado a escribir o leer datos de un componente que funciona como base de datos. Estos conectores van a darle importancia a ese dato y a cuánto ese dato afecta a nuestra base de datos.

Modelo Publicar / Suscribir: PUBSUB. Permite mandar mensajes desde un componente que publique eventos a otro que se suscriba a esos eventos sin necesidad que esos componentes se conozcan entre sí. Esto lo logra a través de conectarse con el publicador y que este publicador le de los eventos, y luego conectarse con el suscritor y que el suscritor le comunique qué eventos le interesa.

Christian Gómez

Hace 6 años

Conector Cola: Lo utilizamos cuando tenemos un productor que tiene mucha más velocidad que un consumidor. Para conectarlos se necesita compatibilizar esa velocidad. para hacerlo se procede a agendar los mensajes y así el consumidor puede ir leyéndolos a medida de que su velocidad se lo permita.
Conector Repositorio / Pizarra: Esta orientado a leer o escribir de un componente que se utiliza como base de datos.
Conector PUBSUB (Publicar / Subscribir): Nos permite mandar mensajes de un componente que publica eventos a otro componente que se subscriba a esos eventos, sin necesidad de que esos componentes se conozcan entre si. Este conector es super importante en aplicaciones distribuidas.

José Valentin Salina Peña

Apache kafka seria un ejemplo de un conector de tipo PUBSUB?

Jair Israel Avilés Eusebio

Hace 5 años

Apache Kafka es una solucion de eventos de stream. En realidad este otro tipo de conector complementa al PUB/SUB pero no son lo mismo.

Jhovny Flores

Message MQ de IBM y Active MQ de Apache

Victor Manuel Sarria Salinas

Hace 4 años

https://docs.google.com/presentation/d/1SrNVT_j8De1TipH8GgGt-aq8vctd55wyinuEEO--UcE/edit?usp=sharing

Fernando Yutiz

Un ejemplo de conector PUBSUB lo encontramos en el protocolo MQTT muy utilizado en IoT (Internet oh Things)

luis daniel coronel posada

encolar o agendar en cola se le pude llamar a una estructura de datos donde la entrada es mayor que su salida, ejemplo de esto puede ser la cola de impresión de documentos.

Gerardo Jesús Mota Olguín

Juan Carlos Ortiz Romero

⭐️⭐️⭐️ Conectores Pizarra, repositorio, colas, modelo PUBSUB 🤖 • Colas: Sirve cuando tenemos un productor tiene mas velocidad que un consumidor, para eso se agenda el procesamiento de cada mensaje, por lo que el consumidor va leyendo los mensajes a la velocidad que él se lo permite. 🤖 • Pizarra/repositorio: Está orientado a escribir o leer datos de un componente que funciona como base de datos. 🤖 • Modelo PUBSUB (Publicar-Suscribir): Permite mandar mensaje de un componente que publica eventos a otro que se suscriba a esos eventos, sin que estos componentes se conozcan entre sí.

https://www.arsys.es/blog/arquitectura-software/

Andrés Madrigal

Ejemplos de estos conectores:
Colas: Event Stack de javascript
Repositorio: Github
PUBSUB: Platzi

Alejandro Picado Brenes

No logré relacionar los ejemplos específicos de conectores,en cómo se clasifican en los diferentes tipos de conectores, traté de identificar los tipos con los ejemplos pero no me quedó claro, hice algo así:

Llamada a procedimiento -------- (llamada asicrónica, sicrónica, cliente-servidor )
enlace --------------------------------- (no identifiqué)
evento --------------------------------- (PUB/SUB)
adaptador ----------------------------- (no identifiqué)
acceso a datos ---------------------- (no identifiqúe)
flujo ------------------------------------- (no identifiqué)
arbitraje ------------------------------- (no identifiqué)
distribuidor --------------------------- (enrutador, difusión)

¿Donde estarían ubicados los conectores específicos cola y repositorio-pizarra en los tipos?

Enrique Devars

Hola, para mi quedaría como:

Llamada a procedimiento -------- (llamada asíncrona, síncrona, cliente-servidor ) enlace --------------------------------- (enrutador,difusión) evento --------------------------------- (PUB/SUB) adaptador ----------------------------- (no identifiqué) acceso a datos ---------------------- Respositorio/pizarra flujo ------------------------------------- Cola arbitraje ------------------------------- PUBSUB distribuidor --------------------------- (enrutador, difusión)

Miguel Santiago Gómez Suárez

Comparto esta pequeña diferencia que me entregó ChatGPT relacionada a conectores de Difusión, Enrutamiento y PUBSUB:

Principales Diferencias y Comparación

Destino de los mensajes:
- Enrutador: Un destinatario específico según criterios.
- Difusión: Todos reciben el mensaje.
- PUBSUB: Solo los suscriptores de un tema reciben los mensajes.
Relación Emisor-Receptor:
- Enrutador y Difusión: Relación directa entre emisor y receptor(es).
- PUBSUB: Totalmente desacoplado, emisor y receptor no interactúan directamente.
Escalabilidad:
- Enrutador y Difusión: Pueden ser menos escalables en redes muy grandes.
- PUBSUB: Escalable para sistemas distribuidos grandes gracias al desacoplamiento.
Flexibilidad:
- PUBSUB es más flexible ya que permite que los receptores elijan qué recibir.
- Difusión es la menos flexible, al ser indiscriminada.

¿Un PUBSUB podría actuar como Enrutador o Difusión?

En teoría, el modelo PUBSUB puede simular funcionalidad de enrutamiento o difusión si se configura de manera adecuada:

Como Enrutador: Publicadores emiten mensajes específicos que solo ciertos suscriptores interceptan (basado en temas).
Como Difusión: Todos los nodos de la red se suscriben al mismo tema, simulando un envío global.

Introducción al curso

Curso Profesional de Arquitectura de Software

Atributos de calidad

Qué son los atributos de calidad en software

Cómo medir idoneidad funcional en software

Qué es eficiencia de ejecución en software

Cómo medir interoperabilidad y coexistencia

Qué es la usabilidad y sus 6 dimensiones

Cómo medir confiabilidad en software

Los 5 pilares de seguridad en software

Cómo garantizar mantenibilidad con tests

Adaptabilidad vs capacidad de instalación vs reemplazo

Tensiones entre atributos de calidad de software

Atributos de calidad según fase de empresa

Patrones de arquitectura

Qué es un patrón de arquitectura

Modelo vista controlador: cómo separar responsabilidades

Arquitectura en capas: controller, servicio y repositorio

Event sourcing vs bases relacionales

Qué es la arquitectura microkernel

Arquitectura Comparte Nada con Map Reduce

Patrón de microservicios: cuándo y cómo

Qué es CQRS y cómo separa lectura de escritura

Arquitectura hexagonal: puertos y adaptadores

Qué son los contextos delimitados en DDD

Cómo combinar patrones de arquitectura

Evolución de patrones desde monolito a microservicios

Diseño de una arquitectura

Cómo traducir requerimientos en decisiones arquitectónicas

Conectores en arquitectura: tipos y cuándo usarlos

Llamadas asíncronas vs síncronas vs cliente-servidor

Conector enrutador vs difusión: Twitter

Conectores cola, repositorio y pub/sub

Framework de diseño orientado a atributos

Cómo detectar fallas y reparar sistemas

Cómo recuperar y prevenir fallas en sistemas

Tácticas para confinar modificaciones

Cómo prevenir efectos dominó en software

Tácticas para controlar eficiencia de ejecución

Cómo detectar, resistir y recuperarse de ataques

Cómo probar que el software funciona correctamente

Cómo controlar la usabilidad con tácticas

Cómo validar arquitectura con ATAM y métricas

Evolución de arquitectura: startup a gran escala

Modelado y documentación de arquitectura

Cómo documentar arquitectura que no se erosione

Cómo sincronizar arquitectura y código fuente

Cómo aplicar atributos de calidad en proyectos

Conectores cola, repositorio y pub/sub