Expliquer les architectures pilotées par les événements

Publié le 27 juillet 2022 par Andrew Owen (5 minutes)

Le développement moderne de logiciels repose sur l’automatisation, l’intégration continue, la livraison continue et les cycles de vie définis par le logiciel. L’idée est de maintenir la qualité tout en permettant aux fonctionnalités d’être livrées dès qu’elles sont prêtes pour la production. Vous connaissez probablement aussi l’abandon des systèmes monolithiques au profit d’une architecture microservices. L’objectif est de construire le système à partir de composants qui peuvent être remplacés sans qu’il soit nécessaire de tout reconstruire.

Mais à la pointe du progrès, il y a l’architecture pilotée par les événements (ADA). En termes simples, il s’agit d’une conception dans laquelle le système dans son ensemble existe en tant qu’état, et tout changement de cet état produit des événements. Au lieu de stocker cet état sous la forme d’une donnée unique, les AED utilisent la source d’événements. Les données sont stockées sous la forme d’une série d’événements immuables au fil du temps dans un magasin d’événements. Il s’agit essentiellement d’un grand livre. Une fois créés, les événements ne peuvent plus être modifiés. Toute modification des données (état) est le résultat d’un nouvel événement. Cette approche présente plusieurs avantages:

• La base de données est traitée comme un journal d’événements, ce qui simplifie et accélère les lectures et les écritures.
• Les événements fournissent un historique qui vous permet de recréer l’état actuel du système à partir de n’importe quel point du passé.
• Les modifications sont publiées dans l’ensemble du système, mais les différentes parties du système n’ont qu’à s’abonner aux événements correspondant à leur fonction.

Une femme sage a dit un jour “Le principal problème des architectures pilotées par les événements est qu’il faut sans cesse expliquer aux clients ce qu’elles sont.

Microservices

Les éléments constitutifs d’une AED sont ses microservices. Généralement, ceux-ci sont autonomes et n’interagissent pas directement les uns avec les autres. Ceci est souvent mis en œuvre en ayant chaque microservice exécuté dans son propre conteneur Docker, géré par Kubernetes. Chaque microservice doit avoir son propre contexte délimité (par exemple, les commandes, le panier, les produits et les clients). Lorsque la communication entre les microservices est nécessaire (par exemple, entre les commandes, les clients et les produits), elle est réalisée en demandant à chaque microservice de s’abonner aux événements qui l’affectent directement. Les événements sont traités dans l’ordre dans lequel ils se sont produits, et un point de contrôle enregistre le dernier événement traité. Cela signifie que:

• Les microservices individuels ne sont pas dépendants les uns des autres.
• Si un microservice est arrêté, lorsqu’il est redémarré, il peut reprendre à partir du dernier événement traité.
• De nouvelles fonctionnalités peuvent être déployées de manière incrémentale sans dépendre d’autres microservices.
• Lorsqu’une nouvelle fonctionnalité est ajoutée, le point de contrôle peut être réinitialisé pour retraiter l’historique des événements, par exemple pour fournir de nouvelles informations.

Relations entre les événements

Les relations entre les événements se répartissent généralement en deux catégories:

• Relations API-événement: il existe une relation univoque ou univoque entre un appel API public et un événement ou un ensemble d’événements.
• Relations schéma-événement: les événements créés par des appels d’API internes modifient les données conformément à un schéma particulier.

Généralement, dans les systèmes API-first, les événements sont liés à un appel API spécifique. Ces appels peuvent être générés par un ou plusieurs composants du système, par l’interaction de l’utilisateur via une interface web ou par un microservice.

D’après mon expérience, vous pouvez très bien vous retrouver avec des clients qui veulent voir le journal des événements. Il peut s’agir d’événements que vous n’avez jamais voulu rendre publics, comme ceux qui concernent le fonctionnement interne du système, par exemple les API privées. Il est peu probable que ces événements fournissent des points de données utiles et, dans l’idéal, vous devriez trouver un moyen de les nettoyer avant de transmettre les données à vos clients.

Applications client

Les AED utilisent généralement des API RESTful pour fournir des méthodes d’accès aux données telles que les informations sur les clients. Les interactions avec les utilisateurs sont gérées par des applications clientes. Chaque application possède sa propre API. En général, l’API existe dans le même réseau que les microservices qu’elle appelle, afin de réduire la latence et d’augmenter les performances. L’API détermine également ce qui doit se passer dans le cas où un microservice spécifique n’est pas disponible.

Diverses options d’authentification sécurisée peuvent être intégrées dans les API:

• OAuth
• OpenID Connect (OIDC)
• Connexion sociale (par exemple, Facebook, Google, Twitter)
• Authentification à deux facteurs
• Fédération de services Web

Les rapports planifiés peuvent être fournis par le biais d’un abonnement à un événement, tandis que les tableaux de bord peuvent être pris en charge par le biais d’agrégations basées sur des flux. En règle générale, cela prend la forme d’un traitement d’extraction, de chargement et de transformation (ELT). Les événements originaux ne sont jamais modifiés, seule la sortie l’est.

Lacs de données

Le plus gros problème que j’ai rencontré dans l’explication des AED est lorsqu’un analyste commercial demande le schéma de la base de données. Les AED sont généralement développés autour de lacs de données, où les données sont stockées dans leur format brut. La base de données sur le backend sera probablement une solution NoSQL telle que Mongo DB. Je préfère penser qu’il s’agit d’un saut de données. On y jette des choses et elles s’y trouvent quelque part, mais on ne sait pas exactement où. La beauté du grand livre est que vous n’avez pas besoin de le savoir.

Image: Original par kooikkari.