Temporal 调研：22K stars 的持久执行 workflow 引擎，为什么 6 年老牌开源能跟 Airflow 拼刺刀

22次阅读
Temporal 调研：22K stars 的持久执行 workflow 引擎，为什么 6 年老牌开源能跟 Airflow 拼刺刀

Temporal 调研：22K stars 的持久执行 workflow 引擎，为什么 6 年老牌开源能跟 Airflow 拼刺刀

Temporal 不是 Airflow 的 ” 竞品 ”——它是 完全不同范式的 workflow 引擎。Airflow 是 ”DAG 调度器 ”（批处理数据管道），Temporal 是 ” 持久执行运行时 ”（长程应用工作流）。22,584 ⭐ / MIT / 6 年老牌 / 3 大 SDK（Python / Go / TypeScript）/ sub-second 调度 + 10,000+ workflow starts/sec —— 本文把 Temporal 跟 Airflow 的根本差异讲透。

写在前面：为什么 workflow 引擎需要 ” 范式升级 ”

2026 年 workflow 引擎市场有个根本困惑：Airflow 已经 47K stars 统治了 7 年，为什么 Temporal 还能涨到 22K stars？

答案藏在两件事的根本不同：

  1. Airflow 的定位：“ 调度 + 监控批处理数据管道 ”（Python DAG / scheduler / executor / metadata DB）
  2. Temporal 的定位：“ 持久执行应用工作流 ”（event-sourced / 确定性重放 / 自动状态恢复）

如果说 Airflow 是“Excel 宏 ”（适合运行昨天的 ETL 任务），Temporal 就是“ 数据库事务 ”（适合管理跨小时 - 跨天 - 跨周的应用状态）。

一、Temporal 是什么

基本信息

项 数据
仓库 temporalio/temporal
Stars 22,584 ⭐（GitHub API 实时）
Forks 1,844
License MIT ✅ 干净
创建 2019-10-16（6 年老牌，不是新项目）
最新 release v1.31.2（2026-07-08，1-2 个月 / 版节奏）
最后 push 2026-08-28（昨天，仍活跃）
Open issues 931（多但合理，enterprise 阶段）
主语言 Go（核心 server）
体积 158 MB
官网 temporal.io / docs.temporal.io
Topics 16 个：durable-execution / workflow-engine / microservices / orchestrator 等

核心架构 ：Temporal = 服务端（Go）+ 多个语言 SDK + UI + CLI。服务端是事件溯源（event-sourced）架构，每个 workflow 执行被记录为事件序列 ，worker 崩溃后从事件历史 确定性重放 恢复状态。

5 个配套仓库

仓库 Stars 定位
temporalio/sdk-python 1,169 ⭐ Python SDK（2026-08-28 仍 commit）
temporalio/sdk-go 958 ⭐ Go SDK（跟主 server 同语言）
temporalio/sdk-typescript 900 ⭐ TypeScript SDK
temporalio/ui 430 ⭐ Temporal Web UI（可视化调试）
temporalio/tctl 50 ⭐ Temporal CLI（命令行管理）

所有 4 个 SDK + UI 都是 MIT ✅ + 2026 年仍活跃 commit，商用完全无风险。

二、Temporal 6 大核心能力

1️⃣ Durable Execution（持久执行）

核心卖点：Workflow 状态自动持久化 —— worker 崩溃、网络分区、Pod 重启都不会丢状态。

实现原理：
– 每个 workflow 执行被记录为
事件序列（event history）
– worker 重启后
自动从事件历史重放，恢复到崩溃前的精确状态
–
不是 ” 任务重跑 ”，是 ” 时间旅行 ” —— workflow 知道自己之前做过什么

@workflow.defn
class OrderWorkflow:
    @workflow.run
    async def run(self, order_id: str):
        # 第 1 步：检查库存
        await workflow.execute_activity(check_inventory, order_id)
        # 第 2 步：扣款
        await workflow.execute_activity(charge_payment, order_id)
        # 第 3 步：发货
        await workflow.execute_activity(ship_order, order_id)
        # 如果第 2 步 worker 崩溃，重启后从第 1 步之后继续，不会重新扣款！

2️⃣ Workflow as Code（不是 DAG 不是 YAML）

Temporal workflow 用普通编程语言写（Go / Java / Python / TypeScript / .NET）：

  • ✅ 用 if/else、for、函数调用 —— 标准编程结构
  • ❌ 不是 YAML DAG 文件
  • ❌ 不是 operator 抽象（没有 BashOperator / PythonOperator）
# Temporal workflow = 普通 Python 函数
@workflow.defn
class UserOnboarding:
    @workflow.run
    async def run(self, user_id):
        # 动态决策
        if await is_premium_user(user_id):
            await send_premium_welcome(user_id)
        else:
            await send_basic_welcome(user_id)

        # 等待 7 天
        await asyncio.sleep(7 * 24 * 3600)  # ✅ Temporal 会持久化这个等待

        # 第 7 天发邮件
        await send_followup_email(user_id)

对比 Airflow：Airflow DAG 写起来 ” 像配置 ”（operator 抽象 + XCom 传递），Temporal 写起来 ” 像正常写应用 ”。

3️⃣ Time Travel Debug（时间旅行调试）

Temporal Web UI 支持 ” 时间旅行调试 ” —— 可以 replay 任意历史时刻的 workflow 状态。

  • 调试第 3 天的 workflow 时，UI 显示第 1 天 / 第 2 天 / 第 3 天的完整执行历史
  • 每个 activity 的输入输出 + 失败原因 + 重试次数
  • Airflow DAG 失败时只能看到 ” 任务失败 ”，看不到失败前的状态

4️⃣ Activity-Level Retry（活动级重试）

每个 activity 可以独立配置重试策略（超时、重试次数、退避算法）：

@activity.defn
async def charge_payment(order_id):
    return await stripe.charges.create(...)

# 配置：5 次重试，每次最多 30 秒，第 1 次失败后等 5 秒再试
payment_activity = activity.defn(
    name="charge_payment",
    retry_policy=RetryPolicy(initial_interval=timedelta(seconds=5),
        maximum_attempts=5,
        maximum_interval=timedelta(seconds=30),
    ),
)

对比 Airflow：Airflow 是 task-level retry（任务级），Temporal 是 activity-level（活动级）—— 粒度更细，重试效率更高。

5️⃣ Multi-Language SDKs（多语言 SDK）

4 大语言 SDK 都是 MIT ✅ + 2026 年活跃 commit：

SDK Stars 最新 commit
Python 1,169 2026-08-28
Go 958 2026-08-28
TypeScript 900 2026-08-28
.NET （集成在 sdk-core） 活跃

对比 Airflow：Airflow 主要用 Python（用 DAG operator 抽象调用其他语言任务）。

6️⃣ Signals & Queries（信号 + 查询）

Temporal 独有：运行时跟 workflow 通信：

  • Signal：外部触发 workflow 内部状态变更（比如 ” 订单已取消 ” signal 传到 OrderWorkflow）
  • Query：外部查询 workflow 当前状态（不改变状态，纯读）

对比 Airflow：Airflow 是 单向调度 （scheduler → task），Temporal 是 双向通信（外部 ↔ workflow）。

三、Temporal vs Airflow 6 维深度对比

10 维对比表

维度 Temporal Apache Airflow
License MIT ✅ Apache-2.0 ✅
Stars 22,584 ⭐ 46,609 ⭐（2 倍 Temporal）
创建年份 2019（6 年） 2015（11 年）
主语言 Go（server）+ Python/TS/Go/Java/.NET SDK Python
核心抽象 Workflow + Activity（Code） DAG + Task（Python file）
状态管理 内置持久化（event history） 外部管理（metadata DB + 用户写 idempotency）
失败恢复 确定性重放（从崩溃点继续） 任务重跑（从 task 起点重跑）
调度延迟 sub-second dispatch 分钟级（scheduler 周期性 parse DAG）
吞吐量 10,000+ workflow starts/sec 数百 DAG runs/min
生态 4 大 SDK（跨语言） 70+ providers（大数据集成）

核心差异深度

1️⃣ 持久执行 vs DAG 调度（哲学根本差异）

Temporal 是事件溯源架构：

[订单 workflow 启动]
   ↓
事件 #1: WorkflowStarted{order_id: 123}
事件 #2: ActivityScheduled{check_inventory}
事件 #3: ActivityCompleted{success: true}
事件 #4: ActivityScheduled{charge_payment}  ← 假设 worker 此时崩溃
   ↓
[新 worker 重启]
   ↓
事件 #4 重放 → 从 "charge_payment" 开始恢复，不会重做 check_inventory

Airflow 是 scheduler 架构：

[scheduler 每分钟扫描 DAG 文件]
   ↓
发现 task "charge_payment" 未完成 → 启动 worker 跑
   ↓
如果之前 "check_inventory" 跑过 30 分钟失败 → retry 从头跑 30 分钟

结论：Temporal 处理长运行 / 长重试场景效率显著更高。

2️⃣ Workflow as Code vs DAG as Config

Temporal：写应用代码

@workflow.defn
class SubscriptionWorkflow:
    @workflow.run
    async def run(self, user_id):
        await workflow.execute_activity(trial_period, user_id)
        await asyncio.sleep(30 * 24 * 3600)  # 30 天 trial
        await workflow.execute_activity(charge_subscription, user_id)
        # 持续循环扣费
        while await workflow.execute_activity(check_active, user_id):
            await asyncio.sleep(30 * 24 * 3600)
            await workflow.execute_activity(charge_subscription, user_id)

Airflow：写 DAG 文件

@dag(schedule='@daily', start_date=days_ago(1))
def subscription_pipeline():
    trial = PythonOperator(task_id='trial_period', ...)
    wait = TimeDeltaSensor(task_id='wait_30_days', delta=timedelta(days=30))
    charge = PythonOperator(task_id='charge', ...)
    trial >> wait >> charge  # DAG 依赖图

结论：Temporal 写复杂业务逻辑更自然，Airflow 写数据管道更直观。

3️⃣ 内置状态管理 vs 外部状态管理

Temporal 自动持久化 workflow 状态 —— 不需要写 idempotency 代码。

Airflow 需要用户自己保证：
– 每个 task 写 idempotent code（重跑不会出问题）
– 用 XCom 或外部 DB 存中间状态
– 任务失败后正确恢复

结论：Temporal 对长程应用工作流友好，Airflow 对批处理数据管道友好。

4️⃣ sub-second 调度 vs 分钟级调度

Temporal：sub-second dispatch + 10,000+ workflow starts/sec

Airflow：scheduler 每分钟扫描一次 DAG 文件，最快分钟级 dispatch

结论：Temporal 适合延迟敏感场景（订单处理 / 用户 onboarding），Airflow 适合延迟不敏感场景（昨天 ETL）。

四、Temporal 5 大场景决策矩阵

场景 推荐 理由
📊 批处理数据管道（每日 ETL / 数据湖入仓） Airflow 70+ providers + 成熟的 DAG 模型 + backfill + 数据间隔感知
⏱️ 长程应用工作流（订单处理 / 订阅管理） Temporal 持久执行 + 状态自动恢复 + sub-second dispatch
🔄 跨服务 saga pattern（分布式事务 / 跨微服务补偿） Temporal Saga 是 Temporal 的标杆用例，自动处理补偿逻辑
👤 用户 onboarding workflow（多步 + 长等待 + 状态保存） Temporal Signal/Query + 30+ 天等待 + 自动恢复
🤖 AI Agent 长程任务（agent 跑小时到天） Temporal 比 LoopX 更成熟，但缺 AI Agent 专用的 evidence/quota 概念

核心判断 ： 如果你 workflow 是 ” 数据管道 ” 用 Airflow，如果是 ” 应用逻辑 ” 用 Temporal。

五、Temporal vs Cadence（前世今生）

Cadence 是 Uber 2017 年开源的 workflow 引擎，Temporal 的两位创始人 Maxim Fateev + Samar Abbas 当时在 Uber 主导 Cadence 项目。

  • 2017：Uber 开源 Cadence（最初的实现）
  • 2019：创始人离开 Uber 创立 Temporal Technologies，从头重写服务端（用 Go 而非 Java）
  • 至今：Temporal 是新一代，Cadence 是旧版（仍在维护但增长停滞）

对比：
– Temporal 22,584 ⭐ / MIT / Go
– Cadence 几千 stars / Apache-2.0 / Java

结论 ： 新项目直接用 Temporal，不要选 Cadence。

六、35 分钟 5 步实战：跑通一个 Order Workflow

Step 1：启动 Temporal Server（10 分钟）

# 用 Docker Compose 启动 Temporal + Postgres + UI
git clone https://github.com/temporalio/temporal.git
cd temporal
docker compose up -d  # 启动 temporal + postgresql + temporal-ui

UI 在 http://localhost:8080，server gRPC 在 7233。

Step 2：装 Python SDK（3 分钟）

pip install temporalio

Step 3：写 Workflow（10 分钟）

# order_workflow.py
from temporalio import workflow, activity
from datetime import timedelta

@activity.defn
async def check_inventory(order_id: str) -> bool:
    # 模拟调用库存 API
    return True

@activity.defn
async def charge_payment(order_id: str) -> str:
    # 模拟调用 Stripe
    return f"payment_{order_id}"

@activity.defn
async def ship_order(order_id: str) -> str:
    # 模拟调用物流 API
    return f"shipped_{order_id}"

@workflow.defn
class OrderWorkflow:
    @workflow.run
    async def run(self, order_id: str):
        # 第 1 步：检查库存
        has_stock = await workflow.execute_activity(
            check_inventory, order_id,
            start_to_close_timeout=timedelta(seconds=30),
        )
        if not has_stock:
            return "out_of_stock"

        # 第 2 步：扣款
        payment_id = await workflow.execute_activity(
            charge_payment, order_id,
            start_to_close_timeout=timedelta(minutes=5),
        )

        # 第 3 步：发货
        shipping_id = await workflow.execute_activity(
            ship_order, order_id,
            start_to_close_timeout=timedelta(hours=2),
        )

        return f"completed: {payment_id} + {shipping_id}"

Step 4：跑 Worker + 启动 Workflow（5 分钟）

# worker.py
import asyncio
from temporalio.client import Client
from temporalio.worker import Worker
from order_workflow import OrderWorkflow, check_inventory, charge_payment, ship_order

async def main():
    client = await Client.connect("localhost:7233")
    worker = Worker(
        client,
        task_queue="order-task-queue",
        workflows=[OrderWorkflow],
        activities=[check_inventory, charge_payment, ship_order],
    )
    await worker.run()

if __name__ == "__main__":
    asyncio.run(main())

# start_workflow.py
import asyncio
from temporalio.client import Client
from order_workflow import OrderWorkflow

async def main():
    client = await Client.connect("localhost:7233")
    result = await client.execute_workflow(
        OrderWorkflow.run,
        "order-123",
        id="order-123-workflow",
        task_queue="order-task-queue",
    )
    print(f"Result: {result}")

asyncio.run(main())

Step 5：故意杀掉 Worker 测自动恢复（7 分钟）

# 跑 worker
python worker.py

# 在另一个 terminal 启动 workflow（10 秒后杀 worker）python start_workflow.py &
sleep 10
kill -9 %1  # 杀掉 worker

# 重启 worker
python worker.py
# Temporal 会自动从断点继续，不会重新跑已完成的步骤！

七、6 条风险清单

⚠️ 风险 1：931 open issues 偏多

22,584 stars + 931 open issues（issue/stars 比 = 4.1%，行业平均 0.5-1%）。社区响应可能滞后，企业生产环境锁定前先观察。

⚠️ 风险 2：自托管复杂

Temporal 自托管需要 server + database + UI + 自定义 worker，至少 4 个组件（比 Airflow 的 5+ 服务略少但仍复杂）。

⚠️ 风险 3：determinism 约束学习曲线

Temporal workflow 代码必须 确定性（不能直接用 random / I/O），所有副作用必须通过 activity。这对很多开发者是反直觉的。

⚠️ 风险 4：生态成熟度不如 Airflow

Airflow 有 70+ providers（Snowflake / BigQuery / dbt / Spark / Kubernetes 等），Temporal 只有 4 个 SDK + 第三方 connector 还在补。

⚠️ 风险 5：商业版 Temporal Cloud 锁定风险

Temporal Technologies 提供 Temporal Cloud（托管服务），部分企业级功能（Multi-region replication / Advanced Observability）可能仅在 Cloud 版可用。

⚠️ 风险 6：worker 重启期间 activity 可能被重复跑

Activity 的 idempotency 需要 用户自己保证（不能完全靠 Temporal 自动防重）。

八、跟已有调研的关系

项目 WP ID 定位 与 Temporal 关系
Apache Airflow 306 DAG-based 批处理调度 范式不同（DAG vs 持久执行）
Dagster 390 Asset-centric 编排 范式类似 Airflow，不是 Temporal
Prefect （待调研） 现代 orchestration 跟 Temporal 类似，可能冲突
Celery 288 Python task queue 不直接冲突，定位更底层
LoopX 403 AI Agent 长程状态控制面 更窄：专攻 AI Agent，Temporal 是通用 workflow
loop-engineering 175 AI Agent 循环方法论 互补：方法论 + 运行时

关键判断：

Temporal 跟 LoopX 是 ” 通用 vs 专用 ” 关系 。LoopX 是 为 AI Agent 设计的状态控制面 （8 host 集成 / 5 CLI / evidence + quota 概念），Temporal 是 通用 workflow 引擎 （5 大语言 SDK / sub-second dispatch / 持久执行）。 如果你的长程任务是 AI Agent，用 LoopX；如果是订单处理 / saga / 订阅，用 Temporal。

九、总结

3 个最值得用 Temporal 的理由

1️⃣ Durable Execution 是 ” 时间机器 ”

Workflow 状态自动持久化，worker 崩溃后从崩溃点继续 ——这不是 Airflow 的 ” 任务重跑 ”（浪费 30 分钟），是 ” 时间旅行 ”（0 浪费）。 对任何长程应用工作流都是质变。

2️⃣ Workflow as Code + 4 大 SDK

写应用代码，不是 DAG 文件 —— 复杂业务逻辑（条件、循环、状态保存）天然适配。Python / Go / TypeScript / .NET 4 大 SDK 都是 MIT ✅ + 2026 年活跃 commit。

3️⃣ 6 年老牌 + 22K stars + sub-second 调度

不是新项目 （2019-10 创建）， 生产环境验证充分。sub-second dispatch + 10,000+ workflow starts/sec 性能远超 Airflow 的分钟级调度。

不适合用 Temporal 的场景

  • ❌ 批处理 ETL / 数据管道 → 用 Airflow
  • ❌ 简单定时任务 → 用 cron
  • ❌ 5 分钟内完成的短任务 → 用任何 worker queue（Celery）
  • ❌ AI Agent 专用长程任务 → 用 LoopX

先试一周

Day 任务
1 Docker Compose 启动 Temporal Server + UI，访问 http://localhost:8080
2-3 跑通官方 hello world（Python SDK）
4-5 写一个 3-step workflow，故意 kill worker 验证自动恢复
6-7 加 Signal/Query，外部触发 workflow 状态变更

一周后如果你觉得 ”workflow 状态不丢 ” 的感觉对了，恭喜你进入了持久执行范式。

参考

  1. temporalio/temporal GitHub —— 主仓 22,584 ⭐ / MIT
  2. Temporal 官方文档 —— 最权威的 workflow 教程
  3. Temporal 官网 —— 商业版 Temporal Cloud 信息
  4. temporalio/sdk-python —— Python SDK 1,169 ⭐
  5. temporalio/sdk-go —— Go SDK 958 ⭐
  6. temporalio/sdk-typescript —— TypeScript SDK 900 ⭐
  7. temporalio/ui —— Temporal Web UI 430 ⭐
  8. Temporal vs Airflow（CodeWords） —— 2026 最详细对比
  9. Temporal vs Airflow（DevJournal） —— 自托管角度
  10. Cadence GitHub —— Temporal 前身 / 已过时
  11. Apache Airflow 调研 (WP 306) —— Temporal 的 ” 互补 ” 对比对象
  12. Dagster 调研 (WP 390) —— 同为编排层
  13. LoopX 调研 (WP 403) —— AI Agent 专用长程控制面
  14. 循环工程 4 件套横评 (WP 428) —— AI Agent 循环层

📎 WordPress 链接

正文完
发表至： 技术
近两天内
 

近期文章

近期评论