01-长链路任务抽象模型

Web web long-task

发布时间 : 2026-01-29 13:27

字数:893 阅读 :

长链路抽象模型
服务流程
1. 标准请求流程设计
2. web-queue-worker 流程设计
行业解决方案

长链路任务模型的核心在于解耦：

通过消息队列将任务提交者与执行者分离，通过状态机明确任务生命周期，通过状态存储和异步通知反馈进度和结果。Web‑Queue‑Worker 架构提供了一种简洁而有效的实现方式，使系统能够处理耗时任务而不阻塞用户请求，并支持扩展、幂等和容错。结合异步 HTTP 模式，可为客户端提供清晰的接口协议与状态反馈机制。遵循这些设计原则和实践建议，可以帮助开发者构建稳定、可伸缩的后台任务系统。

长链路抽象模型

痛点:

我在接触的很多AI相关应用的时候，发现AI调用过程是十分耗时,并且每次任务的执行是非常耗费资源。

比如:

用户上传一份扫描合同，要OCR解析，图片语义解析，Embedding、结构化提取，入库

每一个步骤都十分耗时，而且有很大的概率出现问题，十分耗时，且消耗资源

如果采用同步的方案，客户体验直接差到爆

所以得采用异步消息队列的方案

长链路任务不是函数调用，而是一个有生命周期的系统对象

任务 = 生命周期状态机

任务不是函数，是对象！

是存在一系列状态的对象

简易版本

stateDiagram-v2
    [*] --> PENDING
    PENDING --> RUNNING
    RUNNING --> SUCCEEDED
    RUNNING --> FAILED
    RUNNING --> CANCELED

复杂版本

stateDiagram-v2
    [*] --> CREATED : create task

    CREATED --> QUEUED : publish to broker

    QUEUED --> DELIVERED : worker consume

    DELIVERED --> RUNNING : start execution

    RUNNING --> SUCCESS : finished ok
    SUCCESS --> [*] : ack & done

    RUNNING --> FAILED : exception / timeout / crash

    FAILED --> RETRYING : retry policy

    RETRYING --> QUEUED : re-enqueue

    FAILED --> DEAD : exceed max retries

状态迁移
持久化

执行 ≠ 触发

这是传统的WEB思维:

API 调用 = 执行任务

纠正:

API 只创建任务

Worker 才执行任务

生产者消费者模型

长链路任务的 task system 是一个生产者消费者的模型

flowchart LR
    P[Producer API] --> Q[Task Queue]
    Q --> C1[Worker 1]
    Q --> C2[Worker 2]
    C1 --> DB[Task Store]
    C2 --> DB

过程必须可观测

任务系统必须：

有进度
有事件
有日志轨迹

服务流程

标准请求流程设计

这是一个标准的请求流程

sequenceDiagram

    autonumber
    participant C as 客户端
    participant API as API/任务管理
    participant Q as 队列
    participant W as Worker
    participant DB as 状态存储

    C->>API: POST /tasks (提交任务)
    API-->>C: 202 Accepted\nLocation: /tasks/{id}
    API->>Q: 发布任务 id
    Note over Q: 消息队列缓冲任务
    W->>Q: 拉取任务 id
    W->>DB: 更新状态(RUNNING)
    loop 轮询
        C->>API: GET /tasks/{id}
        API-->>C: 当前状态、进度
    end
    W->>DB: 写入结果并标记完成
    C->>API: GET /tasks/{id}
    API-->>C: 返回结果

web-queue-worker 流程设计

Web‑Queue‑Worker

sequenceDiagram
    participant Client as 客户端
    participant API as 接口服务
    participant Backend as 后端/Worker
    Client->>API: POST /tasks (提交任务)
    API-->>Client: HTTP 202 Accepted + Location: /status/{id}
    API->>Backend: 将任务推送至消息队列
    loop 客户端轮询
        Client->>API: GET /status/{id}
        alt 任务进行中
            API-->>Client: 200 OK (in progress)
        else 任务完成
            API-->>Client: 302 Found /result/{id}
        end
    end
    Client->>API: GET /result/{id}
    API-->>Client: 200 OK + 任务结果

行业解决方案

抽象概念	实际技术
Queue	Redis / RabbitMQ / Kafka
Worker	后台进程 / 容器 / Serverless
State Store	MySQL / Redis
Result Store	数据库 / 对象存储