Patrón de pub/sub

Cuando una plataforma crece, puede resultar difícil que diferentes microservicios interactúen sin crear interdependencia. El patrón de publicación/suscripción (pub/sub) proporciona una comunicación asincrónica entre varios servicios de AWS, como de Amazon SQS, Lambda o Amazon Simple Storage Service (Amazon S3), sin crear interdependencia. En este patrón, los microservicios publican eventos como mensajes en un canal que los suscriptores pueden escuchar. Por ejemplo, una fábrica puede utilizar un patrón de pub/sub para permitir que los equipos publiquen los problemas o errores en un canal y, a continuación, un suscriptor puede mostrar y registrar estos problemas en el equipo.

Debería considerar la posibilidad de utilizar este patrón si:

• Tiene una arquitectura basada en eventos.

• Puede habilitar una arquitectura de acoplamiento flexible.

• No es necesario completar todas las partes operativas de una transacción antes de la respuesta al sistema de llamadas (algunas operaciones pueden ser asincrónicas).

• Debe escalar a volúmenes que superen la capacidad de un centro de datos tradicional. Este nivel de escalabilidad se debe principalmente a las operaciones en paralelo, el almacenamiento en caché de mensajes, el enrutamiento basado en árbol y otras características integradas en el modelo de pub/sub.

  El uso de este patrón presenta varias desventajas. Por ejemplo, el patrón de pub/sub normalmente no puede garantizar la entrega de mensajes a todos los tipos de suscriptores, aunque algunos servicios, como Amazon Simple Notification Service (Amazon SNS), pueden proporcionar una entrega exactamente una vez a algunos subconjuntos de suscriptores. Otra desventaja es que un publicador podría suponer que un suscriptor está escuchando un canal cuando, de hecho, no lo está.

Caso de uso

En este caso de uso, se utiliza un tema de SNS para publicar eventos en varios microservicios dependientes de un sistema de seguros. Una vez que un cliente realiza su pago mensual, la información debe actualizarse en subsistemas como “Cliente” o “Ventas” y debe enviarse al cliente un correo electrónico con la confirmación del pago. Este patrón se puede implementar mediante Amazon SNS o Amazon EventBridge.

EventBridge filtra los eventos entre varios suscriptores. La implementación de EventBridge ofrece las dos opciones siguientes:

• Enviar tres eventos con diferentes tipos de eventos. El destino lejano los elige según la regla de eventos.

• Enviar un mensaje con tres reglas de eventos que escuchan el mismo tipo de evento. Los datos innecesarios se filtran antes de invocar destinos específicos.

Implementación de Amazon SNS

La siguiente ilustración muestra cómo se usa Amazon SNS para implementar el patrón de pub/sub. Cuando un usuario realiza un pago, la función de Lambda “Pagos” envía un mensaje de SNS al tema de SNS “Pagos”. Este tema de SNS tiene tres suscriptores que reciben una copia del mensaje y la procesan.

Implementación de Amazon EventBridge

En la siguiente ilustración, EventBridge se utiliza para crear una versión del patrón de pub/sub en el que los suscriptores se definen mediante reglas de eventos. Cuando un usuario realiza un pago, la función de Lambda “Pagos” envía un mensaje a EventBridge mediante el bus de eventos predeterminado según un esquema personalizado que tiene tres reglas diferentes que apuntan a destinos diferentes. Cada microservicio procesa los mensajes y realiza las acciones necesarias.