Режими розгортання
Durable Workflow v2 має два режими розгортання:
- Сервісний режим: застосунки й worker підключаються через SDK до віддаленого runtime. Оберіть Durable Workflow Cloud або власний Server.
- Вбудований режим: Laravel-застосунок встановлює
durable-workflow/workflowі безпосередньо володіє runtime.
Cloud і власний Server є варіантами runtime всередині сервісного режиму, а не компонентами для спільного запуску. У Cloud Durable Workflow обслуговує оркестрацію та збереження стану, а клієнти запускають клієнти SDK і worker. Cloud містить Managed Waterline. Клієнти Cloud не встановлюють, не розгортають і не підключають власні служби Server чи Waterline. Власний Server не містить Waterline. Оператори можуть окремо розгорнути Waterline для простору імен, яким володіє Server.
Використовуйте цю сторінку для вибору розгортання, яке володітиме набором workflow, планування переходу між варіантами або визначення частин контракту продукту, що мають залишатися однаковими в обох режимах.
Командам Laravel варто скористатися спеціалізованим посібником із впровадження Laravel і переходу runtime для шляхів v1→v2 і вбудований→сервісний, зокрема мосту PHP SDK, що постачається, та його тестової підміни Laravel.
Оберіть runtime сервісного режиму
| Варіант runtime | Хто обслуговує стійкий стан | Що запускає ваша команда | З чого почати |
|---|---|---|---|
| Durable Workflow Cloud | Durable Workflow обслуговує керований runtime простору імен, збереження стану, оновлення, адресу служби та Managed Waterline. | Клієнти застосунків і worker PHP, Python або Rust із наданими обліковими даними. Не запускайте Server або окрему службу Waterline. | Керований runtime Cloud |
| Власний Server | Ваша команда розгортає, захищає, масштабує, резервує й оновлює Server та його сховище. | Server, клієнти застосунків і worker PHP, Python або Rust. За потреби окремо розгорніть Waterline для простору імен Server. | Власний Server |
Обидва варіанти використовують однакову модель клієнтів і worker. Відрізняються обслуговування runtime та облікові дані.
Спільна стійка модель, інша межа
Вбудований і сервісний режими зберігають одне ядро v2. Змінюються межі розміщення, автентифікації й транспорту навколо нього. У сервісному режимі те саме ядро працює за інтерфейсами площини керування й worker HTTP+JSON. Немає обов’язкового gRPC або другого рушія.
| Інтерфейс | Вбудований режим | Сервісний режим | Незмінне в обох режимах |
|---|---|---|---|
| Стійка модель workflow | Laravel-застосунок безпосередньо містить пакет і записує стан workflow у runtime застосунку. | Cloud або власний Server володіє станом workflow за API служби. | ID workflow, ID run, типізована історія, результати команд, повторні спроби, семантика відновлення й експорт історії залишаються тим самим контрактом v2. |
| Площина керування | Запуски й команди надходять із коду застосунку, WorkflowStub або локальних інструментів оператора. | Запуски й команди проходять через API Server, CLI або SDK через HTTP+JSON з явними заголовками автентифікації та протоколу. Незалежні від фреймворку клієнти PHP використовують DurableWorkflow\Client із durable-workflow/sdk. | Політика повторного запуску, вибір run, ID команд та іменовані результати залишаються тими самими. Надсилайте подальші команди до runtime, який прийняв запуск. |
| Транспорт worker | Worker черги Laravel виконують завдання workflow та activity усередині розгортання застосунку. | Worker реєструються, використовують довге опитування, heartbeat і завершують роботу через протокол worker HTTP+JSON. Віддалені worker PHP використовують DurableWorkflow\Worker із durable-workflow/sdk. | Оренди завдань, маркери сумісності, семантика replay та виконання activity щонайменше один раз залишаються тими самими. |
| Типова диспетчеризація завдань | Завдання зазвичай надсилаються до черги Laravel у процесі застосунку. | Сервісний runtime використовує диспетчеризацію через опитування, щоб зовнішні worker знаходили роботу через HTTP. Оператори власного Server можуть явно змінити це типове значення. | Життєвий цикл ready/leased/repair і стійка модель завдання залишаються тими самими. |
| Ключі типів workflow та activity | Псевдоніми PHP можуть розв’язуватися в локальні класи застосунку. | Worker оголошують підтримувані ключі типів під час реєстрації. | Публічні ключі типів мають бути стабільними й незалежними від мови. Не робіть FQCN PHP або дзеркальні типи-заповнювачі PHP публічним контрактом. |
| Інтерфейс оператора | Вбудований пакет Waterline або локальні інструменти читають стійкий стан Laravel-застосунку в його процесі. | Cloud надає Managed Waterline для свого простору імен. Оператори власного Server можуть окремо розгорнути Waterline для його простору імен. API служб, CLI та SDK також читають стан runtime. | Пошукові атрибути, memo, статус run, діагностика черг та експорт історії є стійкими фактами runtime, що володіє run. Waterline не об’єднує runtime чи простори імен. |
| Межа автентифікації й орендарів | Автентифікацію застосунку визначає Laravel-хост для власних маршрутів і сесій. | Вибір простору імен та токени чи підписи автентифікації Server є обов’язковими межами API. | Назви просторів імен, черги завдань, маркери сумісності й фіксований контракт payload Avro мають залишатися стабільними під час переходу. |
| Виявлення runtime | Застосунок може знаходити служби в процесі або через локальну конфігурацію. | Worker і клієнти мають використовувати явну віддалену базову URL-адресу. | Не прив’язуйте жоден режим до спільних APP_URL, APP_KEY, припущень localhost або виявлення в тому самому контейнері. |
| Межа міграції | Наявні вбудовані run продовжують виконуватися там, де почалися. | Нові run сервісного режиму починаються в обраному Cloud або власному runtime й залишаються там. | Автоматичної живої міграції незавершених run між режимами немає. Експорт призначений для аудиту/налагодження, а не імпорту живого стану. |
Коли обрати вбудований режим
- Ваш Laravel-застосунок поєднує написання workflow, виконання worker і доступ оператора в одному розгортанні.
- Наявні черги й модель автентифікації застосунку є правильною межею операцій workflow.
- Вам потрібен найменший самодостатній runtime без незалежного від мови протоколу worker.
- Оператори можуть використовувати Waterline чи інструменти застосунку як основний інтерфейс workflow.
Почніть із вбудованого встановлення та вбудованої документації, зокрема групи налаштувань.
Коли обрати сервісний режим
- Один runtime workflow мають спільно використовувати кілька застосунків або команд.
- Не всі worker, клієнти площини керування чи оператори працюють із Laravel/PHP.
- Потрібна явна віддалена межа автентифікації та простору імен між клієнтами й рушієм workflow.
- Потрібно незалежно масштабувати вхід API, зіставлення/диспетчеризацію та worker у підтримуваній топології ролей Server.
- Для власного Server ви хочете розгорнути Waterline як спостерігач простору імен Server. Cloud натомість містить Managed Waterline.
Для керованого runtime почніть із Durable Workflow Cloud. Для власного розгортання почніть із Server та самостійних розгортань. Потім оберіть PHP SDK, Python SDK або Rust SDK. Користувачі Cloud працюють через Managed Waterline. Оператори власного Server можуть використовувати довідник Server API і моніторинг для розгортання окремої служби Waterline.
Інструменти переходу до власного сервісного режиму
Підтримуваний шлях від вбудованого до сервісного режиму — поетапне впровадження:
- Використовуйте міграцію вбудованого режиму до Server для покрокового переходу.
- Використовуйте
GET /api/cluster/info, щоб підтвердити збірку цільового Server, топологію та контракт можливостей перед перемиканням трафіку. - Використовуйте
POST /api/worker/registerі протокол worker, щоб довести здатність зовнішніх worker обслуговувати обрані стабільні ключі типів. - Використовуйте
GET /api/system/operator-metrics,dw worker:listабо подання оператора Waterline для перевірки реєстрації worker і покриття сумісним набором worker перед перемиканням виробничого трафіку. - Використовуйте можливості клієнтів і worker під час заміни локальних викликів площини керування автоматизацією на основі Server.
- Використовуйте Managed Waterline Cloud, Waterline, підключений до власного runtime, або вбудований експорт історії Server для доказів аудиту/налагодження. Пакети експорту не є шляхом імпорту живих run, якими керує Server.
Три правила міграції обов’язкові:
- Наявні run залишаються в runtime, де вони почалися.
- Нові run Server використовують стабільні ключі типів, назви просторів імен, черги завдань і фіксований контракт payload Avro від першого переходу.
- Signal, query, update, відновлення, скасування, припинення та архівування мають надходити до runtime, який володіє цільовим run.