微服务架构下的 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 流）。

我们的目标架构如下：

统一入口：收口所有 Key，业务方只申请内部 Token。
Token 精确计量：解析输入 Prompt 和输出 Stream，计算真实 Token 消耗。
动态流控：基于 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 脚本实现一个精准的令牌桶算法。

限流策略逻辑：

Pre-Check：请求进来时，根据 Prompt 长度估算 Output（例如预估 1000 Token），尝试从桶里预扣除。
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