Qu'est-ce que l'architecture orientée événements ? Modèles, exemples et utilisations

Les entreprises s'appuient sur diverses technologies et outils pour faire fonctionner leur activité efficacement.

Cependant, ceux-ci peuvent rapidement devenir obsolètes, entraînant une dégradation des performances, une augmentation des coûts et des risques, ainsi que des menaces pour la sécurité. Il n'est pas difficile de voir comment les architectures monolithiques et démodées peuvent souvent constituer un goulot d'étranglement pour la modernisation de votre entreprise.

Une façon d'améliorer l'agilité et l'évolutivité de votre infrastructure informatique est d'adopter une architecture orientée événements. Dans une architecture orientée événements, les systèmes sont construits autour d'événements, qui sont des messages indiquant qu'un événement s'est produit. Cela permet de construire des systèmes qui réagissent rapidement aux changements de leur environnement, les rendant plus agiles et adaptables.

La plupart des systèmes orientés événements utilisent des logiciels de file d'attente de messages pour communiquer entre des systèmes disparates et permettre une communication en temps réel sur une seule couche.

Le modèle de processus d'architecture orientée événements remplace le modèle conventionnel "requête/réponse" dans lequel les services devaient attendre une réponse avant de passer à l'activité suivante. Il offre également des informations en temps réel sur le comportement des utilisateurs, les processus commerciaux et les opérations.

Les événements régissent le flux de l'architecture orientée événements, qui est conçue pour réagir aux événements ou effectuer des opérations en réponse à un événement.

Que signifie être orienté événements ?

Les événements sont des instances d'actions. Ils se produisent lorsque quelque chose se passe à l'intérieur ou à l'extérieur de votre entreprise. Ces activités peuvent inclure un achat par un consommateur, une mise à jour de l'inventaire d'un entrepôt, une tentative de violation de données ou un changement de statut pour une application.

Étant donné que de nombreux événements sont sensibles au temps ou critiques pour les opérations commerciales, les entreprises souhaitent concevoir leurs infrastructures autour de la collecte et de la réponse à ces événements. L'entreprise est dite orientée événements lorsque les événements provoquent une réponse de l'entreprise. À l'ère moderne, les événements sont traités par des systèmes informatiques qui collectent, analysent et réagissent aux événements en fonction d'une logique prédéfinie.

Les architectures orientées événements sont également appelées architectures collaboratives asynchrones car elles reposent sur la messagerie asynchrone entre les différentes parties d'un système avec des réponses en temps réel. Désormais, des systèmes comme les banques et la télémétrie passent au modèle centré sur les événements, où ils commencent à collecter des données en transit et à y réagir en fonction des événements.

Examinons un exemple bancaire d'architecture orientée événements. Le paiement se fait à un endroit spécifique. Dans ce cas, l'architecture orientée événements répond à cette demande plus rapidement et plus précisément que l'approche traditionnelle de requête/réponse, qui vous oblige à attendre une réponse avant de poursuivre votre transaction.

Cela ajoute des fonctionnalités riches, telles que des alertes de fraude et des couches de sécurité qui aident à protéger les clients contre les cybercriminels.

Importance des systèmes orientés événements

Un débit élevé, une évolutivité et une agilité sont des caractéristiques clés des leaders numériques d'aujourd'hui, dont beaucoup ont adopté les microservices et l'architecture orientée événements.

Les infrastructures informatiques monolithiques reposent sur une communication synchrone dans laquelle deux programmes interagissent directement, le plus souvent via des interfaces de programmation d'applications (API). En revanche, la communication asynchrone est orientée événements, permettant à plusieurs applications d'interagir simultanément et rapidement en temps réel. L'EDA est souvent la méthode la plus efficace pour permettre l'interaction d'applications orientées événements asynchrones.

Les entreprises qui utilisent une architecture orientée événements peuvent profiter des avantages d'une communication en temps réel évolutive et robuste en utilisant des files d'attente de messages. De nombreux projets stratégiques peuvent en bénéficier, notamment l'internet des objets (IoT), le commerce électronique, l'intégration de données entre systèmes, ainsi que la détection de fraudes financières et en périphérie.

Architecture orientée événements vs. architecture traditionnelle

Les architectures orientées événements et traditionnelles diffèrent fondamentalement dans les approches de communication et de conception de systèmes. L'EDA repose sur la communication asynchrone, où les événements déclenchent des interactions entre des composants faiblement couplés, permettant une réactivité en temps réel et une évolutivité élevée. Cela la rend idéale pour les systèmes complexes et distribués tels que l'IoT, l'analyse en temps réel et la détection de fraudes financières.

En revanche, l'architecture traditionnelle suit un modèle de requête-réponse impliquant une interaction directe entre des composants étroitement couplés. Bien qu'elle soit plus facile à mettre en œuvre pour des flux de travail simples comme les systèmes transactionnels, les architectures synchrones ont souvent du mal avec la latence et l'évolutivité dans des environnements distribués.

Le choix entre ces approches dépend des exigences du système. L'EDA est préférée pour les systèmes dynamiques, évolutifs et résilients, tandis que les architectures traditionnelles conviennent aux applications avec des schémas de communication plus simples et prévisibles.

Comment fonctionne l'architecture orientée événements ?

Un modèle d'architecture orientée événements aide à développer et déployer des applications et systèmes qui transfèrent des événements entre des composants et services de système faiblement couplés. Une infrastructure orientée événements comporte trois composants principaux :

1. Producteurs d'événements, également appelés émetteurs et agents d'événements
2. Consommateurs d'événements ou récepteurs
3. Courtiers ou canaux

Un producteur d'événements surveille ou détecte un événement et le convertit en message. Après avoir détecté un événement, le producteur envoie le message au consommateur via des canaux d'événements. Le producteur ne connaît pas les consommateurs de l'événement et ne connaîtra jamais le résultat de l'événement.

Les consommateurs d'événements sont responsables de déclencher une réponse lorsqu'un événement se produit. Un consommateur d'événements peut ou non fournir une réponse complète. Par exemple, le consommateur pourrait être responsable de filtrer, traiter et relayer l'événement au composant suivant (généralement des plateformes de streaming d'événements) ou offrir une réponse autonome à un événement.

La plateforme de traitement des événements détermine la réponse appropriée à un événement et transmet l'activité en aval aux consommateurs concernés, où le résultat de l'événement est visible.

L'architecture orientée événements favorise le découplage des applications grâce à un courtier d'événements, similaire à un courtier de messages, qui achemine les événements des producteurs vers les consommateurs. Ces courtiers peuvent être mis en œuvre à l'aide de middleware orienté messages, garantissant que les applications et appareils n'ont pas besoin de connaître la source ou la destination des données. Bien que le découplage pose des défis, il améliore considérablement la flexibilité et l'évolutivité.

Dans l'EDA, les événements sont envoyés sans attendre de réponse autre qu'un accusé de réception du courtier d'événements. Ce découplage garantit que les émetteurs et récepteurs fonctionnent indépendamment.

Les connexions directes entre producteurs et consommateurs peuvent contourner le besoin d'un courtier, comme un producteur interagissant directement avec une base de données pour stocker des événements à des fins d'analyse. Cependant, dans la plupart des configurations, plusieurs émetteurs d'événements génèrent divers événements, avec un ou plusieurs récepteurs les traitant.

Modèles d'architecture orientée événements

Un modèle EDA spécifie comment les producteurs, consommateurs et courtiers d'événements interagissent entre eux. Deux principaux modèles d'architecture orientée événements existent : éditeur/abonné et streaming d'événements.

Architecture éditeur/abonné

Cette architecture basée sur la file d'attente de messages dépend des abonnements aux flux d'événements pour la communication. Le routeur d'événements dans une architecture éditeur/abonné (le modèle pub/sub) enregistre les abonnements des clients aux canaux d'événements. Ce modèle envoie des notifications aux abonnés qui doivent être alertés lorsqu'un événement se produit ou est publié.

Étant donné que les événements ne peuvent pas être rejoués, un consommateur qui s'abonne après qu'un événement s'est produit ne peut pas y accéder plus tard. À partir de ce moment, le consommateur reçoit de nouveaux événements. ActiveMQ et RabbitMQ sont deux courtiers bien connus pour le modèle pub/sub.

Architecture de streaming d'événements

Le streaming d'événements transcende le modèle basé sur l'abonnement. Cette technique stocke les événements dans un journal auquel tous les consommateurs peuvent accéder pour découvrir des événements importants. Les consommateurs peuvent lire à partir de n'importe quelle zone de flux et rejouer des événements précédents.

Apache Kafka est une solution de traitement de flux bien connue. De nombreuses entreprises choisissent Kafka car c'est une solution établie et robuste. En tant que plateforme de traitement de flux de niveau industriel, Kafka a une large base d'utilisateurs, une communauté de soutien et un ensemble d'outils avancés.

D'autres plateformes offrent un mélange de traitement de flux et pub/sub ou leur solution distincte. Pulsar, un produit récent d'Apache, est une plateforme de messagerie pub/sub open-source et riche en fonctionnalités qui facilite à la fois les flux et la mise en file d'attente d'événements, le tout avec une vitesse exceptionnellement élevée.

NATS est un système de messagerie pub/sub qui utilise la "mise en file d'attente synthétique". NATS, ou système de transport autonome neural, est conçu pour fournir des communications courtes et fréquentes. Il offre d'excellentes performances et une latence réduite. Cependant, NATS considère qu'une certaine fuite de données est acceptable, plaçant la performance avant les promesses de livraison.

Exemple d'architecture orientée événements

Voici un exemple d'approche orientée événements pour un site de commerce électronique. Cette architecture permet au site Web de répondre aux mises à jour de plusieurs sources lors d'une forte demande sans perturber le système ou surprovisionner les ressources.

Considérons comment un détaillant en ligne peut utiliser une architecture orientée événements comme exemple. Les clients sont sur le point de passer à la caisse en ligne, et saisir leurs informations de paiement sur une plateforme de commerce électronique est une action fréquente et cruciale. L'interface utilisateur (UI) génère l'événement "Paiement soumis" avec les informations de carte de crédit, et le routeur d'événements sait diriger la notification d'événement vers le service de paiement en fonction des métadonnées de l'événement.

Après avoir reçu la notification, le service de paiement traite l'événement et crée un nouvel événement "Paiement traité" qui indique le succès ou l'échec de l'opération.

Le routeur d'événements renvoie des informations à l'UI, affichant le statut du consommateur et lui demandant de prendre des actions prédéfinies. Par exemple, si un paiement échoue, l'UI peut rouvrir le formulaire pour corriger les détails. Mais si le paiement est réussi, l'UI fournit les informations finales de commande et la date de livraison estimée.

Ni le site frontal ni les services dorsaux ne sont conscients de l'existence de leurs équivalents. Ils s'abonnent aux événements "Paiement soumis" et "Paiement traité", que le routeur d'événements maintient.

Cas d'utilisation de l'architecture orientée événements

Les entreprises s'appuient sur l'EDA pour créer des systèmes qui répondent à une variété de cas d'utilisation. Les plus populaires peuvent inclure :

• Surveillance en temps réel : Les systèmes peuvent créer des événements à mesure que leurs états changent, permettant aux entreprises de rechercher des irrégularités et des comportements suspects.
• Réplication de données : Un seul événement peut être utilisé par de nombreux services qui nécessitent la réplication de données dans leurs bases de données.
• Redondance : Si un service est indisponible, les événements peuvent être stockés dans le routeur jusqu'à ce que le service soit prêt à consommer l'événement.
• Traitement parallèle : Un seul événement peut initier plusieurs processus et s'exécuter de manière asynchrone.
• Interopérabilité : Les événements peuvent être stockés et distribués indépendamment du langage dans lequel les applications sont construites.
• Microservices : L'EDA est fréquemment intégrée aux microservices pour transférer efficacement des données entre des processus découplés à grande échelle.

Avantages d'une architecture orientée événements

L'EDA simplifie le développement par les entreprises d'un système flexible qui réagit aux changements et prend des décisions en temps réel. Voyons quelques façons dont une architecture orientée événements se rend utile.

• Découplage : Les services n'ont plus besoin d'être conscients de l'existence d'autres systèmes pour interagir. Ils doivent être conscients des événements, mais le courtier distribue les événements appropriés aux systèmes corrects. Cela produit des microservices très faiblement couplés qui sont faciles à adapter, tester et déployer.
• Immutabilité : Étant donné que les événements ne peuvent pas être modifiés après avoir été générés, personne n'a à s'inquiéter de quelqu'un d'autre modifiant leur contenu plus tard.
• Réduction des dépenses : Les architectures orientées événements sont basées sur le push, donc tout se produit dès que l'événement apparaît dans le courtier. Les utilisateurs n'ont pas à payer pour un sondage continu pour vérifier un événement. Cela conduit à une utilisation moindre de la bande passante réseau, une consommation moindre de CPU et moins de poignées de main SSL/TLS.
• Tolérance aux pannes : Si un consommateur cesse brusquement de fonctionner ou échoue à traiter un événement, le courtier d'événements ne le considère pas comme traité avec succès. L'événement n'est pas perdu ; il est plutôt reconsommé par une autre instance de consommateur ou traité à nouveau lorsque le consommateur est disponible.
• En temps réel : Une conception orientée événements offre une visibilité inégalée et en temps réel sur tout ce qui se passe dans le système. La capacité de consommer cette connaissance, de tirer des insights au fur et à mesure qu'ils se produisent et d'automatiser la prise de décision est aussi simple que d'ajouter des consommateurs aux événements actuels. Ajouter des fonctionnalités en temps réel à d'autres architectures est faisable mais implique des efforts supplémentaires, de nouveaux outils et des modifications des composants existants.
• Évolutivité : Un seul événement peut être utilisé pour activer de nombreuses actions pour divers consommateurs, permettant une exécution de tâches en parallèle et de meilleures performances. Vous n'avez pas à modifier la logique pour chaque service ou système, vous pouvez donc facilement ajuster la pile technologique pour répondre à de nouvelles exigences ou besoins.
• Récupération : Lorsque vous utilisez un courtier d'événements qui fournit des flux d'événements continus et résilients, vous pouvez "rejouer" des événements passés pour restaurer le travail manquant ou reconstruire la configuration du système.

Défis d'une architecture orientée événements

Maintenant que nous avons couvert tous les avantages de l'infrastructure orientée événements, examinons ses limitations. Certains de ces compromis existent dans d'autres approches de conception, comme le développement de microservices REST, mais ils sont accentués dans une conception orientée événements.

• Complexité : Le découplage élimine le besoin de traçage des dépendances et d'autres obstacles à un modèle de microservices. Le fardeau des services indépendants est qu'il devient plus difficile de comprendre la progression des événements à travers de nombreuses applications, par opposition à la dépendance directe, où les relations sont plus claires.
• Flux synchrones : Parce que les événements sont asynchrones, ce paradigme a du mal à prendre en charge les activités synchrones lorsque le résultat des actions doit être envoyé dans le même cadre de requête-réponse.
• Conception d'événements : Concevoir des événements est difficile. Étant donné que chaque consommateur peut s'abonner à l'événement, il doit être réutilisable, ce qui sacrifie la personnalisation. En même temps, la conception ne peut pas être si générale que le but devient obscur.
• Évolution des événements : À mesure que les systèmes se développent au fil du temps, les événements doivent suivre pour s'adapter aux caractéristiques changeantes du système. Mettre à jour les événements sans affecter d'autres microservices peut être délicat, en particulier dans un scénario distribué où les équipes ne sont pas en contact avec les personnes qui traitent les événements qu'elles créent.

Évoluez votre infrastructure pour réussir

Les architectures orientées événements empilent les services sur une seule couche de transaction. Cette approche permet aux entreprises de détecter les problèmes, de réagir rapidement aux résolutions et de soutenir plus rapidement les processus commerciaux dynamiques.

Des données, des données partout. Obtenez un logiciel de traitement de flux d'événements pour vous aider à comprendre et traiter les données commerciales en transit.

L'article a été initialement publié en 2022. Il a été mis à jour avec de nouvelles informations.