L’architecture orientée événements (EDA, Event-Driven Architecture) est un paradigme de conception dans lequel des programmes s’exécutent en réponse à des événements déclencheurs.
Les entités propres à ce style d’architecture sont les producteurs d’événements, qui génèrent un flux d’événements, et les consommateurs d’événements, qui reçoivent des informations sur ces événements et peuvent être impliqués dans leur traitement.
Dans un environnement orienté événements, un très grand nombre de producteurs et de consommateurs s’échangent des données d’état et de réponse en quasi-temps réel.
Les consommateurs peuvent ainsi répondre immédiatement à des événements à mesure qu’ils se produisent.
Les producteurs et les consommateurs d’événements sont dissociés : un producteur ne peut pas identifier les consommateurs à l’écoute des événements qu’il génère et de nouveaux consommateurs peuvent être ajoutés simplement.
Mais qu’est ce qu’un événement ?
Au niveau architectural, un message est un datagramme (paquet de données) créé par un producteur pour distribuer des informations, via la messagerie asynchrone d’un courtier de messages, afin que des consommateurs agissent en conséquence.
Les messages peuvent être classés en deux catégories :
- Si le producteur attend une action du consommateur, ce message est une commande.
- Si le message informe le consommateur qu’une action a eu lieu, ce message est un événement.
Commandes
Une commande est constituée de données brutes générées par un producteur.
La commande contient les données qui ont déclenchés le service de messagerie.
Un bus de services d’entreprise (ESB, Enterprise Service Bus) traditionnel est un exemple de service de messagerie pouvant stocker les commandes dans une file d’attente jusqu’à ce que le récepteur soit prêt à les recevoir.
Ainsi, un expéditeur peut envoyer un message avec des données brutes et s’attendre par exemple à ce que le consommateur crée un fichier à partir de ces données et envoie une réponse quand il a terminé.
Evénements
Un événement est un type de message déclenché par un producteur pour annoncer des faits. Les événements peuvent être des unités discrètes ou appartenir à une série.
Les événements discrets signalent un changement d’état. Les données d’événement contiennent des informations sur ce qui est arrivé, mais ne comportent pas les données qui ont déclenchés l’événement.
Par exemple, un événement discret peut avertir les consommateurs qu’un fichier a été créé.
Cet événement peut contenir des informations générales sur le fichier, mais pas le fichier lui-même. C’est aux consommateurs de récupérer les fichiers s’ils le souhaitent.
Les événements en série sont des suites d’événements discrets, chronologiques et liés entre eux. Ils permettent l’analyse des changements d’état du producteur de données par un consommateur, qui a besoin de la série séquencée des événements pour analyser ce qu’il s’est passé. Par exemple, les services d’événements en série utilisés dans les solutions Big Data ou IoT permettent au client de suivre l’historique des données issues des capteurs IoT et de construire les tendances de leurs services selon la saisonnalité de leur activité.
Quand choisir l’EDA
Le principe de base de l’EDA est le découplage entre producteur et consommateur.
Il répond avant tout à des situations où les consommateurs sont inconnus, ou nombreux et hétérogènes : le système n’a pas connaissance de qui ils sont, comment ils évoluent, et de ce qu’ils sont capables de faire.
Concrètement :
-
- Non connaissance des consommateurs
- Hétérogénéité des consommateurs (technologies, puissance de calcul, protocoles utilisés etc.)
- Nombre de consommateurs : le modèle EDA facilite la publication d’informations à de nombreux consommateurs, sans avoir à publier n fois le même message
- Besoin d’évolutivité de ces consommateurs ou du producteur
- Volume et vélocité élevés des données transmises, exemple des IoT.
Par ce découplage, l’EDA facilite la capacité du SI à évoluer et à monter en puissance, car il ne se fait pas limiter par ses systèmes (consommateurs) les moins véloces ou différents.
Également, le middleware reste simple et générique, il n’y a pas d’intelligence ou d’échange complexe de message, ce qui facilite cette montée en puissance.
On peut donc souligner les avantages suivants :
- Un accroissement de la scalabilité et la réactivité de l’expéditeur. Celui-ci peut rapidement envoyer un message unique au canal d’entrée, puis revenir à ses principales activités de traitement, l’infrastructure de messagerie se chargeant de vérifier que les messages sont remis aux abonnés.
- Une amélioration de la fiabilité. La messagerie permet aux applications éditrices et consommatrices de continuer à s’exécuter sans interruption en cas de charge accrue et de gérer plus efficacement les défaillances intermittentes.
- Un traitement différé ou planifié des messages. Les abonnés peuvent par exemple attendre les heures creuses pour récupérer ou traiter les messages selon une planification spécifique.
Les modèles de conception de l’EDA
Les modèles courants du côté des consommateurs sont :
- Traitement des événements simples (Simple Event Processing) : un événement déclenche immédiatement une action pour le consommateur. Par exemple, l’exécution d’une fonction serverless (cf. FaaS, Function as a Service) peut être déclenchée à chaque fois qu’un fichier est déposé dans un espace de stockage.
- Traitement des flux d’événements (Event Stream Processing) : un consommateur traite une série d’événements afin d’identifier et analyser les relations de cause à effet dans les données de ces événements. Par exemple, un moteur complexe d’analyse et de traitement des événements peut analyser les données d’un point de vente pour le contrôle des stocks et la détection d’anomalies et déclencher des flux de travail, comme la création d’alertes.
Une architecture basée sur les événements peut utiliser un modèle de publication/abonnement (Publish/subscribe pattern) ou un modèle de flux d’événements :
- Flux d’événements (Event streaming) : les événements sont écrits dans un journal. Ils sont classés dans un ordre strict et sont durables. Les clients ne s’abonnent pas aux flux, mais ils peuvent lire n’importe quelle partie du flux. Il revient au client d’avancer sa position dans le flux. Cela signifie qu’un client peut se joindre à tout moment et relire les événements.
Le modèle de flux d’événements (Event Streaming) est recommandé dans les situations suivantes où les données doivent être ingérées de plusieurs sources et traitées en quasi temps-réel, ou lorsque les consommateurs doivent rejouer une séquence d’évènements.
- Publication/abonnement (Pub/Sub) : les événements sont publiés et communiqués à chaque abonné. Une fois l’événement reçu, il ne peut pas être relu et les nouveaux abonnés ne le voient pas.
Le modèle éditeur-abonné est particulièrement recommandé dans les situations où la même information doit être utilisée par plusieurs consommateurs, sans attendre de réponse de leur part.
Conclusion
Au final, l’EDA s’inscrit dans une réponse à un besoin de scalabilité et d’échanges dans un environnement aux systèmes hétérogènes.
Il présente des avantages certains pour assurer l’évolutivité du SI grâce à un découplage des systèmes permettant malgré tout l’échange de données.
Il ne s’agit pas d’une réponse passe-partout : comme l’EDA ne comprend aucune logique métier, il ne s’inclut pas dans des flux trop complexes, avec des contrôles qui assurent la bonne exécution de cette logique.
Ainsi, l’EDA est une approche complémentaire dans le cadre de la construction d’un SI mais elle a des limites qui doivent être compensées par d’autres approches pour satisfaire l’ensemble des besoins métiers de l’entreprise.[/fusion_text][/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]