Event Grid et architecture pilotée par les événements

Dans une architecture pilotée par les événements, les composants communiquent en publiant des événements et en s’y abonnant, plutôt qu’en s’appelant directement. Un composant (le producteur) émet un événement lorsqu’un fait important se produit : un fichier est envoyé, une commande est passée ou un appareil transmet une mesure. Les autres composants (les abonnés) réagissent indépendamment et de manière asynchrone aux événements qui les concernent. Cela découple les producteurs des consommateurs et améliore la capacité de montée en charge, la résilience et la maintenabilité.

Azure Event Grid est un service entièrement géré de routage d’événements qui transmet les événements de sources (éditeurs) à des gestionnaires (abonnés) selon un modèle push. Event Grid est conçu pour les événements réactifs et discrets : quelque chose a changé et vous devez réagir immédiatement. Il garantit une distribution au moins une fois avec de nouvelles tentatives automatiques, prend en charge le filtrage afin que les abonnés ne reçoivent que les événements pertinents, et peut acheminer les événements vers Azure Functions, Logic Apps, des webhooks, Event Hubs et des files d’attente Service Bus.

Les éditeurs envoient les événements vers une rubrique Event Grid. Les abonnés créent des abonnements aux événements sur une rubrique en indiquant un point de terminaison et, éventuellement, des règles de filtrage. Une même rubrique peut comporter plusieurs abonnements : chaque abonnement reçoit une copie indépendante des événements correspondants. Des services Azure tels que Blob Storage, Resource Manager, Service Bus et Azure Container Registry sont des sources d’événements intégrées, avec des rubriques système qui ne nécessitent aucune configuration supplémentaire.

Les événements publiés sur Event Grid suivent un schéma JSON standard comportant les champs obligatoires suivants : id (identifiant unique), eventType (par exemple Microsoft.Storage.BlobCreated), subject (chemin vers la ressource de l’événement), eventTime (horodatage ISO 8601), dataVersion et data (données spécifiques à l’événement). Event Grid prend également en charge le schéma CloudEvents (norme CNCF) afin d’assurer l’interopérabilité avec d’autres plateformes d’événements.

Les abonnements aux événements prennent en charge le filtrage afin de réduire le bruit à l’arrivée chez l’abonné. Vous pouvez filtrer selon le type d’événement (recevoir uniquement BlobCreated, et non BlobDeleted), selon le préfixe ou le suffixe de l’objet (uniquement les objets blob d’un conteneur donné), ou selon des filtres avancés appliqués à n’importe quel champ des données de l’événement à l’aide d’opérateurs tels que StringContains, NumberGreaterThan et BoolEquals. Le filtrage s’effectue côté serveur : les abonnés ne reçoivent donc que les événements correspondant à leurs critères.

Trois services Azure gèrent les événements et les messages : choisissez en fonction de votre scénario. Event Grid sert au routage réactif d’événements (faible volume, événements discrets et réactifs, par exemple une notification de modification d’une ressource). Event Hubs sert à la diffusion d’événements à haut débit (millions d’événements par seconde, télémétrie, chaînes de traitement des mégadonnées). Service Bus sert à la messagerie d’entreprise avec conservation de l’ordre, déduplication, mise en file d’attente des messages non distribuables et transactions (traitement des commandes, transactions financières).

Publiez des événements personnalisés sur une rubrique Event Grid à l’aide d’une simple requête HTTP POST utilisant la clé d’accès de la rubrique. Tout service ou toute application capable d’effectuer des requêtes HTTP peut publier des événements. Il devient ainsi très simple d’émettre des événements depuis des applications locales, des services tiers ou des services Azure qui ne prennent pas nativement en charge Event Grid. Regroupez jusqu’à 1 Mo d’événements par requête POST pour gagner en efficacité.

Si une tentative de distribution d’un événement échoue (l’abonné renvoie un code HTTP qui n’est pas 2xx), Event Grid effectue de nouvelles tentatives selon un délai exponentiel avec une variation aléatoire, pendant une durée maximale de 24 heures (configurable jusqu’à 72 heures), avec un maximum de 30 tentatives. Une fois toutes les tentatives épuisées, Event Grid peut placer les événements non distribués dans une file de mise en quarantaine d’un conteneur Azure Blob Storage afin de permettre leur examen manuel. Configurez cette fonctionnalité lorsque la distribution fiable des événements est essentielle et que vous devez auditer ou retraiter les événements ayant échoué.

Azure Event Hubs est une plateforme distribuée de diffusion de données capable de recevoir et de traiter des millions d’événements par seconde. Elle utilise un modèle de consommateurs partitionné : les événements sont répartis entre les partitions et chaque groupe de consommateurs lit les événements indépendamment, à son propre rythme. Plusieurs consommateurs peuvent ainsi traiter le même flux sans coordination. Parmi les cas d’utilisation courants figurent l’ingestion de données de télémétrie IoT, l’agrégation des journaux d’application, l’analyse des flux de clics et les chaînes de traitement des données pour les tableaux de bord en temps réel.

Azure Service Bus est un courtier de messagerie d’entreprise qui fournit des files d’attente (de point à point) et des rubriques avec abonnements (publication-abonnement). Contrairement à Event Grid (envoi sans accusé de suivi) et à Event Hubs (diffusion en continu), Service Bus garantit la distribution dans l’ordre (files FIFO), la détection des doublons, des files de mise en quarantaine pour les échecs de traitement, des sessions de messages pour le traitement groupé et des transactions — autant de fonctionnalités essentielles aux flux de traitement des opérations financières et des commandes.

Voici un modèle Azure courant piloté par les événements : un utilisateur envoie un fichier vers Blob Storage, qui déclenche un événement BlobCreated vers Event Grid. Event Grid achemine l’événement vers une Azure Function qui traite le fichier (redimensionne une image, extrait du texte ou valide des données), puis écrit le résultat dans Azure SQL Database. Si le traitement échoue, l’événement est placé dans une file de mise en quarantaine d’un conteneur de stockage. Cette chaîne complète ne nécessite ni interrogation périodique ni ressources de calcul persistantes lorsqu’elle est inactive.

Dans cette leçon, vous avez appris qu’Azure Event Grid achemine des événements discrets des éditeurs vers les abonnés au moyen d’une distribution push, avec filtrage et mise en quarantaine, vous avez distingué Event Grid (événements réactifs), Event Hubs (diffusion en continu) et Service Bus (messagerie d’entreprise fiable), et vous avez découvert comment créer des chaînes pilotées par les événements en reliant les événements de Blob Storage à Azure Functions via Event Grid. Nous allons maintenant découvrir les services Azure DevOps.