Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Patrón de abastecimiento de eventos
El patrón de abastecimiento de eventos se suele utilizar con el Patrón CQRS fin de desacoplar las cargas de trabajo de lectura de las de escritura y optimizar el rendimiento, la escalabilidad y la seguridad. Los datos se almacenan como una serie de eventos, en lugar de como actualizaciones directas a los almacenes de datos. Los microservicios reproducen los eventos de un almacén de eventos para calcular el estado apropiado de sus propios almacenes de datos. El patrón proporciona visibilidad del estado actual de la aplicación y un contexto adicional sobre cómo la aplicación llegó a ese estado. El patrón de obtención de eventos funciona de forma eficaz con el patrón CQRS, ya que los datos de un evento específico se pueden reproducir, incluso si los almacenes de datos de comandos y consultas tienen esquemas diferentes.
Al elegir este patrón, puede identificar y reconstruir el estado de la aplicación en cualquier momento. Esto produce un registro de auditoría persistente y facilita la depuración. Sin embargo, los datos se vuelven coherentes con el tiempo y esto podría no ser apropiado para algunos casos de uso.
Este patrón se puede implementar mediante Amazon Kinesis Data Streams o Amazon EventBridge.
Implementación de Amazon Kinesis Data Streams
En la siguiente ilustración, Kinesis Data Streams es el componente principal de un almacén de eventos centralizado. El almacén de eventos captura los cambios en aplicaciones como eventos y los conserva en Amazon Simple Storage Service (Amazon S3).
El flujo de trabajo consta de los siguientes pasos:
-
Cuando los microservicios “/withdraw” o “/credit” experimentan un cambio de estado de evento, publican un evento escribiendo un mensaje en Kinesis Data Streams.
-
Otros microservicios, como “/balance” o “/CreditLimit”, leen una copia del mensaje, la filtran según su relevancia y la reenvían para su posterior procesamiento.
EventBridge Implementación de Amazon
La arquitectura de la siguiente ilustración utiliza EventBridge. EventBridge es un servicio sin servidor que utiliza eventos para conectar los componentes de la aplicación, lo que facilita la creación de aplicaciones escalables y basadas en eventos. La arquitectura basada en eventos es un estilo que consiste en crear sistemas de software poco acoplados que funcionan juntos emitiendo eventos y respondiendo a ellos. EventBridge proporciona un bus de eventos predeterminado para los eventos publicados por los AWS servicios, y también puede crear un bus de eventos personalizado para los buses de dominios específicos.
El flujo de trabajo consta de los pasos siguientes:
-
El microservicio «Pedidos» publica los eventos en el bus de eventos personalizado. OrderPlaced
-
Los microservicios que deben tomar medidas después de realizar un pedido, como el microservicio “/route”, se inician mediante reglas y objetivos.
-
Estos microservicios generan una ruta para enviar el pedido al cliente y emitir un «RouteCreated» evento.
-
Los microservicios que requieren la adopción de nuevas medidas también se inician con el evento «RouteCreated».
-
Los eventos se envían a un archivo de eventos (por ejemplo, un EventBridge archivo) para que puedan reproducirse y reprocesarse, si es necesario.
-
Los eventos históricos de los pedidos se envían a una nueva cola de Amazon SQS (cola de reproducción) para su reprocesamiento, si es necesario.
-
Si los objetivos no se inician, los eventos afectados se colocan en una cola de mensajes fallidos (DLQ) para su posterior análisis y reprocesamiento.
Debería considerar la posibilidad de utilizar este patrón si:
-
Los eventos se utilizan para reconstruir completamente el estado de la aplicación.
-
Es necesario que los eventos se reproduzcan en el sistema y que el estado de la aplicación se pueda determinar en cualquier momento.
-
Desea poder revertir eventos específicos sin tener que empezar con el estado de la aplicación en blanco.
-
Su sistema requiere un flujo de eventos que se puedan serializar fácilmente para crear un registro automatizado.
-
El sistema requiere operaciones de lectura intensivas, pero operaciones de escritura ligeras; las operaciones de lectura intensiva se pueden dirigir a una base de datos en memoria, que se mantiene actualizada con el flujo de eventos.
importante
Si utiliza el patrón de abastecimiento de eventos, debe implementarlo Saga patrón para mantener la coherencia de datos en todos los microservicios.
