Architecture événementielle : produire, publier, consommer

Architecture événementielle : produire, publier, consommer

Le canevas FlowJam interactif de cette explication : chaque couloir, ligne et flèche ci-dessus appartient à un véritable diagramme QueryChart que vous pouvez ouvrir et modifier.

Comment lire ce visuel

• Lire de gauche à droite : émettre, publier, consommer et conserver.
• La rangée des producteurs ne pointe jamais vers un consommateur : chaque flèche traverse le bus, qui est le découplage rendu visible.
• La branche inférieure est le magasin d'événements : les mêmes événements consommés en temps réel sont également conservés pour la relecture et l'audit.

Produire et publier

"Les services produisent des événements de domaine" relève de l'entière responsabilité du producteur : enregistrer que quelque chose s'est produit. "Les événements sont publiés dans le bus" et "Les événements des itinéraires de bus aux abonnés" constituent l'étape de publication : le bus accepte les événements et les transmet à l'abonné. Le commentaire sur la boîte d'émission explicite la règle : les producteurs ne savent pas qui écoute, ce qui rend le système extensible.

Consommer en temps réel

« Les consommateurs traitent les événements de manière asynchrone » est la voie de droite : les abonnés agissent sur chaque événement (mettre à jour un modèle de lecture, envoyer un e-mail, déclencher un workflow) selon leur propre calendrier. Le traitement asynchrone explique pourquoi un consommateur lent ne ralentit pas un producteur et pourquoi le visuel maintient les deux dans des bandes séparées.

Conserver l'histoire

"Le magasin d'événements conserve l'historique complet" enregistre chaque événement dans l'ordre, et "Les événements peuvent être rejoués à des fins d'audit ou de récupération" est à quoi sert l'enregistrement : reconstruire un état, répondre à une question d'audit ou nourrir un nouveau consommateur du passé. "De nouveaux consommateurs rejoignent sans toucher aux producteurs", c'est le test de l'architecture : parce que l'historique existe et les lignes de bus par abonnement, l'ajout d'un service ne change rien en amont.

Relations et enseignements clés

• Un événement enregistre ce qui s'est passé ; ce n’est pas un ordre adressé à quelqu’un en particulier.
• Le bus découple les producteurs des consommateurs : aucun des deux ne connaît l'identité ni les horaires de l'autre.
• Le magasin d'événements fait de l'historique un système d'enregistrement qui peut être rejoué.
• Les consommateurs sont asynchrones : un consommateur lent ne bloque jamais un producteur.
• De nouveaux consommateurs rejoignent en s'abonnant : toute la prétention de flexibilité de l'architecture repose là-dessus.

Quand utiliser ce visuel

• Enseigner le découpage producteur-bus-consommateur à une équipe passant de la requête/réponse à l'événementiel.
• Concevoir une nouvelle intégration : le magasin d'événements répond si l'historique doit être conservé ou consommé et oublié.
• Audit d'un système événementiel existant pour la défaillance classique : un consommateur qui est en réalité une dépendance synchrone.

Comment cela fonctionne

1. Renommez les parties de votre système

   Remplacez les noms des producteurs, des consommateurs et des événements par vos services réels et les événements qu'ils publient, en ajoutant ceux qui manquent au diagramme générique.

2. Nommer les sujets et leurs consommateurs

   Annotez chaque événement dans le bus avec le nom du sujet et qui est abonné, afin que le découplage soit une carte documentée plutôt qu'une assertion.

3. Ajouter les branches d'échec

   Insérez ce qui se passe lorsque le bus est en panne, qu'un consommateur décède au milieu d'un événement ou qu'un événement arrive deux fois : chacun avec le mécanisme d'idempotence ou de nouvelle tentative qui le gère.

4. Étendre le magasin d'événements

   Ajoutez les règles de conservation et de relecture que votre système utilise réellement (combien de temps l'historique est conservé et quels états sont reconstruits à partir de celui-ci) afin que la bande du magasin reflète votre politique.

Questions fréquentes

Qu’est-ce que l’architecture événementielle ?

Il s'agit d'un style architectural dans lequel les composants communiquent en publiant et en s'abonnant à des événements plutôt qu'en s'appelant directement. Un service qui crée ou modifie quelque chose publie un événement décrivant ce qui s'est passé ; le bus l'achemine vers tous les abonnés qui s'en soucient ; et un magasin d'événements conserve l'historique. Parce que les producteurs ne nomment jamais leurs consommateurs, le système peut se développer sans toucher à ce qui existe déjà.

Quelle est la différence entre une commande et un événement ?

Une commande est une instruction destinée à un destinataire spécifique (« traiter cette commande ») et elle attend un résultat. Un événement est un enregistrement indiquant que quelque chose s'est déjà produit (« commande passée ») et il ne nomme aucun destinataire. La distinction est importante car les commandes couplent l'expéditeur au récepteur, tandis que les événements laissent le récepteur libre de changer. Les producteurs du visuel n'émettent que des événements, ce qui maintient le bus en liberté.

A quoi sert la boutique événementielle ?

Le magasin d'événements est l'historique conservé par le système : chaque événement, dans l'ordre, en permanence. Il répond à trois objectifs : l'audit (ce qui s'est passé et quand), la récupération (reconstruire l'état d'un service en rejouant ses événements) et l'extensibilité (un nouveau consommateur peut rattraper son retard en lisant le passé). Le visuel le représente comme la branche inférieure car il s'agit d'une utilisation distincte des mêmes événements que les consommateurs traitent en temps réel.

Quels sont les modes de défaillance de l’architecture événementielle ?

Les événements classiques sont : les événements livrés plus d'une fois (les consommateurs doivent donc être idempotents), les événements traités dans le désordre (les consommateurs doivent donc gérer les commandes) et la file d'attente des lettres mortes (événements qui échouent à plusieurs reprises). Le traitement asynchrone du visuel est ce qui les rend gérables (un consommateur peut réessayer sans bloquer le producteur), c'est pourquoi les branches d'échec dans les étapes pratiques constituent la moitié pratique de la conception.

Modifier ce visuel dans QueryChart (FlowJam)

Ouvrez ce canevas événementiel exact en tant que votre propre graphique, renommez les producteurs et les consommateurs en vos services et cartographiez vos événements.

Modifier ce visuel dans QueryChart (FlowJam)