 Sakurasan
|
979973ddde
|
feat: 流式首包缓冲容错（hold）与失败分类冷却
流式请求在首个内容事件到达前由网关缓冲（借鉴 magpie 的 holdWriter）：上游的错误
事件、空流、断连、协议形态不符（要流给了整包）都在放行前换渠道消化，客户端无感知。
扣住期间照常发 SSE 注释心跳；缓冲超过 1MB 直接放行退化为普通转发，判定失效不吞正文。
- 新增 proxy/hold.go：streamHold（缓冲/放行/心跳/首 token 计时与放行互斥）、
sseEventHasContent（chat/messages/responses 三种协议的内容判定）、
sseUpstreamError（200+流式形式的错误事件识别）、classifyUpstreamError +
quotaSignals（余额/配额特征识别）
- 非流式改为先读完整响应再写头：读失败（网络错误/超时）发生在写出之前，可换渠道
重试；此前先写 200 头再读，超时只能给客户端留一个 200 空响应
- 协议形态校验：要流却给了整包（didNotStream）按失败换渠道，反复如此的渠道会被
健康计数剔除
- 记账：每次尝试独立 trySink，只有成功走到 EOF 才并入请求级 sink——失败渠道的
message_start 用量不计入账单
- 冷却按原因分类（channel.FailKind）：余额/配额类第一次失败即冷却 30 分钟（429 不
一定是限流，智谱 429「余额不足」也在此列）；其余按连续进冷却次数指数退避
30s→60s→120s，封顶 10 分钟；短于退避值的 Retry-After 不再缩短冷却
- 新增 OT_PROXY_FIRST_TOKEN_WAIT（默认 0=不限）：放行前等内容的最长时间，超时即
取消本次尝试换下一个渠道
- 渠道列表接口返回 cooldown_reason，后台可区分「限流」与「余额耗尽」
- 测试：hold 缓冲/放行/心跳、内容与错误事件判定、失败分类与指数退避、容量热生效
- docs/magpie-plugin-mechanism.md：参考实现的插件机制调研
|
2026-10-30 02:43:23 +08:00 |
|
|
Sakurasan
|
bb20ebbed0
|
perf: 渠道 MaxConcurrency 改配置后排空热生效，无需重启
信号量条目带上容量，TryAcquire 发现容量变更且旧槽已排空时就地换新。
release 闭包持有旧 chan，换新后在途请求释放进旧槽是无害的。
|
2026-10-30 01:42:22 +08:00 |
|
|
Sakurasan
|
6cb840718f
|
fix: Pick 限最高优先级层加权随机，接入绑定级权重，修 loadBound 顺序丢失
- Pick 只在最高 priority 层内加权随机：低优先级渠道此前可能在首选
渠道健康时被随机打中，priority 只体现在故障转移顺序上
- 均衡权重 = 绑定级 Weight × 渠道级 Weight：绑定表 weight 字段此前
存而不用；乘法合成使默认绑定权重 1 时等价纯渠道权重
- loadBound 原按绑定记录返回顺序输出候选，丢掉了 SQL 的 priority
ASC 排序，绑定渠道的故障转移顺序实际是随机的
- 新增两个测试锁定优先级层与权重语义
|
2026-10-30 01:21:41 +08:00 |
|
|
Sakurasan
|
c39c3e7da4
|
feat: 补齐上游细节、渠道观测与模型定价元数据
- 上游 429 的 Retry-After 转成渠道冷却时长（夹在 10 分钟内；比默认值短则不缩短，
否则 1s 就把坏渠道放回轮转）。失败计数改由 proxyOne 就地报——只有它读得到响应头。
- 故障转移时间预算 OT_PROXY_FAILOVER_BUDGET（默认 30s）：只约束第二个及以后的渠道，
首个不受限（长回答本就要跑几分钟），但坏渠道不再把客户端拖到 N×timeout。
- 流式空闲心跳 OT_PROXY_STREAM_HEARTBEAT（默认 15s）：补一行 SSE 注释 `: ping`，
防止 nginx/Cloudflare 的空闲超时掐掉长思考。心跳与正文共用一把写的锁，
gin 的 ResponseWriter 不是并发安全的；注释行不进转换也不计费。
- 渠道观测：GET /api/v1/admin/channels/stats?window=5m|1h|6h|24h|7d 聚合请求量、
成功率、P50/P95/max 延迟、成本与 top_errors；分位只取成功样本，canceled（客户端
主动断开）不计入渠道错误率。渠道页桌面表格加「近N小时」列、移动端加同内容条，
顶部可切窗口。
- 修一个让统计瞎掉的归因问题：全部渠道失败时 recordError 传的是 nil，
usage_logs 里 channel_id=0，这类失败在渠道维度完全看不见。改为归到最后一个
真正试过的渠道。
- 模型定价与元数据：Model 新增 cache_write_price（0 则回退输入价×1.25，可显式配
Anthropic 1h 的 ×2）、context_length 与 supports_tools/vision/reasoning；
finishUsage 走 CacheWritePriceOr()。/v1/models 叠加用户与密钥白名单过滤
（原来会把限制外的模型名直接泄漏在列表里）并返回元数据，价格不外泄。
- /v1/models 的 Anthropic 分支原是死代码：协议只按路径判，而两种客户端共用这个路径。
改为按 x-api-key / anthropic-version 头判，OpenAI SDK 从不发这两个头，互不影响。
- NewGateway 的十个位置参数换成 Options 结构体（三个 Duration 两个 int，传错编译期发现不了）。
新增 6 个用例：Retry-After 两种写法与夹顶、重试预算截止、空闲心跳出帧、
/v1/models 过滤与双形状、缓存写价两条路径、失败归因。
|
2026-10-17 04:09:39 +08:00 |
|
|
Sakurasan
|
d4c5263f1e
|
feat: 运行期渠道冷却可见并可手动恢复
运行期冷却只存在网关进程内存里，DB 的 health_status 看不见它：渠道被踢到
30s 冷却后，管理后台仍显示 healthy，模型也照常出现在 /v1/models，但请求
返回 503 no_channel，管理员只能去翻日志。
- channel.Service 增 RuntimeState（连续失败次数 + 冷却剩余）与 ClearRuntime；
Gateway 包装出 ChannelRuntime / RecoverChannel 供管理端调用。
- GET /api/v1/admin/channels 每项返回 runtime_fails 与 cooldown_seconds。
- 新增 POST /api/v1/admin/channels/:id/recover：清运行期冷却与失败计数，并把
探测写的 health_status 置回 healthy；不改 enabled，上游若真挂着，下一次探测
或再连续 3 次请求失败会重新把它踢掉。
- 渠道页健康列下方显示「冷却中 Ns」/「连续失败 n/3」，仅在冷却或探测不健康时
出现「立即恢复」按钮（卡片与桌面表格两套布局都覆盖）。
仍未处理：冷却到期是裸恢复、没有 half-open 试探；计数是进程内的，多实例各自
为战，要共享得等 Redis 那一步。
|
2026-10-17 01:19:03 +08:00 |
|
|
Sakurasan
|
e865f69a41
|
fix: 修掉模型调用链路上的四处失效逻辑
- 超时：NewGateway 里 gw_timeout*time.Second 把已是 Duration 的值二次换算，
int64 溢出后无论 OT_PROXY_TIMEOUT 填多少都等于没有超时，渠道 timeout_ms
也从没被读过。现在非流式用 context deadline 约束整段时长，流式只约束首包
（Transport.ResponseHeaderTimeout），正文不限时长，长回答不会被砍。
- 断连：上游请求改用 NewRequestWithContext 绑定客户端 context，客户端断开即
取消上游并记 canceled，不再空转生成继续付费；PATCH 已写 200 头后不再往
响应里追加错误体。
- 白名单：APIKey.AllowedModels 以前只存不用，现在 Auth 注入 context 并参与
判定（用户黑名单 > 密钥白名单 > 用户白名单 > 全局）。
- 选路：模型已有渠道绑定时只用绑定渠道，都不可用直接 503 no_channel，不再
把请求发给不认识它的渠道；新增运行期健康（连续 3 次网络错误/超时/429/5xx
进 30s 冷却，成功清零），与 60s 一次的 /models 探测互补。
- 密钥 API：PATCH 回显更新后的完整对象；限额填 0 统一视为不限制（原来
token 配额存 0 会让密钥第一次请求就被 429 打死，而请求配额存 0 又等于
不限制，两个字段语义相反）；前端编辑框总是提交白名单，清空能真的取消。
测试：新增 proxy 链路集成测试（超时生效、流式不被截断、断连取消并记账、
密钥白名单 403、连续 429 后候选剔除）与 channel 用例（绑定模型不退全局、
冷却阈值与到期恢复、成功清零）。
|
2026-10-16 19:15:51 +08:00 |
|
 SakurasanandClaude
|
4d4d09ba58
|
渠道: 模型名称映射(网关生效 + 渠道侧管理)
- 候选渠道携带 upstream_model, prepareUpstream 改写请求体 model 字段为上游名
- 新增渠道视角绑定 CRUD: GET/POST/PATCH/DELETE /admin/channels/:id/models
- 前端渠道页新增"模型映射": 列出绑定、内联改上游名、解除、添加
- rewriteModel 三种协议通用(model 均在顶层)
Co-Authored-By: Claude <noreply@anthropic.com>
|
2026-08-16 00:09:01 +08:00 |
|
|
SakurasanandClaude
|
0637ce0a51
|
M5: 渠道体系(负载均衡+并发控制+健康检查+故障转移)
- channel.Candidates 按模型绑定取候选 + Pick 加权随机负载均衡
- TryAcquire 每渠道并发信号量, 满载溢出到其他候选
- HealthMonitor 后台定时探测, 连续失败进 cooldown, 恢复放回(可配 interval/threshold)
- doProxy 遍历候选故障转移: 网络错误/429/5xx/超时且未写出响应头时安全重试;
400 等业务错误透传, 流式写出首字节后放弃重试
- 单测覆盖候选过滤/加权/并发/健康状态机
- E2E: 杀上游自动切换、cooldown、恢复、并发溢出 10/10
Co-Authored-By: Claude <noreply@anthropic.com>
|
2026-08-15 15:57:48 +08:00 |
|