Une architecture pilotée par les événements - Partie 4

Frameworks, outils et conclusion

Des mini-frameworks pour les développeurs

Pour faciliter le développement des services EDA, nous avons créé un framework dédié, Eventail. Il masque la topologie et prend en charge tous les comportements attendus des services, décrits dans la partie 3, pour que les développeurs puissent se concentrer sur la logique métier. Il leur suffit d’implémenter un callback pour chaque événement ou commande à traiter.

Nous l’avons publié sous licence MIT, en Python, Elixir et Rust :

• Eventail-py
• Eventail-ex
• Eventail-rs

Monitoring

En plus des solutions « classiques » de monitoring réseau et serveurs, nous utilisons des outils plus haut niveau, spécifiques, pour monitorer notre EDA.

Pour la santé globale du bus, nous utilisons le plugin de management de RabbitMQ. Il donne une vue en temps réel de ce qui se passe sur le bus :

• le débit des messages ;
• l’état des queues ;
• la consommation de ressources du broker ;
• l’état des connexions clientes…

Comme nous l’avons dit plus haut, les services envoient leurs logs applicatifs sur le bus, dans un exchange dédié. Le framework Eventail formate les messages de log au format GELF de Graylog, ce qui nous permet de profiter de cet outil de gestion de logs, qui se connecte nativement aux brokers AMQP comme RabbitMQ. Nous utilisons ensuite Graylog pour définir des alertes, construire des dashboards sur les processus métier, chercher dans les logs pour débugger (par identifiant de conversation, par exemple), etc.

En plus des logs applicatifs, les services envoient des health checks périodiques sur le même exchange, eux aussi collectés dans Graylog : à tout moment, nous savons quels services ou quels workers sont down, ou tournent en mode dégradé.

Tests, debug et « réparation »

Le framework Eventail fournit des utilitaires en ligne de commande pour tester, débugger et rejouer les messages de la dead letter queue.

Les commandes de test permettent au développeur de publier des événements sur le bus, ou d’envoyer une commande à un service et d’en afficher le résultat dans la console.

Les commandes de debug permettent au développeur de cibler et d’afficher des logs dans la console, ou de s’abonner à des événements et à des commandes pour en afficher le contenu au fil de l’eau. Une commande permet aussi d’inspecter le contenu d’une queue (sans en consommer les messages).

Dead letters

Nous utilisons pour cela les policies RabbitMQ.
Il suffit aux services de rejeter un message avec le bon flag pour que le broker le route vers le dead letter exchange. Le framework s’en charge automatiquement quand une exception inattendue est levée dans le code utilisateur.

Encore faut-il que quelque chose écoute les dead letters pour que le dispositif serve à quelque chose.
Comme nous l’avons vu, quand un bug survient dans un service, le message qui a provoqué l’erreur part dans la dead letter queue. Nous pouvons alors en inspecter le contenu avec l’outil d’inspection, ou le sauvegarder pour le « jouer » en local sur le poste du développeur avec les utilitaires publish_event ou send_command. Une fois le bug corrigé et le service déployé en production, nous rejouons tous les messages de la dead letter queue avec la commande resurrect. Aucune donnée n’est perdue.

Bilan

Qu’est-ce qu’on y gagne ?

Après six ans en production, notre EDA nous a apporté :

• Le scaling : il suffit de lancer une nouvelle instance d’un service logique, n’importe où sur le réseau, pour tenir la charge.
• La tranquillité d’esprit : aucune donnée n’est jamais perdue. Plus de stress. Plus de panique quand quelque chose casse en production.
• Une latence plus faible : fini le polling, les cron jobs, les batchs…
• Un monitoring et un debug simplifiés.
• Une maintenance sans accroc : grâce au découplage, nous pouvons ajouter, arrêter, redémarrer ou retirer des services à volonté, sans perturber le système.
• Des mises en production sans douleur : une nouvelle fonctionnalité, c’est un nouveau service, totalement transparent pour les autres.