Que signifie « être piloté par 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.
Que signifie « en temps réel » ?
Une réaction en temps réel peut être considérée comme une réponse immédiate. Prenons l’exemple d’un serveur dans un café qui vous demande ce que vous voulez boire.
Le serveur attend une réponse immédiate ou au moins assez rapide. Sinon, il peut reformuler sa question ou penser que vous n’êtes pas poli. Une réponse rapide est demandée et est également appropriée. Le temps de réponse peut varier légèrement, mais il est toujours considéré comme « en temps réel ». Par conséquent, le message d’accueil doit être retourné rapidement, mais vous pouvez réfléchir brièvement à ce que vous voulez commander pour répondre à la question du caissier.
En termes de systèmes logiciels, vous vous souciez uniquement des délais : Le temps de réponse, l’heure d’achèvement, l’heure d’accès, les temps de démarrage, etc. L’utilisateur ou l’application à l’origine de l’accès définissent ces délais.
Remarque
En temps réel, les tâches système exécutent leur fonction dans les délais prescrits.
Vous devez toujours savoir ce qui se passe dans votre système. Veillez donc à ne pas oublier ce qui est évident, à savoir la journalisation, la supervision et la mesure de vos délais.
Important
Veillez à spécifier les échéances et les délais à l’avance et à configurer une solution de supervision non bloquante pour la vérification.
En résumé, nous convenons que la notion « en temps réel » signifie rapidement ou instantanément. Quelle est la rapidité exacte spécifiée par votre scénario donné.
Applications basées sur 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 déclencher et oublier (fire and forget). 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 courtier de messages comme Kafka. Nous n’attendons pas nécessairement une réponse du processus suivant dans le système. Un couplage faible est obtenu au détriment de la cohérence éventuelle, qui doit être prise en charge à un autre niveau.
Pour identifier la nature des applications pilotées par les événements, observons les principaux modèles d’architecture en suivant l’exemple d’un client, nommé Alex, qui achète un café et un cappuccino.
Notification d'événement
La notification d’événement est simplement la notification d’un événement spécifique. Chaque événement est vu séparément. L’exemple d’un client nommé Alex qui achète un café et un cappuccino peut se présenter comme suit :
1. Événement : Alex achète un café.
2. Événement : Alex achète un cappuccino.
Un barista doit écouter attentivement tous les événements pour obtenir l’ensemble de la commande d’Alex. Mais deux baristas peuvent également préparer et servir les boissons indépendamment.
Transfert d’état effectué par l’événement
Avec le transfert d’état effectué par l’événement, toutes les informations nécessaires sont stockées dans un seul événement. Cela est pratique, en cas de perte d’un événement ou si votre service n’écoute pas tous les événements. En ce qui concerne notre exemple, les événements se présenteraient comme suit :
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. Cela permettrait de servir la commande en une seule fois, mais le processus peut prendre plus de temps qu’en exécutant la commande de manière complètement indépendante.
Provisionnement en événements
Avec la fonction Approvisionnement en événements, le stockage des événements est mis en avant. Comme vous pouvez le voir, les événements sont les mêmes que dans le premier exemple. Toutefois, le barista est important dans ce concept au moment où il reçoit un événement, puis réfléchit à tous les événements correspondants pour obtenir l’état actuel de toutes les commandes passées par Alex.
Avec la deuxième commande, le barista sait que la commande d’Alex se compose d’un café, par la mémorisation de la première commande, et d’un cappuccino, qui vient juste d’être commandé. Travailler en parallèle avec un deuxième barista n’est plus vraiment possible.
Quand nous ajoutons un serveur chargé de recevoir les commandes et de servir les boissons, les baristas peuvent travailler indépendamment à la préparation des 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 également un découplage.
1. Événement : Alex achète un café.
Employé à la caisse : (Première) commande (pour Alex) : Café
2. Événement : Alex achète un cappuccino.
Employé à la caisse : (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 auxquels nous pouvons penser. Imaginez le scénario dans lequel vous exploitez un système de réfrigération, par exemple pour des denrées alimentaires ou des médicaments. Vous devez constamment contrôler la température et d’autres données pertinentes dans votre système. La connaissance des données de télémétrie et leur contrôle automatique sont essentiels à votre réussite. La mesure de la télémétrie toutes les deux secondes, puis l’envoi vers le système de contrôle où les données sont analysées, traitées et gérées, constituent 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 afin d’éviter des conséquences tragiques pour l’entreprise.