1. 多网关共存时统一 Key 到底难在哪如果你手上同时跑着 SpringGateway、Zuul、Kong、APISIX 这四类网关大概率会遇到一个很现实的问题每个网关都有自己的鉴权插件、自己的密钥存储、自己的限流配置。SpringGateway 里写 GlobalFilter 校验 HeaderZuul 里挂 ZuulFilter 做前置拦截Kong 用 Key-Auth 插件APISIX 用 consumer key-auth。四套逻辑各写一遍密钥轮换时要在四个地方同步改漏一个就是线上事故。我试过在一个项目里把上游模型调用分散到四个网关后面结果最头疼的不是路由转发而是「同一个 Key 在四个网关里表现不一致」——有的网关把 Key 放在Authorization有的放在apikey有的要求Bearer前缀。调用方每换一个入口就要改一次代码。这篇要解决的问题就是把 TaoToken 当作统一的 Key/API 通道让四类网关都指向同一个上游地址和同一套密钥网关本身只负责路由和转发鉴权与密钥管理收敛到一处。TaoToken 在这里扮演的是「统一上游 统一 Key」的角色它提供 OpenAI 兼容的 API 入口网关只需要把请求转发过去、把 Key 透传或注入即可。适合谁看正在做微服务网关选型或迁移的后端同学已经有多套网关、想统一鉴权链路的运维/架构同学以及想本地快速跑通「网关 → TaoToken → 模型」这条链路的开发者。下面每个网关我都会给出可复制的配置骨架并说明验证动作。2. 前置准备TaoToken 的 Key 与接入地址在动网关配置之前先把上游通道准备好。TaoToken 的 API 入口是https://taotoken.net/api它兼容 OpenAI 的请求格式所以四类网关的转发目标都可以统一写成这个地址。第一步去控制台创建一个 API Key。打开https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite在 API Keys 页面新建一个 Key复制出来形如sk-xxxx的字符串。这个 Key 就是后面四个网关共用的那一把轮换时只改这一处。第二步确认你要转发的具体路径。TaoToken 的对话补全路径是/v1/chat/completions模型列表是/v1/models。网关转发时upstream指向https://taotoken.net/api路径保留/v1/...即可。第三步本地先用 curl 验证 Key 可用避免后面排查时分不清是网关问题还是 Key 问题curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的Key \ -H Content-Type: application/json \ -d { model: gpt-4o-mini, messages: [{role: user, content: ping}] }返回里有choices字段就说明通道正常。这一步过了再往下配网关。如果你还没决定用哪个模型可以先去https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite看一眼可用列表再回来配。注意网关里不要把 Key 硬编码进配置文件提交到 Git。下面示例用环境变量占位实际部署时用配置中心或 Secret 注入。3. 四类网关的可复制配置骨架这一节是全文的核心。四类网关的配置思路一致定义一个上游TaoToken定义一个路由匹配/v1/**把 Key 以 Header 形式注入或透传。区别在于各自的配置语法和插件机制。3.1 SpringGateway用 RouteLocator 默认 HeaderSpringGateway 基于 WebFlux配置分 Java DSL 和 YAML 两种。推荐 YAML改起来直观。核心是spring.cloud.gateway.routes里定义uri和predicates再用default-filters注入 Authorization。spring: cloud: gateway: default-filters: - AddRequestHeaderAuthorization, Bearer ${TAOTOKEN_KEY} routes: - id: taotoken-chat uri: https://taotoken.net/api predicates: - Path/v1/chat/completions - id: taotoken-models uri: https://taotoken.net/api predicates: - Path/v1/models${TAOTOKEN_KEY}从环境变量读取启动时传入。这样调用方访问网关的/v1/chat/completions网关自动补上 Authorization 头转发到 TaoToken。如果调用方自己带了 Key想透传而不是覆盖把AddRequestHeader换成PreserveHostHeader之类的策略或者干脆不加默认过滤器让 Header 原样透传。3.2 ZuulZuulFilter 做前置注入Zuul 1.x 的配置在application.yml里定义路由鉴权靠自定义ZuulFilter。路由部分zuul: routes: taotoken: path: /v1/** url: https://taotoken.net/api sensitive-headers:sensitive-headers留空是为了不让 Zuul 过滤掉 Authorization 头。然后写一个pre类型的过滤器Component public class TaotokenAuthFilter extends ZuulFilter { Value(${TAOTOKEN_KEY}) private String key; Override public String filterType() { return pre; } Override public int filterOrder() { return 1; } Override public boolean shouldFilter() { return true; } Override public Object run() { RequestContext ctx RequestContext.getCurrentContext(); ctx.addZuulRequestHeader(Authorization, Bearer key); return null; } }Zuul 2.x 改成了异步模型过滤器接口不同但思路一样在pre阶段往请求头塞 Authorization。3.3 KongService Route key-auth 插件Kong 用 Admin API 或声明式配置kong.yml管理。声明式配置更适合版本化骨架如下_format_version: 3.0 services: - name: taotoken-service url: https://taotoken.net/api routes: - name: taotoken-route paths: - /v1 strip_path: false plugins: - name: key-auth service: taotoken-service config: key_names: - apikey hide_credentials: false consumers: - username: taotoken-consumer keyauth_credentials: - key: sk-你的Key这里有个关键点Kong 的key-auth插件默认从apikey头或 query 参数取 Key而 TaoToken 期望的是Authorization: Bearer。两种做法——要么让调用方按 Kong 的apikey传再用request-transformer插件改写成 Authorization要么直接不用 key-auth改用request-transformer注入固定 Header。后者更简单plugins: - name: request-transformer service: taotoken-service config: add: headers: - Authorization:Bearer sk-你的Keystrip_path: false很重要否则 Kong 会把/v1前缀吃掉转发到 TaoToken 就变成根路径了。3.4 APISIXroute upstream 插件链APISIX 的配置也是声明式config.yaml里定义 route 和 upstream插件挂在 route 上。骨架routes: - uri: /v1/* name: taotoken-route upstream: type: roundrobin nodes: taotoken.net:443: 1 scheme: https pass_host: node plugins: proxy-rewrite: regex_uri: - ^/v1/(.*) - /api/v1/$1 request-transformer: add: headers: - Authorization: Bearer sk-你的KeyAPISIX 的proxy-rewrite用来改写路径因为上游是taotoken.net/api而路由匹配的是/v1/*需要把/v1/xxx重写成/api/v1/xxx。pass_host: node让 SNI 和 Host 用节点域名避免 TLS 握手失败。四类网关的配置对照可以看这张表网关配置载体Key 注入方式路径处理要点SpringGatewayYAML / Java DSLdefault-filters AddRequestHeaderpredicates 精确匹配ZuulYAML Java FilterZuulFilter pre 阶段sensitive-headers 留空Kongkong.yml / Admin APIrequest-transformer 插件strip_path: falseAPISIXconfig.yamlrequest-transformer 插件proxy-rewrite 改写前缀4. 逐项验证确认请求链路真的通了配完不算完要逐项验证。验证的核心是「请求经过网关后TaoToken 能收到正确的 Key 和路径」。每个网关都用一个 curl 打自己的入口看返回。SpringGateway 和 Zuul 验证方式一样打网关端口curl -s http://localhost:8080/v1/chat/completions \ -H Content-Type: application/json \ -d {model:gpt-4o-mini,messages:[{role:user,content:ping}]}Kong 默认代理端口 8000APISIX 默认 9080curl -s http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model:gpt-4o-mini,messages:[{role:user,content:ping}]}如果返回choices说明链路通了。如果返回 401说明 Key 没注入成功返回 404说明路径被改写错了。这时候去看网关的访问日志确认转发出去的 URL 和 Header 长什么样。一个更细的验证动作在 TaoToken 侧看请求日志控制台有调用记录确认收到的Authorization头是Bearer sk-xxx路径是/api/v1/chat/completions。两边对上了才算真正跑通。5. 本篇常见错排查401 Unauthorized但 curl 直连 TaoToken 是好的。九成是网关把 Authorization 头吃掉了。Zuul 检查sensitive-headers是否留空SpringGateway 检查有没有别的过滤器覆盖了 HeaderKong 检查hide_credentials是不是设成了 true。404 Not Found路径不对。Kong 的strip_path默认是 true会把匹配的前缀删掉必须设 false。APISIX 的proxy-rewrite正则写错也会导致路径拼接错误用regex_uri时注意捕获组和替换串的对应关系。TLS 握手失败或证书错误。APISIX 转发到 https 上游时pass_host设成node让 SNI 用节点域名。Kong 的 service url 写https://时确认证书链没问题。Key 轮换后部分网关失效。这就是多网关共存的典型坑——四个地方各存了一份 Key。解决办法是把 Key 收敛到环境变量或配置中心四个网关都从同一处读。TaoToken 侧轮换 Key 后只需更新配置中心的值重启或热加载网关即可。请求体被网关改写。有些网关默认会压缩或改写 body导致模型接口报格式错误。检查网关有没有开request-transformer的 body 改写或者proxy-rewrite动了 body。6. 把 Key 收敛到一处网关只管转发四类网关配下来你会发现真正需要维护的只有一把 Key 和一个上游地址。SpringGateway 用 default-filtersZuul 用 pre 过滤器Kong 和 APISIX 用 request-transformer 插件本质都是「在转发前把 Authorization 补上」。网关的职责回归到路由和流量治理鉴权和密钥管理交给 TaoToken 统一处理。如果你后面要接更多模型或做长期编码任务可以在https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite看下 Coding Plan 的额度方案需要管理多个 Key 或查看调用明细去https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite操作接入细节和参数说明在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite。本地想先验证模型通不通直接用https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite里的对话入口试一句就行。最后留一个实操建议四个网关的配置文件里Key 一律用${TAOTOKEN_KEY}占位本地用.env线上用 Secret。这样轮换时只改一处四个网关同时生效不会再出现「改了三个漏了一个」的情况。
