Table of Contents

Ce qui est l'architecture de l'événement et pourquoi il importe maintenant

L'architecture d'événements (EDA) est devenue une pierre angulaire de la conception moderne des microservices. À mesure que les organisations étendent leurs systèmes distribués, le modèle traditionnel de requête-réponse synchrone introduit un couplage serré, des défaillances en cascade et un débit limité. EDA résout ces problèmes en déplaçant la communication vers des événements asynchrones – les services publient des faits sur ce qui s'est passé, et d'autres services réagissent de façon indépendante.

Principes de base de l'architecture animée par des événements

Communication asynchrone

Les services n'attendent pas une réponse après avoir publié un événement. Le producteur publie un événement à un courtier de message et poursuit immédiatement son travail. Les consommateurs traitent les événements à leur propre rythme. Ce comportement non-blocage maximise le débit et maintient les services réactifs même lorsque les composants en aval sont lents ou indisponibles.

Couplage de la marge

Un nouveau consommateur peut s'abonner à un sujet d'événement existant sans aucune modification pour le producteur. Ce découplage permet aux équipes de développer, déployer et étendre leurs services de manière indépendante. Il facilite également le remplacement ou la retraite des anciens services sans rompre le système.

Immutabilité de l'événement

Une fois publié, un événement ne peut être modifié. Les événements représentent des faits sur les événements passés – un client enregistré, une commande passée, un paiement effectué. L'immutabilité fournit une piste d'audit fiable, simplifie le débogage et permet de rejouer l'événement pour la récupération ou le test.

Cohérence événementielle

Les systèmes axés sur les événements échangent une forte cohérence pour la disponibilité et la tolérance à la partition. Après la publication d'un événement, il y a un retard avant que tous les consommateurs mettent à jour leur état. Les applications doivent être conçues pour traiter des incohérences temporaires. Par exemple, un site de commerce électronique peut afficher une « commande en attente » pendant quelques secondes après la soumission pendant que les services d'inventaire, de paiement et d'expédition traitent l'événement.

Composantes clés d'un système d'entraînement d'événements

Producteurs d'événements

Les producteurs devraient se concentrer sur les événements pertinents pour les entreprises, et non sur les événements techniques de faible niveau. Au lieu de publier la « ligne de base de données mise à jour », publier « l'adresse du client a changé ». Les producteurs ont besoin de mécanismes de livraison fiables, y compris des relevés et une reconnaissance du courtier.

Consommateurs d'événements

Un événement unique peut déclencher plusieurs consommateurs – par exemple, un événement « placé par ordre » peut mettre à jour l'inventaire, envoyer un courriel de confirmation et analyser le journal. Les consommateurs doivent être idéoptents : traiter le même événement deux fois devrait avoir le même effet que le traiter une fois. Ceci est essentiel parce que la plupart des courtiers de messages fournissent au moins une fois la livraison. Les consommateurs devraient également mettre en œuvre une gestion appropriée des erreurs, en distinguant entre les défaillances transitoires (réessayer avec le recul) et les défaillances permanentes (envoyer à la file d'attente de lettres mortes).

Courtier de message / Bus événementiel

Le courtier se situe entre les producteurs et les consommateurs, gérant le routage, la persistance et la livraison des événements. Il fournit le mécanisme de publication-abonnement qui permet un couplage lâche.

  • Persistance : Les événements survivent au redémarrage des courtiers.
  • Livraison garantie: Au moins une fois ou exactement une fois sémantique.
  • Garanties de commande : Dans une partition ou un sujet.
  • Scalabilité: partitionnement horizontal pour gérer un débit élevé.
  • Tenues de lettres mortes: Pour la manipulation de messages échouée.

Thèmes et canaux

Les événements sont organisés en thèmes ou en canaux.Un sujet regroupe des événements liés – par exemple, "order events" ou "payment events". La granularité des sujets est une décision de conception : trop grossière et les consommateurs reçoivent beaucoup d'événements non pertinents ; trop bien et vous avez une explosion de sujets.

Quand utiliser Event Driven Architecture vs Request-Reponse

L'EDA n'est pas le bon choix pour chaque scénario. Utilisez-le lorsque:

  • Vous avez besoin d'une échelle de services indépendante.
  • La résilience du système exige qu'une défaillance de service ne s'enchaîne pas.
  • Vous avez plusieurs consommateurs pour les mêmes données ou actions.
  • La réaction en temps réel aux changements d'état est essentielle.
  • Vous voulez une piste de vérification immuable de tous les événements d'affaires.

Éviter l'AED lorsque:

  • Votre cas d'utilisation exige une bonne cohérence immédiate (p. ex., mises à jour du grand livre financier).
  • Vous avez un flux linéaire simple avec peu de services.
  • Votre équipe manque d'expérience avec les systèmes asynchrones et de cohérence.
  • Des réponses synchrones à faible latence sont nécessaires pour les demandes faisant appel à l'utilisateur.

De nombreux systèmes utilisent une approche hybride : API synchrones pour les opérations simples CRUD et les modèles d'événements pour les flux de travail complexes, les intégrations et les fonctionnalités en temps réel.

Modèles d'architecture commune entraînée par l'événement

Notification de l'événement

Le modèle le plus simple : un événement léger avec des données minimales (souvent un type d'identification et d'événement) est publié pour informer les consommateurs. Les consommateurs demandent ensuite des détails au producteur. Cela réduit la taille de la charge utile de l'événement mais introduit le couplage parce que les consommateurs doivent savoir interroger le producteur.

Transfert d'État effectué par un événement

Les événements portent tous les besoins des consommateurs de données. Lorsqu'un client change d'adresse, l'événement inclut la nouvelle adresse complète. Cela élimine le besoin de requêtes synchrones, réduit le couplage et améliore les performances des consommateurs. Le compromis est des événements plus importants et le chevauchement potentiel des données entre les services.

Sourcing événement

L'état du système est dérivé du journal des événements plutôt que stocké directement. Chaque changement d'état est annexé comme un événement immuable. L'état actuel est reconstruit par rejouage d'événements (éventuellement avec des instantanés pour la performance). L'approvisionnement en événements fournit une auditabilité parfaite, des requêtes temporelles, et la capacité de reconstruire des modèles de lecture.

CQRS (Segrégation des responsabilités de la Commission d'enquête)

Les commandes génèrent des événements consommés pour mettre à jour les modèles de lecture. Cela vous permet d'optimiser chaque modèle de façon indépendante – par exemple en utilisant un magasin d'écriture hautement normalisé et un magasin de lecture dénormalisé optimisé pour des requêtes spécifiques. CQRS est souvent utilisé avec le sourcing d'événements, mais peut également être utilisé de façon indépendante.

Modèle de Saga

Sagas coordonne les transactions multi-étapes entre microservices sans verrous distribués. Chaque étape publie un événement qui déclenche l'étape suivante. Si une étape échoue, compensant les événements annuler les étapes précédentes. Il y a deux styles d'implémentation:

  • Choréographie: Chaque service sait quel événement publier après avoir effectué sa transaction locale. Ceci est simple mais peut être difficile à tracer.
  • Orchestration: Un coordonnateur central (gestionnaire de saga) envoie des commandes et écoute les événements, en décidant de l'étape suivante. Cela offre une meilleure visibilité mais introduit un point central de coordination.

Les sagas sont essentiels pour assurer la cohérence des données dans les systèmes distribués, et éventuellement cohérents.

Technologies populaires pour l'architecture d'événement Driven

Apache Kafka

Kafka est la principale plateforme de diffusion distribuée pour le traitement des événements à haut débit et tolérant les défauts. Elle organise les événements en thèmes, supporte le cloisonnement pour l'évolutivité et fournit une forte commande dans les partitions. Kafka conserve les événements pour une période configurable, permettant à la fois le traitement en temps réel du flux et le replay historique. L'écosystème comprend Kafka Streams, Kafka Connect et une riche bibliothèque cliente. Kafka a une courbe d'apprentissage raide et nécessite une expertise opérationnelle importante. En savoir plus sur le site officiel.

LapinMQ

RabbitMQ est un courtier de messages mature et riche en fonctionnalités qui met en œuvre AMQP et d'autres protocoles. Il prend en charge le routage flexible par des échanges et des files d'attente, publie-subscribe, files d'attente de travail et des fonctionnalités avancées comme les échanges de lettres mortes et les files d'attente prioritaires. RabbitMQ est plus facile à mettre en place et à opérer que Kafka, ce qui en fait un bon choix pour les équipes nouvelles à l'EDA ou pour les cas d'utilisation qui ne nécessitent pas de Kafkas extrême débit ou rétention à long terme.

Amazon EventBridge

EventBridge est un bus événementiel sans serveur qui relie les services AWS, les applications SaaS et les applications personnalisées. Il offre un registre de schéma, le filtrage d'événements, la transformation et l'intégration native avec les fonctions Lambda et Step. EventBridge ne nécessite pas de gestion d'infrastructure et d'échelles automatiquement.

Hubs d'événements Azure et bus de service

Azure Event Hubs est une plateforme de diffusion de données massives pour l'ingestion de télémétrie, similaire à Kafka. Azure Service Bus est un courtier de messages d'entreprise entièrement géré pour publier-abonnement et files d'attente, avec des fonctionnalités comme les transactions, la détection du duplicata, et la lettre morte.

Google Cloud Pub/Sub

Pub/Sub est un service de messagerie global entièrement géré avec livraison au moins une fois et à l'échelle automatique. Il prend en charge la livraison poussée et tirant et s'intègre aux services Google Cloud. C'est un choix solide pour les architectures basées sur GCP.

Concevoir des événements pour votre système

Événement Granularité

Les événements devraient représenter des événements commerciaux significatifs au bon niveau d'abstraction. Évitez les événements techniques comme « ligne de base de données mise à jour. » Au lieu de cela, les événements modèles autour des concepts de domaine: « CustomerInscribed », « OrderShipped », « Payment Failed ». Les événements devraient être atomiques – un événement par fait commercial.

Conventions sur la désignation des événements

Utilisez le passé tendu pour indiquer quelque chose qui s'est déjà produit. Inclure le contexte du domaine pour éviter l'ambiguïté : « Facturation.Invoicegénérée » vs « Livraison.Invoicegénérée ». La cohérence dans l'ensemble de l'organisation facilite la compréhension et la maintenance du système.

Schéma d'événement

Un schéma d'événement devrait inclure des métadonnées normalisées :

  • eventId: identificateur unique pour la déduplication.
  • eventType: Le type d'événement.
  • timestamp: Lorsque l'événement s'est produit.
  • version: version schéma.
  • corrélationId: Pour le traçage entre les services.

La charge utile doit contenir tous les utilisateurs de données nécessaires pour traiter l'événement sans requêtes supplémentaires (transfert d'état d'événement) Utilisez un registre de schéma pour stocker et faire appliquer les schémas. Choisissez un format de sérialisation : JSON est lisible par l'homme, tandis qu'Avro ou Protobuf offrent une meilleure performance et un support d'évolution de schéma.

Évolution du schéma

Les événements sont des contrats, et ils changeront. Planifiez l'évolution dès le départ:

  • Inclure des informations de version dans chaque événement.
  • Suivre la compatibilité en arrière: les nouveaux producteurs doivent toujours travailler avec les anciens consommateurs.
  • Utilisez des champs optionnels pour les ajouts; ne jamais supprimer ou renommer des champs.
  • Utilisez un registre de schéma qui applique les règles de compatibilité pendant le déploiement.
  • Prise en charge de plusieurs versions de schéma pendant les périodes de transition.

Mise en œuvre des meilleures pratiques

Idempotence

Les consommateurs doivent gérer les événements en double en toute sécurité.

  • Entreposez les identifiants d'événement traités et sautez les duplicata.
  • Utilisez les clés d'idempotency naturelles du domaine d'affaires (par exemple, numéro de commande).
  • Les opérations de conception doivent être idémpotent (définir des valeurs absolues au lieu d'augmenter).

Gestion des erreurs et retraits

Distinguer les erreurs transitoires (délais de réseau, indisponibilité temporaire) à partir d'erreurs permanentes (données non valides, décalage schéma). Utiliser un backoff exponentiel avec jitter pour les rétries. Après un nombre maximum de rétries, envoyer l'événement à une file d'attente de lettre morte pour inspection manuelle. Surveiller les files d'attente de lettre morte et configurer les alertes.

Commande d'événements

L'utilisation de touches de partition (par exemple, ID client, ID de commande) pour acheminer les événements liés à la même partition, en assurant l'ordre dans ce contexte.

Surveillance et observation

Suivez les paramètres clés : taux d'édition des événements, décalage entre les consommateurs, temps de traitement, taux d'erreur, profondeur de la file d'attente. Utilisez des identifiants de corrélation distribués pour suivre les événements à travers les services.

Sécurité

Les événements peuvent contenir des données sensibles. Mettre en place l'authentification et l'autorisation pour la publication et la souscription. Chiffrer les événements en transit (TLS) et au repos. Utiliser la segmentation du réseau pour isoler le courtier.

Défis et solutions communs

Déboguage des flux distribués

Sans pile d'appel unique, les flux d'événements de traçage sont difficiles. Utilisez des ID de corrélation dans tous les événements et journaux. Implémentez des outils de traçage distribués comme Jaeger ou Zipkin. Maintenez un journal d'événements consultable pour reconstruire des séquences historiques.

Tempêtes de l'événement

Un orage d'événement survient lorsque des événements déclenchent des événements en cascade, créant potentiellement des boucles infinies ou accablant le système.

  • Concevoir des événements suffisamment complets pour que les consommateurs n'aient pas besoin de publier plus d'événements pour recueillir des données.
  • Fixation de limites maximales de réessayer.
  • Mise en œuvre de disjoncteurs.
  • Surveillance du volume des événements et alerte sur les tendances inhabituelles.

Essais des systèmes asynchrones

Les systèmes d'essai axés sur les événements nécessitent différentes approches:

  • Tests d'unité : Frappez le courtier, vérifiez que les services publient/consument les événements correctement.
  • Essais d'intégration[: Utiliser des récipients d'essai (p. ex., conteneurs d'essai pour Kafka ou RabbitMQ) pour vérifier le débit réel des événements.
  • : Veiller à ce que les producteurs et les consommateurs s'entendent sur les schémas.
  • Ingénierie du chaos: Test de résilience en simulant les pannes de courtiers, les partitions de réseaux et les défaillances des consommateurs.

Commencer par l'architecture d'événement

1. Identifier vos événements

Lancer des ateliers de tempête d'événements avec des experts du domaine. Identifier les événements qui représentent des événements commerciaux significatifs. Commencez par un petit sous-ensemble bien défini – par exemple, « OrdrePlacé» et «Paiement reçu».

2. Choisissez votre courtier

Pour les équipes qui viennent d'arriver à EDA, envisagez un service géré comme Amazon EventBridge ou Google Cloud Pub/Sub pour réduire les frais généraux opérationnels. Si vous avez besoin d'un débit élevé et d'un replay d'événement, choisissez Kafka malgré sa complexité.

3. Schémas d'événements de conception

Créez des champs de métadonnées standard. Concevez des charges utiles en utilisant le transfert d'état porté par événement. Choisissez un format de sérialisation (JSON pour la simplicité, Avro/Protobuf pour la production). Configurez un registre de schéma si possible.

4. Mise en œuvre et essai

Commencez par un seul producteur et un ou deux consommateurs. Implémentez l'idempotency, la manipulation des erreurs et la surveillance à partir du premier jour. Utilisez les bibliothèques clientes du courtier. Écrire des tests d'intégration avec des conteneurs de test.

5. Iterate et document

Élargissez progressivement les cas d'utilisation. Recueillez les commentaires de développement et d'exploitation. Conservez un catalogue d'événements avec des schémas et des informations sur les consommateurs. Documentez les décisions architecturales.

Cas d'utilisations réelles dans le monde

Traitement des commandes de commerce électronique

Lorsqu'un client passe une commande, l'événement "OrderPlaced" déclenche plusieurs services indépendants : réservation d'inventaire, traitement des paiements, planification d'expédition et notification. Si le paiement échoue, un événement compensateur libère l'inventaire. Chaque service s'équilibre indépendamment en fonction de sa propre charge. Le journal d'événements fournit un historique de commande complet pour le support client et l'analyse.

Analyse en temps réel et détection de fraude

Les clics, les vues des pages et les événements transactionnels sont transmis aux services d'analyse. Le traitement du flux calcule les mesures en temps réel – taux de conversion, nombre de sessions, scores d'anomalie.

Ingestion des données du capteur IoT

Des millions de dispositifs IoT publient des événements télémétriques (température, humidité, localisation) à un courtier de message. Plusieurs consommateurs s'occupent de différentes tâches : stockage de données (base de données de séries chronologiques), détection d'anomalies (alerte), mises à jour du tableau de bord et inférence du modèle d'apprentissage automatique.

Conclusion

L'architecture d'événements est un paradigme puissant pour construire des microservices modernes qui sont évolutives, résilients et durables. En embrassant la communication asynchrone, le couplage lâche et l'immutabilité des événements, vous pouvez éviter les pièges des systèmes distribués synchrones. La clé est de commencer petit, de choisir la bonne technologie en fonction de vos besoins, et d'investir dans l'idempotence, la surveillance et la gestion des schémas dès le début. Utilisez les modèles et les pratiques décrits ici pour concevoir des systèmes axés sur les événements qui peuvent croître avec votre entreprise.