Перейти до основного вмісту
Версія: 2.0

Сумісність і маршрутизація worker

Використовуйте цей посібник для розгортання нової збірки worker, пробного оновлення однієї черги завдань, відкату невдалої збірки або збереження довготривалих workflow під час оновлення. Durable Workflow v2 визначає сумісність worker контрактом маршрутизації.

Основне правило просте: run, запущений в одному сімействі сумісності, має надалі потрапляти на worker, здатні безпечно відтворювати й виконувати його. Система має явно показувати стан «немає доступного сумісного worker» замість прихованого передавання завдання іншій збірці.

Durable Workflow має два пов’язані, але різні інтерфейси оновлення:

  • Build id — ідентичність групи для оператора окремого Server. Worker реєструє її як build_id. API оновлення черги завдань використовують її для drain або resume.
  • Маркер сумісності — ідентичність маршрутизації незавершеної роботи. Для вбудованих і розміщених на Server worker PHP він походить із DW_V2_CURRENT_COMPATIBILITY і DW_V2_SUPPORTED_COMPATIBILITIES. На окремому Server групи build ID є способом оператора переглядати ці сумісні групи worker та керувати ними.

Обидва значення є непрозорими рядками, як orders-2026-04-28 або api-v3. Durable Workflow не інтерпретує semver, не порівнює дати й не вгадує, який рядок новіший.

Що закріплюється​

Сумісність приєднується до стійкої роботи workflow, а не лише живих процесів worker.

  • Запуск workflow записує поточне сімейство сумісності в новий run.
  • Завдання workflow успадковують сімейство й зберігають його через повторні спроби, спливання оренди та повторну диспетчеризацію.
  • Завдання activity успадковують сімейство сумісності батьківського run.
  • Повторні run зберігають сімейство вихідного run.
  • Continue-as-new зберігає сімейство поточного run.
  • Дочірні workflow успадковують сімейство батьківського run.

Отже, довготривалий workflow не переходить до іншого сімейства виконавців лише через зміну розгортання. Нові збірки впливають на нові запуски, якщо ви навмисно не переводите старі групи в drain і не переміщуєте трафік.

Як працює маршрутизація​

Сумісність забезпечується на кількох рівнях.

Звуження під час опитування​

Worker звужують запити за чергою завдань і групою сумісності/збірки, щоб Server або вбудований рушій спочатку не пропонували явно несумісних завдань.

Це підказка ефективності. Остаточна межа безпеки діє під час claim.

Перевірка під час claim​

Перевірка під час claim є межею коректності. Якщо worker не може безпечно виконати завдання, Durable Workflow відхиляє claim з явною причиною сумісності замість прихованого перепризначення власника.

Саме на цей контракт слід спиратися під час змін, що впливають на сумісність:

  • завдання ніколи приховано не допускаються до несумісного worker;
  • спливання оренди й повторна доставка зберігають початкове сімейство;
  • відсутність сумісного worker є спостережуваним станом.

Що мають налаштувати оператори​

Використовуйте стабільні зрозумілі назви сімейств сумісності для збірок, що безпечно відтворюють ті самі незавершені workflow.

Для вбудованих чи розміщених на Server worker PHP задайте:

DW_V2_CURRENT_COMPATIBILITY=orders-2026-04-28
DW_V2_SUPPORTED_COMPATIBILITIES=orders-2026-04-28,orders-2026-04-21

DW_V2_CURRENT_COMPATIBILITY називає сімейство закріплення нових run. DW_V2_SUPPORTED_COMPATIBILITIES називає сімейства, завдання яких worker ще може забирати під час оновлення або відкату. Використовуйте * лише для наборів однієї збірки чи вузьких тестових середовищ. Не приховуйте ним невизначену політику оновлення.

Для worker окремого Server реєструйте стабільний build_id і навмисно переводьте групи в drain або resume через API оновлення build ID.

Безпечний шаблон оновлення​

Для змін worker, що впливають на сумісність:

  1. Запустіть нову групу worker із новим build ID або маркером сумісності.
  2. Залишайте стару групу живою до підтвердження отримання роботи новою.
  3. Переведіть стару групу в drain: вона припиняє брати нові завдання, але може завершити чи звільнити вже орендовані.
  4. Спостерігайте сумісність і черги завдань, доки стара група більше не потрібна.
  5. Відновлюйте стару групу лише за потреби відкату.

Зберігайте сімейство сумісності для збірок, сумісних із replay. Змінюйте його лише коли нові worker більше не повинні забирати завдання старого сімейства.

Явний стан відсутнього worker​

Коли жоден worker не задовольняє потрібного сімейства, Durable Workflow має чітко це показати:

  • огляди набору worker показують відсутність покриття потрібної сумісності;
  • інтерфейси черг і оновлення показують активні, draining, застарілі або зниклі групи збірок;
  • діагностика workflow показує очікування сумісного worker;
  • здоров’я й метрики оператора показують заблоковану сумісністю роботу як іменований стан.

Це очікуваний сигнал часткового оновлення або неповного відкату. Ставтеся до нього як до операційної проблеми, яку потрібно виправити.

Зв’язок з оновленнями build ID​

Стан оновлення build ID та маршрутизація сумісності мають різні завдання:

  • Оновлення build ID показує оператору живі групи worker і дозволяє навмисно переводити їх у drain або resume.
  • Маршрутизація сумісності визначає допустимість виконання конкретного незавершеного завдання конкретним worker.

Зазвичай обидва використовуються разом. Групи build ID показують доступних виконавців, а маршрутизація сумісності спрямовує довготривалу роботу лише до сумісної групи.