Deterministische Workflow-Engine, die auf dem WASM-Komponentenmodell aufbaut
Projektstatus / Haftungsausschluss
Dies ist eine Vorabversion .
Dieses Repo enthält Backend-Code für lokale Entwicklung und Tests. Die Software verfügt über keine Abwärtskompatibilitätsgarantien für die CLI, gRPC oder das Datenbankschema.
Unterstützte Plattformen
Linux x64
Grundprinzipien
Schema zuerst, wobei die WIT-Sprache des WASM-Komponentenmodells als Schnittstelle zwischen Workflows und Aktivitäten verwendet wird.
Eine Freude für Backend-Entwickler
Ein einziger Prozess zum Ausführen des Ausführenden, der Arbeitsabläufe und Aktivitäten, mit einer Notluke für externe Aktivitäten (geplant).
Automatische Wiederholungsversuche bei Fehlern, Zeitüberschreitungen und Fortsetzung der Workflow-Ausführung nach einem Serverabsturz.
Beobachtbarkeit (geplant) – Parameter und Ergebnisse müssen zusammen mit der Funktionshierarchie erhalten bleiben.
Zusammensetzbarkeit – Verschachtelung von Workflows, Aufruf von Aktivitäten, die in jeder unterstützten Sprache geschrieben sind
Vorhandene Workflows erneut abspielen und verzweigen (geplant). Beheben Sie die Probleme und fahren Sie fort.
Konzepte und Funktionen
Aktivitäten , die idempotent (wiederholbar) sein müssen, sodass sie jederzeit gestoppt und erneut versucht werden können. Dieser Vertrag muss durch die Tätigkeit selbst erfüllt werden.
WASI-Aktivitäten werden in einer WASM-Sandbox ausgeführt
Kann HTTP-Server über den WASI 0.2 HTTP-Client kontaktieren.
Kann im Dateisystem lesen/schreiben (geplant).
Unterstützung für die maximale Ausführungsdauer, nach der die Ausführung in einem zeitweiligen Timeout ausgesetzt wird.
Wiederholte Versuche bei Fehlern – bei WASM-Traps (Panik) oder bei der Rückgabe eines Fehlerergebnisses.
Wiederholungsversuche bei Zeitüberschreitungen mit exponentiellem Backoff.
Das Ausführungsergebnis wird beibehalten.
Leistungsoption, um die Ausführung des übergeordneten Workflows aktiv zu halten oder den Ereignisverlauf zu entladen und wiederzugeben.
Deterministische Arbeitsabläufe
Sind wiederholbar: Die Ausführung bleibt bei jeder Zustandsänderung bestehen, sodass sie nach einer Unterbrechung oder einem Fehler wiederholt werden kann.
Läuft in einer WASM-Sandbox, isoliert von der Umgebung
Automatischer Wiederholungsversuch bei Fehlern wie Datenbankfehlern, Zeitüberschreitungen oder sogar Traps (Panik).
Kann untergeordnete Arbeitsabläufe oder Aktivitäten erzeugen, die entweder blockieren, bis das Ergebnis eintrifft, oder asynchron auf das Ergebnis warten.
Workflows können mit hinzugefügten Protokollmeldungen und anderen Änderungen wiedergegeben werden, die den Determinismus der Ausführung (geplant) nicht verändern.
Join-Sets ermöglichen eine strukturierte Parallelität, indem sie entweder blockieren, bis untergeordnete Ausführungen abgeschlossen sind, oder diejenigen abbrechen, die nicht erwartet (geplant) wurden.
WASI-Webhooks
Wird als URL-Pfad bereitgestellt und stellt HTTP-Verkehr bereit.
Kann untergeordnete Arbeitsabläufe oder Aktivitäten erzeugen.
Arbeit stehlender Testamentsvollstrecker
Sperrt regelmäßig einen Stapel aktuell ausstehender Ausführungen und startet/setzt deren Ausführung fort
Aufräumen alter hängender Hinrichtungen mit abgelaufenen Schlössern. Ausführungen, die über das Budget verfügen, werden erneut versucht (geplant).
Parallelitätskontrolle – Beschränkung der Anzahl der Worker, die gleichzeitig ausgeführt werden können.
HTTP-Webhook-Trigger können neue Ausführungen (Workflows und Aktivitäten) starten und auf das Ergebnis warten, bevor sie die Antwort senden.
Leiten Sie stdout und stderr (konfigurierbar) von Aktivitäten und Webhooks weiter
Unterstützung für verteiltes Tracing und Protokollierung von Komponenten, die von OTLP gesammelt wurden
Zuordnung von beliebigen Ausführungsergebnissen (z. B. Traps, Timeouts, Fehlervarianten) zu anderen Ausführungsergebnissen über -await-next
Serverüberprüfung – lädt Komponenten herunter, überprüft die TOML-Konfiguration und gleicht Komponentenimporte mit Exporten ab.
Strukturierte Parallelität für Join-Sets – Blockieren des übergeordneten Elements, bis alle untergeordneten Ausführungen abgeschlossen sind
HTML-basierte Benutzeroberfläche zur Anzeige von Ausführungen, Ereignisverlauf und Beziehungen
Drucken Sie die Importe und Exporte jeder Komponente im WIT-Format
Heterogene Join-Sets, die es einem Join-Set ermöglichen, mehrere Funktionssignaturen und Verzögerungen zu kombinieren
Dateisystem mit Verzeichniszuordnung für Aktivitäten und Webhooks verfügbar machen
Machen Sie die Netzwerkkonfiguration für Aktivitäten und Webhooks verfügbar
Keepalives für Aktivitäten, Verlängerung der Sperre bis zur Fertigstellung
Beispiele mit C#, Go, JS, Python
Zukunftsideen
Interaktive CLI für die Ausführungsverwaltung
Externe Aktivitäten gRPC-API
OpenAPI-Aktivitätsgenerator
Prozesse aus WASM-Aktivitäten erzeugen und deren Ergebnisse lesen
Gegendruck: Beschränkungen für ausstehende Warteschlangen oder eine Räumungsstrategie verlangsamen LimitReached
Unterstützung externer Ausführender – Starten von Ausführungen ausschließlich basierend auf WIT-Exporten. Externe Ausführende müssen sich den Schreibzugriff auf die SQLite-Datenbank teilen.
Etiketten, die Arbeitsabläufe/Aktivitäten auf Ausführende beschränken
Periodische Planung
Fristverbreitung
Ausbreitung der Stornierung
Einstellung der Warteschlangenkapazität, wodurch Gegendruck zur Ausführungsübermittlung hinzugefügt wird
Möglichkeit, das Verhalten des Systems bei injizierten Fehlern zu simulieren
Aktivitäten benachrichtigen. Beim Aufruf muss ihr Rückgabewert über einen API-Endpunkt bereitgestellt werden.
Eine API zum Auflisten von Ausführungen mit ihren offenen Benachrichtigungsaktivitäten.
Schreibgeschützte Abfragefunktion, die während eines Wartepunkts oder nach Abschluss der Ausführung aufgerufen werden kann.
Optionale stdout,stderr Persistenz/Weiterleitung
Intelligentes Abhängigkeitsrouting von einem Aufrufer über einen Schnittstellenimport zu einer von vielen Komponenten, die ihn exportieren.
Intelligente Wiederholungen – Wiederholungsbudget, das Wiederholungsversuche deaktiviert, wenn die Aktivität einen bestimmten Prozentsatz der Anfragen fehlschlägt
Konfigurierbarer Jitter zu Wiederholungsversuchen hinzugefügt
Workflow-Speicher-Snapshots für eine schnellere Wiedergabe
Zeitreisender Debugger für Workflows, der in allen WASM-Bereitstellungen funktioniert
Möglichkeit zur Hotfixierung einer Reihe von Arbeitsabläufen mit einem Genehmigungssystem, wenn Nichtdeterminismus erkannt wird
Verfolgen Sie Zeichenfolgen über Workflows und Aktivitäten hinweg bis zu ihrem Ursprung
Webhook-Zuordnungen: Ausführen einer einzelnen Funktion, Übersetzen zwischen HTTP- und WIT-definierten Parametern und Rückgabewerten
Verteilte Tracing-Kontextweiterleitung für ausgehende HTTP- und Webhooks
Erlauben Sie die Angabe permanenter Fehlervarianten als Anmerkungen in WIT
Unterstützung für (verteilte) Sagen – Rollbacks für Aktivitäten definieren und bei fehlgeschlagenen Workflows aufrufen
Bauen aus der Quelle
Richten Sie die Entwicklungsabhängigkeiten mit Nix-Flakes ein:
nix develop
# or `direnv allow`, after simlinking .envrc-example -> .envrc
Oder laden Sie alle Abhängigkeiten manuell herunter, siehe dev-deps.txt und Ubuntu-basierte Überprüfung Dockerfile Führen Sie das Programm aus
cargo run --release
Ausführen von Tests
./scripts/test.sh
Deterministische Tests mit dem madsim -Simulator
./scripts/test-madsim.sh
Mitwirken
Dieses Projekt hat eine Roadmap und Funktionen werden in einer bestimmten Reihenfolge hinzugefügt und getestet. Wenn Sie eine Funktion beitragen möchten, diskutieren Sie die Funktion bitte auf GitHub. Damit wir Patches und andere Beiträge akzeptieren können, müssen Sie unserer Contributor-Lizenzvereinbarung (die „CLA“) zustimmen. Die aktuelle Version des CLA finden Sie hier.
