dsh_ai1net_server/交付物/五种角色选择场景-明确件-20260926.md

五种角色选择场景 · 明确件（2026-09-26）

用户口径（原文，5 条 ＋ 1 条）：

1. 用户在服务器 dsh 主体上安装插件 → 选择成为节点 → manager，成为管理节点
2. 用户在服务器 dsh 主体上安装插件 → 选择成为节点 → worker，选择对应 manager 成为对应工作节点
3. 用户在客户端 dsh 主体安装插件 → 选择成为节点 → manager，有 IP 和域名成为管理节点
4. 用户在客户端 dsh 主体安装插件 → 选择成为客户端，可以选择 manager 进行接入
5. 用户在服务器 dsh 主体上安装插件 → 选择成为节点 → manager，可以关联 manager 形成多个 manager 网络（其中一个可以升级为根服务）
6. 数据库建立在 manager 节点上（后续多个 manager 互联可以考虑主从库机制）

🔴 本议题的唯一权威 = 定稿 dsh-server-docs/02-架构设计/覆盖网络-顶层架构全貌.md（定稿 2026-09-21，263 行） —— 其自述：「本文与过程档案冲突时，以本文为准」。 本文只做一件事：把你的 6 条对到定稿的哪一条，⛔ 不重述定稿正文、⛔ 不改定稿。

---

0 两处更正（一处是我的错，一处是你的第 6 点与定稿冲突）

0.1 更正一：我此前说「当 Manager 不能自选」—— 作用域搞错了

我之前说	更正
「当 Manager」不能由用户自选	🔴 只对「去当现有平台的 Manager」成立；对「在自己机器上起一个新的 Manager」不成立。

准确判据：「判决者唯一」的作用域 = 「一个区之内」，不是「整个形态」。 定稿的形态就是多区自治、彼此联邦 ⇒ 每区各一个 Manager（判决者），互不冲突。 ⇒ 「选择成为 Manager」形态成立；但性质是「建一个区」，⛔ 不是「插件里的一个角色开关」。

0.2 更正二（我上一稿的错）：定稿存在，且早就回答了大半

我上一稿写的	事实
「定稿件在文档库 架构设计/ 目录不存在」	🔴 错 —— 它存在：dsh-server-docs/**02-架构设计**/覆盖网络-顶层架构全貌.md。我只找了不带序号的 架构设计/，漏了带序号前缀的目录
「跨区可见性默认未自决（现状倾向互不可见）」	🔴 错 —— 定稿 §8.3：✅ 已定（用户 2026-09-24 拍板）＝可见性跟随「用户 × 区」成员关系；原文"倾向默认互不可见"已作废

定稿里已经有的（我上一稿漏掉的）：

• 一句话形状：「签发是中心化的，校验是分布式的，数据是网状的」。
• §二 两张图分离：分水岭 = 根在不在数据路径上（信任图里根在，数据图里 ❌ 无根 ❌ 无中心）。
• §三 三层权威 ＋ 判据三句：「跟着用户走」的数据 ⇒ 留锚定区、⛔ 不跨区同步｜「全局唯一」的标识 ⇒ 只在根｜「区域内唯一」（归属/租约/资格）⇒ 只在区 Manager，根 ⛔ 不镜像。
• §三「明确不做」（写下防后人当 bug 修）：⛔ 用户数据跨区同步 · ⛔ 区域 PG 互联或双向复制 · ⛔ 根当区域代理 · ⛔ 区域自取区名。
• §4.1 多个根 —— 已支持（受信根是一个列表，any-of-N）。
• §4.2 Manager 可升级为根 —— 成立（根与签名者密钥同形；角色由「公钥进哪个清单」决定；升级只改授权关系、不换密钥，且可降级）。
• §4.4 代价：任一根沦陷 = 全网沦陷；升格当前不可逆（撤根无机制）⇒ 在此之前升格只能人工、离线、低频。
• §五.2 跨区访问 = 数据不动，只有请求动（路由到锚定区，home 不迁移）。
• §六 缺口 G1–G7 ＋ §七 推进顺序 F1–F8：🔴 F1.5（签名清单序号，治 G1＋G6）是一切的前置。

⇒ 下面 §1 的判定，等于把你的 5 条场景对到定稿的 §5.3「四条入口路径」上。

---

1 五场景逐个明确（对着定稿）

#	你的场景	定稿里对应哪一条	判定	今天缺什么
1	服务器 → Manager	§5.3 路径 A「新服务器首启 ⇒ 建本区或加入他区」	⚠️ 形态成立，入口缺失	定稿原话：A「今天只有 CLI，无 Web 通路」
2	服务器 → Worker → 挂某 Manager	§三「区内 Worker / 节点 = 执行面」＋ 既有集群形态	✅ 最可行	系统级能力接入方式 ＋ 到该 Manager 入向可达 ＋ 平台放行（白名单默认拒绝）
3	客户端 → Manager（有 IP 和域名）	§5.3 路径 C「自建独立区（不联联邦），不需要任何根」	⚠️ 形态成立，通路缺失	定稿原话：C「今天无通路」（与 D 同依赖 G2 区域名录，而 G2 依赖 F1.5）
4	客户端 → 客户端 → 接 Manager	§5.3 路径 B「设备加入已有区」	✅ 机制齐备	无（仅卡在"设备读包权限"那条待拍板）
5	多 Manager 网络 ＋ 升根	§5.3 路径 D（自建区加入联邦，需根背书区身份）＋ §4.1/4.2/4.4	⚠️ 前半已是定稿形态；"升根"现在不可逆	路径 D「今天无通路」；升格受 §4.4 约束 ⇒ 只能人工/离线/低频，且必须等 F1.5

关于场景 3 的"有 IP 和域名"：它确实是门槛之一，但只是之一 —— 定稿把路径 C 的缺口归到 G2 区域名录（"新机器不知道有哪些区可加入"）。域名解决"别人找得到你"，解决不了"别人知道你这个区存在、且能被批准加入"。

关于场景 5 的"升根"：定稿 §4.2 明确成立（技术路径写得可直接施工）；但 §4.4 明确不可逆，并把它定为「开放升格的前置条件 = 撤根机制」。⇒ ⛔ 它不是插件里能点的按钮，是人工、离线、低频的动作。

---

2 五条真正的共性 ＋ 一条硬约束

插件适合做「选择 ＋ 申请 ＋ 存配置 ＋ 界面」；⛔ 不适合做「承载」。

理由（硬）：插件跑在 dsh 实例内、权限是收窄的；而 Manager / Worker 都要系统级能力 —— 起服务、建独立账号（每用户一个 uid）、cgroup 配额、监听端口、写系统配置。 ⇒ 这 5 个场景里插件的位置全是引导器 ＋ 界面。引导层清单由 5 件 → 6 件（＋起承载服务 Manager / Worker 本体）。

🔴 并上一条定稿给的硬约束（直接管"选哪个 manager"）：

§5.3：「首管理员设置页上的『有哪些 manager 可选』不可做成公开列表 —— 那是拓扑信息，公开即扩大暴露面。改法：凭邀请码才列出该区信息。」

⇒ 对你的场景 1/3/5："选一个 Manager 加入"这个界面，⛔ 不能做成一张公开的节点清单，必须是凭邀请码才展开该区信息（命中 R5 权限面）。

---

3 用户第 6 点：库在 Manager（✅ 一致）／多 manager 主从库（🔴 与定稿冲突）

3.1 「库建立在 manager 节点上」—— ✅ 与定稿一致

定稿 §三三层权威：根（区域名录 · 用户全局唯一名 · 联邦吊销）｜区 Manager（本区归属 · 租约 · 资格）｜区内 Worker / 节点（执行面 · 本机运维库）。

⇒ 「库在 Manager 上」正是第二层，现状也已经是事实（Manager 本机一个库；Worker 无库）。不需要新做。

3.2 🔴 「多个 manager 互联 ＋ 主从库」—— 与定稿的「明确不做」直接冲突

定稿 §三白纸黑字：⛔ 区域 PG 互联或双向复制（列在「明确不做，写下来防止后人当 bug 修」里）。

⇒ 必须把「区内」与「跨区」分开，两边的答案相反：

	区内（同一个区内的 Manager 主备）	跨区（多个区的 Manager 之间）
主从库（同一个库的副本）	⚠️ 可议 —— 属本区高可用，定稿未禁止	🔴 定稿明确不做（区域 PG 互联 / 双向复制）
选主（谁是判决者）	⚠️ 代码只有位、没有实现（见 3.4）	不需要 —— 每区各一个判决者，天然唯一

🔴 定稿给跨区的答案是：「数据不动，只有请求动」（§5.2）—— 用户在外地登录 ⇒ 路由到锚定区 ⇒ 由锚定区的实例服务，home 不迁移。 ⇒ 跨区不靠复制，靠路由。 所以"多 manager 互联要上主从库"这条，方向与定稿相反：定稿要的是各写各的 ＋ 请求路由，不是"把库复制到一起"。

3.3 🔴 主从库 ≠ 解决「多个判决者」（这条仍然成立）

• 主从库（数据库层复制）解决同一个库的高可用与读扩展；
• 判决者唯一（应用层）靠选主，⛔ 不靠数据库复制；
• ⇒ 只上主从库、不上选主 = 两个 Manager 都能写 = 脑裂（下游仍是："两个进程写同一个实例的家 ⇒ 会话日志 append 冲突 ⇒ 数据损坏"）。
• ⚠️ 还有同源冲突：从库自动提升本质上就是「单方面接管」 —— 与既有纪律「无心跳判据时禁止单方面接管」顶牛 ⇒ 切换必须人工确认，不能全自动。

3.4 代码实测（⛔ 非推演）：位在哪、缺什么

事	现状
部署模式	三值：local（默认，本机库）/ k8s（多副本控制面 ＋ 共用一个库）/ cluster（我们生产用的）
多副本共用一个库	✅ 代码注释里声明支持（靠共享的库地址）
选主	🔴 只有位、没有实现 —— 配置项 podName 注释写着"用于选主"，但全源码只有声明与赋值，零消费点
主从 / 只读副本	🔴 零支持 —— 只有一个库地址，全仓无 replica / standby / 只读 相关字样

⇒ 结论："库在 Manager 上"已实现；"多个 Manager 之间共享权威库"定稿明确不做；"区内主备"要新做且必须先有选主。

---

4 汇总：角色 → 判定 → 现在缺什么

选什么	判定	现在缺什么
客户端（设备）	✅ 机制齐备（定稿路径 B）	仅卡"设备读包权限"那条待拍板
Worker（挂到某 Manager）	✅ 最可行	系统级能力接入方式 ＋ 入向可达阈值标定
Manager（建自己的区）	⚠️ 形态成立、入口缺失（路径 A / C）	A 今日只有 CLI 无 Web 通路；C 今日无通路，且依赖 G2 区域名录（G2 又依赖 F1.5）
Manager（接管现有平台）	❌	⛔ 不属"自选"，属迁移 / 接管
升级为根	⚠️ 技术上成立、流程上不可逆	撤根机制（G6）＋ 清单序号（G1）⇒ 即 F1.5；在此之前只能人工/离线/低频
多 Manager 互共享权威库（主从）	❌ 与定稿冲突（⛔ 区域 PG 互联/双向复制）	定稿的答案是**"数据不动，只有请求动"** ⇒ 走路由，不走复制

---

5 与既有的衔接（⛔ 不重复正文，只给指针）

• 🔴 本议题唯一权威 ⇒ dsh-server-docs/02-架构设计/覆盖网络-顶层架构全貌.md（定稿 2026-09-21）；其 §七 推进顺序 F1–F8，F1.5 是一切前置。
• 判决者 / 承载体 / 端 三分 ⇒ 交付物/平台新增功能总盘点与插件化归属-20260926.md §16
• 引导层清单（本轮 5 → 6 件）⇒ 交付物/基础服务插件-能做不能做总清单与拍板路径-20260926.md §4
• 节点与端全表、两张网、三个门 ⇒ 交付物/节点与端-互联互通与调用关系-20260926.md

---

6 待拍板

⚠️ 先说清楚：定稿 §八 里有两条不是本线能拍的（属覆盖网络线，本文只登记指针）

• 定稿 §8.1 骨干资格签发权 —— F4 之前必须定（三案 A / B / C，定稿 倾向 B：区签 ＋ 根背书）。
• 定稿 §8.2 根清单落地 —— 受信根放几把、分别谁保管，定稿写明属凭据类、须你决定。

⛔ 本文不重复这两条的候选与论证 —— 要看请直接打开定稿 §八。

本线台账（承接 基础服务插件-能做不能做总清单与拍板路径-20260926.md §7，逐条编号）

• P1 插件规划走不走（客户端形态）—— 决定 P2/P3/P4
• P2 设备要不要有「读平台插件包」的权（权限面）
• P3 节点提供哪些具体服务（业务方向）
• P4 跨用户要不要打通（⚠️ 排在 P1 之后；P1 走 A 案则可能自动消失）
• P5 平台要不要做成「用户可以自己搭一套」（服务端形态，与 P1 不同轴）—— 倾向 A 案但分两步：先只做多控制面共存所需的最小件，「升根」挂起到 F1.5 有结论

⚠️ 兜底一句：P5 若定 A 案，优先级要排在定稿的 F1.5 之后 —— 定稿明确「没有防重放序号，后面每一项下发的签名清单都是可重放的」，而"多 Manager 共存"做的正是下发签名清单。