Une architecture basée sur des événements est un modèle de conception logicielle, dans lequel les microservices réagissent à des changements d'état, appelés événements. Les événements peuvent présenter un état (tel que le prix d'un article ou une adresse de livraison) ou des identifiants (notification indiquant la réception ou l'expédition d'une commande, par exemple). Les événements déclenchent des microservices qui fonctionnent ensemble pour atteindre un objectif commun, mais qui n'ont pas besoin de connaître quoi que ce soit les uns des autres, à l'exception du format de l'événement. Bien qu'ils fonctionnent ensemble, chaque microservice peut appliquer une logique métier différente et émettre ses propres événements de sortie.
Un événement présente les caractéristiques suivantes :
- Il s'agit d'un enregistrement d'un événement qui s'est produit.
- Il capture un fait immuable qui ne peut être ni modifié, ni supprimé.
- Il se produit, qu'un service applique ou non une logique lors de son utilisation.
- Il peut être conservé indéfiniment à grande échelle et utilisé autant de fois que nécessaire.
Dans un système basé sur des événements, les événements sont générés par des producteurs d'événements, ingérés et filtrés par un routeur d'événements (ou agent), puis diffusé de manière ramifiée vers les consommateurs d'événements (ou récepteurs) appropriés. Les événements sont transmis aux abonnés définis par un ou plusieurs déclencheurs correspondants. Ces trois composants (producteurs d'événements, routeur d'événements, consommateurs d'événements) sont découplés et peuvent être déployés, mis à jour et mis à l'échelle indépendamment :
Le routeur d'événements associe les différents services. Il sert de support pour l'envoi et la réception des messages. Il génère une réponse pour l'événement d'origine généré par un producteur d'événements et l'envoie en aval aux consommateurs appropriés. Les événements sont gérés de manière asynchrone et leurs résultats sont déterminés lorsqu'un service réagit à un événement ou est affecté par celui-ci, comme indiqué dans le schéma suivant représentant un flux d'événements très simplifié :
Quand utiliser des architectures basées sur des événements
Prenez en compte les utilisations suivantes lors de la conception de votre système.
- Surveillance et réception d'alertes en cas d'anomalie ou de modification des buckets de stockage, des tables de bases de données, des machines virtuelles ou d'autres ressources.
- Distribution ramifiée d'un seul événement à plusieurs consommateurs. Le routeur d'événements envoie l'événement à tous les consommateurs appropriés, sans que vous ayez à écrire de code personnalisé. Chaque service peut ensuite traiter l'événement en parallèle, mais différemment.
- Interopérabilité entre différentes piles technologiques tout en préservant l'indépendance de chaque pile.
- Coordination des systèmes et des équipes opérationnels et déployés dans différentes régions et différents comptes. Vous pouvez réorganiser la propriété des microservices. Les équipes sont moins dépendantes les unes des autres et vous pouvez réagir plus rapidement aux modifications qui seraient normalement entravées par des obstacles à l'accès aux données.
Avantages des architectures basées sur des événements
Voici quelques avantages de la création d'une architecture basée sur des événements.
Couplage faible et agilité accrue des développeurs
Les producteurs d'événements sont séparés logiquement des consommateurs d'événements. Ce découplage entre la production et la consommation d'événements signifie que les services sont interopérables, mais peuvent être mis à l'échelle, mis à jour et déployés indépendamment les uns des autres.
Le couplage faible réduit les dépendances et vous permet de mettre en œuvre des services dans différents langages et frameworks. Vous pouvez ajouter ou supprimer des producteurs d'événements et des récepteurs, sans avoir à modifier la logique d'un service. Vous n'avez pas besoin d'écrire de code personnalisé pour interroger, filtrer et acheminer les événements.
Événements asynchrones et résilience
Dans un système basé sur des événements, les événements sont générés de manière asynchrone et peuvent être émis dès qu'ils se produisent, sans avoir à attendre de réponse. Grâce aux composants faiblement couplés, si un service échoue, les autres ne sont pas affectés. Si nécessaire, vous pouvez enregistrer les événements afin que le service destinataire puisse les reprendre à partir du point de défaillance ou consulter les événements passés.
Messages push, flux d'événements en temps réel et réduction des coûts
Les systèmes basés sur des événements facilitent l'envoi des messages push. Les clients peuvent recevoir des mises à jour, sans avoir à interroger continuellement les services distants pour connaître les changements d'état. Ces messages envoyés permettent de traiter et de transformer des données à la volée, et d'effectuer des analyses en temps réel. De plus, moins vous interrogez les données, plus vous réduisez les E/S réseau et les coûts.
Simplification des audits et approvisionnement basé sur les événements
L'emplacement centralisé du routeur d'événements simplifie l'audit et vous permet de contrôler qui peut interagir avec un routeur, ainsi que les utilisateurs et les ressources qui ont accès à vos données. Vous pouvez également chiffrer vos données en transit et au repos.
En outre, vous pouvez utiliser l'approvisionnement basé sur les événements, un modèle d'architecture qui enregistre toutes les modifications apportées à l'état d'une application dans la séquence dans laquelle elles ont été initialement appliquées. L'approvisionnement basé sur les événements fournit un journal d'événements immuables qui peut être conservé à des fins d'audit, pour recréer des états historiques ou en tant qu'argument canonique pour expliquer une décision basée sur l'activité.
Considérations relatives à l'architecture
Une architecture basée sur des événements peut nécessiter une approche de conception d'application différente. Bien qu'elle soit adaptée aux applications qui utilisent des microservices ou des composants découplés, vous devez également tenir compte des points suivants :
Votre source d'événements peut-elle garantir la diffusion si vous devez traiter chaque événement ?
Il doit s'agir d'une source d'événements durable et fiable.
Votre application peut-elle gérer plusieurs requêtes asynchrones ?
Les performances de votre système ne doivent pas reposer sur un champ d'application global ou des bases de données non élastiques.
Comment souhaitez-vous suivre votre flux d'événements ?
Une architecture basée sur des événements permet d'effectuer le suivi dynamique à l'aide de services de surveillance, au lieu d'un suivi statique via une analyse de code.
Voulez-vous utiliser les données de votre source d'événement pour les reconstituer ?
Assurez-vous que vos données sont dédupliquées et ordonnées.
Étapes suivantes
- Pour comprendre comment Eventarc gère les événements, consultez la présentation d'Eventarc.
- Découvrez comment créer un déclencheur Eventarc.