Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Modèle d’approvisionnement d’événement
Le modèle de sourcing d'événements est généralement utilisé pour Motif CQRS dissocier les charges de travail de lecture et d'écriture et pour optimiser les performances, l'évolutivité et la sécurité. Les données sont stockées sous la forme d'une série d'événements, au lieu de mises à jour directes vers les magasins de données. Les microservices reproduisent les événements depuis un magasin d'événements pour calculer l'état approprié de leurs propres magasins de données. Le modèle fournit une visibilité sur l'état actuel de l'application et un contexte supplémentaire sur la façon dont l'application est arrivée à cet état. Le modèle d'approvisionnement d'événements fonctionne efficacement avec le modèle CQRS car les données peuvent être reproduites pour un événement spécifique, même si les magasins de données de commandes et de requêtes ont des schémas différents.
En choisissant ce modèle, vous pouvez identifier et reconstruire l'état de l'application à tout moment. Cela produit une piste d'audit persistante et facilite le débogage. Cependant, les données finissent par devenir cohérentes, ce qui peut ne pas être approprié pour certains cas d'utilisation.
Ce modèle peut être implémenté à l'aide d'Amazon Kinesis Data Streams ou d'Amazon EventBridge.
Implémentation d'Amazon Kinesis Data Streams
Dans l'illustration suivante, Kinesis Data Streams est le composant principal d'un magasin d'événements centralisé. Le magasin d'événements capture les modifications apportées aux applications sous forme d'événements et les conserve sur Amazon Simple Storage Service (Amazon S3).
Le flux de travail se compose des étapes suivantes :
-
Lorsque les microservices « /withdraw » ou « /credit » subissent un changement d'état d'un événement, ils publient un événement en écrivant un message dans Kinesis Data Streams.
-
D'autres microservices, tels que « /balance » ou « /CreditLimit », lisent une copie du message, le filtrent en fonction de sa pertinence et le transmettent pour un traitement ultérieur.
EventBridge Implémentation d'Amazon
L'architecture de l'illustration suivante utilise EventBridge. EventBridge est un service sans serveur qui utilise des événements pour connecter les composants de l'application, ce qui vous permet de créer plus facilement des applications évolutives pilotées par des événements. L'architecture axée sur les événements est un style qui consiste à créer des systèmes logiciels faiblement couplés qui fonctionnent ensemble en émettant des événements et en y répondant. EventBridge fournit un bus d'événements par défaut pour les événements publiés par les AWS services, et vous pouvez également créer un bus d'événements personnalisé pour les bus spécifiques à un domaine.
Le flux de travail se compose des étapes suivantes :
-
« OrderPlaced » les événements sont publiés par le microservice « Orders » sur le bus d'événements personnalisé.
-
Les microservices qui doivent intervenir après la passation d'une commande, tels que le microservice « /route », sont initiés par des règles et des cibles.
-
Ces microservices génèrent un itinéraire pour expédier la commande au client et émettent un événement « RouteCreated ».
-
Les microservices qui doivent prendre des mesures supplémentaires sont également initiés par l'événement « RouteCreated ».
-
Les événements sont envoyés vers une archive d'événements (par exemple, une EventBridge archive) afin de pouvoir être rejoués pour retraitement, si nécessaire.
-
Les événements de commande historiques sont envoyés vers une nouvelle file d'attente Amazon SQS (file de rediffusion) pour être retraités, si nécessaire.
-
Si les cibles ne sont pas initialisées, les événements concernés sont placés dans une file d'attente des lettres mortes (DLQ) pour une analyse et un retraitement approfondis.
Vous devriez envisager d'utiliser ce modèle si :
-
Les événements sont utilisés pour rétablir complètement l'état de l'application.
-
Vous avez besoin que les événements soient rejoués dans le système et que l'état d'une application puisse être déterminé à tout moment.
-
Vous souhaitez pouvoir inverser des événements spécifiques sans avoir à démarrer avec un état d'application vide.
-
Votre système a besoin d'un flux d'événements qui peut facilement être sérialisé pour créer un journal automatique.
-
Votre système nécessite de lourdes opérations de lecture, mais peu d'opérations d'écriture ; les opérations de lecture intensives peuvent être dirigées vers une base de données en mémoire, qui est mise à jour avec le flux d'événements.
Important
Si vous utilisez le modèle d'approvisionnement en événements, vous devez le déployer Sagamotif pour maintenir la cohérence des données entre les microservices.
