Dandelion 提出的新编程模型核心在于“将云原生应用重构为纯计算函数 + 通信函数的 DAG 数据流图”，从而实现极致弹性与资源效率。以下是对该模型的详细解析，以及对现有应用兼容性和改造难度的评估：
✅ 新编程模型思路详解
| 维度 | 传统 FaaS（如 AWS Lambda） | Dandelion 新模型 |
|---|---|---|
| 函数定义 | 包含计算+系统调用+网络通信 | 明确拆分为： - 纯计算函数（无系统调用） - 通信函数（平台提供，如 HTTP） |
| 运行环境 | 需完整 POSIX 沙箱（如 Firecracker MicroVM） | 轻量级隔离（KVM/进程/CHERI/rWasm），无需 Guest OS |
| 冷启动 | 数十毫秒（含快照） | 百微秒级（<100μs） |
| 编程接口 | 开发者可自由使用系统调用 | 纯函数通过文件语义读写输入输出（无 syscall） |
| 数据传递 | 依赖外部存储（如 S3） | 明确声明输入输出，平台自动调度 |
| 并发模型 | 每个函数独立运行，OS 调度 | DAG 显式表达并行性，平台可弹性调度 CPU 核心 |
🧩 应用兼容性评估
| 应用类型 | 兼容性 | 改造难度 | 说明 |
|---|---|---|---|
| 数据处理管道（如ETL、MapReduce） | ✅ 高 | 🟢 低 | 天然符合 DAG 模型，易于拆分 |
| AI 推理链（如 Text2SQL、RAG） | ✅ 高 | 🟢 低至中等 | LLM调用→SQL查询→格式化输出，天然为多个阶段 |
| REST API 服务 | ⚠️ 中 | 🟡 中等 | 需将每个 API endpoint 拆分为 DAG；I/O 密集型部分需转为通信函数 |
| 微服务链（如订单→库存→支付） | ⚠️ 中 | 🟡 中等 | 需将每个服务调用转为通信函数，计算逻辑封装为纯函数 |
| 需要共享内存/线程同步的应用 | ❌ 低 | 🔴 高 | 如在线游戏、数据库内核，不适合 Dandelion 模型 |
| 传统 POSIX 应用（如 NGINX、Redis） | ❌ 低 | 🔴 高 | 需重写为无状态纯函数，或放弃使用 |
🔧 改造难度详解
✅ 低难度（适合优先迁移）
- 无状态函数（如图像压缩、日志解析、数据格式转换）
- 已有 DAG 表达（如 Spark SQL、Beam Pipeline）
- REST 调用为主的链式逻辑（如 AI Agent、RAG）
⚠️ 中等难度
- 有状态服务（如会话管理、缓存）
- 需将状态外置（如 Redis、DynamoDB）
- 异步 I/O 代码（如 Python asyncio、Node.js）
- 需通过“continuation”技术自动拆分（Dandelion 未来计划支持）
❌ 高难度（不建议迁移）
- 多线程共享内存程序（如 TensorFlow 训练、游戏服务器）
- 系统级服务（如文件系统、网络代理）
🧪 实际案例：Text2SQL 改造示例
| 原始流程 | Dandelion DAG 表达 |
|---|---|
| 用户输入 → LLM 推理 → SQL 查询 → 格式化结果 | 4 个节点： 1. 输入解析（纯函数） 2. LLM 调用（通信函数） 3. SQL 执行（通信函数） 4. 输出格式化（纯函数） |
改造工作量：一位无经验的学生在几小时内完成 [论文 7.7]
详见应用改造对比：Web 服务（REST API） vs AI Agent（Text2SQL 场景）
🔮 未来兼容性增强方向
Dandelion 团队计划支持：
- 自动分解工具：通过编译器将现有 async 代码自动拆分为 continuation 图（受 VectorVisor 启发）
- 支持更多语言：LLVM 前端（Rust、Go）、rWasm（JS、Python、C#）
- 混合模式：允许部分函数保留传统行为（Dandelion-hybrid 原型已验证）
✅ 总结建议
一句话总结：Dandelion 的编程模型适合“云原生、无状态、数据驱动”的现代应用，对传统有状态服务兼容性有限，但可通过架构重构逐步适配。
| 建议 | 场景 |
|---|---|
| 立即迁移 | 无状态、数据并行、AI 推理链 |
| 试点改造 | REST API、日志处理、ETL |
| 观望评估 | 有状态服务、异步系统 |
| 不建议迁移 | 共享内存、系统级服务、训练任务 |
评论