L'architecture orientée évènements est un modèle d'intégration construit autour de la publication, de la capture, du traitement et du stockage (ou de la persistance) des évènements. Lorsqu'une application ou un service effectue une action ou subit un changement dont une autre application ou un autre service pourrait avoir besoin d'être informé, elle ou il publie un évènement (un enregistrement de cette action ou de ce changement) qu'une autre application ou un autre service peut consommer et traiter pour effectuer des actions à son tour.

L'architecture orientée évènements permet un couplage lâche entre les applications et les services connectés. Ils peuvent communiquer entre eux en publiant et en consommant des évènements sans rien savoir les uns des autres, sauf le format de l'évènement. Ce modèle offre des avantages considérables par rapport à une architecture de requête/réponse (ou modèle d'intégration), dans laquelle une application ou un service doit demander des informations spécifiques à une autre application ou un autre service spécifique qui attend la requête spécifique.

L'architecture orientée évènements maximise le potentiel des applications cloud natives et permet d'utiliser des technologies d'applications puissantes, telles que l'analytique en temps réel et l'aide à la décision.

Dans une architecture orientée évènements, les applications jouent le rôle de producteurs ou de consommateurs d'évènements (et souvent les deux).

Un producteur d'évènements transmet un évènement sous la forme d'un message à un courtier ou à une autre forme de routeur d'évènements, dans lequel l'ordre chronologique de l'évènement est conservé par rapport aux autres évènements. Un consommateur d'évènements ingère le message en temps réel (au moment où il se produit) ou à tout autre moment qu'il souhaite et traite le message pour déclencher une autre action, un flux de travail ou un évènement qui lui est propre.

Dans un exemple simple, un service bancaire pourra transmettre un évènement « dépôt », qu'un autre service de la banque consommera et auquel il répondra en inscrivant un dépôt sur le relevé du client. Mais les intégrations orientées évènement peuvent également déclencher des réponses en temps réel basées sur l'analyse complexe d'énormes volumes de données, comme lorsque « l'évènement » d'un client cliquant sur un produit sur un site de commerce électronique génère des recommandations de produits instantanées basées sur les achats d'autres clients.

Il existe deux modèles de base pour la transmission des évènements dans une architecture orientée évènements.

Messagerie d'évènements ou publication/abonnement

Dans le modèle de messagerie d'évènements ou de publication/abonnement, les consommateurs d'évènements s'abonnent à une ou plusieurs classes de messages publiés par les producteurs d'évènements. Lorsqu'un producteur d'évènements publie un évènement, le message est envoyé directement à tous les abonnés qui veulent le consommer.

En général, un courtier de messages s'occupe de la transmission des messages d'évènements entre les éditeurs et les abonnés. Le courtier reçoit chaque message d'évènement, le traduit si nécessaire, maintient son ordre par rapport aux autres messages, les met à la disposition des abonnés pour qu'ils les consomment, puis les supprime une fois qu'ils ont été consommés (afin qu'ils ne puissent plus être consommés à nouveau).

Transmission d'événements en continu

Dans le modèle de transmission d'évènements en continu, les producteurs d'évènements publient des flux d'évènements en direction d'un courtier. Les consommateurs d'évènements s'abonnent aux flux, mais au lieu de recevoir et de consommer chaque évènement au fur et à mesure de sa publication, les consommateurs peuvent accéder à chaque flux à tout moment et consommer uniquement les évènements qu'ils souhaitent. La différence essentielle ici est que les évènements sont conservés par le courtier même une fois que les consommateurs les ont reçus.

Une plateforme de diffusion en continu de données, telle que Apache Kafka, gère l'enregistrement et la transmission d'énormes volumes d'évènements à très haut débit (littéralement des milliards d'enregistrements d'évènements par jour, en temps réel, sans retard de performance). Une plateforme de diffusion en flux présente certaines caractéristiques qu'un courtier en messages ne possède pas :

• Persistance des évènements : comme les consommateurs peuvent consommer les évènements à tout moment après leur publication, les enregistrements de flux d'évènements sont persistants ; ils sont conservés pendant une durée configurable, allant de quelques fractions de seconde à une éternité. Cela permet aux applications de flux d'évènements de traiter des données historiques, ainsi que des données en temps réel.
  
  
• Traitement d'évènements complexes : comme la messagerie d'évènements, la transmission d'évènements en continu peut être utilisée pour le traitement d'évènements simples, dans lequel chaque évènement publié déclenche la transmission et le traitement par un ou plusieurs consommateurs spécifiques. Mais elle peut également être utilisée pour le traitement d'évènements complexes, dans lequel les consommateurs d'évènements traitent des séries entières d'évènements et exécutent des actions en fonction du résultat.

Comparée à l'architecture d'application de demande/réponse, l'architecture orientée évènements offre plusieurs avantages et possibilités aux développeurs et aux entreprises.

Réponse et analytique puissantes en temps réel : la transmission d'évènements en continu permet aux applications de réagir aux situations commerciales changeantes au moment où elles se produisent, puis de faire des prévisions et de prendre des décisions sur la base de toutes les données actuelles et historiques disponibles en temps réel. Cela présente des avantages dans de nombreux domaines, qu'il s'agisse de traiter les flux de données générés par une myriade d'appareils IoT, de prévoir et d'éliminer les menaces de sécurité à la volée ou d'automatiser les chaînes d'approvisionnement pour une efficacité optimale.

Tolérance aux pannes, évolutivité, maintenance simplifiée, polyvalence et autres avantages du couplage lâche : les applications et les composants d'un article orienté évènements ne dépendent pas de la disponibilité des autres ; ils peuvent être mis à jour, testés et déployés indépendamment sans interruption de service, et lorsqu'un composant tombe en panne, une sauvegarde peut être mise en ligne. La persistance des évènements permet de « rejouer » des évènements passés, ce qui peut aider à récupérer des données ou des fonctionnalités en cas de panne d'un consommateur d'évènements. Les composants peuvent être mis à l'échelle facilement et indépendamment les uns des autres sur le réseau, et les développeurs peuvent réviser ou enrichir les applications et les systèmes en ajoutant et en supprimant des producteurs et des consommateurs d'évènements.

Messagerie asynchrone : l'architecture orientée évènements permet aux composants de communiquer de manière asynchrone. Les producteurs publient des messages d'évènements, selon leur propre calendrier, sans attendre que les consommateurs les reçoivent (ou même sans savoir si les consommateurs les ont reçus). En plus de simplifier l'intégration, cela améliore l'expérience de l'application pour les utilisateurs. Un utilisateur qui termine une tâche dans un composant peut passer à la tâche suivante sans attendre, indépendamment des intégrations en aval entre ce composant et les autres composants du système.

Dans les microservices (une architecture fondamentale d'applications cloud natives), les applications sont assemblées à partir de services à couplage lâche et déployables indépendamment. Les principaux avantages des microservices sont essentiellement les avantages du couplage lâche : facilité de maintenance, souplesse de déploiement, évolutivité indépendante et tolérance aux pannes.

Il n'est pas surprenant que l'architecture orientée évènements soit largement considérée comme la meilleure pratique pour la mise en œuvre des microservices. Les microservices peuvent communiquer entre eux à l'aide d'API REST. Mais le système REST, un modèle d'intégration de type demande/réponse, compromet bon nombre des avantages de l'architecture de microservices à couplage lâche en forçant une intégration synchrone et étroitement couplée entre les microservices