Durable Execution Using Temporal - Ori Zeiri

TechGym · 2026-05-31 · 35м 17с · 91 просмотров · YouTube ↗

Топики: durable-execution

🎧 Аудио

📝 Summary

model=deepseek-v4-flash · prompt=summary-v7 · 11 135→2 521 tokens · 2026-07-20 14:57:37

🎯 Главная суть

Temporal — open-source платформа для durable execution (отказоустойчивого выполнения), которая позволяет писать меньше кода, делегируя механизмы повторных попыток, отслеживания состояния и восстановления после сбоев. Вместо того чтобы вручную строить retry-механизмы, state machines и компенсационные транзакции, разработчик описывает бизнес-логику в виде Workflows и Activities, а Temporal гарантирует, что выполнение продолжится с последней успешной точки даже после падения сервера, перезагрузки пода или обрыва сети.

Проблема: сбои в распределённых системах

В любой системе с несколькими микросервисами количество потенциальных точек отказа резко возрастает: таймауты, сетевые ошибки, перезагрузки подов, частичные сбои. Разработчики часто сталкиваются с ситуацией, когда после деплоя всё выглядит хорошо, но через пару минут один из подов перезагружается, и нет сохранённого состояния — данные в базе есть, но информация о том, какой код уже выполнился, теряется. Приходится восстанавливать вручную по логам, а вернуться точно к моменту остановки невозможно.

Наивное решение: retry + idempotency — но с кучей оговорок

Рассмотрим пример онлайн-платежа. Фронтенд отправляет запрос в бэкенд, который должен: списать деньги с клиента (через платежного провайдера), сохранить транзакцию в БД и отправить email с квитанцией. Самое простое — обернуть весь процесс в цикл с try/except и повторами. Но что, если списание уже прошло, а БД упала? Повтор приведёт к двойному списанию. Нужен механизм идемпотентности: проверять, была ли уже списана сумма, и если да — не повторять. Это ведёт к усложнению: нужно хранить состояние, делать проверки перед каждым шагом, писать компенсационные действия при частичных отказах. В итоге вместо простого списания строится целая система Workflow’ов.

Workflows и Activities в Temporal

В Temporal вся логика делится на два уровня:

Workflow — оркестрация, описывает последовательность шагов и их условия.
Activity — конкретное действие с бизнес-логикой (вызов API, запись в БД, отправка email).

Workflow — это как программа, которая может «засыпать» на неопределённое время и просыпаться при наступлении событий. Каждый Activity должен быть идемпотентным и максимально атомарным — как кнопка включения/выключения компьютера: для каждого состояния есть свой Activity (включить, выключить).

В коде Workflow определяется как класс с аннотациями, внутри которого вызываются Workflow.execute_activity(). Весь код, который раньше требовал циклов с retry, сводится к паре декораторов.

Архитектура Temporal

Кластер Temporal состоит из трёх ключевых сервисов:

Frontend Service — шлюз для всех клиентов. Принимает запросы на запуск Workflow’ов и предоставляет встроенный веб-интерфейс для мониторинга выполнения.
History Service — записывает каждую точку выполнения (Workflow started, Activity started, Activity completed и т.д.). Этот журнал позволяет в любой момент восстановить точное состояние.
Matching Service — управляет очередями задач (Task Queues). Когда History Service фиксирует завершение шага, он уведомляет Matching Service, тот помещает новую задачу в очередь.
Worker Service — это код, который вы пишете. Worker подписывается на определённую очередь, забирает задачи и выполняет Workflow’ы и Activities. Сам по себе Worker «глупый» — он не знает, что будет делать, просто берёт следующую задачу.

Механизм работы: Worker забирает задачу из Matching Service, выполняет Activity, возвращает результат в History Service, который обновляет лог и уведомляет Matching о следующем шаге. Так образуется бесконечный цикл.

Демонстрация: запуск и мониторинг

На практике всё выглядит так: запускается локальный Temporal Server командой temporal server start-dev. Он поднимает все компоненты кластера в Docker. Затем запускается Python-Worker, который одновременно слушает очередь задач и регистрирует Workflow’ы с Activities. После этого выполняется клиентский код, отправляющий запрос на запуск Workflow’а.

Веб-интерфейс Temporal (по умолчанию на localhost) показывает все активные и завершённые Workflow’ы. Кликнув на конкретный ID, можно увидеть детальную временную шкалу: когда начался Workflow, когда стартовал Activity, когда завершился и так далее. Этот UI агностичен к языку и типу бизнес-логики — любые Workflow’ы, запущенные через Temporal, отображаются здесь автоматически.

Retry Policy и обработка ошибок

Для каждого Workflow и Activity можно задать Retry Policy: максимальное количество попыток, интервал между ними, максимальный интервал, а также список исключений, при которых повтор не нужен (например, если ошибка неисправима — сразу вернуть ошибку пользователю). Всё это конфигурируется декларативно, без написания циклов.

Пример кода: в Workflow определяется retry_policy = RetryPolicy(maximum_attempts=3, backoff_coefficient=2), затем при вызове execute_activity(Withdraw, payment_details, retry_policy=retry_policy) Temporal сам делает повторы с экспоненциальной задержкой.

Пример перевода денег

В демо используется сценарий перевода средств между счетами. Activities: Withdraw и Deposit. Оба должны быть идемпотентными. Workflow выполняется так: сначала вызывается Withdraw, после успеха — Deposit, затем возвращается подтверждение. Если Worker падает во время выполнения, Temporal не теряет состояние: при перезапуске Worker продолжает с того Activity, который не был завершён.

Одно из наглядных испытаний: запускается Workflow, Worker временно останавливается. В UI видно, что Workflow перешёл в состояние «Running», задача висит в очереди передачи денег (Task Queue). Как только Worker снова запускается, он мгновенно подхватывает задачу, выполняет Activity, и процесс завершается. Весь журнал истории сохраняется без потерь.

Temporal и AI-воркфлоу

Temporal активно используется для построения AI-агентов. Например, при помощи Temporal можно реализовать LLM-пайплайн, где агент получает промпт от пользователя, проходит несколько этапов обработки, обращается к Stripe API и возвращает результат. Temporal гарантирует, что даже при сбое в середине обработки запроса не придётся начинать заново.

Компании, использующие Temporal

Snapchat — деплой микросервисов.
Netflix — cloud operations.
Stripe — обработка платежей.
OpenAI — масштабирование ChatGPT и поддержка AI-агентов.

Temporal полностью open source, поддерживается фондом Agentric AI Foundation (те же люди, что развивают Linux).

Дополнительные возможности

Сигналы — способ передавать данные между Workflow’ами и изменять их состояние извне.
Child Workflows — возможность вызвать один Workflow из другого, получая вложенные диаграммы.
Scheduling — Workflow’ы могут находиться в ожидании месяцами (например, для отложенных уведомлений).
Saga-паттерн и компенсации — если в середине длинного процесса происходит сбой, Temporal может автоматически выполнить компенсирующие действия (rollback).
Concurrency и масштабирование — автоподстройка количества Worker’ов, приоритетные очереди, fairness.

Коротко: что даёт Temporal

При работе с микросервисами отказы — норма. Самая слабая часть — собственно выполнение (execution). Temporal превращает его в durable: вы пишете бизнес-логику в Activities, описываете последовательность в Workflow, а всё восстановление, повторные попытки и ведение лога истории берёт на себя платформа. Это open source, легко выводится в продакшн, имеет готовый UI и большое комьюнити.

📜 Transcript

he · 3 717 слов · 73 сегментов · clean

Показать текст транскрипта

בוקר טוב לכולם, אני רוצה רגע להתחיל באיזשהו סיפור, בוא נדמיין שאנחנו עכשיו איזושהי חברת e-commerce, ויש לנו איזשהו מוצר, עכשיו השעה לא תשע בבוקר, השעה 2.17 דקות, בדיוק הפייפליין שלנו עבר, הדיפלוימנט עלה, על הנייר, הכל נראה ארוך. אנחנו עוברות לנו איזה שתי דקות, מתחיל לנו איזשהו תהליך, אבל מסיבה כלשהי, אחד הפודים שלנו החליט שהוא עושה ריסטארט. זה אומר שאין לנו איזשהו סטייט שנשמר, ואנחנו לא בדיוק יודעים מה קרה לקוד שכבר רץ בקלאסטר שלנו. בדיוק בנקודה הזאת, מה שקורה זה שאנחנו שומרים, את הדאטה, אבל אנחנו לא בהכרח צומרים את הביצועים של מה שקרה לנו. זאת אומרת, אנחנו כן יודעים לבוא ולהגיד, לבוא ולהסתכל ללוגים, לנסות לבוא לפעניח, אבל אין לנו היום איזושהי דרך קונקרטית לבוא ולחזור בדיוק לנקודה שממנה עצרנו, שבה קרה הקשר. אז היום אני רוצה לדבר איתכם על איך אפשר לכתוב פחות קוד, איך להפוך אותו להיות הרבה יותר עמיד. בהרצאה שלי, Durable Execution Using Temporal. אז על מה אנחנו נדבר היום? אנחנו נדבר רגע על עולם הבעיה, כמו שכבר הצגתי אותו מאוד מאוד בקטנה. אנחנו נדבר על מה זה הקסם הזה שקוראים לו Temporal, יהיה לנו איזשהו דמו קטן, ונדבר על איך זה רלוונטי לכם, ומה אתם יכולים לצאת מההרצאה הזאת. אבל רגע לפני כן, אני אציג את עצמי, אז כמו שאתם כבר מכירים, אורי זאירי, סינור סופטור אנג'ניר ב-Drivenets, ואני רוצה ספר לכם גם קצת על הדרך שלי. אז את הדרך המקצועית שלי התחלתי אי שם ב-2015, כשהייתי בתיכון, התחלתי דרך תוכנית שכולם מגשימים, מעומדת על ידי משרה הביטחון. והרעיון שנחשפים לתוכן שהוא אפילו ברמה אקדמיית, מגיל מאוד צעיר. שם זו הייתה הטעימה הראשונה שלי. משם התגייסתי ל-81, שירתי שם גם כשלוש שנים, כמפתח פול סטאק ואוטומציה. מה שהוביל אותי להתגלגל לתעשייה הביטחונית. עבדתי ברפאל על פרויקט קטן ומאוד מאוד מעניין שנמצאים בחדשות, אבל נדבר על זה אחרי הרצאה. אם מישהו מעניין אותו, שברפאל התחלתי כמפתח יחיד בצוות, ולאחר, אחרי שנה וחצי, הפכתי להיות ראש צוות, ואיפשהו בדרך, ראיתי את, קפץ לי איזשהו פרסום בלינקדין, על טקג'ים, אמרתי, טוב, יאללה, בוא ניתן לזה צ'אנס, והיום, כבר בשנה האחרונה, מפתח תוכנה בדרייבנטס. אז, זו הדרך שלי, ובזכותה אני פה ואתם פה, אז שוב, ממש מבסוט, ממש שמח, ויאללה, בואו נקפוץ. אז Distributed System in a RARD, בטח שאנחנו מדברים על מיקרו סרוויסים, שבאופן כללי, ברגע שיש לנו יותר מאיזשהו סרוויס אחד, יכולים להיות לנו הרבה מאוד נקודות של קשל, בטח שאנחנו רצים על הרשת. יכולים להיות לנו טיימאוטים או כל מיני מקומות של ריטראים בכל מקום, תהליכים מאוד מאוד ארוכים, מבלי הפסקות, יש לנו תמיד את הקטע הזה של It works on my machine, אבל זה ממש לא משנה בפרודקשן, שורה תחתונה, כישלונות, קרשים, דיפלוימנט, כל הדברים האלה נורמליים לחלוטין. עכשיו, בואו ניקח דוגמה, בואו נדבר את השלומים. ואני מניח שלכולנו יצא בצורה כזו או אחרת לבוא ולהעביר איזשהו תשלום באינטרנט. אני יוצא מנקודת הנחה שיש לנו איזשהו פרונט-אנד שמדבר עם הבקד שלנו. אנחנו עכשיו הולכים לבוא ולהעביר איזשהו תשלום, ורוצים לשמור אותו לדטאבייס, ואז בסוף לבוא ולשלוח איזשהו אימייל על הקבלה ללקוח שלנו. אז אחרי שדיברנו... על הארכיטקטורה, אם היינו צריכים לבוא ולעשות את זה בקוד, מול הבקן שלנו, זה הנראה פלוס מינוס ככה, נכון? יש לנו איזשהו אורדר אי-די, ההזמנה שבעצם היוזר, עם אותו יוזר אי-די רוצה לבוא ולמבצע, וכמה אנחנו צריכים לעבור ולחייב אותו. יש לנו את אותו פיימנט פרוויידר, שיכול להיות משהו פנימי או חיצוני, אנחנו בוחרים את אותו יוזר כמה אנחנו רוצים לחייב, רוצים לשמור את הטרנזקציה הזאתי, ובסוף לבוא ולהפיץ איזושהי קבלה. הלאה, נהיה? נראה פשוט, אחלה. אבל מה קורה אם אנחנו נכשלים בדרך? אז אם אנחנו נכשלים, בואו ננסה שוב. אז נבוא וניצור פה איזשהו פתרון נאיבי, שאנחנו נכנסים לאיזושהי לולת פור. ונעטוף אותה באיזשהו try and accept, במידה ויש לי איזושהי שגיאה, אני תופס אותה ואני רוצה לבוא ולנסות עוד פעם. אבל אתם בטח שואלים את עצמכם, מה קורה אם כבר חייבנו את הלקוח? או ה-DB קרס מאיזושהי סיבה מסוימת. אז פה אנחנו גם רוצים להשאיר איזשהו מנהנון של ID Impotency, זאת אומרת אנחנו לא רוצים שאם כבר חייבנו את אחד הלקוחות שלנו, אנחנו חייב אותו עוד פעם ועוד פעם, זה לא התנהגות שהיא תקינה, בטח שאנחנו מדברים במערכת שהיא בסקייל, אז אנחנו יכולים לבוא ולהוסיף לדוגמה שלנו, איזושהי בדיקה, לפני שאנחנו נכנסים לבוא ולנסות, במידה וכבר שילמתי, אז אל תרצי לי כלום. ושוב, לא פתרון שהוא אידיאלי, בטח כי אנחנו גם צריכים עכשיו לבוא ולפצל את כל מה שקשור לאימייל, או לתשלום. יש לי פה איזשהו סטייץ' שאני צריך כל הזמן לעקוב אחריו, ולנסות לראות מה בכלל קורה פה. אז אם שילמתי כבר, אז אל תעשה כלום, אבל אם לא שילמתי, אז כן תנסה לחייר את הלקוח, כן תשמור לי את הטרנזקציה לדאטאבייס, לא אופטימלי. אז מה בתכלס בנינו פה? בנינו איזשהו מנגנון של ריטרייז, איזשהו State Tracking, שאנחנו צריכים כל הזמן לבוא ולנסות לשמור מה קורה, יצרנו איזשהו Recovery Job, State Machine, מין הסתם כבר הסכרתי, שאנחנו צריכים לבוא ולעקוב אחרי מה שקורה, יכול להיות לנו איזשהו מנגנון של Compensation, שאם נכשלתי בדרך, אז אני צריך לבוא ולנסות לתקן את זה, בתכלס, מה שרצינו לעשות, זה לבוא ולחייב כרטיס, סיימנו פה, עם כל הדוגמת קוד הזאת, עם מערכת Workflowים שלמה. ולכן, אני רוצה לדבר איתכם על temporal. temporal זה כלי שהוא Open Source, ויש לו הרבה מאוד יתרונות. הוא יכול להיות מנועל self-hosted בקלאסטר שלכם, או בדוקר קומפוז, הוא יכול להיות גם כן managed. זאת אומרת, בקלאוד, אם אתם בוחרים להרוב ולשלם לטמפורל, אבל תכף, או בהמשך נדבר על זה. אז איך הקסם הזה בכלל קורה? אנחנו נדבר פה על שלושה נושאים, אנחנו נתחיל מלהפיין בכלל מה זה Workflow and Reactivities, נדבר על הארכיטקטורה של טמפורל, ובסוף איך כל השילוב ביניהם נותן לנו את ה-Durable Execution. אז, וורקפלווז, וורקפלווז everywhere, באמת ככה, כשאנחנו באים ועובדים בתשתית הזאת, אנחנו באים במיינדסט של וורקפלוים, ומה זה אומר בכלל? כמו שאתם יכולים לרוב ולהכיר מתהליכים כאלה ואחרים, יש לנו וורקפלוים כחלק מ-Gitab Actions, יכול להיות איזשהו תהליך מאוד מאוד סדור שיש לנו בפלטפורמה שלנו, מבחינת טמפורל, כל דבר יכול לבוא ולהיות וורגפלו, ואיך זה נראה, יש לנו בעצם איזושהי נקודת התחלה, ויש לנו נקודת סיום, ויש לנו את הבלוקים, שכל בלוק בעצם מעביר הלאה את השלב הקודם. אז אם עכשיו אנחנו צריכים לבוא ולדבר על איזשהו וורגפלו לדוגמה, נגיד ויש לי פה את ה... תהליכון הזה שאנחנו רואים פה על המסך, יש לי פה שלושה activities, שהרעיון של כל פונקציה פה זה שבעצם היא מחזירה איזשהו ערך סופי. אז יש לנו פה את FOO שתחזיר לנו את A, יש לנו את BAR שתחזיר לנו את B, ויש לנו את BOO שתחזיר לנו את C. כשאנחנו באים ועובדים עם כל activity, כמו שדיברנו מקודם, כל activity צריך לבוא ולהיות בסוף ID important. אם אנחנו צריכים לבוא ולהדגים את זה, תחשבו רגע על המחשב שלנו. נכון? בכל מחשב ארם יש איזשהו כפתור כיבוי, כשאנחנו לוחצים עליו, הוא מבצע איזושהי פעולה בהתאם לסטייט הנוכחי של המחשב. אם הוא דלוק, אז הוא מכבה אותו, ואם הוא כבוי, אז המחשב שלנו נדלק. אם היינו צריכים לבוא ולהפליל את זה דרך טמפורל, היינו צריכים שיהיה לנו כפתור במרכאות עבור כל פעולה כזאת. זאת אומרת, היינו צריכים איזשהו activity לכיבוי, והאם צריכים activity להדלקה. אז אני חוזר רגע ל-workflow שלנו, ההתחלתי של התשלום. תשימו לב שהיום בצורה פייטונית, אני מייצר פה איזשהו class, אני אומר, זה ה-workflow definition, כשאני עכשיו הולך לבוא ולהריץ את ה-workflow שלי, אלה הפרמטרים שאני רוצה לבוא ולקבל, ומה שאני עושה בתכלס, אני עושה Workflow Execute, ל-Activity, זאת אומרת שכל הביזנס לוג'יק שלי, כל activity מוגדר, כל הביזנס לוג'יק שלי סליחה, מוגדר בתוך אותה activity. אז יש לנו, כמו שאמרתי, את המסגרת שזה Workflow, ויש לנו activity שזה באמת מה קורה בתכלס, מי הולך לבצע את המשימה הזו. אז תשימו לב שאם עכשיו אנחנו צריכים לעבור לחזור לדוגמה התחלתית, שדיברנו על תשלומים, פתאום זה נראה הרבה הרבה יותר דומה, מה שהוספנו סך הכל זה עוד כמה שורות של דקורטורים, שבעצם מגדירים לנו שאנחנו הולכים להשתמש בטמפורם, אבל בתחתסן אנחנו כותבים פה באמת הרבה פחות קוד, והוא גם הרבה יותר קרי, פלוס כל הקסם שאנחנו תכף הולכים לדבר עליו. אז מה יכול להיות? Workflow, כל דבר, שורה התחתונה, כל דבר, אם אנחנו צריכים להבוא ולדבר על דוגמאות, יכולים להיות לנו תשלומים, איזשהו subscription renewal, עכשיו מאוד מאוד חזק הרבה מאוד פייפליינים שקשורים ל-AI, יש גם פייפליינים שלמים שאנחנו יכולים להוסיף איזשהו human approval, כחלק מהלופ, אז אני רוצה לעבור רגע ל... לאחיטקטורה, איך בעצם כל הדבר הזה קורה, אז מה שאנחנו יכולים לראות פה על המסך, זה איזשהו סקרינשוט, מהאחיטקטורה הרשמית של טמפורל, יש פה כל מיני אלמנטים, לאיך הקסם הזה קורה, מה שאנחנו צריכים לבוא ולדעת, שלנו יש איזו אפליקציה, שמשתמשת בטמפורל SDK, לא משנה באיזה שפה, ואנחנו צריכים לבוא ולכתוב בסוף, את אותו טמפורל וורקר. מה קורה פה בתוך טמפורל קלאסטר, ברגע שאנחנו מרימים פה את השרת, ממש עוד רגע ניגע לזה, אבל בשביל לבוא ולעשות לנו קצת סדר בעיניים, בוא ניקח איזושהי אבסטרקציה, נתייחס לזה בצורה של בלוקים, ונתחיל מה-front-end service. כשמו כן הוא, front-end, כמו שאנחנו מכירים באפליקציות front-end, הוא בעצם הגשר שלנו לבוא ולתקשר, עם כל מה שקשור לטמפורל קלאסטר, עם הסרוויסים הפנימיים שלנו. זאת אומרת שיש לנו את האפליקציה הבקנדית שלנו, שמשתמשת, יודעת לבוא ולעשות אינבוק לטמפורל, הפרונטנט סרוויס שלנו יודע לבוא ולהיות הגשר בין הבקשות, ובנוסף לזה הוא גם מראה לנו איזשהו UI מאוד מאוד חמוד, שאנחנו יכולים לבוא ולעקוב אחרי כל התהליכים שלנו, מקצה לקצה. הוורקל סרוויס שלנו, אז אם בדיאגרמה ראינו במלבן הצהוב, כמו שאמרתי מקודם, ה-Worker Service הוא קטע קוד שאנחנו צריכים לבוא ולממש אותו. ה-Worker הוא בעצם, ה-Worker קצת טיפש, הוא הולך ומריץ את ה-Business Logic שלנו, הוא יודע לבוא ולהריץ גם Workflowים וגם Activities, ובעצם יש איזשהו תור פנימי. בסרוויס שאנחנו תכף נדבר עליו, שהוורקר יודע כל הזמן לבוא ולמשוך משימות, אנחנו אומרים לו, זה הטסקיו שאתה הולך להסתכל עליו, במידה ונכנס לשם, נכנסה לשם איזושהי משימה, פשוט תמשוך ותבצע, אבל הוא לא באמת יודע מה הוא הולך לבצע, ושוב, אנחנו נראה את זה בהמשך בדמו, איך אנחנו מגדירים את זה ומה אנחנו עושים שם בדיוק, אבל מבחינת הארכיטקטורה, אז תחשבו שאנחנו קיבלנו איזושהי פקודה בקלאסטר, יש לנו איזושהי משימה שנכנסה לתור, ה-worker שלנו יודע לבוא ולשלוף את אותה משימה, ובתכלס-תכלס מה שקורה, ה-workflow שלנו או ה-activity יודע לבוא ולהתחיל ערוץ. אני עובר לסרוויס נוסף, יש לנו את ה-history service, כשמו כן הוא יודע לבוא ובעצם לתעד. כל נקודה ונקודה בתהליך. אז יש לנו Workflow שהתחיל, אנחנו יודעים לבוא ולסמן שכרגע איזשהו activity התחיל, של Charge Payment, סיימנו את האקטיביטי הזה, אנחנו נראה שאנחנו בעצם מתחילים איזשהו activity חדש, סיימנו לשמור לדאטאבייס, אנחנו יכולים לבוא ולציין שסיימנו את התהליך שלנו, ואיך כל זה קורה? אז הגענו בעצם למאצ'ינג סרוויס, המאצ'ינג סרוויס יודע לבוא ולנהל לנו את כל התורים הפנימיים, זאת אומרת, אם אנחנו עכשיו צריכים לבוא ולדבר על איזשהו לופ, אז אמרנו שההיסטוריה, שהסרוויס היסטוריה יודע לבוא ולתעד לנו בכל שלב ושלב את התהליך, ההיסטורי בעצם מקפיץ הודעה למאצ'ינג, אוקיי, תהיה דתי, אתה יכול לבוא ולהתחיל לעבוד, נכנסה לי איזושהי בקשה על התור, ולאחר מכן, הוורקר שלי יודע לבוא ולהגיד, הנה נכנסה לי עבודה, אני מבצע אותה. סיימתי לבצע אותה, אני דוחף את העתקון הזה חזרה להיסטורי, וככה בעצם חוזר חלילה הלופ בצורה מאוד מאוד מופשטת. אז אם אני צריך רגע לבוא ולחזור להי-לבל ארכיטקטור, יש לנו את האפליקציה שלנו, יש לנו את הפרונט-אנד הטמפורלי, שדרכו אנחנו יכולים לעבור ולראות את כל מה שקורה בדרך, היסטורי שמתעד, מאצ'ינג שמקבל את הבקשות, וורקר שמבצע אותן, כל הלופה זה חוזר חלילה, והיסטורי ומאצ'ינג ששני מחוברים מאחורי הקליים הסוף לדאטאבייס שלנו, שיודעים לבוא ולשמור את כל התהליך. עכשיו אחרי שדיברנו מאוד מאוד בקצרה על כל סרוויס וסרוויס, זה נראה פלוס מינוס ככה. יש לנו את האפליקציה בקצה, אותו היסטורי סרוויס, פרונטנד, הקוד שלנו של הוורקל, וגם כשאנחנו נמצאים בסוף בפרודקשן, אז יש לנו גם איזשהו דאטאבייס שיודע לעבור ולשמור, לנהל את כל התהליכים האלה, כשאנחנו עובדים בסקייל, ההחלטות האלה הרבה יותר משפיעות, אם אנחנו רוצים לעבור ולעבוד עם, דאטה בי שהוא SQL או NO SQL, וגם על זה אפשר לדבר מאוד מאוד בהרחבה, אבל אם אנחנו צריכים לרוב ולקמת את זה לטובת השקף הנוכחי, אז זאת הארכיטקטורה בגדול. ואני רוצה רגע איזושהי התנחת הקומית, אני לא יודע, אני מכם מכיר את החייזר הזה שאנחנו רואים פה על הנוסח, כשאנחנו מדברים בעצם על Durable Execution, יצאו במהלך שיווקי, שהם מאמצים בעצם את דובוני הים. למי שמכיר, דובוני הים זה בעצם איזשהו אורגניזם חי מאוד מיקרוסקופי, שכל הרעיון שלו זה שהוא עמיד בסביבות מאוד מאוד קיצוניות. אז למה אני מראה לכם את זה? כי תכירו את זיגי, הקמאה של טמפורה. כמה טמפורל בטוחים בדורבל אקסקיושן שלהם, עד כדי לשלוח רסברי פאי לחלל ביחד עם זיגי, יש פה סרטון מאוד מאוד מעניין, שיש פה איזשהו טמפורל וורקר שרץ על רסברי פאי, אנחנו יכולים לראות מצלמה בלייב שמשדרת, תוך כדי שעוברים על הקוד ומסבירים מה המהות של טמפורל ואיך זה קורה, ואנחנו יכולים... לראות ממש בשידור עצמו, איך הכדור פורח הזה יוצא מהאטמוספירה, מפסיק לשדר, וברגע שאנחנו חוזרים למצב שיש קליטה, השידור ממשיך, וכל זה קורה באמת כחלק מהדורבל אקסקיושן של טמפורל. אז זה מהלך שיווקי גיוני בעיניי. אז אחרי שדיברנו רגע על כל מה שקשור לדורבל אקסקיושן, אנחנו יכולים לבוא ולשמור כל שלב ושלב בסטייט, אנחנו יכולים לבוא ולנסות באופן אוטומטי להמשיך מהנקודה שהפסקנו בה, וגם אם נקננו באמצע, אנחנו יכולים לבוא ולחזור בדיוק לנקודה האחרונה שממנה עצרנו. אז... נעבור רגע לאיזשהו דמו קצרצר, אז העדצי את הפקודה של temporal server, סטאר דיו, מה שהוא עושה מאחורי הקלעים, הוא בעצם מרים לנו את כל ה-temporal cluster, עם כל הסרוויסים השונים, מה שנשאר לי להריץ כרגע, זה בעצם את ה-worker שלי, אני כרגע מריץ איזשהו Python worker, כמובן כבר נמצא פה בתוך איזשהו virtual environment, וגם הפרויקט הזה, מי שמעניין אותו, זה פרויקט open source, אני יכול לשלוח לכם את הלינק הזה, אלא אחרי זה, ומה שכרגע אני עושה זה בעצם מריץ את ה-workflow שלי. אז הדוגמה פה היא מדברת על תשלומים, אבל מדברת על תשלומים מסוג אחר. אנחנו בהתחלה דיברנו על לרוב ולחייב ולשלוח קבלה, בדוגמה הנוכחית אנחנו מדברים פה על העברת כספים מחשבון בנק לאחר, אבל זה די אגנוס לי לצורך הדוגמה, אז תשימו לב שכרגע יש לי פה איזשהו UI על המסך, UI של טמפורל, אתם פרקים לב לראות שהוא self-hosted, אם עכשיו אני אבוא ורענן, תשימו לב שיש לי פה כבר איזשהו walkflow שיתבוצע, אני... לוחץ על ה-workflow ה-ID הזה, ובאופן אוטומטי אני יכול לבוא ולראות את כל המידע לגבי אותו תהליך, אם זה ברמת ה-Time Stamp, כמו שאמרתי לכם, יש לנו פה איזושהי התחלה של Workflow Execution Started, Activity Started, סיימתי את האקטיביטי, אז אני חוזר לתור מסמן שסיימתי, מתחיל את האקטיביטי הבא, ומעבר לזה אנחנו יכולים גם לבוא ולראות את כל התהליך. מקצה לקצה. אורי, זה ה-UI של טמפורל עצמו? כי זה לא UI שלך. זה מה שאותן ה-open source. זה ה-UI, נכון, זה ה-UI ה-open source של טמפורל, שהוא מתממשק בעצם, הוא אגנוסטי לכל workflow ו-activity שעובד עם טמפורל, זאת אומרת שברגע שהגדרנו את הקוד שלנו כמו שצריך, אנחנו נראה את התהליכים האלה פה. וזה כמובן משהו שאנחנו רואים בה מאחור הקלעים, אז מה קרה פה עד עכשיו? אז דיברנו, אמרנו שיש לנו את ה-Temporal Server, יתנו את ה-Worker שלנו, שהוא בעצם זה שמבצע את הבקשות, ויש לנו את ה-Python Run Workflow, שבסוף מחזיר לנו את ה-Transfer Complete, אז בואו נסתכל רגע על מה קורה בתוך Run Workflow, תשימו לב, יש לי פה איזשהו קליינט קונקט, אני שוב מתחבר לסרבר, פחות מעניין אותנו כרגע, מגדירים פה איזשהו קלאס של פיימנט דיטלס, ובסוף, מאחורי הקלעים, קליינט אקסקיוט וורקפלוא, מה הורקפלוא שאנחנו רוצים לרואו ולבצע, תכף אנחנו נעשה עליו דיפ דייב, מאיזה טסק שאנחנו רוצים לרואו ולקרוא, ובסוף מה ה-ID שאנחנו הולכים לראות או לשמור עליו. את כל בקשה ובקשה. אז אם אנחנו צריכים ללכת רגע לריצה עצמה, אז יש לנו פה את הקובץ Workflows.py, כמו שראינו בדוגמת קוד במצגת, יש לנו פה Workflow Definition, ויש לנו כאן את Workflow Run, אז איך ריצה בתפלס נראית? אני צריך לבוא ולהגדיר איזשהו retry policy, כדי שאני ידע לבוא ולהגיד. מתי נכשלתי מה הגבולות גזרה שלי, אני צריך לבוא ולהגיד, מה המקסימום הטמפ שאני רוצה לבוא ולנסות כל פעם? מה הטיים דלתה ההגיוני שאני רוצה לחכות בינו, או לפעול בתחום זמנים הזה? אם קיבלתי איזושהי שגיאה מאחד הסוגים הבאים, אל תנסה לעשות את זה, זה אקספשן מבחינתי. אני צריך להחזיר פה שגיאה ליוזר, או שגיאה שלא הצלחתי לבצע את התהליך. אז לכל וורקפלוק הזה, אנחנו צריכים לעבור ולהגדיר איזשהו retry policy. על הנייר, שוב, אנחנו אומרים, תבצע לי את האקטיביטי מסוג withdraw. מה הretry policy שלי, ומה ה payment details, זה מה שהגדרנו למעלה. תבצע לי את withdraw. סיימתי לבצע את המשיכה שלי, אוקיי, אז תבצע לי בעצם איזשהו דפוזיט, מה קורה בתוך אותו דפוזיט או בתוך אותו ווידרו, בואו ניכנס לזה, אז תשימו לב שיש לנו בעצם את activities.py, ואנחנו יכולים ממש לראות, מה קורה בתוך כל activity כזה, עכשיו כמובן שפה זה בצורה מסומלצת, אבל אם היינו צריכים עכשיו לבוא ולעבוד עם איזושהי מארכד בסקייל, או לבוא ולעשות איזושהי פנייה, האקטיביטי שלנו זה המקום לבוא ולהגדיר את הביזנס לוגיק, אנחנו רוצים לבוא ולפנות לאיזשהו API חיצוני, אנחנו רוצים לבוא ולשמור, וזה בדיוק הנקודה שאנחנו צריכים לחשוב עליה, מה הפעולה שצריכה לבוא ולהיות ID and Potence, וגם המיינדסט שאנחנו באים וכותבים את אותם אקטיביטיז, צריך לבוא ולהיות טמפורליים. זאת אומרת שהמשימות הן מאוד מאוד מוגדרות, מאוד מאוד קטנות, כמו בדוגמה שראינו של ההדלקה וכיבוי של המחשב. אז כשאנחנו באים ומבצעים את אותה משיכה, אז בסוף אנחנו מקבלים פה ריצה של ה-withdraw, וכנה לגבי ה-deposit. מצרפים את זה לאיזשהו פרד אסינכרוני. ובסוף אנחנו מקבלים את ה-confirmation, וזה גם מה שקיבלנו בסוף בקונסול שלנו. אז יוני שאלה שאלה טובה מאוד מקודם, מה קורה, איך אני רוצה לבוא ולעשות retry, איך אני יכול לבוא ולנהל כל מה שקשור. אז אני כרגע עצרתי את ה-worker שלי. אני אריץ כרגע עוד איזשהו workflow. אני לא מקבל כלום, בוא נקפוץ רגע ל-UI של Temporal, שימו לב שכרגע יש לי פה איזשהו תהליכון נוסף, שכרגע הוא נמצא במצב של ראנינג, כל הקלאסטר שלי באוויר, ה-work floor started, הוא כרגע בסקג'ול, הוא עבר את ה-history, ה-history תחיל לשמר לנו כל מיני נקודות בדרך, נכנסה בקשה בעצם לתוך ה-Transfer Money Task Queue, וכרגע אני בעצם מחכה שיהיה מישהו שיבוא וירים את המשימה. אז שמחו עליי, אני במסך נפרד מרים רגע את הוורקר. תוך שנייה, תשימו לב, הוורקר בא וידע לאסוף את המשימה שנכנסה לתור. בטח ראיתם גם בלייב שההיסטורי, שכל הטיימסטמפים שלנו פה התקדמו. וזו רק דוגמה אחת, לקוח של טמפורל. אז אם אני עכשיו צריך לבוא ולהסתכל על מה זה אותו וורקר, אז שוב, בצורה מאוד מאוד פשוטה, יש לנו את הקליאנט שלנו, אנחנו אומרים לו, אוקיי, זה התור שאתה הולך לדבר עליו, סליחה, זה התור שאתה הולך להזין לו, אלה סוגי הוורקפלואים שאתה יכול לבוא ולהריץ, ואלה האקטיביטים. שאתה יכול לבוא ולטפל בהם. זה הכל. זה כל הקוד ה-work-age שלנו. מבחינתי, כשאני ראיתי את זה בפעם ראשונה, זה פוצט פליט המוח. ואני חוזר רגע לשאלה של נטה מקודם, כשאנחנו עובדים בסקאל, מין הסתם זה נראה אחרת לחלוטין, אבל העקרונות, הן עקרונות זהים לגמרי. איפה רואים את החיבור בין הקוד שלך ל-UI היפה של הטמפורל שמציג לך את כל ה... איפה החיבור הזה קורה? אז אנחנו לא באמת רואים את זה, זה פשוט ברמת הקליינט קונקט, ברגע שאנחנו יודעים לבוא ולהגיד, זה הסרבר שאני מאזין עליו, זה כבר קורה מאחורי הקלעים, אין לנו אופציה לבוא ולעשות בראוז למה סוגי האקטיביטים שאנחנו תומכים בהם, אלא יש לנו דרך לרוב ולראות, רק את הריצה או את הריצות האחרונות. יש לנו אופציה גם לבוא ולפלטר כל מיני, אם זה רץ היום, אנחנו יכולים לבוא ולתזמין, דברים שרצים כרגע. אם אנחנו עובדים באיזשהו קלאסטר, אנחנו יכולים לבוא ולסנר אותם לפי נאימספייסים. דיפלימנט זה ממש ממש תורה, לאיך אנחנו יכולים לבוא ולהשתמש בכלי המטורף הזה. טוב, אז אני חוזר למצגת. אז כמו שהבנתם, בטמפורל הכל עובד ב-workflowים, לא סתם שמתי את השקף הזה מקודם, ואיפה זה בעצם פוגש אותנו בעידן ה-AI? AI Workflows. AI Workflows Everywhere. אז יש פה איזשהו סרטון מאוד מאוד מגניב, של איך אפשר לבוא ולבנות איזשהו AI Agentים טמפורל, ניסיתי לבוא ו... לעשות איזשהו דמו קצרצר, ראיתי שזה גוזל יותר מדי זמן, אז העדפתי לתת לכם לינק ליוטיוב, מה שאתם יכולים לבוא ולראות בסרטון, זה איזשהו LLM, שיש לנו פה איזשהו פרונטנד, יודע לבוא ולקבל פרומט, ואנחנו יכולים ממש לבוא ולראות את הריצה תוך כדי, בסוף זה גם יודע לבוא ולהתממשק לאיזשהו Stripe API, אני אשלח לכם את כל הלינקים, כל הדברים, כל המושגת, לסוף ההרצה. אז אחרי שדיברתי, ושיבחתי כל כך הרבה את הכלי הזה, אני רוצה לבוא ולהרים לו עוד קצת, טמפורל, קודם כל זה כלי שהוא אופן סורסי, אופן סורס לחלוטין. ולא רק זה, הוא גם נתמך עכשיו על ידי האג'נטיק AI פאונדיישן, שזה בעצם החבר'ה שמפתחים, וממשיכים להוציא עדכונים ללינוקס, אז שתבינו, כמה הכלי הזה הוא לא בדיחה, כמה הוא רציני וכמה אנשים בעצם חזקים מאמינים בו, ואני ביחד איתם. ויותר מזה, אם כבר נדבר על סיפורי הצלחות, אז יש פה הרבה מאוד חברות שמשתמשות בטמפורל מאחורי הקלעים, על איך סטרייק משתמשת בטמפורל כדי לרוב לבצע את התשלומים שלהם. OpenAI נותנים איזושהי מעטפת כדי לבוא ולעשות סקיילינג ל-HGPT, ובנוסף לזה, טמפורל יודע לבוא ולתת תמיכה לאג'נטים של OpenAI בצורה מאוד מאוד כלילה. נטפליקס השתמשו בטמפורל כדי לבוא ולהגדיל את ה-Cloud Operations שלהם. סנאפשט משתמשים בטמפורל בשביל לעשות להם deploy. למיקרו סרוויסים שלהם, ויש באמת עוד כל כך הרבה דוגמאות באינטרנט, זה תורה מבחינתי, ואפשר להמשיך ולדבר על זה עוד כל כך הרבה זמן. טוב, אז נגענו בהרצאה הזאתי, ב-Basics, למי שזה מעניין אותו, אני זרוק לכם פה עוד כמה נקודות שהן מעבר, ששווה לחקור עליהן. מי שרוצה לבוא ולרקור או לקרוא על איזשהו קונקרנסי, מה קורה בעצם שאנחנו רוצים לעבור ולהריץ כמה אקטיביטיז במקביל, כמה אקטיביטיז, כמה וורקפלואים במקביל, איך אנחנו בכלל מתמודדים עם זה בסקייל, יש גם המון גישות, אנחנו עושים אוטו סקיילינג לוורקרים, איך אנחנו יודעים לבוא ולתת איזשהו תיעדוף מבחינת כל התורים שלנו. אז יש priority cues ו-fairness, שזה גם נושאים מאוד מאוד מעניינים. אם אנחנו רוצים לבוא ולשמור איזשהו state, ולהעביר אותו בין ה-workflowים, אנחנו יכולים לבוא ולהשתמש בסיגנלים, או איזשהם מתכונים. Child workflows, מתוך workflow אנחנו יכולים לעשות invoke לאיזשהו workflow אחר, ואז אנחנו מקבלים איזושהי הדיאגרמה. אנחנו יכולים לבוא ולהוסיף איזשהו מנגנון של תזמונים, סקג'ולינג, יש תהליכים שיכולים לחכות באופן רדום חודשים על גבי טמפורל, ועוד פתרון שגם נגדנו עליו מאוד, דיברתי עליו מאוד בקטנה, זה סאגה פאטרנס וקומפנסיישן, איך אנחנו יודעים לבוא ולעשות ריקאברי מכישלונות חלקיים, ולדעת לבוא ולעשות את הרול בקזה בצורה חכמה. אז מה יוצא לכם מההרצאה הזאת? כשעובדים במיקרו סבריסים, יש הרבה מאוד כישלונות וזה מוגדר ככה, אקסקיושן היא החוליה החלשה, טמפורל עוזר לנו בעצם להפוך את האקסקיושן להיות הרבה יותר עמיד, כשאנחנו כותבים וורקפלויים, אנחנו יכולים להתעסק בביזנס לוגיק, באקטיביטיז ולא... לא לדאוג ל-Recovery Logic שלנו, זה Open Source לחלוטין, זה מאוד מאוד קל לקחת את זה לפרודקשן, ותודה רבה על הזמן.

⚙️ Pipeline jobs

Stage	Status	Att.	Updated
download	done	1/3	2026-07-20 14:56:46
transcribe	done	1/3	2026-07-20 14:57:07
summarize	done	1/3	2026-07-20 14:57:37
embed	done	1/3	2026-07-20 14:57:39

📄 Описание YouTube

Показать

“Write Less Code. Make It More Durable.”

Distributed systems fail all the time—deployments happen, pods restart, networks glitch. Yet while we persist data, we rarely persist execution.

In this talk, we’ll explore why handling retries, state, and recovery logic turns simple flows (like payments) into complex, fragile systems - and how Temporal changes that. Instead of building your own workflow engine by accident, you’ll learn how to make execution durable by design.