Moteur de workflow déterministe construit sur le modèle de composant WASM
Statut du projet / Avis de non-responsabilité
Il s'agit d'une pré-version .
Ce référentiel contient du code backend pour le développement et les tests locaux. Le logiciel n'a pas de garanties de compatibilité descendante pour le schéma CLI, gRPC ou de base de données.
Plateformes prises en charge
Linuxx64
Principes fondamentaux
Schéma d'abord, en utilisant le langage WIT du modèle de composant WASM comme interface entre les flux de travail et les activités.
Le plaisir du développeur backend
Processus unique pour exécuter l'exécuteur, les flux de travail et les activités, avec une trappe de secours pour les activités externes (prévues).
Nouvelles tentatives automatiques en cas d'erreurs, de délais d'attente et d'exécutions de flux de travail se poursuivant après une panne de serveur.
Observabilité (prévue) : les paramètres et les résultats ainsi que la hiérarchie des fonctions doivent être préservés.
Composabilité - workflows d'imbrication, activités d'appel écrites dans n'importe quel langage pris en charge
Rejouez et dupliquez les workflows existants (prévus). Résolvez les problèmes et continuez.
Concepts et fonctionnalités
Activités qui doivent être idempotentes (récupérables), afin de pouvoir être arrêtées et réessayées à tout moment. Ce contrat doit être rempli par l'activité elle-même.
Les activités WASI sont exécutées dans un bac à sable WASM
Capable de contacter des serveurs HTTP à l'aide du client HTTP WASI 0.2.
Capable de lire/écrire sur le système de fichiers (prévu).
Prise en charge de la durée d'exécution maximale, après quoi l'exécution est suspendue dans un délai d'attente intermittent.
Nouvelles tentatives en cas d'erreurs - sur les pièges WASM (paniques) ou lors du renvoi d'un résultat d'erreur.
Nouvelles tentatives en cas d'expiration du délai d'attente avec une interruption exponentielle.
Le résultat de l’exécution est conservé.
Option de performances pour maintenir l'exécution du flux de travail parent à chaud ou décharger et relire l'historique des événements.
Flux de travail déterministes
Sont rejouables : l'exécution est persistante à chaque changement d'état, afin qu'elle puisse être rejouée après une interruption ou une erreur.
Exécuté dans un bac à sable WASM, isolé de l'environnement
Nouvelle tentative automatique en cas d'échecs tels que des erreurs de base de données, des délais d'attente ou même des pièges (panique).
Capable de générer des flux de travail ou des activités enfants, soit en bloquant jusqu'à ce que le résultat arrive, soit en attendant le résultat de manière asynchrone.
Les workflows peuvent être rejoués avec des messages de journal ajoutés et d'autres modifications qui ne modifient pas le déterminisme de l'exécution (planifiée).
Les ensembles de jointures permettent une concurrence structurée, soit en bloquant jusqu'à ce que les exécutions enfants soient terminées, soit en annulant celles qui n'étaient pas attendues (planifiées).
Webhooks WASI
Monté en tant que chemin d'URL, servant le trafic HTTP.
Capable de générer des flux de travail ou des activités enfants.
Exécuteur testamentaire voleur de travail
Verrouillage périodique d'un lot d'exécutions actuellement en attente, démarre/continue leur exécution
Nettoyer les anciennes exécutions suspendues avec des serrures périmées. Les exécutions qui disposent du budget seront retentées (planifiées).
Contrôle de concurrence : limite du nombre de travailleurs pouvant s'exécuter simultanément.
Déclencheurs de webhook HTTP capables de démarrer de nouvelles exécutions (workflows et activités), capables d'attendre le résultat avant d'envoyer la réponse.
Transférer les sorties stdout et stderr (configurables) des activités et des webhooks
Prise en charge du traçage distribué, journalisation des composants collectés par OTLP
Mappage de n'importe quel résultat d'exécution (par exemple, interruptions, délais d'attente, variantes d'erreur) vers d'autres résultats d'exécution via -await-next
Vérification du serveur : télécharge les composants, vérifie la configuration TOML et fait correspondre les importations de composants avec les exportations.
Concurrence structurée pour les jeux de jointures - blocage du parent jusqu'à ce que toutes les exécutions des enfants soient terminées
Interface utilisateur basée sur HTML pour afficher les exécutions, l'historique des événements et les relations
Imprimer les importations et exportations de chaque composant au format WIT
Ensembles de jointures hétérogènes, permettant à un ensemble de jointures de combiner plusieurs signatures de fonctions et délais
Exposer le système de fichiers avec mappage de répertoires pour les activités, webhooks
Exposer la configuration réseau pour les activités, les webhooks
Keepalives pour les activités, prolongeant le verrouillage jusqu'à la fin
Exemples avec C#, Go, JS, Python
Idées futures
CLI interactive pour la gestion de l'exécution
API gRPC des activités externes
Générateur d'activité OpenAPI
Processus de génération des activités WASM, lecture de leurs résultats
Contre-pression : limites sur les files d'attente en attente, ou stratégie d'expulsion, ralentissez sur LimitReached
Prise en charge des exécuteurs externes - démarrage des exécutions uniquement sur la base des exportations WIT. Les exécuteurs externes doivent partager l'accès en écriture à la base de données SQLite.
Étiquettes restreignant les flux de travail/activités aux exécuteurs testamentaires
Planification périodique
Propagation des délais
Propagation de l'annulation
Paramétrage de la capacité de la file d'attente, ajoutant une contre-pression à la soumission de l'exécution
Capacité à simuler le comportement du système avec des pannes injectées
Notifier les activités. Lorsqu'elle est appelée, cette valeur de retour doit être fournie via un point de terminaison d'API.
Une API pour répertorier les exécutions avec leurs activités de notification ouvertes.
Fonction de requête en lecture seule qui peut être appelée pendant un point d'attente ou une fois l'exécution terminée.
Stdout facultatif, persistance / transfert stderr
Routage intelligent des dépendances d'un appelant via une importation d'interface vers l'un des nombreux composants qui l'exportent.
Nouvelles tentatives intelligentes – Budget de nouvelle tentative, désactivation des nouvelles tentatives lorsque l'activité échoue à un certain % de demandes
Gigue configurable ajoutée aux tentatives
Instantanés de mémoire du workflow pour une relecture plus rapide
Débogueur temporel pour les flux de travail, qui fonctionne sur tous les déploiements WASM
Possibilité de corriger un ensemble de workflows, avec un système d'approbation lorsqu'un non déterminisme est détecté
Tracez les chaînes jusqu'à leur origine à travers les flux de travail et les activités
Mappages de webhook : exécution d'une seule fonction, traduction entre les paramètres définis HTTP et WIT et la valeur de retour
Transfert de contexte de traçage distribué pour le HTTP sortant ainsi que les webhooks
Autoriser la spécification de variantes d'erreur permanentes sous forme d'annotations dans WIT
Prise en charge des sagas (distribuées) - définissez des restaurations sur les activités, appelez-les en cas d'échec des flux de travail
Construire à partir de la source
Configurez les dépendances de développement à l'aide de nix flakes :
nix develop
# or `direnv allow`, after simlinking .envrc-example -> .envrc
Ou téléchargez manuellement toutes les dépendances, voir dev-deps.txt et Dockerfile de vérification basé sur Ubuntu Exécutez le programme
cargo run --release
Exécution de tests
./scripts/test.sh
Tests déterministes utilisant le simulateur madsim
./scripts/test-madsim.sh
Contribuer
Ce projet a une feuille de route et les fonctionnalités sont ajoutées et testées dans un certain ordre. Si vous souhaitez contribuer à une fonctionnalité, veuillez en discuter sur GitHub. Afin que nous puissions accepter les correctifs et autres contributions, vous devez adopter notre contrat de licence de contributeur (le « CLA »). La version actuelle de la CLA peut être consultée ici.
