admin
ce8e6ceed9
回收 411 MB（470 M → 58.8 M），全部经回收站，可恢复： - 待清理/（146.2 M，含 relay 分片 128 M 与 42 项过程目录） - tmp/（32.4 M，按接续棒命名的过程临时区） - .workbuddy/tmp/（39.5 M） - 4 份 workbuddy.db 冗余副本（101 M，09-23 事故的坏副本 / 抢救产物） - tmp/im16/gw/centrifugo 二进制（63.9 M，可重下）+ 缓存残留 入库范围：常驻规则（CODEBUDDY.md / README.md / state.py）、在途接续入口与 接续包、docs/、交付物/、交接单/、归档/、scripts/、.codebuddy/、 .workbuddy/memory/；共 398 件，其中 >60 KB 的 26 件全为文档。 排除（.gitignore）：tmp/、待清理/、运行态日志与缓存、*.db 与 DB 备份整目录、 打包二进制（*.tar.gz / *.tgz）、记忆修复前备份。
9.0 KiB
覆盖网络 · 「插件 vs 改内核」架构判断（2026-09-16）
性质：只读架构评估。⛔ 未改任何代码、未动服务器。 取证范围：
D:\github\dsh_shenxian工作树（HEAD4e3a1a4）——src/supervisor/spawner.ts（全读）·src/worker/agent.ts（头部 62 行 + 接口）·src/结构清点 · 会合中继拆分方案 C1–C4。 一句话判定：主力形态既不是"dsh 插件"也不是"把东西塞进平台主进程"，而是"平台内模块化 + 独立进程/单元" —— 因为要解决的问题（跨机可达、节点身份、寻址）发生在实例之外，dsh 插件机制在架构上够不到；而平台已有独立组件的先例（Manager / Worker 分体），顺着走即可。
一、先拆概念：「插件」在这个项目里有两个完全不同的含义
| (a) dsh 官方插件（profile 层业务插件） | (b) 平台自身的模块化 | |
|---|---|---|
| 跑在哪 | 用户实例内部（dsh 进程内） | 平台进程 / 独立进程 |
| 能做什么 | 加 UI 卡片与分区、注册工具、改实例内行为 | 任何事 |
| 够得到 Worker↔Manager 隧道？ | ❌ 架构上够不到（实例是隔离的运行体，看不见宿主网络栈） | ✅ |
| 发版与回滚 | 独立（候选池 → 用户自助启停） | 跟平台版本走 |
| 现有先例 | @dsh-local/portal-entry、business-plugins |
Manager / Worker 分体、dshs-worker.service |
⇒ 概念澄清（很重要）：覆盖网络根本不涉及 @deepseek-ai/dsh 主程序 ⇒ 红线 R2 不构成约束，这套东西整个发生在平台侧。所以"插件 vs 改代码"的真正对象是平台自己的代码仓，不是 dsh。
二、三层归属：哪块该放哪
| 层 | 内容 | 建议形态 | 理由 |
|---|---|---|---|
| 数据面组件 | 会合（rendezvous）· 中继（relay）· 发布层（对外服务暴露） | 独立进程 / 独立 systemd 单元（可多实例、可换机） | ① 跨机、要碰宿主网络栈 ② 需独立扩缩容与独立安全加固（发布层要挡 DDoS）③ 塞进主进程 = 与平台同生共死，违反"控制面/数据面分离" |
| 平台侧集成 | 寻址（via）· 节点身份与凭据 · 骨干资格签发 · 容量准入 |
改平台代码 | 必须与归属 / 租约同源（单点写），外置就是第二个权威源 = 脑裂 |
| 实例内展示与工具 | 「我的网络 / 我的设备」面板 · agent 的文件互传工具 · 网络状态 | dsh 插件（唯一真正适合插件的地方） | 纯实例内 UI 与工具，正是插件机制的用途 |
三、三种形态的优劣
A · dsh 插件形态（把覆盖网络做成插件）
优点：不动平台内核；可独立发版；用户可自助启停；回滚粒度细（禁用即可）。
缺点：能力边界是硬的 —— 插件跑在实例内部，看不见宿主网络栈、够不到 Worker↔Manager 隧道、无法参与控制面归属与租约；覆盖网络的核心问题（跨机可达 / 节点身份 / 寻址）一个都解决不了；且插件加载失败会把实例拖进崩溃循环（已有探活回滚机制，但仍是额外风险面）。
⇒ 判定：只能覆盖第三层（实例内展示与工具），不能承担主力。
B · 改内核形态（把会合/中继塞进平台主进程）
优点：改动集中；复用现有配置与日志；部署单元不增加；短期最快。
缺点：与平台同生共死（中继挂了平台一起受影响）；中继要独立扩缩容时做不到；对外暴露面与内核同进程（发布层因此无法做独立安全加固）；端口空间与 Manager 全局共享（就是现状的 C2 耦合）；版本矩阵无法独立演进。
⇒ 判定：现状就是这个形态，也正是要拆掉的那个问题。
C · 独立组件 + 平台内模块化（推荐主力）
优点：① 顺着现有架构走 —— 平台已有 Manager / Worker 分体与独立 systemd 单元的先例，不是新造范式；② 控制面/数据面天然分离，符合既有分层判据；③ 可独立换机、多实例、独立加固（发布层单独处理 DDoS）；④ 每一步可独立回滚（S0–S4 已定）。
缺点：多一个部署单元与版本矩阵；本机开发环境要能跑起来（本机是 Windows，需容器或远程）；会引入"组件间契约"这条新的维护面。
四、现有项目代码评估：设计基本合理，且为这个方向留了缝
4.1 合理之处（有代码证据）
| # | 事实 | 为什么关键 |
|---|---|---|
| 1 | Spawner 是干净的后端抽象缝（launch / stop / status / endpointFor / restartAndProbe，src/supervisor/spawner.ts:94-149） |
新增一种节点 = 多一个实现，不是改内核；route 层只依赖接口 |
| 2 | Worker agent 有四条协议纪律（单向拨入 / 幂等键 operationId / 最小接口白名单 / self-fencing，src/worker/agent.ts:10-17） |
这就是现成的"节点契约"—— 客户端节点可直接复用同一套语义 |
| 3 | 归属 / 租约只有 Manager 能写（epoch+1 fencing） |
与"客户端不可信"天然相容 ⇒ 客户端天生只能当数据面，不会有脑裂 |
| 4 | tunnelTarget === '' ⇒ 完全不建隧道（agent.ts:154） |
扩展点是预留的：同机形态零影响，跨机才启用 |
| 5 | 全仓仅 1 处 process.platform 分支（supervisor/firewall.ts:42） |
跨平台改造成本低 |
| 6 | instanceHost 已是参数（注释："跨机时填内网 IP"） |
寻址已经是参数化的，不是写死 |
4.2 不足（4 处，均为已知或有据的具体欠账）
| # | 不足 | 证据 | 影响 |
|---|---|---|---|
| 1 | 寻址只有 {host, port}，表达不了"经谁到达" |
Endpoint = {host, port}（spawner.ts:80-83）；hostsProvider 把 dsh_hosts.endpoint 直接当 agentUrl |
换中继时表里无处表达 ⇒ 必须加 via 字段（越晚改越贵） |
| 2 | 共享 bearer token，无法按节点吊销 | agent.ts:40 注释自陈："本版是 bearer 式比较，HMAC/防重放留待后续" |
公网上不成立；这是项目自己记录的已知欠账，正好是覆盖网络要补的 |
| 3 | 中继与 Manager 同生共死 | 隧道落在 Manager 的 sshd（32022），端口空间与 Manager 全局共享 |
中继不可多实例、不可换机、单点 |
| 4 | 控制面 PG 复用同一条隧道 | DSHS_TUNNEL_STATIC_PORTS，设计上含控制面 PG |
换中继时 DB 连接一起断 ⇒ 回滚面比看上去大 |
4.3 总评
合理程度：中上。 它是"为多节点预留了缝"的设计 —— 抽象缝（Spawner）、协议纪律、参数化寻址、开关式隧道，这四样都在。 但也正因为缝开对了，改造的成本主要在"补两个字段 + 分两步换绑定"，而不是重构内核。 唯一的严肃欠账是身份（共享 token），而项目自己已经在注释里写明了这是待办 —— 说明设计者是清醒的，不是漏掉。
五、能否支持这个方向的改造：能，且不需要重构
| 需要的改造 | 现有设计支持度 | 落点 |
|---|---|---|
| 新增一种节点类型（客户端/骨干） | ✅ 直接支持 —— 加一个 Spawner 实现 + 复用 agent 四纪律 |
新文件，不动内核 |
寻址加 via |
⚠️ 需加字段（向后兼容：有默认值，旧代码不受影响） | S2（方案已出） |
| 会合地址出 env | ✅ 易（tunnelTarget 已是配置；再加一个优先项即可） |
S1 |
| 中继独立成单元 | ✅ 易 —— 已定"不换协议、只换绑定关系" | S4 |
| 节点身份（一机一钥） | ⚠️ 要新写，但接口位置清楚（token 校验点集中） | 拆分方案之后 |
| 发布层 | 🆕 全新，与平台主进程分开 = 天然适合独立单元 | 新组件 |
⇒ 结论：改造路径与现有架构不冲突**，是"顺着缝往下切"，不是"推倒重来"。**会合中继拆分方案 S0–S4 已经把顺序定好了（S0 纯新增文件 + 可选字段，零行为变化）。
六、我选了什么（可推翻）
- 主力形态 = 独立组件 + 平台内模块化，不是 dsh 插件、也不是塞进主进程。
- dsh 插件只承担第三层（实例内的"我的网络/我的设备"面板与文件互传工具）—— 这是唯一适合插件的部分。
- 先"平台内模块化 + 独立 systemd 单元"，暂不拆独立仓库 —— 现在只有两台机器，独立仓库会带来版本矩阵与同步成本；而 S0 的接口抽象已经让"以后再拆"变得便宜。
- 身份（一机一钥）放在拆分之后，但它必须排在任何公网暴露之前。
七、本次未做
- ⛔ 未改任何代码、未动服务器、未写文档库（全局执行锁被
修复轮-决策方法-2b占用）。 - 📌 未新增上抛项 —— 待拍板仍是：骨干服务范围（A 自用 / B 全网）+ 发布层形态与成本。