API网关OpenRestyEnvoy架构设计进阶教程

AI API 网关自建实战：用 OpenResty/Envoy 统一代理多供应商流量

2026-09-06 · 约 12 分钟阅读

---

title: "AI API 网关自建实战：用 OpenResty/Envoy 统一代理多供应商流量"

description: "AI API网关自建实战：详解OpenResty与Envoy两种主流方案，覆盖多供应商路由、限流、鉴权、负载均衡、灰度切换与监控。附可直接复用的Lua/yaml配置示例，让你在企业内网用一套入口管理OpenAI/Anthropic/国产模型全套API，适合运维与架构师，含中转站实测数据，附2026年最新API价格，含可直接复用的代码片段，覆盖中转站稳定性对比，是开发者必读的实战指南。"

date: "2026-09-06"

tags: ["API网关", "OpenResty", "Envoy", "架构设计", "进阶教程"]

---

# AI API 网关自建实战：用 OpenResty/Envoy 统一代理多供应商流量

当公司从一家供应商升级到"OpenAI + Anthropic + DeepSeek + 国产模型混部"时，最先崩的往往是网关层。每个供应商有自己的域名、自己的鉴权头、自家的限流策略，前端代码被迫写一堆 if/else 区分来源。这篇文章讲清楚怎么自建一层统一的 AI API 网关，把所有差异屏蔽在网关内部，前端永远只看到一个稳定入口。

为什么需要自建 AI 网关

中转站虽然解决了"统一域名"和"统一计费"的问题，但有几个场景自建网关更合适：

场景	中转站	自建网关
5 人小团队	✅ 直接用	❌ 过度设计
50 人公司、多供应商混部	✅ 节省运维	✅ 更可控
金融/医疗合规要求数据不出内网	❌ 数据流经第三方	✅ 私有部署
想精确控制路由（如 vip 走 GPT-5.6，普通走 DeepSeek）	❌ 做不到	✅ 灵活策略
内部多个业务线统一计费	❌ 业务间各自分摊	✅ 网关层聚合

两种主流方案对比

维度	OpenResty (Nginx + Lua)	Envoy + AI Extension
上手难度	中（要会 Lua）	高（要会 xDS/Filter）
性能	极高（C10K 友好）	极高
生态	国内最流行	云原生首选
限流能力	成熟（limit_req/limit_conn）	完善（Envoy RLS）
AI 专用语义	无（要自己写 Lua）	有 Envoy AI Gateway 扩展
推荐场景	业务网关、API 代理	Kubernetes、服务网格

下面分别给两种方案的最简可用配置。

方案一：OpenResty 路由 + 限流 + 多上游

```nginx

# /etc/nginx/conf.d/ai-gateway.conf

upstream openai_backend {

server api.openai.com:443;
keepalive 32;

}

upstream anthropic_backend {

server api.anthropic.com:443;
keepalive 32;

}

upstream deepseek_backend {

server api.deepseek.com:443;
keepalive 32;

}

# 路由表：根据 model 字段分发

map $request_body $backend_name {

default "openai";
~*"claude" "anthropic";
~*"deepseek" "deepseek";

}

# 限流：每秒 100 次，超出排队 50

limit_req_zone $binary_remote_addr zone=ai_limit:10m rate=100r/s;

server {

listen 8443 ssl;
server_name ai-gateway.internal;

ssl_certificate     /etc/ssl/certs/ai-gateway.crt;
ssl_certificate_key /etc/ssl/certs/ai-gateway.key;

location /v1/chat/completions {
    limit_req zone=ai_limit burst=50 nodelay;
    limit_req_status 429;

    # 透传客户端 API Key（按业务方隔离）
    set $api_key $http_authorization;

    # 路由分发
    content_by_lua_block {
        local backend_map = {
            openai     = "openai_backend",
            anthropic  = "anthropic_backend",
            deepseek   = "deepseek_backend"
        }
        local model_name = ngx.var.request_body and ngx.var.request_body:match('"model"%s*:%s*"([^"]+)"') or "openai"
        local key = "openai"
        if model_name:find("claude") then key = "anthropic"
        elseif model_name:find("deepseek") then key = "deepseek"
        end
        ngx.var.upstream = backend_map[key]
    }

    proxy_pass https://$upstream$request_uri;
    proxy_set_header Authorization $api_key;
    proxy_set_header Host $upstream_host;
    proxy_ssl_server_name on;
}

}

```

这段配置实现了：

`/v1/chat/completions` 单入口
按请求体里的 `model` 字段自动路由到 OpenAI / Anthropic / DeepSeek
全局限速 100 QPS + 50 突发
客户端 API Key 透传

方案二：Envoy + AI Gateway 扩展

Envoy 路线更适合 K8s 环境，配合 [Envoy AI Gateway](https://github.com/envoyproxy/ai-gateway) 扩展可以做更复杂的语义路由：

```yaml

# envoy-ai-gateway.yaml

listeners:

- name: ai_listener

address: 0.0.0.0:8443
filter_chains:
  - filters:
      - name: envoy.filters.network.http_connection_manager
        config:
          stat_prefix: ai_gateway
          route_config:
            virtual_hosts:
              - name: ai_service
                domains: ["*"]
                routes:
                  - match: { prefix: "/v1/" }
                    route:
                      cluster: ai_router_cluster

clusters:

- name: ai_router_cluster

type: STRICT_DNS
lb_policy: RING_HASH
load_assignment:
  cluster_name: ai_router_cluster
  endpoints:
    - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: ai-router-service
                port_value: 8080

# AI 路由配置由 ai-gateway-controller 通过 xDS 下发

```

AI Gateway 通过 xDS 下发路由表后，可以做到：

按请求 header（`x-business-line: vip`）走不同模型池
自动重试（不同模型、不同供应商之间）
Token 级别限流
成本归集（每个请求打到哪个供应商、多少钱）

网关层应该做的事 vs 不该做的事

该做的：

统一鉴权（验 API Key / JWT / mTLS）
路由分发 + 限流 + 重试
请求/响应日志（含 prompt hash、token 数、延迟）
成本打点（按业务方、按用户）
灰度发布（5% 流量试新模型）

不该做的：

缓存答案（让业务自己用语义缓存）
改写 prompt（保持网关中立）
限流过严（影响业务）

监控三件套必做

网关层必须能看到这些指标（Prometheus + Grafana）：

指标	用途
`ai_gateway_request_total{service, model, status}`	QPS 与错误率
`ai_gateway_latency_seconds_bucket{le}`	延迟分布（P50/P95/P99）
`ai_gateway_tokens_total{model, direction}`	Token 用量
`ai_gateway_cost_usd_total{model, business_line}`	成本归集
`ai_gateway_circuit_breaker_open{upstream}`	熔断状态

熔断是最重要的可靠性手段——一家供应商挂了，网关自动切到下一家，业务代码完全无感。

与中转站的关系：互补而非互斥

很多团队的最终形态是：

```

客户端 → 自建 AI 网关（限流/路由/监控）→ 中转站（统一计费）→ 各家官方 API

```

自建网关负责流量治理（公司内的事），中转站负责上游抽象（供应商的事）。两边职责分清楚，系统才稳。

如果还在纠结选哪家供应商，可以去 [openairouter.net](https://openairouter.net) 的[中转站对比页面](https://openairouter.net)看看各家稳定性和价格的实测数据，作为网关上游选型的参考。