DevFlow 云化架构方案

拍板日期 2026-10-21 · 阶段1 已在飞书实机闭环验证 · 状态源：任务 711e1390 / 6e13f49b

一、核心决策（已拍板）

决策1中继不新建：复用生产 u-relay（:9180，纯中继零改动），df-im-gateway 以 WS Commander 身份接入
决策2df-im-gateway 走方案 A：先落在 devflow workspace 当第 9 个 crate，四端全通后再拆独立仓（避免模块 vs 实际代码脱节坑）
决策3云端零业务逻辑零落盘：任务/AI对话/审批状态全留桌面端 SQLite；AI Provider key 不上云，本机直连
决策4语言对齐 Rust：复用 df-tunnel 类型与 systemd 原子切换发布模式（publish-u-relay 同款）

二、部署拓扑总览

  用户四端                ┌─────────────────── 云端（已有云主机复用，不新购）──────────────────┐
  ┌────────┐             │                                                                 │
  │ 飞书   │──WS 长连接──┼──▶ ┌─────────────────────────────┐                              │
  │ 钉钉   │─Stream Mode─┼──▶ │ df-im-gateway (Rust, 新增)   │                              │
  │ 企微   │──WS 长连接──┼──▶ │ · 四端协议适配(验签/AES/卡片)  │                              │
  │ Web    │─HTTPS/WSS───┼──▶ │ · WS Commander 身份          │                              │
  └────────┘             │    │ · 审批转发                    │                              │
                         │    └────────────┬────────────────┘                              │
                         │                 │ df-tunnel 协议                                │
  u-relay :9180  ◀──────┼─────────────────┘  (纯中继：WS 长连接管理/路由/Commander 注册表)   │
                         │                                                                 │
                         │    Nginx :443 (TLS 终结 + 反代, 后续挂 df-cloud-server 用)         │
                         │                                                                 │
                         └────────┬──────────────────────────────┬──────────────────────────┘
                                  │ 出站 WS（穿透 NAT）             │ 出站 WS
                                  ▼                              ▼
                   ┌── 用户本机 ─────────────────────────────────────────────────┐
                   │  DevFlow 桌面端 (Tauri 2, 唯一执行引擎 + 状态源)              │
                   │  · AI Provider 直连 (GLM/DeepSeek, key 本机)                 │
                   │  · SQLite (任务/对话/审批 全量状态)                           │
                   │  · 8-crate workspace (+未来第9 crate df-im-gateway)          │
                   └─────────────────────────────────────────────────────────────┘

三、数据流

方向	路径	用途
下行指令	IM/Web → df-im-gateway → u-relay → 桌面端	发消息 / 审批 / 停止
上行事件	桌面端 → u-relay → df-im-gateway → 各端	流式回复 / 状态广播

⚠ 桌面端全程主动出站，不开任何入站端口——NAT 友好，家里/公司网络都能用；云端被攻破也拿不到业务数据（无状态管道）。

四、阶段路线

阶段1 · IM 远程接入进行中·飞书实机

飞书单端 E2E 闭环（握手→事件→卡片流式→审批回调→流式回复）——代码已全落地，实机验证中
df-im-gateway 作为 workspace 第 9 crate 承载
钉钉/企微/Web = 后续扩展，不阻塞
唯一动 u-relay 的点：Commander 身份注册（配置级）

阶段2 · devflow-core 抽取设计启动

UI 无关 crate 界定为 devflow-core（工作流引擎/任务管理/存储层）
存储 trait 双实现：SQLite（本地）/ PostgreSQL（云端）
AI Provider 双模式：key 本机直连（个人版）/ 云端集中托管（团队版）
同主机 Nginx 后追加 df-cloud-server，管道层不动

阶段3 · 完整云端化预留

云端接管全部业务逻辑，桌面端降级薄客户端
多用户 / 多设备 / 团队协作（任务池/审批/知识库共享）
可选本地引擎保离线能力

五、组件清单与状态

组件	形态	部署位置	状态
u-relay :9180	Rust 二进制（已有）	云端主机，systemd 原子切换	✅ 复用零改动
df-im-gateway	Rust crate（新增，方案A先驻 workspace）	联调期本机 → 常驻期云端主机	✅ 飞书端已通，实机验证
Nginx :443	TLS 终结 + 反代（已有）	云端主机	✅ 复用
DevFlow 桌面端	Tauri 2 应用	用户本机	✅ 唯一状态源
df-cloud-server	Rust 服务（规划）	云端主机，Nginx 后	阶段2 拍板后立项

六、风险与关键点

风险1飞书卡片版本：审批按钮回调仅新版卡片 card.action.trigger 生效，旧版 card 帧被 SDK 直接丢弃——联调最大坑（已知已沉淀）
风险2假活自愈：断流约 13 分钟由看门狗 notify_waiters 唤醒（45f0560f），云端常驻部署后需关注长连接巡检参数
注意1双库分歧：devflow.db vs devflow-dev.db 是刻意设计（cfg! 分支），云化时存储层抽象需保留该模式
注意2钉钉/企微降级：P3/P4 保持 todo，不阻塞阶段1 验收与阶段2 并行

DevFlow 云化架构 · 生成于 2026-10-21 · 依据知识库拍板记录 978a3cf0 · 相关任务 6e13f49b / 711e1390