bluebay2014 - Fotolia

Conseil

3 modèles d'event sourcing qui facilitent les opérations applicatives

Dans cet article, nous examinons les avantages et les inconvénients de trois modèles d’approvisionnement en événements (event sourcing). Ils peuvent régler certains problèmes, mais en provoquent de nouveaux au sein d’une architecture orientée événements.

Matt Heusser
par
Publié le: 08 janv. 2020

Les modèles d’event sourcing permettent de créer des architectures applicatives qui suivent les changements dans un système en se reposant sur les événements plutôt que les traiter directement à travers un serveur central ou une base de données.

Par exemple, une commande d’un client via une application web comme un site e-commerce, génère de multiples modifications. Dans une architecture basée sur l’event sourcing, elles sont toutes des événements déclencheurs.

Ces modifications peuvent également provenir de l’application elle-même. Elles sont ensuite archivées dans un journal (log), ce qui constitue l’objectif fondamental de l’event sourcing.

Le sourcing d’événements permet essentiellement de découpler les changements applicatifs de l’enregistrement de ces changements. Toutefois, cela signifie qu’un autre système doit retenir la demande jusqu’à ce qu’elle soit traitée. Cette étape implique éventuellement d’utiliser plusieurs middlewares qui fonctionnent à leur propre rythme. En cas de problème, cela peut générer des défauts de coordination, de réconciliation et de débogage.

Pour résoudre ces problèmes, nous nous tournons vers trois modèles d’architectures orientées événements : la file d’attente, le mode publication/abonnement couplé à un bus de service et le modèle Binary Star Reactor. Les concepteurs et développeurs d’applications devraient connaître les avantages et les inconvénients de ces trois patterns basiques.

La file d’attente

Ce modèle implique un traitement des événements dans leur ordre d’arrivée. Le client final côté serveur peut effectuer une requête que l’application emmagasine. Le système gère les pics de trafic et les retards pour les rattraper plus tard.

La file d’attente des messages correspond à un bout de middleware qui stocke temporairement les informations des événements servis par les applications. Le serveur traite ces événements en fonction de leur priorité. Ainsi, la base de données n’a pas besoin de conserver les données. Cela permet de garder un volume de stockage libre et donc de gagner en performance.

Cependant, ce middleware peut être un élément. Il convient d’ajouter un logiciel serveur supplémentaire que l’équipe doit maintenir tout au long du cycle de vie de l’application. Il a pour charge de mettre en tampon les événements.

En outre, la fille d’attente ne peut gérer qu’un seul type d’événements à la fois, de sorte que ce middleware peut devenir un goulot d’étranglement si l’application doit traiter plusieurs éléments en même temps. C’est là que le modèle de publication/abonnement entre en jeu.

Publication/Abonnement

Dans les applications web, plusieurs systèmes veulent souvent recevoir les messages d’un seul événement. Pour contourner ce problème, les développeurs peuvent configurer un middleware de bus de service. L’ESB reçoit l’événement et le publie ensuite à tout composant abonné qui souhaite en faire usage. Ce modèle est également connu sous le nom de multidiffusion ou de messagerie de groupe.

Toutefois, des problèmes peuvent survenir avec ce modèle de publication/abonnement dans une architecture orientée événements quand le système requiert une haute disponibilité.

Si un système est en maintenance au moment de l’envoi d’un message, ce message peut se perdre et les services qui en dépendent peuvent ne plus fonctionner.

Pour éviter cette situation, il est possible de configurer les gestionnaires de bus de service pour qu’ils demandent un accusé de réception et renvoient les messages non parvenus jusqu’à ce qu’ils soient traités correctement. Une autre approche consiste à combiner le bus de service avec un modèle de file d’attente. Le second aide le premier à stocker à traiter tout transfert de message défaillant.

Une troisième option existe : le binary star reactor. 

Inconvénients des modèles d’approvisionnement en événements

Les modèles de sourcing d’événements décomposent une seule transaction logique en plusieurs petits composants. Au niveau d’une base de données, chaque transaction est atomique ce qui signifie que soit tout fonctionne, soit tout échoue. Il n’y a pas d’éléments partiels ou complets désordonnés à rechercher et à nettoyer.
Si le software ne peut pas faire cette transaction assez rapidement pour le consommateur d’une application cible, ces modèles permettent de décomposer cette étape, mais il faut s’attendre à plus de complexité dans la gestion des opérations et du débogage.

Le plus gros défi découlant de ces choix d’architecture est sans doute l’observabilité. En cas d’erreur, savoir d’où elle vient et pourquoi sont deux questions importantes. Avant de vous lancer dans une hiérarchie complexe d’événements, il convient de réfléchir à l’effort à fournir et à la manière de résoudre les problèmes.

Binary star Reactor

Le modèle Binary star reactor demande principalement à mettre en place deux serveurs séparés. Le premier héberge le système qui gère le traitement au quotidien et un second est consacré à la sauvegarde des transactions. Il peut prendre le relais si le premier serveur tombe.

Évidemment, ce modèle de sourcing d’événements double la quantité de puissance nécessaire à une opération d’application donnée.

Les utilisateurs peuvent stocker le backup dans le cloud, mais cette configuration implique toujours une augmentation des dépenses et de la complexité. Un modèle binary star reactor multiplie également par deux le trafic réseau, ce qui crée une surcharge de communication par rapport aux autres patterns. La sécurité que ce modèle offre est contrebalancée par un coût élevé.

Pour approfondir sur Architectures logicielles et SOA