APISIX 云原生网关与 AI 流量治理

这个技能解决什么

微服务拆完之后，认证、限流、灰度这类横切逻辑常常被复制进每个业务服务：每个模块各自校验一遍 token，各自写一套令牌桶，灰度开关散落在代码里。结果不是漏配，就是配置漂移。换到 AI 场景会更糟：OpenAI、Claude、本地模型各有一套 base URL 和 Key，按租户切模型、按 token 算预算的逻辑很难收敛到一处。

这个技能把「流量入口架构师」当作默认角色，核心主张是：网关不该只是转发器，而是把认证、限流、灰度、可观测这些横切关注点从业务代码里抽出来的正确位置；在 AI 场景下，模型路由要作为一等公民来治理。

适用场景包括：

• 需要统一多个后端服务的认证与限流
• 想做 A/B 灰度、金丝雀发布，又不想改业务代码
• 需要在一个入口收敛多个 LLM Provider，并按 Key 或租户路由

它怎么落地

APISIX 的能力来自插件链，请求按顺序穿过各层。技能给出的推荐组合：

• 限流用 limit-req / limit-count，按 consumer 维度计数更公平
• 认证用 key-auth / jwt-auth，配合 consumer 做多租户
• 灰度用 traffic-split，按 header 或权重切流
• AI 路由用 ai-* 系列插件，注意 token 计费与超时
• 可观测用 prometheus / skywalking，把指标暴露给 Grafana

落地顺序是：先画路由表，列出 path、上游、需要的插件，写成路由配置而不是临时 curl；再为每个调用方建 consumer，把密钥与限流绑定到 consumer 上；然后处理 AI 网关特例——为不同模型建路由，用 traffic-split 做主备或按成本路由，并为 LLM 调用单独设置更长超时和 token 预算；最后让配置即代码，用 apisix.yaml 或 Helm 管理，禁止手动改 etcd，并接上 Prometheus 指标和访问日志采样。

边界与注意点

常见陷阱是裸奔路由：忘记挂认证插件，网关就变成公网开放代理。其次是插件顺序问题，限流放在认证之后会让未鉴权请求提前占掉配额。另外不要把网关当计算节点，在网关里塞重逻辑会拖慢整条链路。

安全配置（认证、鉴权、限流）应以 APISIX 官方安全基线为准，生产环境需结合官方文档与团队安全规范核实。该技能不替代网关本身的部署与运维，只负责治理设计的判断与配置的组织方式。