微服务架构下的 AI 治理：基于 Spring Cloud Gateway 实现大模型 Token 计费与限流

📉 前言：AI 调用的“狂野西部”时代结束了

2024 年，你的团队里可能每个人都在调用 OpenAI、Azure 或千问的 API。
最初，大家直接在代码里硬编码sk-xxxx。很快，财务找上门了：“为什么上个月 API 账单几十万？”安全团队也炸了：“谁把 Key 传到 GitHub 上了？”

作为架构师，我们必须意识到：LLM 能力不应该是一个随意的 HTTP 请求，它必须被视为一种核心的“基础设施资源”。

我们需要在应用层和模型层之间，架设一道**“AI 网关”。
今天，我们将基于 Spring Cloud Gateway (SCG)，结合 WebFlux 响应式编程，构建一个支持流式 Token 计费、动态限流、统一鉴权**的 AI 治理平台。

🏗️ 架构设计：从“透传”到“治理”

普通的网关只做流量转发，但 AI 网关需要理解 LLM 的协议（SSE 流）。

我们的目标架构如下：

1. 统一入口：收口所有 Key，业务方只申请内部 Token。
2. Token 精确计量：解析输入 Prompt 和输出 Stream，计算真实 Token 消耗。
3. 动态流控：基于 Token 消耗量的限流，而不是简单的 QPS 限流。

核心流量路径图：

⚔️ 核心难点一：如何处理 SSE 流式响应的 Token 计算？

这是最大的技术挑战。LLM 的响应是Server-Sent Events (SSE)，数据是一块一块回来的。我们不能等所有数据都回来再计算 Token，那样会增加巨大的延迟，失去了流式的意义。

我们需要使用 Spring Cloud Gateway 的GlobalFilter配合ServerHttpResponseDecorator来“旁路”监听数据流。

技术栈选择：

• Token 计算库：JTokkit(Java 版 TikToken，性能极高)。
• 响应式编程：Reactor (Mono/Flux)。

核心代码实现思路：

@ComponentpublicclassAiTokenBillingFilterimplementsGlobalFilter,Ordered{privatefinalEncodingRegistryregistry=Encodings.newDefaultEncodingRegistry();privatefinalEncodingenc=registry.getEncoding(EncodingType.CL100K_BASE);@OverridepublicMono<Void>filter(ServerWebExchangeexchange,GatewayFilterChainchain){ServerHttpResponseoriginalResponse=exchange.getResponse();DataBufferFactorybufferFactory=originalResponse.bufferFactory();// 装饰器：拦截响应流ServerHttpResponseDecoratordecoratedResponse=newServerHttpResponseDecorator(originalResponse){@OverridepublicMono<Void>writeWith(Publisher<?extendsDataBuffer>body){if(bodyinstanceofFlux){Flux<?extendsDataBuffer>fluxBody=(Flux<?extendsDataBuffer>)body;returnsuper.writeWith(fluxBody.map(dataBuffer->{// 1. 读取流中的数据块byte[]content=newbyte[dataBuffer.readableByteCount()];dataBuffer.read(content);Stringchunk=newString(content,StandardCharsets.UTF_8);// 2. 异步计算 Token (注意：这里要处理 SSE 格式 parsing)// 实际代码需处理 "data: {...}" 这种 SSE 协议包裹inttokens=countTokens(chunk);// 3. 记录到 Request 属性中，用于后续计费recordUsage(exchange,tokens);// 4. 重新包装数据流返回给客户端returnbufferFactory.wrap(content);}));}returnsuper.writeWith(body);}};returnchain.filter(exchange.mutate().response(decoratedResponse).build()).then(Mono.fromRunnable(()->{// 请求结束，触发 Redis 结算扣费逻辑finalizeBilling(exchange);}));}}

注意：上述代码省略了复杂的 SSE 拆包逻辑，生产环境需要处理跨包截断的问题。

⚖️ 核心难点二：基于 Token 的动态限流 (Token Bucket)

传统的 QPS 限流对 AI 不公平。

• 请求 A：问“你好”，消耗 5 Token。
• 请求 B：让 AI 写一本书，消耗 5000 Token。
  如果都算 1 次 QPS，显然不合理。我们需要基于Token/Minute (TPM)进行限流。

我们需要利用Redis + Lua 脚本实现一个精准的令牌桶算法。

限流策略逻辑：

1. Pre-Check：请求进来时，根据 Prompt 长度估算 Output（例如预估 1000 Token），尝试从桶里预扣除。
2. Post-Check：请求结束时，根据真实消耗（例如实际只用了 50 Token），将多扣的 950 Token返还到桶里。

Redis Lua 伪代码：

-- 预扣除脚本localkey=KEYS[1]localrequested_tokens=tonumber(ARGV[1])locallimit=tonumber(ARGV[2])localrate=tonumber(ARGV[3])-- 计算当前桶内剩余令牌 (结合时间窗口衰减算法)localcurrent_tokens=...ifcurrent_tokens>=requested_tokensthen-- 扣除并返回成功redis.call("DECRBY",key,requested_tokens)return1elsereturn0end

🛡️ 企业级增强：多模型统一适配

Spring Cloud Gateway 还有一个巨大的优势：RewritePath (路径重写)。

你可以统一接口规范，例如都使用 OpenAI 格式的接口/v1/chat/completions。
然后在 Gateway 配置路由规则：

• Header 带x-model: ernie-> 转发到百度文心一言，并利用Filter进行协议转换（OpenAI 格式转文心格式）。
• Header 带x-model: gpt-4-> 转发到 Azure OpenAI。

这样，业务代码只需要适配一套 OpenAI SDK，就可以无缝切换底层的所有模型！

📝 总结

通过 Spring Cloud Gateway，我们把 AI 能力从“裸奔的 API”变成了“可管理的资产”。

1. 可观测：谁用了多少 Token，一清二楚。
2. 可控制：部门预算用完，自动停止服务。
3. 可审计：网关层可以落盘所有的 Prompt 和 Response（注意脱敏），用于安全审计。

架构师的价值，不在于写了多少 CRUD，而在于能否为新技术构建可落地的“护栏”。

博主留言：
你在做 AI 网关时，是如何处理SSE 流式数据的粘包/拆包问题的？
在评论区回复“网关”，我发给你一份《Spring Cloud Gateway 适配 SSE 流处理的完整工具类》，帮你解决 Netty 缓冲区截断的深坑！