Architecture · Production

ApiMimo 生产请求链路

本文说明公网请求如何经过 Caddy、Identity Gateway、NewAPI41、session-router、Bifrost、NewAPI02、Guard / CLIProxy，最终到达供应商，以及异常时如何回退到 bf-pool。 站点由 Caddy 原生 file_server 托管，不新增 Node / Python 常驻进程。

文档域名doc.apimimo.zaiyunding.com
现网主机35 · 209.209.51.35
托管方式Caddy file_server
链路验证完整请求 200

完整架构流程

完整链路应包含 NewAPI02 后面的实际上游，而不是停在 NewAPI02。

公网客户端→ Caddy→ Identity Gateway→ NewAPI41→ session-router→ Bifrost v1.5.16→ cache-01 … cache-10→ NewAPI02→ Guard / CLIProxy→ 供应商 / 模型上游→ 原路返回 
公网客户端
  -> Caddy
  -> Identity Gateway
  -> NewAPI41 鉴权/配额/模型映射
  -> session-router（HMAC 校验、bucket 选择）
  -> Bifrost v1.5.16
  -> cache-01 ... cache-10 provider/key
  -> NewAPI02 对应 cache group/channel
  -> Guard / CLIProxy
  -> 供应商或模型上游
  -> 原路返回
bf-pool 是异常时的回退路径。10 个 bucket 是 Bifrost 内部的 10 个隔离 provider，不是 10 个 Bifrost 容器。NewAPI41 仍负责用户鉴权、配额和模型映射。

逐层说明

01

公网客户端

使用自己的 API key 请求 OpenAI-compatible 或 Anthropic-compatible 接口，例如：

/v1/chat/completions
/v1/messages
02

Caddy

负责公网入口：

  • HTTPS / TLS 终止
  • 域名路由
  • 反向代理到 Identity Gateway
  • 不负责模型鉴权和 bucket 选择
03

Identity Gateway

负责把用户 API key 转换成可信身份：

  • 读取 NewAPI41 的 token 数据
  • 确认 token 有效且未过期
  • 生成 account_id 和 conversation_id
  • 用 HMAC 签名
  • 删除客户端伪造的身份头
  • 将可信身份头转发给 NewAPI41

它不负责额度、权限或模型访问控制。

04

NewAPI41

用户策略控制层：

  • 验证 API key
  • 检查用户额度
  • 检查模型权限
  • 执行模型别名和模型映射
  • 选择 77 号生产渠道
  • 保留请求计费和审计能力

例如用户请求 mimo-v2.6-flash，NewAPI41 可能映射为内部的 newapi02/mimo-v2.6-flash。

05

session-router

会话亲和路由层：

  • 验证 Identity Gateway 的 HMAC
  • 根据用户和会话计算稳定 hash
  • 从 cache-01 到 cache-10 中选择 bucket
  • Redis 保存会话与 bucket 的映射
  • bucket 故障时执行备用迁移
  • 将模型改写为类似 cache-07/mimo-v2.6-flash

如果身份无效、Redis 不可用或路由器关闭，则回退到 bf-pool。

06

Bifrost v1.5.16

provider / key 适配层：

  • 根据 cache-07/... 识别 bucket
  • 选择对应的虚拟 provider
  • 使用该 bucket 专属的 NewAPI02 key
  • 处理 OpenAI-compatible 请求格式
  • 将响应统一返回给上游

当前是一个 Bifrost 进程，内部配置了 10 个隔离 provider，不是 10 个 Bifrost 容器。

07

NewAPI02

上游渠道控制层：

  • 接收 Bifrost 使用的 cache key
  • 根据 key 所属 group 选择对应 channel
  • 管理每个 bucket 的主渠道和备用渠道
  • 控制渠道状态、权重、优先级和模型权限
  • 继续负责渠道级别的计费和失败处理
08

Guard / CLIProxy

实际的上游执行层：

  • Guard 负责健康检查、熔断、inflight 和故障状态
  • CLIProxy 负责具体协议转换、代理和上游连接
  • 处理供应商认证、重试和实际模型调用
09

供应商或模型上游

最终执行模型推理并返回结果。当前可以验证请求成功和路由稳定，但因为供应商没有提供可靠的 cache token 指标，暂时不能证明缓存节省比例。

请求生命周期

正向路径

公网客户端
→ Caddy
→ Identity Gateway
→ NewAPI41
→ session-router
→ Bifrost
→ cache bucket
→ NewAPI02
→ Guard / CLIProxy
→ 供应商

返回路径

响应按相反方向返回：

供应商
→ CLIProxy / Guard
→ NewAPI02
→ Bifrost
→ session-router
→ NewAPI41
→ Identity Gateway
→ Caddy
→ 用户

bf-pool 回滚机制

bf-pool 不参与正常 bucket 分流，但始终保留：

核心分工

Caddy              公网入口
Identity Gateway   可信身份
NewAPI41           用户权限与配额
session-router     会话亲和
Bifrost            provider/key 适配
NewAPI02           渠道控制
Guard/CLIProxy     实际代理与故障保护
供应商             最终模型执行
bf-pool            紧急回滚

当前运行状态