Style d’architecture basée sur les événements

Une architecture basée sur les événements est constituée de producteurs d’événements qui génèrent un flux d’événements et de consommateurs d’événements qui écoutent les événements.

Les événements étant remis en quasi-temps réel, les consommateurs peuvent y répondre immédiatement à mesure qu’ils se produisent. Les producteurs sont dissociés des consommateurs (un producteur ne peut pas identifier les consommateurs qui sont à l’écoute). Les consommateurs sont aussi dissociés les uns des autres, et chaque consommateur voit tous les événements. Il s'agit d'une différence notable par rapport au modèle des consommateurs concurrents, où les consommateurs extraient les messages d'une file d’attente et où un message est traité une seule fois (à condition qu'il n'y ait pas d'erreurs). Dans certains systèmes, comme IoT, les événements doivent être ingérés dans de très gros volumes.

Une architecture basée sur les événements peut utiliser un modèle de publication/abonnement (également appelé pub/sub) ou un modèle de flux d’événements.

• Publication/abonnement : l’infrastructure de messagerie effectue le suivi des abonnements. Quand un événement est publié, elle communique l’événement à chaque abonné. Une fois l’événement reçu, il ne peut pas être relu et les nouveaux abonnés ne le voient pas.

• Streaming d’événements : les événements sont écrits dans un journal. Les événements sont classés dans un ordre strict (au sein d’une partition) et sont durables. Les clients ne s’abonnent pas au 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.

Du côté du consommateur, il existe quelques variantes courantes :

• Traitement des événements simples : un événement déclenche immédiatement une action dans le consommateur. Par exemple, vous pouvez utiliser Azure Functions avec un déclencheur Service Bus, de telle sorte qu’une fonction s’exécute chaque fois qu’un message est publié dans une rubrique Service Bus.

• Corrélation entre les événements de base. Un consommateur doit traiter un petit nombre d’événements commerciaux discrets, généralement corrélés par un identifiant, en conservant certaines informations des événements antérieurs pour les utiliser lors du traitement des événements ultérieurs. Ce modèle est pris en charge par les bibliothèques telles que NServiceBus et MassTransit.

• Traitement des événements complexes : un consommateur traite une série d’événements, à la recherche de modèles dans les données d’événement, en s’appuyant sur une technologie telle que Azure Stream Analytics. Par exemple, vous pouvez agréger les relevés d’un appareil intégré dans une fenêtre de temps et générer une notification si la moyenne mobile dépasse un certain seuil.

• Traitement des flux d’événements : utilisez une plateforme de diffusion de données, telle qu’Azure IoT Hub ou Apache Kafka, comme pipeline pour ingérer les événements et les transmettre aux processeurs de flux. Les processeurs de flux agissent de façon à traiter ou transformer le flux. Il peut exister plusieurs processeurs de flux pour différents sous-systèmes de l’application. Cette approche est parfaitement adaptée aux charges de travail IoT.

La source des événements peut être extérieure au système. Il peut s’agir par exemple des appareils physiques d’une solution IoT. Dans ce cas, le système doit pouvoir ingérer les données selon le volume et le débit imposés par la source de données.

Dans le diagramme logique ci-dessus, chaque type de consommateur est représenté par un cadre unique. Dans la pratique, il est courant d’avoir plusieurs instances d’un même consommateur pour éviter que celui-ci devienne un point de défaillance unique dans le système. Plusieurs instances peuvent aussi s’avérer nécessaires pour gérer le volume et la fréquence des événements. De même, un même consommateur peut traiter les événements de plusieurs threads. Cela peut être une source de problèmes si les événements doivent être traités dans l'ordre ou s'ils nécessitent une sémantique « exactly-once » (exactement une fois). Consultez Réduire la coordination.

Il existe deux topologies principales dans de nombreuses architectures pilotées par les événements :

• Topologie de répartiteur. Les composants diffusent des événements à l’ensemble du système, et les autres composants agissent sur l’événement ou l’ignorent. Cette topologie est utile lorsque le flux de traitement des événements est relativement simple. Il n'y a pas de coordination ou d'orchestration centrale, de sorte que cette topologie peut être très dynamique. Elle est fortement découplée, ce qui contribue à l'évolutivité, à la réactivité et à la tolérance aux pannes des composants. Aucun composant ne possède ou ne connaît l’état d’une transaction commerciale à plusieurs étapes, et les actions sont effectuées de manière asynchrone. Ainsi, les transactions distribuées sont risquées car il n'existe aucun moyen natif de les relancer ou de les rejouer. La gestion des erreurs et les stratégies d’intervention manuelle doivent être soigneusement prises en compte, car cette topologie peut être une source d’incohérence des données.

• Topologie de médiateur. Cette topologie traite certaines des lacunes de la topologie de répartiteur. Il existe un médiateur d’événements qui gère et contrôle le flux des événements. Le médiateur d'événements maintient l'état et gère le traitement des erreurs et les capacités de redémarrage. Contrairement à la topologie de répartiteur, les composants diffusent des occurrences sous forme de commandes et uniquement vers des canaux désignés, généralement des files d’attente de messages. Ces commandes ne sont pas censées être ignorées par leurs consommateurs. Cette topologie offre un contrôle accrue, une meilleure gestion des erreurs distribuées et une meilleure cohérence des données. Cette topologie introduit un couplage accru entre les composants, et le médiateur d’événement pourrait devenir un goulot d’étranglement ou mettre en danger la fiabilité.

Quand utiliser cette architecture

• Plusieurs sous-systèmes doivent traiter les mêmes événements.
• Traitement en temps réel avec un décalage dans le temps minimal.
• Traitement des événements complexes, tel que les critères spéciaux ou l’agrégation dans des fenêtres de temps.
• Volume et vélocité élevés des données, par exemple IoT.

Avantages

• Les producteurs et les consommateurs sont dissociés.
• Aucune intégration point à point. Simplicité d’ajout de nouveaux consommateurs au système.
• Les consommateurs peuvent répondre immédiatement aux événements, dès leur arrivée.
• Architecture hautement scalable et distribuée.
• Les sous-systèmes ont des vues indépendantes du flux d’événements.

Défis

• Transmission non garantie.

  Dans certains systèmes, surtout dans les scénarios IoT, il est essentiel de garantir la transmission des événements.

• Traitement des événements dans l’ordre ou une seule fois.

  Chaque type de consommateur s’exécute généralement dans plusieurs instances à des fins de résilience et de scalabilité. Cela peut être une source de problèmes si les événements doivent être traités dans l’ordre (dans un type de consommateur) ou si la logique de traitement des messages idempotents n’est pas implémentée.

• Coordination des messages entre services.

  Dans le cadre de processus métier, les services sont souvent amenés à publier des messages et à s’y abonner pour obtenir un résultat cohérent à l’échelle de toute une charge de travail. Il est possible d’utiliser des modèles de workflow tels que le modèle de chorégraphie et l’orchestration Saga pour gérer de manière fiable les flux de messages entre divers services.

• Gestion des erreurs.

  L’architecture événementielle utilise principalement une communication asynchrone. Un défi avec la communication asynchrone est la gestion des erreurs. Une façon de résoudre ce problème est d’utiliser un processeur de gestion des erreurs distinct. Ainsi, lorsque le consommateur d’événements rencontre une erreur, il envoie immédiatement et de manière asynchrone l’événement erroné au processeur de gestion des erreurs et continue. Le processeur de gestion des erreurs tente de corriger l’erreur et renvoie l’événement au canal d’ingestion d’origine. Mais si le processeur de gestion des erreurs échoue, il peut alors envoyer l’événement erroné à un administrateur pour une inspection plus approfondie. Si vous utilisez un processeur de gestion des erreurs, les événements erronés seront traités hors séquence lorsqu’ils seront resoumis.

Considérations supplémentaires

• La quantité de données à inclure dans un événement peut être un facteur important qui affecte les performances et les coûts. Regrouper toutes les informations pertinentes nécessaires au traitement dans l’événement lui-même peut simplifier le code de traitement et éviter des recherches supplémentaires. Regrouper un minimum d’informations dans un événement, comme quelques identifiants seulement, réduit le temps et le coût de transport, mais nécessite le code de traitement pour rechercher toute information supplémentaire dont il a besoin. Pour plus d’informations à ce propos, consultez ce billet de blog.
• Bien qu’une requête soit visible uniquement par le composant de gestion des demandes, les événements sont souvent visibles par plusieurs composants d’une charge de travail, même si ces composants ne sont pas destinés à les consommer ou ne sont pas destinés à les consommer. En utilisant une mentalité de « violation de principe », gardez à l’esprit les informations que vous incluez dans les événements afin d’empêcher l’exposition involontaire d’informations.

Ressources associées

• Vidéo de discussion de la communauté sur les considérations relatives au choix entre la chorégraphie et l’orchestration.