mirrors2/openteam
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
111 Commits 2 Branches 0 Tags
5d6e5bdb045240764e04b0229f10c7d225f77c18
Commit Graph
14 Commits
Author SHA1 Message Date
Sakurasan 531a03c836 perf: 流式错误判定预过滤、再减一个写索引，加可选明细保留期 
- 流式放行前的上游错误判定加廉价子串预过滤（"error" / response.failed）：
  长思考阶段几十上百条事件不再逐条 json.Unmarshal。
- usage_logs 去掉 idx_channel_created：没有任何查询按 channel_id 过滤该表
  （渠道统计走 created_at 时间窗后在内存分组），复合索引只是每行一次多余的
  B-tree 插入；schema v9 迁移里显式 DROP 旧库索引。至此该表只剩
  (user_id, created_at)、created_at 两个真被用到的索引。
- 新增可选保留期（OT_USAGE_RETENTION_DAYS，默认 0=永久保留）：每天分批
  （2000 行/批、批间 50ms）清理过期 usage_logs，避免长期运行后时间窗查询
  与备份随表增长变慢；余额流水 balance_logs 不在清理范围。

参数复测（记账稳态吞吐，3 次取中位）：
- batch 64（当前）30.2k rows/s；batch 128 19.0k、batch 256 14.3k（更差，保持 64）
- wal_autocheckpoint(4000)、cache_size(-64MB) 与当前配置无差别，不引入

验证：go vet、go test ./...、-race（usage/proxy/store）全绿；新增保留期三项测试
（只删明细不动流水、未开启不动数据、跨分批删完）。
 2026-10-30 16:45:57 +08:00
Sakurasan 8e5fe16611 perf: 鉴权缓存让命中请求零 SQL，去掉两个无用索引 
profile（16 并发）显示请求路径的 CPU 有 ~70% 花在鉴权上：每个代理请求都要用
密钥哈希查 api_keys、再用 user_id 查 users，两条随机读。

- 新增鉴权缓存（OT_PROXY_AUTH_CACHE_TTL，默认 2s，0=关闭）：缓存密钥与用户行，
  但密钥状态、用户状态、密钥过期仍按当前时间逐请求判定；管理端写操作与用户的
  密钥写操作经中间件立即清空缓存。余额随用户行一起缓存，只影响「≤0 就 402」
  这道软闸，最长滞后一个 TTL（请求照样计费）。
- last_used_at 节流改由缓存内的 touch 表记账（原先按 DB 行时间戳判断，行被缓存后
  时间戳不再变化，会导致每请求都写一次库）。touch 用 sync.Map：早先与缓存共用一把
  排他锁，16 并发下互斥饥饿把吞吐从 31k 拖到 3.2k（p99 7ms），换 sync.Map 后消失。
- 去掉 usage_logs 上从未被查询过滤的 key_id / trace_id 索引（没有查询按它们过滤，
  每个索引都是每行一次 B-tree 插入）；schema v8 迁移里显式 DROP 旧库上的索引。

实测（16 并发、mock 上游、SQLite）：
- 鉴权缓存开：p50 131–177µs、p99 0.6–1.2ms、RPS 56k–81k
- 鉴权缓存关：p50 535–631µs、p99 1.6–2.8ms、RPS 21k–27k
（4 并发下同样受益：30k→41k）

测试：新增缓存命中零 SQL、状态/过期重判、失效、TTL 到期、缓存关闭、并发七项；
go vet、go test ./...、-race（proxy/usage/store/api）全绿。
 2026-10-30 16:31:41 +08:00
Sakurasan 117e03673b perf(sqlite): 写事务改 immediate + synchronous=NORMAL，单 worker 批 64 
上一轮发现「多 worker 在 SQLite 上更慢」，这轮把它当成一个可调优问题重新测：

基准（2000 条记账、暖机后跑稳态，同一台机器反复 3 次取分布）：
- 默认 deferred 事务 + batch 32：11k–20k rows/s，抖动极大（并发写升级锁失败触发
  SQLITE_BUSY 重试，这正是之前 p99 飙到 19–34ms 的原因）
- _txlock=immediate + batch 32：28.2–28.5k rows/s，抖动收敛
- _txlock=immediate + batch 64 + synchronous=NORMAL：29.7–30.1k rows/s，波动 <1%
- 同样配置下 2 个 worker：7.7k–16.7k，仍更差（SQLite 只有一个写者）

因此：
- store.withSQLitePragmas 增加 _txlock=immediate 与 _pragma=synchronous(NORMAL)；
  immediate 让写事务在 BEGIN 就取写锁，消除升级冲突；NORMAL 是 WAL 下的标准配置，
  提交不再逐次 fsync（代价：断电可能丢最后一个事务，已在注释里写明）。
- 记账批大小按驱动区分：SQLite 单 worker 用 64，PG 保持 32。
- 保持 SQLite 单 worker（数据不支持多 worker）。

端到端复测（16 并发、mock 上游）：p50 649µs→548µs、p99 2.32ms→1.60ms、
RPS 21.2k→24.9k；对比本轮开始前的 18.7k/2.2ms 亦有改善。

验证：go vet、go test ./...、go test -race（usage/proxy/store）全绿。
 2026-10-30 16:08:55 +08:00
Sakurasan 8c12207478 perf: 目录缓存与流式正文快路径，请求热路径开销减半 
按性能分析逐项落地，实测对比（16 并发、mock 上游零延迟、SQLite）：

- 每请求 SQL 10 → 2：模型/渠道目录（模型行、绑定、渠道行）进程内缓存 10s，
  运行期状态（冷却、健康）仍每次实时判定；管理端写操作经中间件、
  健康状态变化经回调立即失效。新增 TestProxyRequestSQLBudget 钉住预算。
- 端到端 p50 1.3–1.6ms → 0.66–0.70ms，RPS 3.5–8.9k → 16–18k。
- 流式正文累积：字符串 += 改 strings.Builder（原为 O(n²)），
  逐行 JSON 提取改字节快路径，并加廉价的子串预过滤、拿到输出 usage 后停累积。
  500 块：949µs/7.9MB 分配 → 83µs/136KB。
- 请求体定点改写：模型映射从整包 unmarshal/marshal 改为顶层字段替换
  （100KB：585µs → 29µs），stream_options 注入同理；requestText 改为
  只在「上游没报用量」时按需提取，亲和键改用原始体前缀。
- 渠道满载背压：新增 Acquire 有界排队（OT_PROXY_CHANNEL_ACQUIRE_WAIT，
  默认 150ms）；排队仍满时返回 503 + Retry-After 而不是 502。
  实测渠道上限 4、16 并发：无排队 81 次 503；排队 150ms 后 400/400 成功。
- 记账按批聚合：同批同用户一次扣款、流水批量插入、日表按 (user,model,日期)
  聚合，替代每行 5 条语句；幂等仍靠 ref_id 唯一索引兜底。
- gorm 开启 PrepareStmt（SQL 解析此前占 CPU 15%）；tiktoken 编码器按模型复用。
- 管理端用量列表不再返回原始请求/响应体（可能几十 MB），
  改为 has_raw 标记 + GET /admin/usage/:id 按需拉取，前端弹窗打开时取。

验证：go vet、go test ./...、go test -race（proxy/channel/usage/tokenizer）、
vue-tsc、eslint、vite build 全绿；本地起 mock 上游实测列表/详情接口与
管理页弹窗按需加载。
 2026-10-30 14:14:21 +08:00
Sakurasan 04dfb4285d feat: 会话亲和粘住缓存渠道；透传 opaque 字段；用量记思考/1h 缓存写/实际模型 
会话亲和（proxy/affinity.go）：同一会话粘住上次应答的渠道，命中上游提示词
缓存而非被加权随机打散后全价重算。会话身份 = 密钥 + 模型 + 请求文本稳定前缀
摘要，不依赖各客户端会话头；TTL 默认 5m（OT_PROXY_AFFINITY_TTL，0=关闭），
成功应答刷新。亲和渠道必须在候选集内（健康/未冷却/绑定），否则回退加权随机。
proxyOne 增加 served 返回值区分「应答成功」与「已终结但失败」。

opaque 透传（convert）：chat↔responses 互转原样携带 metadata、service_tier、
parallel_tool_calls。此前逐字段重建请求体会丢它们，而中转上游会校验/使用。

用量细化（proxy+store）：usage_logs 新增 reasoning_tokens（展示口径，不重复
计费）、cache_write_1h_tokens（Anthropic 1h 缓存写按 2× 输入价，此前统一
1.25× 少算 60%）、served_model（上游实际应答模型，映射/聚合商场景对账）。
schema v6→v7。

验证：go vet ./... 干净；go test ./... 与 go test -race ./... 全绿；
新增测试覆盖亲和粘性与冷却回退、opaque 双向透传、reasoning 不重复计费、
1h/5m 缓存写分开计价、served_model 提取（非流式与流式）。
 2026-10-30 11:41:51 +08:00
Sakurasan 1f8af649ca fix: 收尾 P2——登录恒定耗时、AdminUsage N+1、用量索引重塑与时区缝 
- 登录失败路径补 argon2 恒定耗时校验（用户不存在/被禁用与密码错误的时序不可区分，抹掉用户名枚举面）
- AdminUsage 每行 2 次查询改批量预取（100 行分页省 200 次查询）
- usage_logs 补 key_id 索引与 (user,created)/(channel,created) 复合索引（schema v6）；AutoMigrate 按名跳过已存在索引，旧库的复合索引需一次性删掉重建，用 system_configs 打标记防 PG 每次启动重演
- 用量统计默认窗口改 UTC（usage_daily 的 date 键是 UTC，非 UTC 服务器上图表窗口偏移一天）
- 注册 email 大小写归一；并发撞唯一索引回查后返回 409 而非 500
- PatchKey 的 name 校验与 CreateKey 对齐（1-64 字符），PATCH 不再能绕过
- TrendChart 条宽不超过槽位（点数多时不再互相重叠），超过 32 个点隐藏标签行
 2026-10-29 03:05:56 +08:00
Sakurasan e3ff0d3329 security: 会话可撤销与认证面加固 
- users 加 token_version（schema v4）：改密/登出递增，该用户全部已发 access/refresh 立即作废；refresh 改轮换式换发新 cookie
- 邀请码改精确匹配 + 注册成功后消费（一码一用），修复子串匹配让任意后缀放行、可无限薅体验金
- 生产校验拦下 .env.example 占位密钥；OT_ENV 枚举校验（拼错不再静默跳过断言）；生产强制 COOKIE_SECURE；非 development 拒绝默认密码播种管理员
- WebAuthn 会话启用过期校验 + 4096 容量上限（未认证 login/begin 可无限撑爆内存），begin/complete 挂登录级限速
- /api/v1 挂 1MB 请求体上限；login 先限 IP 桶再解析 body；全局安全响应头 + CSP
- 连接池配置（PG 30/SQLite 8）；SQLite DSN 自动追加 WAL + busy_timeout（驱动只认 _pragma，旧注释的 _journal_mode 写法不生效）
 2026-10-29 02:56:46 +08:00
Sakurasan 7c597a6aa0 fix: 补上漏掉的 schema 版本号，修好渠道添加模型失败 
c39c3e7 给 Model 加了 cache_write_price/context_length/supports_* 等列
但没递增 schemaVersion，user_version>=2 的库直接跳过 AutoMigrate，
models 表缺新列导致 Create 失败、渠道管理添加模型报缺列错误。
bump 到 3 触发一次迁移补齐列。
 2026-10-28 15:40:03 +08:00
Sakurasan 6d951a0d61 fix: sync schemaVersion to 2 matching production 2026-08-31 18:16:19 +08:00
Sakurasan 1f5f60e905 fix: move timeout migration outside schema version check 2026-08-31 18:01:33 +08:00
Sakurasan c6a4fcfbbc fix: migrate existing channels timeout_ms to 300000 2026-08-31 17:47:52 +08:00
Sakurasan 658a9cb580 fix: SQLite 迁移加版本锁，消除每次启动全量重建表 
GORM sqlite AutoMigrate 对已有表判定不收敛（实测已迁移库再跑
仍触发 12 次表重建），SQLite 无在线 ALTER，每次重建走
CREATE __temp + INSERT SELECT + DROP 全表拷贝；usage_logs 含
raw_request/raw_response 大文本，一轮 40~80s，生产每次重启
重演导致启动数分钟。

- 新增 schemaVersion 常量，PRAGMA user_version 记录已迁移版本
- 版本达标跳过 AutoMigrate 秒开；旧库首次升级迁移一次写版本
- postgres 不受影响（支持 ALTER，保持原行为）
- 维护约定：改表结构须递增 schemaVersion
 2026-08-29 12:46:52 +08:00
SakurasanandClaude ec4de8d913 M0-M4: 推倒重来基线(基建+用户/密钥/核心代理+前端+管理后台+三协议互转) 
- 后端 Go+Gin+GORM: 配置(OT_ env)/SQLite/Postgres 双驱动、用户体系(argon2id+JWT access/refresh)、
  API Key(sk- 48位, 仅存 SHA-256 哈希)
- 代理网关: /v1/chat/completions、/v1/responses、/v1/messages、/v1/models;错误按客户端协议返回
- 三协议互转(convert 包): Chat↔Messages↔Responses 请求/响应 + 流式 SSE 逐事件转换(直通优先)
- 用量计费: 异步批量记账、余额扣减、balance_logs、usage_daily 日聚合
- 管理 API: 用户/渠道 CRUD+测试+模型导入/模型定价+绑定/统计/系统配置
- 前端 Vue3+TS+Tailwind(taste-skill 设计 tokens): Landing/登录注册/控制台/管理后台,
  自建组件+Phosphor 图标+自建 SVG 趋势图, 已过 web-design-guidelines 复查
- mock 上游: OpenAI+Anthropic 双协议模拟(含流式)

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-08-15 15:34:06 +08:00
Sakurasan 360c6b33a6 M0+M1: 基建 + 用户/密钥/核心代理 
后端 (Go/Gin/GORM):
- 配置(viper+env)、SQLite/Postgres 迁移、argon2id、AES-GCM 渠道密钥、JWT+refresh cookie
- 用户注册/登录/刷新/登出、API Key CRUD(仅存哈希、明文一次展示)
- 代理网关: /v1/chat/completions、/v1/responses、/v1/models 直通 OpenAI 渠道
  非流式+流式(SSE 零缓冲转发), 用量捕获(chat 末块/responses completed 嵌套),
  OpenAI 错误格式(401/402/404/502), 余额检查
- 异步批量记账 + 余额流水 + 日聚合, admin 用户/余额/配置 API
- 单测: crypto/jwt/apikey/流式 usage 提取

前端 (Vue3+TS+Vite+Tailwind v4):
- taste-skill 设计 tokens: 深色仪表盘, 石墨+信号铜色, Outfit+JetBrains Mono
- Landing/登录/注册, 控制台(仪表盘图表/密钥管理/用量明细)
- 基础组件 Button/Input/Badge/Modal, ECharts 用量图

部署: docker-compose(nginx+api+postgres), 双 Dockerfile, nginx SSE 反代
联调: scripts/mockupstream 本地 mock 上游, 端到端验证通过
 2026-08-15 13:10:47 +08:00