Англійський словник для тимчасових розробників робочих потоків

Temporal — це довговічна платформа для написання надійних, довготривалих потоків роботи у коді. Його використовують інженерні команди в таких компаніях, як Netflix, Stripe і Datadog, щоб організувати складні процеси — від багатокрокових бізнес-процесів, що тривають декілька днів, до розподілених транзакцій, які повинні пережити аварії інфраструктури. Temporal має точний і чіткий словник: Робочі потоки, Дії, Сигнали, Запити, Дочірні потоки та версії, які є фундаментальними для правильного використання платформи. Якщо ваша команда використовує Temporal, оволодіння цим словником є необхідним для участі у перегляді проекту, зневаджування виробничих інцидентів і написання коду потоку робіт, який можуть підтримувати ваші колеги. У цьому повідомленні описано основні терміни, пов’ язані з тимчасовими даними.

Ключовий словник

** Потік роботи ** Тривала, детерміністична функція, яка керує бізнес- логікою за допомогою координації дій і інших потоків роботи. Тимчасові гарантії того, що робочий потік буде виконано до завершення, навіть після перезапусків сервера, аварій і збоїв мережі. Код робочого потоку повинен бути детермінованим — даний той же історія подій, він повинен завжди виробляти ті ж самі рішення.

• Приклад: « Написати логіку виконання замовлення як тимчасовий робочий процес — якщо сервер зазнає аварії під час виконання, тимчасовий процес відтворить історію робочого процесу і відновить його з того місця, де він зупинився. » *

Діяльність Функція, яка виконує недетермінований побічну дію — виклик зовнішнього API, запис до бази даних, надсилання електронної пошти або будь- яку іншу дію, яка взаємодіє з зовнішнім світом. Дії викликаються з потоків робіт і автоматично повторюються у разі невдачі. На відміну від потоків робіт, код діяльності не повинен бути детермінованим. Приклад: «Загорнути виклик Stripe charge в дію — дії автоматично повторюються при невдачі і можуть безпечно здійснювати зовнішні виклики API, які не може виконати робочий процес.»

Сигнал Асинхронне повідомлення, надіслане до запущеного потоку робіт, яке може змінити його стан або зняти блокування з очікування. Сигнали надсилаються ззовні (з коду програми або іншого потоку робіт) і отримуються обробником сигналів потоку робіт. Сигнали є тривалими — їх буде надіслано навіть у випадку, якщо робочий потік перебуває у стані сну.

• Приклад: « Надіслати сигнал cancel-order до потоку виконання, коли користувач натисне кнопку скасувати — обробник сигналів потоку виконання зупинить процес виконання і запустить дію повернення коштів. » *

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

• Приклад: « Додати обробник запиту, який повертає поточний крок і відсоток завершення потоку роботи з перенесення даних — кінцева точка стану буде викликати цей запит кожні 5 секунд, щоб показувати поступ у інтерфейсі користувача. » *

** Дочірній поток роботи ** Потік роботи було розпочато з іншого потоку роботи. Дочірні потоки роботи виконуються незалежно один від одного, і їх можна налаштувати на продовження роботи навіть у разі скасування батьківського потоку роботи. Вони корисні для паралельності (розгорнутих шаблонів), розбиття великих потоків робіт на прості у керуванні одиниці і повторного використання логіки потоків робіт.

• Приклад: « Для кожного замовлення у масовій партії запустити дочірній робочий потік для обробки окремого замовлення — дочірні потоки роботи виконуються паралельно, а батьківський робочий потік чекає на завершення всіх потоків роботи, перш ніж продовжити роботу ». *

Расписание Вбудований у Temporal механізм для запуску потоків робіт за повторюваним розкладом, визначеним за допомогою виразу cron. Розклади замінюють потребу у зовнішніх завданнях cron або запланованих завданнях — Temporal керує часом, обробляє пропусчені запуски і надає вам історію запланованих виконань.

• Приклад: « Створити часовий розклад з виразом cron 0 3 * * * для запуску потоку роботи щоночі о 3 годині ранку — ви можете переглядати цей поток роботи і керувати ним з інтерфейсу веб- програми Temporal, не торкаючись жодної інфраструктури. » *

** Версії потоку робіт ** Механізм безпечного зміни коду потоку робіт, який зараз виконується у виробничому режимі. Оскільки тимчасовий робочий потік відтворює історію робочого потоку для відновлення стану, зміна логіки робочого потоку може призвести до помилок, пов’ язаних з недетермінізмом потоків дій. Керування версіями (за допомогою workflow.getVersion() або API для латів) надає вам змогу вносити зміни без порушення існуючих запусків.

• Приклад: « Скористайтеся workflow.getVersion(), щоб ввести нову логіку повторних спроб оплати — потоки робіт під час виконання будуть виконуватися за старим шляхом, нові потоки робіт — за новим шляхом, і після завершення всіх старих потоків робіт ви зможете вилучити гілку версії. » *

Временная Хмара Пропозиція Temporal SaaS з повним керуванням, яка запускає інфраструктуру сервера Temporal (планування, відновлення, зберігання історії) на інфраструктурі Temporal, а не вашій власній. Команди використовують Temporal Cloud, щоб уникнути роботи сервера Temporal, бази даних Cassandra і кластера Elasticsearch. Приклад: “Ми перейшли з самостійно розміщеного Temporal на Temporal Cloud в минулому кварталі - ми виключили операційне навантаження Cassandra і інженерна команда зосередилася виключно на коді Workflow замість інфраструктури.”

Як використовувати цей словник

Темпоральні обговорення проектування зосереджені на розділенні між логікою потоку роботи (оркестрація, стан, рішення) і логікою діяльності (побічні ефекти, зовнішні виклики). Поширений коментар перегляду: «цей зовнішній виклик API повинен бути в дії, а не безпосередньо в робочому потоці» - тому що код робочого потоку повинен бути детермінованим, а зовнішні виклики не є.

Обговорення сигналів і запитів виникають під час створення потоків робіт, які потребують взаємодії з системами, що працюють з користувачем. Команди обговорюють питання « Які сигнали слід отримувати цьому потоку роботи? » і « Які запити слід показувати для API стану? » Версії є повторюваною темою, коли потрібне оновлення потоку роботи, який виконується вже довгий час — правило « завжди використовувати getVersion під час зміни логіки потоку роботи » є стандартною тимчасовою найкращою практикою.

Приклад розмови

** Вера: ** Мені потрібно оновити логіку повторення спроб платежу у потоці роботи з поверненням коштів. Він працює на замовлення вже три дні. ** Omar: ** Не змінюйте код Workflow безпосередньо — це призведе до помилок недетермінованого типу для запусків у польоті. Використовувати версії потоку робіт. Вера: Так — я використаю getVersion, щоб розгалужити нову логіку. Старі шляхи йдуть старими шляхами. Omar: Exactly. Також додайте обробник запитів, щоб команда підтримки могла перевіряти кількість повторних спроб без перегляду бази даних.

Practice

1. Пояснити розбіжність між потоком робіт і діяльністю розробнику, який не має досвіду роботи з тимчасовими файлами. Використовуйте аналогію (наприклад, менеджер проекту проти підрядника), а потім відобразіть її назад до технічних концепцій детермінізму і побічних ефектів.
2. Створіть тимчасовий поток дій для процесу вилучення облікового запису користувача: поток дій має надіслати прощальну електронну пошту (Дія), зачекати 14- днівовий період очікування, перевірити, чи було повторно активовано користувача (Запит), а потім вилучити обліковий запис (Дія). Визначте, де ви хочете використовувати Сигнали, Запити і Дії.
3. Поясніть роботу з версіями потоку робіт колегі за допомогою метафори запущеного конвеєра. Почему бы тебе не просто изменить код и передислоцировать? Яка проблема вирішується getVersion?

Національний гідрографічний інститут: Відповідь і відповіді

Сила Temporal полягає не тільки в його технічній архітектурі - надійне управління станом, надійне планування - але також у тому, як команди спілкуються навколо нього. Для не рідних англомовних носіїв, розуміння тонких нюансів професійних робочих потоків і зворотного зв’язку може бути значною перешкодою. Одне — це зрозуміти, що означає коментар перегляду коду; зовсім інше — впевнено відповісти на нього, або навіть розпочати конструктивну дискусію. Поширеною ситуацією є отримання зворотнього зв’ язку щодо визначення потоку робіт, яке не відразу стає зрозумілим. Розглянемо цей сценарій: Сара, новачок у Temporal, надіслала PR, що містить складний робочий процес, що включає декілька дій і сигналів. Під час перегляду коду, старший інженер Мартін залишив коментар, в якому сказав: «Чи можете ви пояснити мету сигналу on_success тут? Це виглядає трохи розмовним, враховуючи очікуваний результат»

Це не тільки про синтаксис або технічну коректність; це про передачу намірів і забезпечення узгодженості зі стандартами команди. Простого “так” або “ні” не вистачить. Сара должна понять, почему Мартин отметил это. Можливо, сигнал був надто складним, що призвело до потенційних проблем з продуктивністю. Або, можливо, простіший підхід міг би досягти того ж результату більш чітко. Ключовим є активне спілкування і демонстрація розуміння найкращих практик Temporal. Фрази на кшталт «Я ціную, що ви на це звернули увагу» або «Дайте мені пояснити мої міркування…» можуть розсіяти потенційні незручні ситуації і продемонструвати бажання навчатися. Також важливо задати прояснюючі питання — «Чи можете ви розібратися, що ви маєте на увазі під «слівним» в цьому контексті?» — а не припускати розуміння. Аналогічно, коли ви пишете описи PR, будьте чіткими щодо наміру ваших змін. Не просто вкажіть « Оновлено робочий процес ». Замість цього скажіть щось на зразок: « Переглянуто робочий процес order_processing для інтеграції з новою системою обліку запасів, використовуючи signal, який було запущено після успішного завершення замовлення для оновлення рівнів запасів »

Крім того, розмови Slack часто включають обговорення часових складностей. Поширений обмін може бути: “Гей команда, ми бачимо деякі піки затримки в shipping_workflow. Чи є у когось ідеї?» Добра відповідь не була б просто «Перевірте журнали». Замість цього вона б визнала проблему і запропонувала співпрацю: «Я досліджую затримку shipping_workflow. Я почав моніторити тривалість активності і час поширення сигналу — можливо, ми можемо пов’ язати це з останніми змінами у визначенні потоку роботи або налаштуваннях розкладу? » Використання точної термінології, наприклад, « тривалість активності », « час поширення сигналу » або « налаштування розкладу », демонструє знайомість з основними концепціями Temporal і дозволяє ефективніше вирішувати проблеми.

# Example: Checking activity status within Temporal using the CLI
temporal activities list --workflow shipping_workflow --query "status = 'running'"

Ця команда, хоча і здається простою, показує звичайну взаємодію потоку робіт — спостереження стану дії у межах тимчасового потоку робіт. Зрозуміти, як сформулювати цей процес - і потенційні результати - є життєво важливим для ефективного співробітництва в рамках тимчасової команди розробки. Пам’ятайте, що чітке спілкування не тільки про уникнення непорозумінь; це про створення співпраці середовища, де кожен може внести свій внесок у свої знання.