Les architectures pilotées par événements (EDA) sont devenues la référence pour construire des microservices évolutifs. Cependant, la gestion du code de liaison entre les services conduit souvent à une logique complexe et difficile à maintenir, dispersée dans divers gestionnaires et consommateurs de messages. Kestra propose une approche révolutionnaire en traitant vos processus métier comme des citoyens de premier ordre, définis entièrement en YAML. Cela permet de découpler la logique métier complexe de l'infrastructure sous-jacente, garantissant que vos flux de travail restent lisibles, testables et indépendants de la pile technologique spécifique qui les alimente.
Le problème avec l'implémentation EDA traditionnelle
Dans une configuration typique de microservices, lorsque le Service A publie un événement, le Service B le consomme, traite les données et peut déclencher le Service C. Cette chaîne repose souvent sur des frameworks lourds, une logique de nouvelle tentative personnalisée et une gestion d'état codée en dur. Lorsque les exigences changent, les développeurs doivent souvent refactoriser en profondeur dans la base de code, risquant des effets secondaires dans des services non liés. De plus, l'observabilité est fragmentée ; le suivi d'une transaction métier à travers plusieurs services nécessite de recoller les journaux provenant de différentes sources.
Entrée de Kestra : Flux de travail définis en YAML
Kestra change le paradigme en vous permettant de définir votre logique d'orchestration dans des fichiers YAML lisibles par l'homme. Au lieu d'écrire du code Java ou Python pour gérer la consommation et le routage des messages, vous définissez le quoi (les étapes) et le quand (les déclencheurs) dans un format déclaratif. La plateforme gère le comment (exécution, nouvelles tentatives, persistance de l'état et observabilité).
Cette séparation des préoccupations signifie que votre logique métier est portable. Si vous devez changer le moteur d'exécution sous-jacent ou ajouter une nouvelle étape au processus, vous modifiez uniquement la définition YAML. L'infrastructure s'adapte à votre logique, et non l'inverse.
Exemple pratique : Flux de traitement des commandes
Considérez un système de commerce électronique où un e-mail de confirmation de commande doit être envoyé et où l'inventaire doit être mis à jour uniquement après la vérification du paiement. Avec Kestra, vous pouvez définir ce processus clairement :
id: order-processing
namespace: com.company.orders
triggers:
- type: com.kestra.plugin.core.trigger.Webhook
id: order-trigger
uri: /webhooks/orders
body:
orderId: "{{ trigger.body.id }}"
amount: "{{ trigger.body.amount }}"
tasks:
- id: verify_payment
type: com.example.plugins.tasks.VerifyPayment
orderId: "{{ trigger.body.id }}"
amount: "{{ trigger.body.amount }}"
retry:
type: FIXED
interval: "5s"
maxAttempt: 3
- id: update_inventory
type: com.example.plugins.tasks.UpdateInventory
orderId: "{{ trigger.body.id }}"
dependencies:
- verify_payment
- id: send_confirmation
type: com.kestra.plugin.http.Request
method: POST
url: https://email-service.local/send
body:
to: "{{ trigger.body.customerEmail }}"
subject: "Order Confirmed"
Bénéfices clés pour les développeurs
1. Clarté déclarative : Les parties prenantes non techniques peuvent souvent comprendre le flux d'un processus métier en lisant le YAML. Cela comble le fossé entre les exigences métier et l'implémentation technique.
2. Résilience intégrée : Kestra inclut un support natif pour les nouvelles tentatives, les dépassements de délai et le branchement conditionnel. Vous n'avez pas besoin d'écrire une logique de nouvelle tentative personnalisée pour chaque interaction de service ; elle est gérée de manière déclarative.
3. Observabilité unifiée : Chaque exécution de tâche est journalisée et visualisée dans l'interface Kestra. Vous pouvez suivre l'état exact d'un flux de travail à tout moment, ce qui rend le débogage considérablement plus rapide que la corrélation des journaux à travers des microservices disparates.
4. Intégration du contrôle de version : Puisque les flux de travail sont des fichiers YAML basés sur le texte, ils peuvent être gérés dans Git, permettant des revues de code, une gestion des versions et des pipelines CI/CD pour votre logique métier, tout comme vous le faites pour votre code applicatif.
Conclusion
Kestra permet aux développeurs de construire des microservices pilotés par événements robustes sans se noyer dans la gestion de l'infrastructure. En exploitant les définitions YAML, vous créez un contrat clair entre votre logique métier et le moteur d'exécution. Cette approche non seulement simplifie le développement et la maintenance, mais assure également que vos systèmes restent agiles et réactifs aux besoins métier changeants. En explorant Kestra, considérez à quel point vous pouvez supprimer de la complexité de vos microservices existants en externalisant votre logique d'orchestration.