夜雨聆风近期有很多伙伴社区或私下问过我如何快速构建一个AI网关，类似替代NewAPI实现完全自己可控的办法，本文为一套原生自主搭建的AI网关技术解决方案分享给大家，大家可以拿来作参考，有建议也可以评论区评论。
一、目标
目标：自研一套完全独立的AI API网关系统，替代NewAPI。所有鉴权、权限、安全能力均自研，不依赖任何外部平台。
核心定位：AI模型调用的统一接入层，提供多模型代理、API Key管理、配额限流、用量统计、安全审计等全套能力。
二、整体架构
核心组件说明
组件 | 职责 |
Nginx/NLB | 入口流量分发，SSL/TLS卸载，IP访问控制 |
API Gateway Service | 核心代理服务，执行中间件链（Go + Gin） |
Key Manager | 自研API Key 生成/校验/配额管理，数据存Mysql |
Auth 模块 | API Key 身份认证 + 模型权限校验 |
Rate Limiter 模块 | 基于Redis 的RPM/TPM 限流 |
Channel Router 模块 | 多渠道路由、负载均衡、Failover |
AuditLogger模块 | 异步审计日志写 Kafka |
Redis Cluster | 限流计数、Token配额实时扣减、热点缓存 |
MySQL | API Key、渠道配置、用量记录持久化 |
Kafka | 审计日志异步罗盘 |
Nacos/etcd/zookeeper | 服务注册与发现，多实例动态路由 |
Admin Dashboard | Web 管理后台（渠道/Key/报表） |
三、请求处理流程
3.1 标准请求时序
3.2 中间件处理链
请求进入 Nginx--> TLS 卸载 + IP 黑白名单过滤（Nginx层）--> API Key 身份认证（自研Auth模块，查Mysql/Redis缓存）--> 模型权限校验（Key剩余 Token是否充足）--> 限流（RPM/TPM，基于Redis，Key级别 + 全局级别）--> 渠道路由（加权负载均衡 + 健康检查 Failover）--> 上游代理转发（含SSE流式）--> 异步审计日志（写Kafka）--> 异步扣减Token配额（写Redis + MySQL）--> 返回客户端
3.3 渠道Failover流程
四、安全设计
第一层：网络层（Nginx）
HTTPS/TLS 强制加密 IP 黑白名单（Nginx allow/deny） 请求大小限制、慢速请求防御
第二层：应用层（自研Auth模块）
API Key HMAC 签名校验 KEY 与可用模型绑定 Key 有效期控制 配额实时校验 异常访问检测（短时间大量失败请求自动封禁）
4.1 API Key体系
API Key由网关Admin后台统一生成管理，无需对接外部平台 Key格式：sk-{base62随机串} （与OpenAI格式兼容） Key 存储：MySQL（主存储）+ Redis（校验热缓存、TTL5分钟） Key 属性：名称、绑定用户、可用模型列表、Token配额、有效期、状态
4.2 权限校验流程
4.3 限流策略
维度 | 策略 | 存储 |
API Key 级别 | RPM/TPM 独立限流 | Redis（滑动窗口） |
全局渠道限流 | 上游API总QPS保护 | Redis |
模型级别 | 单模型并发控制 | Redis |
IP级别 | 异常IP自动封禁 | Redis + Nginx |
五、多模型渠道管理
5.1 支持的上游提供商
类型 | 提供商 | 协议 |
海外模型 | OpenAI、Anthropic Claude、Google Gemini | HTTPS REST |
国内模型 | 阿里通义、百度文心、字节豆包、腾讯混元 | HTTPS REST |
私有部署 | 内部自建模型 |
5.2 渠道注册结构
字段 | 说明 |
channel_name | 渠道名称(唯一) |
type | 提供商类型(OpenAI/Anthropic/custom...) |
base_url | 上游API地址 |
api_key | 上游API Key(AES-256加密存储) |
models | 支持的模型列表 |
weight | 负载均衡权重 |
priority | 故障转移优先级 |
timeout | 超时时间(默认30s) |
rate_limit | 上游调用速率限制 |
status | 启用/禁用/故障 |
5.3 模型路由策略
客户端请求 model=gpt-4o---> 路由表查找：gpt-4o --> [渠道A（权重3），渠道B（权重1）]---> 加权随机选择 --> 渠道A---> 渠道A 健康？ --是--> 转发--否--> 自动切换渠道B（Failover）
5.4 数据库设计
主要表说明
表明 | 说明 | 关键字段 |
channels | 上游渠道配置 | name,type,base_url,weight,status |
tokens | API Key 信息 | key_hash,user_id,quota,user_quota,models |
logs | 请求用量记录 | token_id,channel_id,model,prompt_tokens,completion_tokens,cost |
users | 管理员账户 | username,role,passwd_hash |
model_prices | 模型单价配置 | model_name,input_price,output_price |
七、部署架构
7.1 基础设施清单
组件 | 国内 | 海外 |
Gateway Service | 2副本 （腾讯/阿里 托管K8s） | 2副本（AWS EKS） |
MySQL | 主从集群 | 主从集群 |
Redis | Redis Cluster | Redis Cluster |
Nacos/etcd/Zookeeper | 独立集群 | 独立集群 |
Kafka | 独立集群（审计日志） | 独立集群 |
Nginx/负载均衡 | 阿里SLB/腾讯CLB + 七层域名 | AWS-NLB + 七层域名 |
7.2 网络隔离
国内/海外数据库完全隔离，数据不跨境
服务间通信VPC内网
外部访问统一经Nginx + TLS，不依赖外部安全网关
八、项目排期
假设投入：2名后端（Go） + 1名前端 + 0.5名运维
九、技术选型
方向 | 选型 | 理由 |
后端语言 | Go | 高并发低延迟，适合代理场景 |
Web框架 | Gin | 轻量高性能 |
服务发现 | Nacos/etcd | 多实例动态路由 |
消息队列 | Kafka | 审计日志异步写入，稳定性高 |
缓存/限流 | Redis Cluster | 滑动窗口限流、配额热缓存 |
数据库 | MySQL 8.0 | 成熟稳定 |
前端 | React + Ant Design Pro | 管理后台快速开发 |
容器化 | Docker + K8S | 建议选择成熟第三方云厂商托管，如AWS、阿里云、腾讯云 |
监控 | Prometheus + Grafana | 指标采集可视化 |
网关入口 | Nginx | TLS卸载、IP控制、完全自主管理 |
十、风险与建议
风险 | 说明 | 缓解措施 |
SSE流式代理复杂度 | 断流、超时、背压处理 | 阶段一MVP重点投入、充分测试 |
上游API格式差异 | 各厂商协议不 | 统一Adpter层，每家厂商单独适配 |
自研鉴权安全性 | 独立实现需防止Key泄露 | HTTPS强制、Key哈希存储、Redis短期缓存 |
数据迁移风险 | Key/配额迁移可能影响用户 | 灰度切流+双写过渡期 |
海外合规 | 跨境数据传输请求 | 国内/海外数据完全隔离 |
