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

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, щоб розгалужити нову логіку. Старі шляхи йдуть старими шляхами. Точно. Також додайте обробник запитів, щоб команда підтримки могла перевіряти кількість повторних спроб без перегляду бази даних.

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'"

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