|
|
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 |
|
