Lazy loaded image
gateway
LLM Access Gateway：项目导读
Words 2269Read Time≈ 6 min
2026-4-1
2026-4-4
type
Post
status
Published
date
Apr 1, 2026
slug
gateway
summary
tags
gateway
category
icon
password

我为什么做这个项目?

这个项目是为了证明,我能围绕模型服务构建一个治理型接入层
我把这个项目定义为一个面向多租户模型服务的接入与治理网关

执行摘要

这个项目的核心目标有三个：
  1. 把“模型服务接入”从一个零散的调用问题，收敛成一个有清晰边界的系统问题。
  1. 把“能跑”的 demo，推进成一个可部署、可观测、可压测的治理型网关。
  1. 把整个实现过程拆成一组可复现、可评审、可交叉验证的工程证据，而不是一篇泛泛的项目总结。
如果你只想快速判断这个项目值不值得继续看，可以先看这三点：
  • 边界：它解决的是模型服务的接入与治理，不解决训练、推理内核、算子优化。
  • 核心能力：统一接入、SSE 流式代理、多租户鉴权与配额、路由/重试/回退、可观测与交付。
  • 验证方式：我会用阶段性的验证文章来证明它，而不是只给一个“功能列表”。

一、为什么做这个项目

过去一段时间，我的学习和实践主线一直比较明确：
围绕 Dubbo、微服务治理、网关、流量路径、可观测性和稳定性 这些平台/基础设施后端问题去积累。
但当我积极去拥抱AI时，我发现一个很现实的问题：
很多所谓的“AI 项目”，本质上只是把模型接口接起来，再做一个聊天页面，最多加一层业务逻辑包装。
这类项目我也可以快速做出来，但它并不能很好地证明平台工程能力，也很难和我已经积累的 Dubbo / 网关 / 服务治理主线形成自然衔接。
于是我想把问题重新定义：
如果我想继续沿着平台基础设施后端这条线走，同时又想让项目进入 AI 方向，那么我最适合切入的层，到底是哪一层？
多番调研后我得到一个答案：模型服务接入与治理层。
它天然连接了我已经在做的事情和我想探索的方向：
  • 传统网关关心：统一入口、鉴权、限流、超时、重试、熔断、观测。
  • 模型服务接入层关心：统一 provider、流式代理、配额与成本、fallback、日志/指标、交付与演练。
从系统视角看，后者更像是前者在 AI 场景里的自然延伸。
所以，这个项目我想锻炼自己的能力：
把自己熟悉的流量治理与平台工程方法，迁移到模型服务接入这个新场景里。

二、这个项目到底解决什么问题

它解决的是：一个系统如何接住、治理和交付模型服务请求。
具体来说，我希望它覆盖下面几个真实工程痛点。

1. 多个模型服务的接口并不统一

不同 provider 可能有不同的 base URL、认证方式、模型名、错误语义和响应格式。
如果业务方直接对接每一个 provider，接入成本和维护成本都会快速上升。

2. 流式输出不是普通 HTTP 转发

模型服务很常见的调用方式是 SSE / chunked response。
这带来一系列普通 API 转发里不明显的问题：
  • 如何正确 flush chunk
  • 如何记录首包延迟（TTFT）
  • 如何处理 client disconnect
  • 如何区分“开始输出前失败”和“已经输出后失败”

3. 模型调用需要租户级治理

如果只是一个本地 demo，大家都用同一个 API Key，问题不大。
但一旦进入多租户场景，就会立刻出现：
  • 谁能调用哪些模型
  • 每个租户有多少预算
  • 是否要限制 RPM / TPM
  • token usage 怎么记录
  • 某个 key 被禁用后如何立即生效

4. 上游模型服务并不稳定

真实场景里，上游 provider 可能超时、5xx、局部不可用，或者单个实例抖动。
如果接入层没有 health check、retry、fallback 这些治理能力，调用链会非常脆弱。

5. “能跑”不等于“能维护”

一个项目本地跑通，只能说明它不是空壳。
但如果没有：
  • logs / metrics / traces
  • 结构化 access log
  • Docker 化
  • Kubernetes 部署
  • 压测与故障演练
那它离“像平台工程作品”还差得很远。
所以，这个项目真正要解决的，不是“怎么把请求发给模型”，而是：
怎么把模型服务接入这件事，收敛成一个可治理、可观测、可交付、可评审的系统。

三、系统边界

LLM Access Gateway 是位于应用与模型服务提供方之间的一层治理型接入网关。
它处在调用链上的位置，大致可以表示为：
在这条链路里：
  • Client / App 只关心统一调用入口
  • Provider 只负责实际执行模型请求
  • Gateway 负责把接入、治理、观测与交付这些横切能力集中起来
所以它的角色是“模型服务的代理层 / 控制面入口”。

四、模块拆分(快速浏览)

为了让边界更清晰，我把这个项目拆成 7 个模块。

1. API Gateway 层

这一层负责暴露统一对外入口。
第一阶段只做最核心的接口：
  • POST /v1/chat/completions
  • GET /v1/models
它的职责不是承载复杂业务，而是把请求收进来、做基础校验、生成 request id，并把后续治理链路串起来。

2. Provider Adapter 层

这一层负责屏蔽不同模型服务之间的接口差异。
它解决的问题包括：
  • 不同 provider 的请求体字段差异
  • 不同模型名和 base URL 的映射
  • 错误格式不统一
  • 非流式与流式响应的统一抽象
我希望把“接多个模型服务”这件事，从业务侧挪到这一层来处理。
这样，业务方看见的是一个统一协议，而不是多个供应商各自不同的接口细节。

3. Streaming Proxy 层

这一层专门处理流式输出。
它要负责：
  • stream=true 场景的 SSE 透传
  • chunk flush
  • 首包时间（TTFT）记录
  • client 主动断开连接时的处理
  • 区分“首 chunk 前失败”和“首 chunk 后失败”
我认为这是这个项目最能体现“AI 场景特殊性”的一层。
普通 API 代理的很多经验，在这里并不完全够用。

4. Auth / Tenant / Quota 层

这一层负责治理能力的最小闭环。
第一阶段我会重点做：
  • API Key 校验
  • tenant 识别
  • key 状态管理
  • RPM / TPM / budget 的基础控制
  • token usage 记录
没有这层，这个项目就只是在做“模型 API 转发器”。
有了这层，它才开始具备“多租户接入与治理”的味道。

5. Routing / Resilience 层

这一层负责把调用链从“能请求”推进到“更可靠”。
第一阶段只做最基础的三类策略：
  • 静态权重路由
  • 主备 fallback
  • 健康检查与不健康 provider 剔除
它们对应的是最基本的可靠性诉求：
  • 某个 provider 慢了怎么办
  • 某个 provider 挂了怎么办
  • SSE 场景下允许在哪个时点 retry / fallback

6. Observability 层

这一层负责让系统“自证健康”。
我希望它至少覆盖三类信号：
  • logs
  • metrics
  • traces
首批我会关注的指标包括：
  • 请求总量
  • 请求耗时
  • SSE 请求数
  • provider 错误率
  • provider 延迟
  • tenant token usage
  • fallback 次数
  • 限流拒绝次数
有了这一层，系统才开始“可被维护”。

7. Delivery / Ops 层

这一层负责让项目从“本地 demo”走向“像平台”。
第一阶段会重点补：
  • Dockerfile
  • docker-compose
  • K8s Deployment / Service / ConfigMap / Secret
  • 健康检查 endpoint
  • 基础压测脚本
  • 简单故障演练脚本
这部分是我刻意要补的短板,这能证明“我能把一个小型系统交付出去”。
回到首页
Catalog