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）、记忆修复前备份。
7.6 KiB
7.6 KiB
覆盖网络方案答疑：群聊与 Agent 参与 · 备份 · 迁移速度 · 传输保密
日期：2026-09-16 ｜ 性质：技术答疑（承接
覆盖网络_全球架构复盘_20260916.md） 🟢 范围：只考虑技术实现；跨境数据合规由使用者自行考虑。
一、群聊 + 「用户配置的 agent 也在群里互动」——✅ 可以实现
关键判断：群聊不是覆盖网络的机制，它是应用层的事。覆盖网络只解决"参与者散在各种网络里也能互相到达"——而这恰好是群聊最麻烦的那一半。所以两者是互补，不是一回事。
1.1 三种分发拓扑（必须选一种，推荐第三种）
| 拓扑 | 优点 | 缺点 |
|---|---|---|
| 中心房间（消息过服务端） | 简单、天然全序、易持久化 | 中心带宽与单点；隐私面大 |
| 网状（成员间直连分发） | 省中心 | N²、顺序与送达确认难做 |
| 混合（推荐） | 小群网状 / 大群走区域汇聚节点；离线补拉 | 实现复杂度最高，但可控 |
1.2 覆盖网络给不了的，必须在应用层补
覆盖网络只提供"可达"，不提供"有序、去重、不丢"。所以群聊必须自己带：
- 消息 ID（内容寻址/哈希）⇒ 去重
- 因果/逻辑时钟 ⇒ 排序（无需全局时钟）
- 送达确认 + 离线补拉（拉取式，不是推送式）
- 房间级权限：加入房间才可见 —— 与"接入 ≠ 可见"一致
1.3 Agent 作为群成员的四个要点
- 身份：agent 是一个独立的对等成员（有自己的密钥与地址），但身份绑定其主人、权限可单独授（可只读、可仅在被 @ 时发言）。
- 运行位置决定数据面：跑在用户自己机器上 ⇒ 消息不出去；跑在服务器 ⇒ 平台要路由给它。
- ⚠️ 最大的坑 = agent 互相激发造成无限循环（A 说 → B 回 → A 再说）。必须内建四条硬约束：
- 禁止 agent 直接触发 agent —— 只有人的消息能触发 agent 发言（切断自激环）；
- 每轮发言预算（每个 agent 每 N 分钟最多 M 条）；
- 静默期（发言后冷却）；
- 房间级全局速率上限 + 排队（多 agent 同时发言时按序，不刷屏）。
- 风暴防护：群聊是典型"推送放大点"（1 条消息 × N 成员）⇒ 大群禁止"每人每条广播给全体"，改"摘要比对 + 按需拉取"。
二、服务器用户数据备份 —— 主备份优先对象存储，覆盖网络只当搬运通道与第三副本
用户问「优先还是云存储方案」。答案是分层组合，不是二选一；但从"备份的本质指标"看，主备份应当优先对象存储。
2.1 三层组合（推荐）
| 层 | 落点 | 作用 | 为什么 |
|---|---|---|---|
| 快速恢复层 | 本地盘 | 最近 N 份，恢复最快 | RTO 最短、零流量 |
| 主备份层 | 对象存储（自建 MinIO 或云 OSS/COS） | 长期、异地、不可变 | 备份的核心是可恢复性 + 不可变，对象存储天然给 SLA、版本化、生命周期 |
| 第三副本 / 通道 | 覆盖网络内的自有节点 | 异地冗余 + 搬运 | 零月费、跨地域；但没有 SLA |
2.2 为什么"覆盖网络不适合当主备份"
P2P/网内副本的根本弱点：对端是否在线不由你控制，没有 SLA、没有不可变、容易被误删或版本混乱。它适合"搬运"，不适合"存档"。
2.3 工程要点（决定成本与可用性）
- 只备不可再生数据：已有实测口径 —— 不可再生 46.3 MB、可重建 2.9 GiB ⇒ 只备前者 + 附一份重建清单，体积降一个数量级。
- 增量 + 内容寻址去重（同一份只存一次）。
- 上传前先加密（服务端/对象存储不持有明文）。
- 校验和 + 版本化 + 防误删（对象存储的 lifecycle / 不可变桶）。
- 恢复演练自动化（现有平台已有恢复演练先例，保持）。
- ⚠️ 别用那条慢链路当备份通道：跨云实测 22 KB/s —— 备份上传应走各自到公网/对象存储的路径，而不是两地直连。
三、迁移服务器速度优化
现状痛点：47→106 直连实测 ~22 KB/s（46.3 MB 需 ~35 分钟）。
按收益排序的手段：
| 序 | 手段 | 收益 |
|---|---|---|
| 1 | 不搬可重建的（只搬 46.3 MB，而非 2.9 GiB） | ~64× —— 已在做，最大的那一招 |
| 2 | 分片并行 + 多流 | 单流受 BDP（带宽时延积）限制；多流才能吃满链路 —— 实测脚本已在用分片 |
| 3 | 先压缩再传 | 文本/JSON 常见 10:1 |
| 4 | 增量 / 块级 diff（rsync 式或内容寻址） | 只传变化块 |
| 5 | 多路径并行（直连 + 中继同时传） | 覆盖网络带来的新能力；⚠️ 需给中继留额度，别打满 |
| 6 | 惰性迁移（内容寻址 + 按需拉取） | 把"前置全量"变成"用哪个拉哪个" —— 体验上最优 |
| 7 | 经公网对象存储中转 | 两地直连慢时，各自到云的带宽往往更快 |
断点续传是前提（不追求一次传完；分块落盘、可续）。验收：以实测吞吐为准，目标把 22 KB/s 提到链路可支持的量级。
四、如何确保用户信息在覆盖网络传输中的保密性
4.1 三层加密（缺一层都不算保密）
| 层 | 机制 | 防谁 |
|---|---|---|
| 隧道层 | WireGuard / Noise 端到端加密；中继只转发密文、不解密 | 中间网络、中继运营者 |
| 应用层（E2EE） | 消息在应用层再加一层；密钥只在成员间分发 | 连自己的控制面/中继也读不到内容 |
| 静态层 | 磁盘与备份加密（上云前先加密） | 存储侧泄露 |
4.2 身份与密钥（当前最大的缺口）
- 一机一钥替换共享令牌（现状是共享 bearer，无法吊销单台）。
- 密钥轮换与吊销（会话密钥定期 rekey —— WireGuard 已有基础）。
- 群聊的群密钥轮换：成员变更即轮换 ⇒ 前向保密。
- 必须校验控制面签名：否则可以下发假的网络地图（假身份）⇒ 中间人。
4.3 元数据保护（最容易忽略的一层）
隧道只保护内容，控制面与中继仍能看到谁连谁、何时、流量多大。要减少暴露：
- 最小网络地图：只下发"你确实需要连接的"对端，不下发全网名单。
- 不透明 ID：中继侧不用真实用户名/主机名。
- 隐私模式：直连会向对方暴露自己的真实 IP（P2P 的固有代价）⇒ 需要隐私的流量强制走中继，不暴露 IP。
4.4 一句话判据
"中继只能看到密文与元数据，控制面只能看到密文与身份" —— 任何一条不满足即视为不合格。
五、与现有平台的关系（这三件哪些是现成的）
| 需求 | 现成度 | 说明 |
|---|---|---|
| 群聊 | ❌ 需要新建 | 平台现在是"每用户一个实例 + 会话"，没有"房间"抽象 ⇒ 这是新增能力，不是开关 |
| Agent 入群 | ⚠️ 部分 | agent 能力有，但"作为群成员"需新增成员类型 + 发言预算机制 |
| 备份 | ✅ 基础已有 | backup.sh + cron + /opt/dsh/backups/ + 恢复演练；需补"对象存储 + 只备不可再生" |
| 迁移提速 | ⚠️ 部分 | 分片已在用；缺多流并行、惰性迁移 |
| 传输保密 | ⚠️ 缺口在身份 | 隧道加密已有；共享令牌 ⇒ 一机一钥是硬前置；E2EE 需新增 |