|
|
c90d4f3791
|
feat(cluster,webapi): 集群页可切换负载均衡模式（每节点一个开关）
## 为什么之前没有开关（以及为什么现在这么加）
模式原本只读一次环境变量 `W4F_BALANCE_MODE`，UI 只显示「观察模式 / 已启用」。
把开关加进来时有两个坑必须一起解决，否则开关是个摆设：
1. **不持久化就等于骗人**：只用 env，页面上翻一下、重启一次就回到默认，
而页面已经显示成功了。
2. **不能做成集群级开关**：每个成员只释放自己的转发，根本没有一个动作能把它们
一起翻过来。做成集群开关就是撒谎。
所以：**每节点一个开关**，写的是本节点自己的设置。
## 持久化与优先级
- 新增 `settings` 表的 `balance_mode` 列 + `Store.BalanceMode()`。**单独一列**，
不是塞进 settings JSON：那个 JSON 是整份重写的，而这是会被各节点同时写、必须
各自收敛的状态，跟 `nodeKey`/`settings` 同一类处理。
- **存了就以存的为准**，env 只作首次启动的默认值；`Settings()` 读回时带上它，
但 `UpdateSettings` 只在非空时镜像到列，所以一次无关的设置保存不会把它清掉。
- `SetModeFromUI` **先落盘再应用**：写失败就什么都不改，否则节点会运行一个重启后
复现不出来的模式——开关就成了谎言。
- 认不出的模式一律拒绝（400），不猜。
## 报告新增两个字段
- `modeSource`: `env` | `stored` —— 说清当前模式是启动参数给的还是有人在这里选的。
- `canControl`: 由**调用者的权限**决定，只读身份不会看到一个点了会 403 的开关。
`PUT /cluster/balance/mode` 走 **write** 级鉴权：释放会停 worker、断活连接。
## 两处我自己抓到并修掉的错
1. **`ModeSource()` 一开始写成「能存就算 stored」**（判据是 `persist != nil`），
于是**每个有 store 的节点都自称 stored**，哪怕从没人设过。canary 第一轮就露了：
`mode=dry-run source=stored`。改成看「是否真的存过值」。
2. **启动日志打的是 env 变量而不是生效值**，存过 `on` 之后仍打 `DRY-RUN`——
上一行的 `loaded from settings` 还在，两行自相矛盾，正好会让人以为释放是关的
而它其实开着。
## 测试
新增 6 条：存的模式压过 env、没存就回落 env、落盘失败则模式不变、乱值被拒、
UI 切换同时落盘并生效、无持久化能力时不宣称可控制。
canary 实跑 6 步：初始 `dry-run/env` → 设 `on` → 复查 `on/stored` → 乱值 400 →
乱值后模式不变 → **重启后仍 `on/stored`**，启动日志 `load balancing ON (source=stored …)`。
vue-tsc 干净；go build / vet / go test ./... 全绿。
|
2026-10-06 14:37:18 +08:00 |
|
|
|
c69fb2caba
|
feat(cluster): 负载均衡改为每节点自主「先撤销本地转发，再丢回环」
按用户要求重做：不再由 leader 单独调度，而是**每个节点对自己的转发跑同一条
规则**，超了就自己撤销一条、把任务丢回环上，由环原有的「最闲者认领」决定它
落到哪台。
## 为什么必须是 owner 自己动手（不是洁癖，是实测逼出来的）
真机探针（跑完已删）显示，真实 revoke 之后：
TopologyOwner after revoke = "n1" ← 条目还在（只标记不删除）
n1 Forwards=3 score=310.0 ← 负载根本没降
after step: revoking=true publishing=false
⇒ 一节点的负载**只有它自己的拓扑条目消失时才会下降**，而条目是本地簿记，没有任何
对端可以代它写。leader 从外面只能看见失衡、无法让失衡成为事实——它必须伸手去改
另一个节点的簿记，而这正是这个环到处都在避免的跨节点写（revoke / restart 定向往
owner 也是同一个理由）。
⇒ 而且旧实现**根本跑不起来**：phase 1 判据是「条目消失」，可 mark-don't-remove
让它永远不消失，于是每 120s 打一条 `revoking … timed out; abandoning`，
**phase 2 永不执行，一条转发都不会迁**。开 `W4F_BALANCE_MODE=on` 只会刷日志。
## 规则（替代原来的 ratio 阈值）
当 Forwards >= 2 且 Forwards > ceil(总数/存活节点数) 时，撤销一条
- **自限**：3 条 / 3 台 → owner 2 > 1，卸一条 → 1，`1 > 1` 不成 → 停。
没有上界的话 owner 会把转发**全部卸光**。
- **不会卸空**：低于下限（2）永不撤销。
- 平摊值向上取整（3/3=1，不是 0），否则 1 条 / 3 台的节点也算「超了」。
- **不再用 mem/net 参与判据**：实测 `.30` 空闲时 netPct 能到 55%，Score 会高于
有转发的节点——用 Score 会把纯网络抖动当成负载。
- 节奏用**每节点冷却**（默认 600s）而不是「失衡持续多久」窗口：规则本身已经要求
真实失衡，没有需要平滑的瞬态，只有需要限制的抖动频率。
## 为什么必须是新的 Release 任务类型，不能复用 Revoke
用户停止（Revoke）**保留拓扑条目**作为 disabled 标志的载体；均衡释放必须**删除
条目**，因为 (a) 负载由自己的条目数算出，条目不删负载不降；(b) 每个节点的
duplicate-guard 会拒绝「已有 owner 的转发」的创建任务——保留条目会让**所有节点
都拒领**，转发被永久搁死在刚放弃它的那台机器上。
Release 因此：`Handler.Release`（停 worker，但**不标记 stopped**）→ 删条目 →
`SubmitTask` 以**启用状态**重新发布。它需要自己的 Handler 方法，不能回落到
Revoke：Revoke 会顺手把 link 标成 stopped，而这条转发即将在别的节点上跑。
## 顺带修掉两个既有缺口（实测确认）
1. **`submitMigrate` 发布不出去**：`OnToken` 的 localPending 重合并只保留「从未
publish 过」的本地 pending，而只有 `Add*` 系列会记 `published`。引擎里直接写
`PendingTasks` 的任务会在下一次 adopt 时被静默丢弃。
⇒ 新 `ReleaseTask` 走 `AddPending`。
（`SubmitRestart` 有同样的毛病，但它不在本次范围，未改动——见提交说明末尾。）
2. `Release` 需要绕过 duplicate-claim 守卫（同 Restart），否则「owner 本来就持有
这条转发」这一前提会让每条 Release 都被丢掉。
## 测试（17 条，全绿）
规则：平摊值取整、超了才撤、撤到平摊就停、单节点不撤、低于下限不撤、不撤已停
转发、候选选择确定。
机制：Revoke 留载体 vs Release 删条目（这是两种语义的核心差异）、Release 只由
owner 执行且不消费他人的任务、owner 释放后环的普通认领把它接走。
模式：dry-run 不动任何东西、off 真的什么都不做、未知模式回落 dry-run、
冷却限制抖动频率、确认超时清理。
只读：Report 不变更任何状态、能解释「超了但不动」的原因、均衡节点给出真实答案。
**双向验证 3 条**（改坏→变红→还原→变绿）：
- 去掉 Release 的 duplicate-guard 例外 → `the owner released 0 times, want 1`
- 去掉「不超过平摊值」上界 → `2 owned against share 2 must not release`
- Release 改成只标记不删除 → `n1 should now own 2, got 3`
go build / go vet / go test ./... 全绿（go clean -testcache 后逐包实跑）。
## 未做 / 待办
- `SubmitRestart` 的同类发布缺口未修（同样会被 adopt 丢弃），需要单独确认它
在实机上是否真的丢过 restart。
- UI 尚未跟进新报告结构（下一步）。
|
2026-10-06 14:03:03 +08:00 |
|
|
|
8176478269
|
feat(cluster,httpapi): GET /cluster/balance 只读负载视图
## 为什么需要它
balancer 的判断原本只能从日志看，而且**只在"确实失衡 且 迟滞窗口已满"时才输出**。
运维问"这个集群均衡吗"——在健康状态下得到的是**沉默**，与"负载均衡没开"
完全无法区分。这个端点把它的判断做成可主动查询的。
## 关键性质：Report() 不扰动迟滞计时器
Report 只读，**不碰 overSince**。否则好奇的运维反复轮询这个端点就会不断重置
"失衡已持续多久"的计时，导致真正的迁移永远不会触发——一个"看一看就把它看没了"
的只读接口。测试 TestReportDoesNotDisturbHysteresis 正是钉住这点：轮询 5 次后
计时器必须原封不动，且随后满足窗口时迁移仍要发生。
## 只 leader 报计划
`wouldMigrate`/`overloadedSince` 仅在 `IsLeader()` 时给出。非 leader 仍返回各节点
Score（那是信息性的），但不报"会迁什么"——否则运维随便查一台节点会拿到与集群
实际行为不符的答案。TestReportOnFollowerHasNoPlan 钉住。
## 返回内容
nodes[] 各节点 Forwards/MemPct/NetPct/Score
isLeader 只有 leader 会行动
overloadedSince 超载已持续多久（迟滞进度）
wouldMigrate 窗口满足后会迁哪条、从哪到哪
inFlight 两阶段迁移进行中（revoke 慢 vs 卡死可区分）
dryRun / enabled 当前是观察还是真迁
## 接线
Balancer 在 NewBalancer 时就创建（HTTP 层需要），W4F_BALANCE_* 解析完再用
SetRatioAndSustain 应用；新增 SetDryRun / DryRun / SetRatioAndSustain，
避免初始化顺序耦合。Handler.Balancer 为 nil 时端点返回 404。
## 测试
新增 4 条：Report 不扰动迟滞（轮询后计时器不变、且迁移仍能触发）、
follower 无计划、窗口满足前后计划的有无、in-flight 可见。
go clean -testcache 后逐包实跑 7/7 全绿。
|
2026-10-06 12:44:17 +08:00 |
|
|
|
45a6a76621
|
feat(cluster): 负载均衡接入运行时 —— 默认 dry-run，显式 opt-in 才真正迁移
承接 7d5bca5（Balancer 状态机）。本提交接线到 main.go，并让 **dry-run 成为默认**。
## 为什么默认不启用
线上此刻是 `.30` 持 3 条转发、另两台 0 条。按已实现的规则，这会在第一次
检查就立刻触发迁移 —— 而每条迁移都要停一个 frpc worker、断掉活跃连接。
在没有看过真实数据会迁什么之前就把这个开关打开，等于拿生产连接赌一把。
所以：
W4F_BALANCE_MODE=dry-run 只报告不动手（默认）
W4F_BALANCE_MODE=on 真正迁移
W4F_BALANCE_RATIO=2 超载 = Score 超过均值 2 倍
W4F_BALANCE_SUSTAIN=1800 失衡需持续 30 分钟
W4F_BALANCE_INTERVAL=10 每 10 秒检查一次
dry-run 走同一套决策与迟滞逻辑（stepDryRun 复用 planBalance），因此它报告的
就是真开会迁的东西 —— 先用它观察，确认符合预期再切 on。
## 只有 leader 平衡
WatchBalance 里 `if !b.engine.IsLeader() { continue }`。搬转发是全集群决策，
令牌是共享的：若每个成员各自决定，必然出现两个节点同时对同一条转发发 revoke。
（这与 Restart/RemoveNode 走同样的 owner 定向是同一类约束。）
## envFloat
新增：环境变量解析失败时回落到默认值并打日志，而不是静默变成 0（0 会被
NewBalancer 当成非法值钳制，但静默钳制无法与"用户显式要 0"区分）。
## 测试
- TestDryRunNeverTouchesTheRing —— dry-run 必须报告"would migrate"且**不发布任何
任务、不动拓扑、不进入 in-flight**。这是它作为默认值存在的全部意义。
- TestOnlyLeaderBalances —— 非 leader 跑 WatchBalance 不得发布任何任务。
go build / go vet / go test ./...（go clean -testcache 后）全绿，gofmt 干净。
## 下一步（未包含）
集群页 UI 展示超载提示与迁移进度；以及**先以 dry-run 在生产跑一轮观察**，
确认 planBalance 对真实数据的判断符合预期后再决定是否切 on。
|
2026-10-06 11:56:23 +08:00 |
|
|
|
7d5bca5b72
|
feat(cluster): 负载均衡迁移 —— 定向投递 + 两阶段提交
承接 875e580（只落决策逻辑）。本提交补齐运行时：周期检查、迟滞判定、
两阶段迁移，以及让迁移任务**定向**到指定节点。
## 为什么必须是定向的（核心安全点）
loadSnapshot() 的 Forwards 来自 ForwardsOwnedBy，所以旧 owner 一旦被摘掉条目，
它立刻变成最闲节点。而普通创建任务是"任何最闲者认领"—— 于是它会把刚迁走的
转发**当场抢回**，迁移变成"只重启一次 worker"的空操作。
故 Task 新增 Migrate + Target 字段，runCommands 的选择循环照 Restart 的范式
处理：Target == 自己才认领，否则 `continue` 让任务随环前进。
## 为什么必须两阶段（不能一次发 revoke + submit）
1. 旧 owner 变最闲后会把未定向的任务抢回（上面那条）；
2. PendingList 按 `t<ID>` **字符串**排序（`t10 < t5`），同轮内两个任务的先后
不可控。
Balancer 因此是显式状态机：phase1 发布 revoke 并等待旧条目真正消失，确认后才
发布 phase2 的定向 migrate。两个超时兜底：revoke 超时则放弃；migrate 超时
（target 没认领）则退回**无定向** SubmitTask，让"任何最闲者"接手 —— 转发不会
被丢，只是延迟。这与环本身的行为一致（实测：只要还有更闲的节点，pending 任务
最终会被认领；只有"全员都更忙"时才滞留）。
## 两个被测试逼出来的设计修正
- **绝对下限 minForwards=2**：只有"超均值倍数"在小集群失真——3 节点 1 条转发时
owner Score≈105 而两台空闲≈5，20 倍于均值会触发迁移，但那是完全正常的分布，
迁它只会断一条活跃连接。倍数负责看形状，下限负责"有没有东西值得搬"。
- **Migrate 也要绕过 duplicate-claim 守卫**，否则旧条目还在时目标节点会拒绝
认领（这条守卫正是为了防止同一 remotePort 注册两次 → frps 报
"proxy already exists"）。
## 测试（本项目第六次假绿的教训）
新增 6 条，全绿。做双向验证时发现
TestMigrateTaskIsAddressedNotClaimedByLightest **删掉定向分支后仍然 PASS**，
查因：`loadSnapshot()每次 OnToken 都用 Handler.RuntimeLoad() 刷新 mem/net，
我手工设的 State.Nodes[].Load 被静默覆盖 ⇒ n2/n3 始终平手 ⇒ "最闲者"恰好
就是 target，定向性从未被验证。
改为**用三个 Handler 的不同 RuntimeLoad 制造真实差异**（n3 最闲、n2 是较重的
target）后，删掉定向分支如期变红：
n3 (the LIGHTEST node) claimed 1 migrate task(s); the task is addressed
to n2 and must ignore load entirely
⇒ 这条纪律再次生效：测试必须制造出能让错误实现暴露的**不对称**，否则"恰好通过"
比"失败"更危险。
go build / go vet / go test ./... 全绿，gofmt 干净。
|
2026-10-06 11:50:53 +08:00 |
|
|
|
875e5805eb
|
feat(cluster): 负载均衡迁移的决策逻辑（planBalance）
用户提出「加负载均衡算法，定期重新分配任务」。本提交只落**决策**部分：
给定当前环快照，算出「该不该迁、迁哪条、迁给谁」。运行时接线未包含在内。
## 决策规则（刻意保守）
- **阈值**：某节点 Score 超过均值 minOverRatio 倍，且与最闲节点相差**至少一条转发的量**
（Score 里 Forwards 权重 100，所以差 <100 视为噪声）——避免为 1% 的差异重启 worker
- **一次一条**：负载抖动时不会引发一批 worker 同时重启（每次迁移都断活跃连接）
- **不动停用的转发**：迁走 disabled 的转发等于把用户明确关掉的东西重新拉起来
- **不动 offline 节点**：否则会迁到一台不存在的机器上
- **完全均衡时返回"无事可做"**：这就是阈值触发的意义——健康环零开销
## 尚未实现（本提交不含）
1. **持续时间判定**：阈值命中需持续 N 分钟才动手，避免瞬时尖峰触发迁移。
当前 planBalance 是无状态的，时间维度留给调用方的 BalanceTracker。
2. **两阶段提交**：这是**安全性关键**，不能简单地把 RevokeTask 与 SubmitTask
一起发出去。实测 PendingList 按 `t<ID>` 字符串排序（`t10 < t5`），同轮内
顺序不可控；且旧 owner 停掉 worker 后自己的 Load 立刻下降，很可能又成为
最闲节点而把刚迁走的转发重新认领回去。正确做法是先确认旧条目已消失，
再提交新任务。
3. **周期性检查与 API/UI 暴露**。
## 测试
4 条，均针对 planBalance：搬走超载节点的一条转发 / 不搬停用转发 / 均衡时不动 /
不选 offline 节点。构造 seed 时经 JSON 往返让每个 State 持有独立 Nodes 切片
（AdoptState 是值赋值但 Nodes 是切片，共享底层数组会造成假绿——这个坑本项目
已踩过多次）。
|
2026-10-06 11:14:25 +08:00 |
|
