本帖最后由 云栈大前端 于 2026-1-14 18:11 编辑
在上一篇文章中提到，这个周末我将视频生成真正做成了一条可复用的流程。但很快我就发现一件事：如果流程足够稳定，它就不该只是“我自己用的脚本”。
于是，我索性往前多走了一步——用 Rust 把这条流程，直接做成了一个视频生成平台。
为什么不是“工具”，而是“平台”
起初，我的目的仅仅是提高个人的工作效率。但在不断拆解流程的过程中，我发现视频生成本质上具备以下几个显著特征：
- 多步骤、强依赖顺序：流程环环相扣，前一步的输出是后一步的输入。
- 容错需求高：每一步都可能失败，必须具备重试机制。
- 性能敏感：对计算资源和稳定性的要求极高。
- 管道化特性：非常适合“任务化 / 管道化”处理。
这已经不是一个简单的“调用 API 的脚本”能解决的问题了，而是一个典型的 后端 任务系统。既然如此，与其堆砌各种零散的工具，不如直接按照平台化的思路来设计。
为什么选择 Rust
选择 Rust 并非出于情怀，而是基于非常现实的工程考量。
1. 视频生成是“重 IO + 重 CPU”的混合场景
视频生成的流程极其复杂，涉及不同类型的资源消耗：
- IO 密集型：文案生成、TTS（语音合成）、素材拉取等步骤主要依赖网络 IO。
- CPU 密集型：视频合成、渲染、转码等步骤则大量消耗 CPU 资源。
Rust + Tokio 的组合非常适合这种混合场景，它具备以下优势：
- 高并发：能够轻松处理大量并发任务。
- 低开销：运行时资源占用极低。
- 强资源控制：开发者可以精确控制系统资源的使用。
2. 我需要一个“不会越跑越慢”的系统
视频生成任务通常具有以下特点：
- 批量化：往往需要同时处理多个视频。
- 长时运行：单个任务耗时较长。
- 易堆积：后期任务容易在队列中积压。
Rust 的核心优势在于内存可控。它不容易出现“跑了一晚上服务就崩溃”的情况，非常适合构建长期稳定运行的服务。
3. 平台一定会“越写越复杂”
一旦系统演变为平台，复杂度就会指数级上升，我们需要处理：
- 任务状态管理
- 失败自动重试
- 限流、队列与并发控制
- 不同生成策略的扩展
在这种情况下，Rust 的类型系统反而成为了加分项：它迫使我们将复杂度提前暴露在编译期，而不是等到线上运行时才爆炸。
整体架构设计
从一开始，我就没把它当成一个简单的“视频工具”，而是将其定义为一个任务编排系统。整体架构可以拆解为以下 4 层：
API 层：只负责“接需求”
这一层做得极薄，不包含任何业务逻辑，主要负责：
任务编排层（核心）
这是整个平台的中枢神经，负责：
- 拆解一个完整的视频生成任务
- 将任务细分为多个步骤（Step）
- 控制步骤间的依赖关系
- 管理状态流转（Pending / Running / Failed / Done）
本质上，这是一个 DAG（有向无环图） + 状态机 的组合。
执行层：每一步都是插件
所有的具体操作都被抽象为插件，例如：
每一步都抽象成了统一的接口规范：
- 输入是什么？
- 输出是什么？
- 是否可重试？
- 是否可并行？
这种设计使得后续无论是更换模型、调整生成策略，还是增加新能力，都不需要改动核心流程。
资源与限流层
这是很多人在初期容易忽视，但非常关键的一层。它负责：
- 控制并发数
- 控制 CPU / IO 的使用率
- 控制第三方 API 的调用速率
- 防止一波突发任务把服务器打死
对于这一层，我基本采取“先设计，再实现”的策略，而不是等到出问题了再事后补救。
平台化带来的变化
将脚本升级为平台后，带来了几个非常明显的变化：
✅ 从“写一次”到“反复跑”
- 同一套流程可以适配不同的内容输入。
- 不再需要为单个视频编写定制化的逻辑代码。
✅ 从“人驱动”到“任务驱动”
- 不需要人工实时盯着运行过程。
- 出错有明确的状态记录、日志追踪以及自动重试机制。
✅ 从“玩具”到“可扩展系统”
- 可以对接 Web 前端。
- 可以开放给他人使用。
- 可以在不推翻重来的前提下，持续增加新能力。
一些真实感受
这次实践让我最有成就感的，不是“生成了多少视频”，而是：
我终于把一件创作型的事情，用工程手段彻底驯服了。
AI 负责处理不确定性，Rust 负责保障确定性，而我，只需要决定“值不值得做”。这大概是我目前最喜欢的工作状态。
如果你也对构建高性能的后端系统感兴趣，欢迎访问 云栈社区 进行更多技术交流。 | 
发表于 2 小时前
|
查看: 3|
回复: 0
