Feature Proposal: Use open-next-router (ONR) as routing core

[onewesong]

背景

one-api 已经是非常好用的统一网关。这里提一个架构层建议：

是否考虑将 open-next-router (ONR) 作为可选路由内核（routing core）？

为什么值得考虑

1) 配置驱动、原子更新

ONR 受 Nginx 的原子配置理念启发，核心能力通过配置文件声明而不是复杂代码改动。

• 路由策略、通道接入、权重/回退可配置化
• 发布/回滚路径更清晰
• 对运维和灰度更友好

2) 多模型通道接入成本更低

ONR 强调“通过简单配置接入多样模型渠道”，这和 one-api 的目标高度一致。

• 新 provider 接入更标准化
• 减少适配层重复代码
• 对社区贡献者更友好（更易 PR）

3) 路由能力更容易扩展

作为独立 routing core，ONR 模块化后可更快演进：

• 负载均衡 / 健康检查 / 失败切换
• 按模型能力或成本做策略分流
• 按租户/场景细粒度路由

4) 降低 one-api 主仓复杂度

将“复杂路由逻辑”与“网关管理能力”适度解耦，可以减少主仓心智负担。

建议的落地方式（低风险）

1. 先做可选后端（optional backend），保持当前路由实现不变
2. 增加开关：ROUTER_ENGINE=legacy|onr
3. 先支持最小能力集：基础转发 + 回退 + 权重
4. 逐步灰度，收集性能和稳定性指标后再扩面

参考

• ONR: https://github.com/r9s-ai/open-next-router

如果你们愿意，我也可以帮忙整理一份更具体的 PoC 接入草案（接口边界、配置映射、迁移路径）。

[onewesong]

补一个可落地的 PoC 草案（尽量低风险，不破坏现有行为）：

PoC 目标

在不改现有默认路由逻辑的前提下，引入 ONR 作为可选路由引擎。

1) 接口边界（one-api ↔ ONR）

• one-api 继续负责：鉴权、配额、计费、用户/渠道管理、审计日志
• ONR 负责：模型路由决策（权重/回退/健康检查/策略分流）
• one-api -> ONR 透传最小上下文：model, provider_preference, tenant, request_tags, timeout_budget_ms
• ONR 返回：chosen_upstream, retry_plan, policy_trace（可选）

2) 配置映射（建议）

• one-api 渠道配置映射到 ONR channel/provider 配置
• one-api 的模型别名映射到 ONR route rules
• 增加单开关：ROUTER_ENGINE=legacy|onr（默认 legacy）

3) 最小能力集（MVP）

仅做三件事：

1. 基础转发（按模型路由）
2. 加权负载均衡
3. 失败回退（单次/有限重试）

4) 迁移策略

• Phase A: shadow 模式（只做决策对比，不真正转发）
• Phase B: 小流量灰度（如 1%-5%）
• Phase C: 指定租户/模型切换 ONR
• 全程可一键回滚到 legacy

5) 验收指标

• 路由成功率 / 5xx 率 / P95 延迟
• 回退命中率
• 与 legacy 的结果一致性（shadow 阶段）

如果维护者认可这个方向，我可以再补一版“具体配置样例 + 最小代码改动点（入口文件/抽象接口）”。