Вступ
Durable Workflow 2.0 зберігає стан та історію workflow поза короткочасними
процесами застосунку. Завдяки цьому worker на PHP, Python або Rust може безпечно
продовжити роботу після перезапуску. Якщо ви тут уперше, почніть із
швидкого старту Durable Workflow 2.0. Він допоможе довести
один workflow до стану completed, перш ніж ви перейдете до докладного
довідника можливостей.
Оберіть модель розгортання
Сервісний режим
Застосунки звертаються до віддаленого середовища виконання через офіційні SDK. Оберіть, хто його обслуговуватиме:
- Durable Workflow Cloud пропонує керований сервіс. Durable Workflow відповідає за оркестрацію, збереження даних та Managed Waterline. Ваша команда запускає клієнти SDK і worker, які працюють із наданим namespace. Користувачам Cloud не потрібно встановлювати або запускати Durable Workflow Server чи окремий сервіс Waterline.
- Власний Server надає вашій команді ту саму сервісну межу. Ви самостійно розгортаєте, захищаєте, масштабуєте, оновлюєте середовище виконання та створюєте його резервні копії. Waterline для спостереження можна розгорнути як окремий сервіс, підключений до namespace, яким керує Server.
Обидва варіанти надають ту саму версіоновану площину керування HTTP+JSON, протокол worker, модель namespace та мовно незалежний формат payload. Межі відповідальності описано в моделях розгортання.
Вбудований режим Laravel
Вбудований режим є окремою моделлю розгортання для застосунку Laravel, який
хоче зберігати стан workflow, черги, конфігурацію та інструменти оператора у
власній інфраструктурі. Він встановлює durable-workflow/workflow, не
підключається до Cloud і не потребує окремого Server. Вбудований пакет
Waterline читає стан цього застосунку в тому самому процесі.
Починайте зі встановлення вбудованого пакета, якщо ви свідомо обрали керування середовищем виконання всередині застосунку.
Командам Laravel, які переходять зі стабільної v1 або переглядають наявне вбудоване розгортання 2.0, варто скористатися посібником із впровадження в Laravel та переходу між середовищами виконання. Він допоможе порівняти робочі приклади вбудованого режиму та PHP SDK до перемикання трафіку.
Оберіть SDK для сервісного режиму
- PHP SDK: встановіть
durable-workflow/sdkу застосунку PHP без прив'язки до фреймворку або у віддаленому worker. - Python SDK: створюйте детерміновані workflow та activity й використовуйте асинхронний клієнт площини керування. Стабільний випуск Python зазначено в тому самому машинозчитуваному маніфесті стабільних випусків, що й у швидкому старті для Server.
- Rust SDK: створюйте детерміновані workflow та activity й запускайте нативні сервіси worker.
Усі три SDK є офіційними реалізаціями тієї самої публічної сервісної межі. Посібник можливості клієнтів і worker чітко визначає підтримувані можливості та навмисні відмінності між їхніми інтерфейсами.
Ваш перший завершений workflow
Швидкий старт одразу визначає мету, вибір середовища виконання, передумови, потрібний час та очікуваний результат. PHP, Python і Rust доступні на рівних умовах, а кожен приклад показує один робочий шлях для обраної мови. Для вправи з опублікованими артефактами без вихідного коду використовуйте локальний Server. Для керованого namespace використовуйте параметри підключення Cloud, не запускаючи Server самостійно.
Як улаштований сервісний режим
Розгортання в сервісному режимі складається з трьох частин:
- Середовище виконання відповідає за збережений стан, запис команд та історії, зіставлення завдань, timer, розклади, namespace та протоколи з автентифікацією. Для керованих namespace його обслуговує Cloud, а для власного розгортання ваша команда.
- Worker застосунку виконують код workflow та activity через PHP, Python або Rust SDK. Їх можна розгортати разом із застосунком або як незалежні сервіси та масштабувати окремо від середовища виконання.
- Клієнти й інструменти оператора запускають, перевіряють та керують
тим самим станом через клієнти SDK, CLI
dw, HTTP API, машинозчитувані схеми, Waterline та інтерфейси для агентів.
Єдиний публічний контракт виконання
Офіційні SDK використовують спільні зареєстровані рядкові назви типів workflow та activity й публічний формат payload. Формат зазначає свій codec і містить переносимі значення, замість серіалізації PHP, pickle Python або внутрішніх типів реалізації Rust.
Worker відновлюють рішення workflow із збережених команд та історії. Вхідні дані й результати activity та дочірніх workflow можуть передаватися між мовами, якщо worker оголошують той самий публічний codec і реєструють відповідні назви типів. Перед використанням конкретної можливості SDK перевірте довідник можливостей та discovery середовища виконання.
Вивчайте відповідні приклади
- Сервісний режим та кілька мов: скористайтеся швидким стартом і посібником PHP, Python або Rust SDK.
- Вбудований режим Laravel: галерея Sample App показує типові workflow для Laravel та результати їхнього спостереження у Waterline.
Галерея вбудованих прикладів не є універсальною відправною точкою для користувачів Cloud або власного Server у сервісному режимі.
Контракт для роботи агентів
Люди та автономні агенти використовують той самий машинозчитуваний контракт. Цикл, який можна перевірити, має вигляд Виявити можливості -> Змінити -> Запустити -> Діагностувати -> Відновити: маніфести версій та можливостей, явні команди workflow, структуровані результати, типізована історія й діагностика worker та черг, безпечні зміни і перевірка після них. Дивіться робочий цикл агента та оцінювання рушія для AI-агентів.
Чи потрібен вам workflow?
Імовірно, вам потрібен workflow, якщо:
- Процес триває хвилини, години або дні
- Потрібно чекати на схвалення людини
- Потрібно чекати на webhook або іншу зовнішню подію
- Потрібно призупинити роботу та продовжити пізніше, не тримаючи процес запущеним
- Потрібно відновитися після збою без помилок або повторного виконання роботи
Якщо завдання полягає в тому, щоб запустити п'ять завдань черги по черзі та зупинитися після першої помилки, зазвичай краще підходить ланцюжок завдань. Durable Workflow потрібен там, де наступний крок залежить від зовнішньої події, очікування або рішення, якого неможливо знати заздалегідь.