 qian
|
e648e51340
|
feat(ui):管理后台添加文档网站入口
|
2026-09-02 22:47:21 +08:00 |
|
|
chengqian
|
652c6903f6
|
fix(permissions):修复提权漏洞
|
2026-09-02 19:43:42 +08:00 |
|
|
chengqian
|
ec182c5a71
|
chore(doc):完善文档描述
|
2026-09-02 17:41:10 +08:00 |
|
|
qian
|
71135aa321
|
fix(setting):移除停用的配置项
|
2026-09-02 00:10:26 +08:00 |
|
|
qian
|
4d0e2901d9
|
fix(setting):渠道代理改为系统配置而不是配置文件
|
2026-09-01 23:34:14 +08:00 |
|
|
qian
|
3c749c6c0a
|
fix(setting):移除设置中多个未生效设置项
|
2026-09-01 23:11:31 +08:00 |
|
|
qian
|
e800cd4b05
|
fix(setting):移除安全配置中的无用配置
|
2026-09-01 21:34:45 +08:00 |
|
|
qian
|
df78724773
|
fix(setting):修复注册限流不生效的问题
|
2026-09-01 21:20:22 +08:00 |
|
|
chengqian
|
fdd1bc7653
|
feat(role):权限管理功能
|
2026-09-01 20:32:35 +08:00 |
|
|
chengqian
|
f129221942
|
fix(billing):修复货币符号固定未更随系统设置变化问题
|
2026-09-01 16:20:49 +08:00 |
|
|
chengqian
|
0372d4fff5
|
feat(role):新增用户权限功能
|
2026-09-01 15:47:10 +08:00 |
|
|
chengqian
|
0ea011616f
|
fix(monitor):修复监控数据未及时更新的问题
|
2026-09-01 00:50:56 +08:00 |
|
|
Qian
|
b25d053f7b
|
Merge pull request #24 from qianfree/dev
用户端UI调整
|
2026-09-01 00:48:05 +08:00 |
|
|
qian
|
f0feacd15f
|
improve(ui):优化用户端ui
|
2026-09-01 00:44:20 +08:00 |
|
|
qian
|
15ec726f68
|
improve(log):优化渠道日志揭露，方便排查问题
|
2026-09-01 00:11:32 +08:00 |
|
|
qian
|
bf5dc7684d
|
fix(log):修复token计算错误，缓存率超过100%的问题
|
2026-08-31 23:29:21 +08:00 |
|
|
qian
|
211148a0af
|
improve(workbench):优化工作台页面
|
2026-08-31 23:29:21 +08:00 |
|
|
qian
|
a2beb8230a
|
fix(relay):修复转换层层数据断层导致连接中断没有正确计费的问题
|
2026-08-31 22:19:35 +08:00 |
|
|
chengqian
|
bdfd1b6567
|
feat(ui):管理后台新增工作台，可便捷查看告警信息
|
2026-08-31 20:07:15 +08:00 |
|
|
chengqian
|
f679105430
|
refactor(ui):优化用户端的仪表盘
|
2026-08-31 20:07:14 +08:00 |
|
|
chengqian
|
5917f0a9b1
|
refactor(ui):优化用户端的仪表盘
|
2026-08-31 20:07:14 +08:00 |
|
|
chengqian
|
8c8b63da77
|
fix(email):修复邮件相关功能
|
2026-08-31 16:21:20 +08:00 |
|
|
chengqian
|
0fd2e737ef
|
Merge remote-tracking branch 'origin/dev' into dev
|
2026-08-31 15:59:55 +08:00 |
|
|
chengqian
|
1f07fae1c2
|
fix(email):修复邮件相关功能
|
2026-08-31 15:59:22 +08:00 |
|
|
Qian
|
623b43c2ce
|
Merge pull request #23 from qianfree/dev
新增本位币设置
|
2026-08-29 10:25:44 +08:00 |
|
|
qian
|
cd019cf817
|
feat(billing):新增本位币设置，初始化时可选择全局货币单位，一旦设置就不能修改
|
2026-08-29 10:22:47 +08:00 |
|
|
qian
|
3bf1b4ca75
|
fix(channel):修复模型性能中详情的tps错误
|
2026-08-29 08:44:12 +08:00 |
|
|
qian
|
5c08c7c218
|
fix(log):修复使用日志查询时间固化问题
|
2026-08-29 08:43:25 +08:00 |
|
|
qian
|
d1711b702b
|
improve(log):优化模型广场页面
|
2026-08-29 00:13:01 +08:00 |
|
|
qian
|
483ffded09
|
improve(log):优化管理后台请求日志显示效果
|
2026-08-29 00:12:42 +08:00 |
|
|
qian
|
0964d9014b
|
fix(update):修复在线更新检测后缓存问题导致无法正常更新
|
2026-08-28 22:23:00 +08:00 |
|
|
chengqian
|
958f6c4d75
|
type(relay):修正测试代码里面的函数名为纯英文
|
2026-08-28 17:40:24 +08:00 |
|
|
chengqian
|
96bcd3e46f
|
fix(channel):修复渠道更新key后无法立即生效
|
2026-08-28 16:55:28 +08:00 |
|
|
Qian
|
d9c520401f
|
Merge pull request #22 from qianfree/dev
修复渠道健康度问题
|
2026-08-27 23:50:26 +08:00 |
|
|
qian
|
e8dfe9499d
|
improve(log):优化日志输出
|
2026-08-27 23:36:20 +08:00 |
|
|
qian
|
8f42091cef
|
fix(channel):修复渠道查询报错
|
2026-08-27 23:31:59 +08:00 |
|
|
qian
|
ed6f91b88d
|
chrome(db):合并数据库变更文件
|
2026-08-27 23:28:10 +08:00 |
|
|
qian
|
daffb7f947
|
fix(channel):修复渠道监控中TPS计算错误
|
2026-08-27 23:16:06 +08:00 |
|
|
qian
|
ba26450d4c
|
fix(ui):修复模型广场页面布局问题
|
2026-08-27 23:15:07 +08:00 |
|
|
chengqian
|
ce59b12622
|
fix(cron): 兜底任务 panic，并支持自定义渠道探测间隔
panic 兜底：cron.New() 默认不带 Recover 链，robfig/cron v3 的 startJob 是裸的
`go func(){ j.Run() }()`——任意一个定时任务 panic 会直接崩掉整个进程，而不只是让该
任务失败。在 runJobInternal 内兜住并转成普通 error，进程存活且失败经 recordExecution
落进 sys_cron_jobs，管理后台可见，不再表现为一次无声重启。堆栈只进日志，避免撑爆
last_error 的展示。渠道自动探测再加一层 per-channel recover：单个渠道 panic 只跳过
自己，本轮剩余渠道继续（否则整轮被中断）。
探测间隔可配置：新增 channel_auto_test_interval_minutes（默认 5，范围 1-1440），
原先固定 */5 * * * *。用 @every 而非 */N——*/N 只在 N<60 时有意义，*/90 会被静默
解析成 */30，给出与配置不符的频率；@every 还让各实例按启动时刻错开，不会所有实例
卡在同一分钟同时探测。
配套两处基础能力：CronScheduler 记录 cron.EntryID 并新增 Reschedule（先加新条目、
成功后再摘旧条目，非法表达式时保持原调度，避免一次错配把任务彻底摘出调度器）；
ConfigService 新增 OnSettingsChanged 回调钩子，挂在既有的 settings:changed 订阅上，
使配置变更能触发动作而不只是让缓存失效，多实例各自重排、无需重启。
|
2026-08-27 21:59:45 +08:00 |
|
|
chengqian
|
dd02bf4ac3
|
feat(admin): 渠道列表/详情展示最差模型，暴露被均值摊薄的单模型故障
渠道健康分是各模型 succ_ewma 的均值，单个模型全挂会被其余健康模型摊薄——10 个
健康模型 + 1 个挂掉仍能算出 90 分绿灯，而这恰是模型级熔断要隔离的典型场景。
补一个最差项：ChannelRuntimeStates 遍历目录快照时顺带取每个渠道 succ_ewma 最小的
模型，按 succ^α×100 折算为与渠道分同口径的健康分。
不落库、不加列：catalog 内存快照已逐 (渠道,模型) 持有 SuccEwma，遍历它即可，零额外
I/O；数据是调度器同源的 5 秒刷新值，比 5 分钟落盘快照更新鲜。取最小值也天然免疫冷
模型问题——无上报的模型读作满分 1.0，永远不会被选为最差项。
byModel 是 map，遍历顺序随机，同分时按模型名取小者打破平局，否则全部模型满分时
每次请求返回的模型名都会跳变。
前端：列表页健康度列在最差项低于 80（健康档）时补一行「⚠ 模型名 分数」，详情页
健康度字段同理；disabled / testing 渠道不在目录快照，不展示。
|
2026-08-27 21:59:45 +08:00 |
|
|
chengqian
|
faddc45978
|
chore(dao): gf gen dao 同步 multiplier 列注释
迁移 000018 执行后重跑，mdl_tenant_models.multiplier 的注释与库一致。
纯注释变更，无字段与类型改动；本轮全表重生成只有该表有差异。
|
2026-08-27 21:59:45 +08:00 |
|
|
chengqian
|
af96f52b1a
|
fix(pricing): 修正 mdl_tenant_models.multiplier 列注释为当前实际公式
线上库该列注释仍是 000001 的初始文案，与 000014 Up 改写的版本不符（2026-08-27
重跑 gf gen dao 时发现：生成结果会回退掉代码里的倍率优先级链说明）。
两版历史文案都已不准确，按当前实现重写：模型乘数是预留能力（mdl_models 无
multiplier 字段、computeCost 未接入，model_multiplier 快照恒为 1.0），而 000016
引入时段定价后 computeCost 实际乘的是 TenantMultiplier × TimeMultiplier。新注释
写明实际公式 = 基础价格 × 租户乘数 × 时段乘数，并保留 discount_ratio > multiplier
> 租户等级 price_multiplier 的优先级链（已对照 pricing.go:260-298 复核仍成立）。
执行后需重跑 gf gen dao 同步 entity/do/dao 注释。
|
2026-08-27 21:59:44 +08:00 |
|
|
chengqian
|
d12ea0566d
|
chore(dao): gf gen dao 刷新健康度两张表的生成注释
迁移 000017 执行后重跑 gf gen dao，把修正后的列注释同步进 entity/do/dao。
纯注释变更，无字段与类型改动——entity 中 success_rate / latency_ms /
health_score 仍为 float64（非金额小数，符合 float64/decimal 分类规范）。
此前 entity 里 health_score 的注释写着已废止的四因子加权公式，是全链路唯一会
主动误导后来人的地方，至此与实现对齐。
|
2026-08-27 21:59:44 +08:00 |
|
|
chengqian
|
1f3489c37d
|
docs(dispatch): 修正健康度列注释与过时文档，清理两个僵尸字段
chn_health_scores 的列注释仍写着健康体系重写前的加权公式（成功率×0.40 + 延迟分×0.25
+ 稳定性×0.20 + 连续失败分×0.15），而实际实现是 avg(succ_ewma)^α×100。注释经
gf gen dao 流入 entity/do/dao，是全链路唯一会主动误导后来人的地方。迁移 000017 改写
health_score / success_rate / latency_ms / calculated_at 的 COMMENT 为实际口径。
stability_score / consecutive_failures 自重写后从未被更新，只在建渠道和重置健康度时
写入常量，趋势图与调度均不消费，却仍通过 HealthTrendPoint 返给前端。改为：注释标注
【已废弃】、代码停止写入与查询、从趋势接口响应中移除。保留列不删除以免破坏历史快照；
chn_health_snapshots.stability_score 为 NOT NULL 且无默认值，迁移补 DEFAULT 0，
否则代码停写后插入会失败。
docs/reference/多项目渠道调度对比.md 的 team-api 部分描述的是重写前的实现（引用的
relay/scheduler/、internal/logic/relay/health.go 均已删除），加时效声明并指明现行口径。
注意：迁移执行后需重跑 gf gen dao 刷新 entity/do/dao 中的列注释。
|
2026-08-27 21:59:44 +08:00 |
|
|
chengqian
|
4f07b64ac7
|
fix(admin): 模型级健康分统一为 succ^α 口径，探测/重置结果即时落盘
能力列表的模型级健康分用线性 succ×100，而调度 healthFactor、维护快照落盘、健康变化
日志三处都用 succ^α×100。前端两处共用同一套 80/50 阈值，于是 succ=0.89 时模型行显示
89「健康」、渠道行显示 79「降级」，同一个渠道点进去自相矛盾。改为经
dispatchadapter.HealthAlpha() 取当前生效策略的 α（策略支持热更新，不硬编码 2）。
该入口刻意不走 Coordinator()，避免管理后台读接口有装配整个调度引擎的副作用。
渠道测试与重置健康度后请求即时重算快照：维护循环 5 分钟一轮，此前测试成功后 Redis
立刻变、能力列表（直读 Redis）立刻变，唯独渠道健康分要等下一轮，看起来像「测试没
生效」。重置单模型的分支此前完全不写 chn_health_scores，展示分永远停在旧值，一并修复。
|
2026-08-27 21:59:43 +08:00 |
|
|
chengqian
|
a5e2ecf527
|
fix(dispatch): 渠道健康聚合只统计有真实上报的模型，降级时保留库中旧值
渠道展示分是目录内全部模型 succ_ewma 的算术平均，而无流量模型读到的是乐观默认满分。
20 个模型的渠道死掉 1 个（succ→0.05）仍能算出 avgSucc≈0.95、91 分绿灯，恰好掩盖了
模型级熔断要隔离的典型场景。改为只统计 HasHealth 的模型；全渠道无真实上报时
Counted=0，保留库中上一次的分数而不是用默认满分覆盖历史结论。
Redis 读失败（Degraded）时跳过落盘并打 Warning：照常落盘会把全渠道健康分刷成 100，
连带 chn_health_snapshots 把假象写进历史趋势，事故期间的曲线反而全绿。自动禁用判定
一并跳过——该操作不可逆，不能基于不可信读值触发。
聚合逻辑抽成纯函数 aggregateChannelHealth 以便单测；另新增 RequestHealthSnapshot
按需重算入口（维护循环消费，满则丢弃由下一轮兜底），供渠道测试/重置健康度接入。
健康上报是 fire-and-forget，重算前等 500ms 让 worker 落完 Redis。
|
2026-08-27 21:59:43 +08:00 |
|
|
chengqian
|
3f3fc43856
|
fix(dispatch): 健康读值区分「无数据」与「读失败」，Redis 降级不再清零健康记忆
ReadRuntime 此前对「该模型没有流量」和「Redis 读失败」返回同样的乐观默认值
succ=1，调用方无从分辨。后果是 catalog.Rebuild 会用这批默认值重建快照，把上一轮
真实的 EWMA 覆盖掉——注释声称的 last-known 语义实际没有兑现，Redis 抖一下全渠道
healthFactor 集体回满分。
RuntimeReadout 新增 HasHealth（确有真实上报，脏值/精确 0/字段缺失都不算）与
Degraded（读失败，读值整体不可信）两个标记；Rebuild 在 Degraded 时沿用上一份快照的
健康读值，无历史可沿用才保持乐观默认（新实例启动即遇 Redis 故障不应把全渠道判死）。
|
2026-08-27 21:59:43 +08:00 |
|
|
chengqian
|
3035fa118c
|
fix(dispatch): 修复 HMGET 判空失效导致冷渠道健康分被读成 0
ReadRuntime 用 `!vals[0].IsNil()` 判断 HMGET 结果是否存在，但 gredis 把 Redis
nil 数组元素包装成非 nil 空 gvar（IsNil() 恒为 false、Float64() 静默返回 0），
导致所有从未被真实流量访问过的渠道×模型被读成健康 0 分而非默认满分 1.0：管理
后台渠道健康度全线坍缩（如某渠道 (1.0+0)/2 → 0.5²×100=25 长期不动），调度侧
healthFactor 同样归零，冷模型路由权重被压死。
GET/HGET 单值回复的 IsNil() 正常，仅数组回复有此坑；仓库内 HMGET 调用点仅
ReadRuntime 与 readBreaker 两处，后者因默认值 BreakerClosed 恰为零值而侥幸
无害，一并改为按字符串判空。
- ReadRuntime：TrimSpace 判空 + ParseFloat 值域校验（succ 取 0<f<=1，EWMA
由正数衰减而来不会精确到达 0，精确 0 视为异常数据）
- 回归测试：key 不存在须回落默认值、空串/非法值/精确 0 防御
- 通用规则写入 goframe-conventions.md 框架使用错误记录
同时补齐探测与健康分的可观测性（本次排查绕行三次的直接原因是全链路静默）：
- [ChannelProbe] 探测全流程：轮次起止、模型与上游映射、结果、是否上报健康
- [ChannelHealth] 健康分变化：EWMA 变化点（Outcome.Probe 区分探测/真实流量
来源）、快照落盘含各模型 succ 明细、维护轮次覆盖摘要
- 快照落库失败由 Debug 升为 Warning（此前静默，健康分冻结无从定位）
- 探测目标不在调度目录时告警（该场景健康分不落盘且渠道不参与调度）
- 变化类日志按「分数实际移动」触发，稳态降为 Debug，避免生产流量刷屏
|
2026-08-27 21:59:42 +08:00 |
|
|
qian
|
08c885aa6c
|
fix(web):修复前端缓存导致点击页面没反应
|
2026-08-27 00:08:31 +08:00 |
|