Qu'est-ce qu'un système basé sur les événements et quelle est la rapidité du temps réel ?

Si nous y réfléchissons, nous pouvons identifier de nombreux scénarios pilotés par les événements. Beaucoup d’entre eux nécessitent une réaction en temps réel.

Qu’entendons-nous en temps réel ?

Une réaction en temps réel peut être considérée comme une réponse immédiate. Prenons un exemple d’un caissier dans un café qui vous demande ce que vous voulez boire.

Le caissier s’attend à une réponse instantanée, ou au moins une réponse qui est donnée très tôt. Sinon, le caissier pourrait rééduler la question ou soupçonner que vous étiez grossier. Une réponse rapide est demandée et également appropriée. Le temps de réponse peut varier légèrement, mais il est toujours considéré comme étant « en temps réel ». Donc, le retour d’un message d’accueil devrait se produire rapidement, mais il est bon de penser brièvement à votre commande pour répondre à la question du caissier.

Si vous traduisez ce scénario en systèmes logiciels, vous vous souciez du moment : Temps de réponse, Heure d’achèvement, Heure d’accès, Heure de démarrage, et ainsi de suite. L’utilisateur ou l’application accédant définit ces minutages.

Vous devez toujours savoir ce qui se passe dans votre système. Veillez donc à ne pas oublier l’évidence, qui est la journalisation, la surveillance et la mesure de vos minutages.

En résumé, nous sommes d’accord que le temps réel signifie super rapide, en un instant. La rapidité exacte est spécifiée par votre scénario donné.

Applications pilotées par les événements

Si vous pensez à un événement de clic, vous pensez à autre chose. Les applications pilotées par les événements utilisent le principe de déclenchement et d’oubli . L’événement est envoyé ou déclenché vers le système suivant, qui peut être un autre service, un hub d’événements, un flux ou un répartiteur de messages comme Kafka. Nous n’attendons pas nécessairement une réponse du processus suivant dans le système. Le couplage libre est obtenu au prix de la cohérence éventuelle, qui doit être gérée à un autre niveau.

Pour identifier la nature des applications pilotées par les événements, examinons les principaux modèles d’architecture en utilisant l’exemple d’un client, nommé Alex, achetant un café et un cappuccino.

Notification d'événements

La notification d’événement est la notification d’un événement ou d’un événement spécifique. Chaque événement est vu séparément. L’exemple d’un client nommé Alex achetant un café et un cappuccino pourrait ressembler à ceci :

1. Événement : Alex achète un café.

2. Événement : Alex achète un cappuccino.

Un barista aurait à écouter attentivement tous les événements pour obtenir l’ordre entier d’Alex. Mais deux baristas pourraient également préparer et servir les boissons indépendamment.

Transfert d’état effectué par l’événement

Avec le transfert d’état porté par l’événement, toutes les informations nécessaires sont stockées dans un seul événement. Cela est pratique si un événement est perdu ou si votre service n’écoute pas tous les événements. Pour notre exemple, les événements ressemblent à ceci :

1. Événement : Alex achète un café.

2. Événement : Alex achète, en plus du café, un cappuccino.

Avec un seul barista, écouter uniquement le deuxième événement peut être suffisant. Avec deux baristas, le second doit regarder le premier. La commande peut être traitée ensemble, mais le processus peut prendre plus de temps que si on le faisait complètement séparé.

Approvisionnement en événements

Avec l’approvisionnement en événements, le stockage d’événements entre en focus. Comme vous pouvez le voir, les événements sont les mêmes que dans le premier exemple. Mais le barista est important pour ce concept au moment où le barista reçoit un événement, puis pense à tous les événements correspondants pour obtenir l’état actuel pour toutes les commandes effectuées par Alex.

Avec la deuxième commande, le barista sait que l’ordre d’Alex se compose d’un café, en se souvenant de la première commande, et un cappuccino, parce que cette boisson vient d’être commandé. Travailler en parallèle avec un deuxième barista n’est pas aussi facilement possible.

Lorsque nous ajoutons un caissier pour recevoir les commandes et servir les boissons, les baristas peuvent travailler indépendamment pour préparer les boissons. Ils n’ont pas besoin de savoir quoi que ce soit sur les clients. Dans ce scénario, le serveur correspond au « magasin d’événements », qui conserve les événements. L’approvisionnement en événements ajoute une autre couche de complexité, mais il ajoute également un découplage.

1. Événement : Alex achète un café.

Caissier : (Première) commande (pour Alex) : Café

2. Événement : Alex achète un cappuccino.

Caissier : (Deuxième) commande (pour Alex) : Cappuccino

Les données de télémétrie sont des événements en temps réel

Il existe également d’autres exemples dont nous pouvons penser. Imaginez le scénario d’exécution d’un système de réfrigération, par exemple, pour les fabricants d’aliments ou de médicaments. Vous avez besoin d’un contrôle constant de la température et d’autres données pertinentes dans votre système. La prise en compte des données de télémétrie et le contrôle automatiquement seraient essentielles à votre réussite. Mesurer les données de télémétrie toutes les deux secondes, puis les envoyer vers le système de contrôle où les données sont analysées, traitées et gérées est un système piloté par les événements. En outre, les données doivent être traitées en temps réel, car il est essentiel de réagir rapidement pour éviter les conséquences tragiques pour l’entreprise.