admin
c1b5e4d966
- 变更规模：新增 514 / 修改 62 / 重命名 155 / 删除 4（归档重组与文档轮次） - .gitignore 修：`归档/**/db-cwd归一-备份-*/` —— 原规则写绝对层级（归档/db-cwd归一-…）， 目录搬进 归档/配置与备份/ 后**静默失效**，43 MB 的 DB 备份又变成未跟踪 - .gitignore 补：嵌套 git 内部数据（归档/内嵌git-20261008/、归档/skills-git-旧线-20261007/dotgit-原样移出/） - .gitignore 补：运行态与部署副本（.workbuddy/collab/、.workbuddy/tools/、.workbuddy/.load-pending、.workbuddy/tmp-*） - .gitignore 补：备份件（*.bak-*） - 未跟踪文件从 2190 降到 890（其余为 归档/ 归档件与 .workbuddy/memory/ 知识文件，按口径入库）
162 lines
13 KiB
Markdown
162 lines
13 KiB
Markdown
# 五种角色选择场景 · 明确件（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 共存"做的正是**下发签名清单**。
|