AI 网关实战（一）：参考 OpenAI 架构，从零设计企业级 AI 网关
Spring AI Alibaba 实战系列番外篇。完整记录从架构设计到代码实现的全部过程。 本文是「AI 网关实战」系列第 1 篇。
目录
一、为什么要自己搭 AI 网关？
AI 网关、Spring AI Alibaba、企业级 AI 系统架构——这三个关键词，是我做完 AI 客服系统之后反复思考的问题。
做完那个项目回头看，发现一个严重的问题：客服系统里混进了一堆不该它管的事。
1.1 问题：业务系统里塞了一堆非业务功能
AI 客服系统的核心业务是什么？多轮对话、意图识别、Agent 工具链、RAG 知识库检索——这些才是业务层该关心的事。
但实际代码里，还躺着这些：
AiCustomerService/
├── auth/ ← JWT 鉴权，跟"客服"没关系
├── ratelimit/ ← 限流，跟"客服"没关系
├── compliance/ ← 敏感词过滤，跟"客服"没关系
├── audit/ ← 审计日志，跟"客服"没关系
└── chat/ ← 这才是业务
每加一个 AI 能力，这些横切关注点就要重新写一遍。认证写一次、限流写一次、合规过滤写一次——客服系统、内容生成系统、数据分析系统，每个系统都在重复造轮子。
更麻烦的是：这些功能和业务无关，但直接影响系统安全性。密钥怎么存、Token 怎么校验、审计日志怎么不可篡改，每个系统实现都不一样，隐患很大。
1.2 解决思路：把网关从业务层剥离出来
思路其实很直接：
这些功能不该属于某个业务系统，它们属于"AI 能力接入"这个层。
把认证、限流、合规、审计、渠道路由这些事情，统一收到一个独立的网关里：
业务系统（客服、内容生成、数据分析...）
↓ 只调一个接口
AI 网关（本项目）
↓ 路由到
OpenAI / 通义千问 / 智谱 / ...
业务系统从此只需要关心一件事：调 POST /v1/chat/completions，拿到响应，处理业务。
网关负责剩下所有事：
- 你是谁（认证）
- 你能调多少次（限流）
- 你发的内容合规吗（过滤）
- 这次调用花了多少钱（审计）
- 哪家供应商可用、优先级谁高（路由）
1.3 顺带解决：各家供应商接口不统一
接了通义千问，后来要接智谱 GLM，发现接口格式完全不一样：
通义千问：POST /api/v1/services/aigc/text-generation/generation
智谱 GLM：POST /paas/v4/chat/completions
OpenAI： POST /v1/chat/completions
有了网关，业务系统只认 OpenAI 兼容格式，差异全部在网关内部通过适配器抹平。
二、业界是怎么做的？
OpenAI 网关架构、AI 服务统一接入——这些是大厂一直在做的事。
OpenAI 自己有一套完整的网关架构，所有请求都经过统一接入层：
客户端请求
→ 认证（API Key / OAuth）
→ 限流（Rate Limit）
→ 合规检查（内容过滤）
→ 路由到对应模型
→ 返回响应
这套东西大厂有团队专门维护，但中小企业没有这个资源。
我们的目标就是：用 Spring Boot 搭一套够用、可维护、符合国内合规要求的 AI 网关。
三、我们的网关长什么样
对照 OpenAI 的架构，结合银行场景的特殊要求，我设计了这 7 个模块：
| 模块 | 做什么 | 为什么需要 | 星级 |
|---|---|---|---|
| API 网关层 | 统一入口，兼容 OpenAI 格式 | 屏蔽下游差异，客户端只认一套接口 | ★★★★★ |
| 认证授权 | JWT 管理端 + API Key 应用端 | 不再把 Key 写死在前端 | ★★★★★ |
| 渠道路由 | 多供应商接入 + 故障转移 | 一家挂了自动切到另一家 | ★★★★★ |
| 合规过滤 | 敏感词 + 脱敏 + 风险提示 | 银行场景强制要求 | ★★★★ |
| 限流熔断 | 多层限流 + 熔断降级 | 控制成本，保护服务 | ★★★★ |
| 流式处理 | SSE 流式返回 | AI 对话必须流式，否则体验太差 | ★★★★★ |
| 审计日志 | 每一条请求可追溯 | 合规要求，不可篡改 | ★★★★★ |
★ 越多表示越核心，★☆ 是可选模块。系列后续会按星级顺序讲解，确保核心功能先上线。
四、这个网关不做什么
AI 网关架构设计里最难的决定，往往不是"做什么"，而是"不做什么"。
以下几个事情，明确不做：
| 不做的事 | 原因 |
|---|---|
| 知识库管理（RAG） | 这是应用层的事，网关只负责转发 |
| 对话场景管理 | 同上，网关不持有业务状态 |
| 复杂运营后台 | 管理功能做在独立后台，网关只暴露必要 API |
| 向量检索 | 不属于网关职责范围 |
网关的职责边界：AI 服务调用的统一代理 + 安全合规 + 稳定性保障。
守住边界，系统才不会越做越重。
五、这个系列会写什么
整个系列按照开发顺序来写，不是按模块编号：
第一部分：为什么 & 怎么设计（第 1~3 章）
- 第 1 章（本篇）：架构参考 + 整体设计思路
- 第 2 章：7 个模块详解 + 请求完整流转路径
- 第 3 章：技术选型——为什么是 Spring Boot 3 WebFlux + PostgreSQL + Redis
第二部分：从零搭建（第 4~5 章）
- 第 4 章：项目初始化、依赖配置、Docker Compose 一键启动
- 第 5 章：数据库设计（10 张表）+ 统一响应规范
第三部分：认证与密钥（第 6~7 章）
- 第 6 章：双认证体系（JWT 管理端 + API Key 应用端）
- 第 7 章：渠道密钥加密存储（AES-256-GCM，不能明文）
第四部分：核心网关能力（第 8~9 章）
- 第 8 章：OpenAI 兼容接口 + 渠道路由 + 故障转移
- 第 9 章：流式响应 + 多渠道适配器（6 家供应商）
第五部分：稳定性保障（第 10~11 章）
- 第 10 章：多层限流（全局 + Key + 模型三维度）
- 第 11 章：链路追踪 + 审计日志
第六部分：合规（第 12 章）
- 第 12 章：敏感词过滤 + 脱敏 + 风险提示
第七部分：上线（第 13 章）
- 第 13 章：开发排期 + 部署 + 踩坑总结
六、下一篇预告
第 2 章会详细讲解 7 个模块的设计细节，以及一个请求从进入到响应，在网关内部到底经过了什么。
我会把每个模块的星级（重要性）也标出来，方便你判断哪些可以先上线、哪些可以后补。
预计 5 月中旬发布。
七、关于源码和开发进度
这个项目的开发进度会在 GitHub 上持续更新，每一章对应的代码推进都会留下提交记录，你可以随时看到项目从零到一的完整过程。
GitHub 地址：github.com/ynzz-j/bank…
完整源码计划在完成最新 MVP 版本后，统一上传到 Gitee，届时会在文章和公众号同步通知，欢迎 Star 和提 Issue。
系列进度
| 章 | 主题 | 状态 |
|---|---|---|
| 01 | 参考 OpenAI 架构，设计企业级 AI 网关（本篇） | ✅ 已发 |
| 02 | 7 个模块详解 + 请求完整流转路径 | 📝 计划中 |
| 03 | 技术选型：为什么是这套栈 | 📝 计划中 |
| 04 | 项目初始化 + Docker Compose 一键启动 | 📝 计划中 |
| ... | ... | ... |
🔔 关注有价值
如果这篇文章帮到了你，欢迎 关注「亦暖筑序」。
我正在系统更新「项目实战指南」系列——AI 网关实战，从架构设计到代码实现，全部开源记录：
- ✅ 已发：AI 客服系统全栈实战（第 1~4 篇）
- 🔧 下一篇：《AI 网关实战（二）：7 个模块详解 + 请求完整流转路径》（预计 5 月中旬）
- 🐙 开发进度在 GitHub 持续更新：github.com/ynzz-j/bank…
- 📦 完成最新 MVP 后，完整源码统一上传 Gitee，关注不迷路
参考资料：完整架构设计文档含 10 张数据库表设计、API 接口规范、安全设计、合规过滤设计、限流设计、技术栈与依赖、项目结构、代码规范、开发排期等完整内容，可在公众号「亦暖筑序」内回复“AI网关”获取。
