gateway学习笔记Apache APISIX&ai gateway

上将邢道荣
0 阅读1小时+

Apache APISIX 是 Apache 软件基金会下的顶级项目，由 API7.ai 开发并捐赠。它是一个具有动态、实时、高性能等特点的云原生 API 网关。

你可以使用 APISIX 网关作为所有业务的流量入口，它提供了动态路由、动态上游、动态证书、A/B 测试、灰度发布（金丝雀发布）、蓝绿部署、限速、防攻击、收集指标、监控报警、可观测、服务治理等功能。

本教程使用脚本在本地环境快速安装 Apache APISIX，并且通过管理 API 来验证是否安装成功。

前置条件#

快速启动脚本需要以下条件：

  • 已安装 Docker，用于部署 etcd 和 APISIX。
  • 已安装 curl，用于验证 APISIX 是否安装成功。

安装 APISIX#

caution

为了提供更好的体验，管理 API 默认无需授权，请在生产环境中打开授权开关。

APISIX 可以借助 quickstart 脚本快速安装并启动：

curl -sL https://run.api7.ai/apisix/quickstart | sh

该命令启动 apisix-quickstart 和 etcd 两个容器，APISIX 使用 etcd 保存和同步配置。APISIX 和 etcd 容器使用 Docker 的 host 网络模式，因此可以从本地直接访问。

如果一切顺利，将输出如下信息：

✔ APISIX is ready!

验证#

你可以通过 curl 来访问正在运行的 APISIX 实例。比如，你可以发送一个简单的 HTTP 请求来验证 APISIX 运行状态是否正常：

curl "http://127.0.0.1:9080" --head | grep Server

如果一切顺利，将输出如下信息：

Server: APISIX/Version

这里的 Version 是指你已经安装的 APISIX 版本，比如 APISIX/3.3.0。

现在，你已经成功安装并运行了 APISIX！

配置路由

本教程由 API7.ai 编写。

Apache APISIX 使用 routes 来提供灵活的网关管理功能，在一个请求中，routes 包含了访问路径和上游目标等信息。

本教程将引导你创建一个 route 并验证它，你可以参考以下步骤：

  1. 创建一个指向 httpbin.org的 upstream。
  2. 使用 cURL 发送一个请求，了解 APISIX 的代理和转发请求机制。

Route 是什么#

Route（也称之为路由）是访问上游目标的路径，在 Apache APISIX 中，Route 首先通过预定的规则来匹配客户端请求，然后加载和执行相应的插件，最后将请求转发至特定的 Upstream。

在 APISIX 中，一个最简单的 Route 仅由匹配路径和 Upstream 地址两个信息组成。

Upstream 是什么#

Upstream（也称之为上游）是一组具备相同功能的节点集合，它是对虚拟主机的抽象。Upstream 可以通过预先配置的规则对多个服务节点进行负载均衡。

前置条件#

  1. 参考入门指南完成 APISIX 的安装。

创建路由#

你可以创建一个路由，将客户端的请求转发至 httpbin.org（这个网站能测试 HTTP 请求和响应的各种信息）。

通过下面的命令，你将创建一个路由，把请求http://127.0.0.1:9080/ip 转发至 httpbin.org/ip：

curl -i "http://127.0.0.1:9180/apisix/admin/routes" -X PUT -d '
{
  "id": "getting-started-ip",
  "uri": "/ip",
  "upstream": {
    "type": "roundrobin",
    "nodes": {
      "httpbin.org:80": 1
    }
  }
}'

如果配置成功，将会返回 HTTP/1.1 201 Created。

验证#

curl "http://127.0.0.1:9080/ip"

你将会得到类似下面的返回：

{
  "origin": "183.94.122.205"
}

负载均衡

本教程由 API7.ai 编写。

负载均衡管理客户端和服务端之间的流量。它决定由哪个服务来处理特定的请求，从而提高性能、可扩展性和可靠性。在设计需要处理大量流量的系统时，负载均衡是一个关键的考虑因素。

Apache APISIX 支持加权负载均衡算法，传入的流量按照预定顺序轮流分配给一组服务器的其中一个。

在本教程中，你将创建一个具有两个上游服务的路由，并且启用负载均衡来测试在两个服务之间的切换情况。

前置条件#

  1. 参考入门指南完成 APISIX 的安装。
  2. 了解 APISIX 中路由及上游的概念。

启用负载均衡#

创建一个具有两个上游服务的路由，访问 /headers 将被转发到 httpbin.org 和 mock.api7.ai 这两个上游服务，并且会返回请求头。

curl -i "http://127.0.0.1:9180/apisix/admin/routes" -X PUT -d '
{
  "id": "getting-started-headers",
  "uri": "/headers",
  "upstream" : {
    "type": "roundrobin",
    "nodes": {
      "httpbin.org:443": 1,
      "mock.api7.ai:443": 1
    },
    "pass_host": "node",
    "scheme": "https"
  }
}'

如果路由创建成功，你将会收到返回 HTTP/1.1 201 Created。

info
  1. 将 pass_host 字段设置为 node，将传递请求头给上游。
  2. 将 scheme 字段设置为 https，向上游发送请求时将启用 TLS。

验证#

这两个服务返回不同的数据。

httpbin.org 返回：

{
  "headers": {
    "Accept": "*/*",
    "Host": "httpbin.org",
    "User-Agent": "curl/7.58.0",
    "X-Amzn-Trace-Id": "Root=1-63e34b15-19f666602f22591b525e1e80",
    "X-Forwarded-Host": "localhost"
  }
}

mock.api7.ai 返回：

{
  "headers": {
    "accept": "*/*",
    "host": "mock.api7.ai",
    "user-agent": "curl/7.58.0",
    "content-type": "application/json",
    "x-application-owner": "API7.ai"
  }
}

我们生成 100 个请求来测试负载均衡的效果：

hc=$(seq 100 | xargs -I {} curl "http://127.0.0.1:9080/headers" -sL | grep "httpbin" | wc -l); echo httpbin.org: $hc, mock.api7.ai: $((100 - $hc))

结果显示，请求几乎平均分配给这两个上游服务：

httpbin.org: 51, mock.api7.ai: 49

密钥验证

本教程由 API7.ai 编写。

API 网关主要作用是连接 API 消费者和提供者。出于安全考虑，在访问内部资源之前，应先对消费者进行身份验证和授权。

身份验证

APISIX 拥有灵活的插件扩展系统，目前有很多可用于用户身份验证和授权的插件。例如：

本教程中，你将创建一个带有 密钥验证 插件的 消费者，并学习如何启用和停用身份验证插件。

Consumer 是什么#

Consumer（也称之为消费者）是指使用 API 的应用或开发人员。

在 APISIX 中，消费者需要一个全局唯一的 名称，并从上面的列表中选择一个身份验证 插件。

Key Authentication 是什么#

Key Authentication（也称之为密钥验证）是一个相对比较简单但是应用广泛的身份验证方法，它的设计思路如下：

  1. 管理员为路由添加一个身份验证密钥（API 密钥）。
  2. API 消费者在发送请求时，在查询字符串或者请求头中添加密钥。

启用 Key Authentication#

前置条件#

  1. 参考快入门指南完成 APISIX 的安装。
  2. 完成配置路由。

创建消费者#

创建一个名为 tom 的消费者，并启用 key-auth 插件，密钥设置为 secret-key。所有携带密钥 secret-key 的请求都会被识别为消费者 tom。

caution

生产环境请使用复杂的密钥。

curl -i "http://127.0.0.1:9180/apisix/admin/consumers" -X PUT -d '
{
  "username": "tom",
  "plugins": {
    "key-auth": {
      "key": "secret-key"
    }
  }
}'

如果消费者创建成功，你将得到返回 HTTP/1.1 201 Created。

启用 Authentication#

在教程配置路由中，我们已经创建了路由 getting-started-ip，我们通过 PATCH 方法为该路由增加 key-auth 插件：

curl -i "http://127.0.0.1:9180/apisix/admin/routes/getting-started-ip" -X PATCH -d '
{
  "plugins": {
    "key-auth": {}
  }
}'

如果增加插件成功，你将得到返回 HTTP/1.1 201 Created。

验证#

我们可以在以下场景中进行验证：

1. 发送不带任何密钥的请求#

发送一个不带请求头 apikey 的请求。

curl -i "http://127.0.0.1:9080/ip"

如果你已经启用了密钥身份验证，你将会得到返回 HTTP/1.1 401 Unauthorized，即未授权。

HTTP/1.1 401 Unauthorized
Date: Wed, 08 Feb 2023 09:38:36 GMT
Content-Type: text/plain; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Server: APISIX/3.1.0
2. 发送携带错误密钥的请求#

发送一个携带错误密钥（比如 wrong-key）的请求。

curl -i "http://127.0.0.1:9080/ip" -H 'apikey: wrong-key'

如果密钥错误，你也将得到返回 HTTP/1.1 401 Unauthorized，即未授权。

HTTP/1.1 401 Unauthorized
Date: Wed, 08 Feb 2023 09:38:27 GMT
Content-Type: text/plain; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Server: APISIX/3.1.0
3. 发送携带正确密钥的请求#

发送一个携带正确密钥（secret-key）的请求。

curl -i "http://127.0.0.1:9080/ip" -H 'apikey: secret-key'

你将会得到返回 HTTP/1.1 200 OK。

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 44
Connection: keep-alive
Date: Thu, 09 Feb 2023 03:27:57 GMT
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Server: APISIX/3.1.0

禁用 Authentication#

将参数设置 _meta.disable 为 true，即可禁用密钥验证插件。

curl "http://127.0.0.1:9180/apisix/admin/routes/getting-started-ip" -X PATCH -d '
{
  "plugins": {
    "key-auth": {
      "_meta": {
        "disable": true
      }
    }
  }
}'

你可以发送一个不带任何密钥的请求来验证：

curl -i "http://127.0.0.1:9080/ip"

因为你已经禁用了密钥验证插件，所以你将会得到返回 HTTP/1.1 200 OK。

限速

本教程由 API7.ai 编写。

APISIX 是一个统一的控制中心，它管理 API 和微服务的进出流量。除了客户端发来的合理的请求，还可能存在网络爬虫产生的不必要的流量，此外，网络攻击（比如 DDos）也可能产生非法请求。

APISIX 提供限速功能，通过限制在规定时间内发送到上游服务的请求数量来保护 APIs 和微服务。请求的计数在内存中完成，具有低延迟和高性能的特点。

Routes Diagram

在本教程中，你将启用 limit-count 插件来限制传入流量的速率。

前置条件#

  1. 参考入门指南完成 APISIX 的安装。
  2. 完成配置路由。

启用 Rate Limiting#

在教程配置路由中，我们已经创建了路由 getting-started-ip，我们通过 PATCH 方法为该路由增加 limit-count 插件：

curl -i "http://127.0.0.1:9180/apisix/admin/routes/getting-started-ip" -X PATCH -d '
{
  "plugins": {
    "limit-count": {
        "count": 2,
        "time_window": 10,
        "rejected_code": 503
     }
  }
}'

如果增加插件成功，你将得到返回 HTTP/1.1 201 Created。上述配置将传入流量的速率限制为每 10 秒最多 2 个请求。

验证#

我们同时生成 100 个请求来测试限速插件的效果。

count=$(seq 100 | xargs -I {} curl "http://127.0.0.1:9080/ip" -I -sL | grep "503" | wc -l); echo "200": $((100 - $count)), "503": $count

请求结果同预期一致：在这 100 个请求中，有 2 个请求发送成功（状态码为 200），其他请求均被拒绝（状态码为 503）。

"200": 2, "503": 98

禁用 Rate Limiting#

将参数设置 _meta.disable 为 true，即可禁用限速插件。

curl -i "http://127.0.0.1:9180/apisix/admin/routes/getting-started-ip" -X PATCH -d '
{
    "plugins": {
        "limit-count": {
            "_meta": {
                "disable": true
            }
        }
    }
}'

验证#

我们再次同时生成 100 个请求来测试限速插件是否已被禁用：

count=$(seq 100 | xargs -i curl "http://127.0.0.1:9080/ip" -I -sL | grep "503" | wc -l); echo "200": $((100 - $count)), "503": $count

结果显示所有的请求均成功：

"200": 100, "503": 0

更多#

你可以使用 APISIX 的变量来配置限速插件的规则，比如 $host 和 $uri。此外，APISIX 也支持使用 Redis 集群进行限速配置，即通过 Redis 来进行计数。

APISIX 安装指南

本文将介绍如何在你的环境中安装并运行 APISIX。

关于如何快速运行 Apache APISIX，请参考入门指南。

安装 APISIX#

你可以选择以下任意一种方式安装 APISIX：

  • Docker
  • Helm
  • RPM
  • DEB
  • Source Code

使用此方法安装 APISIX，你需要安装 Docker 和 Docker Compose。

首先下载 apisix-docker 仓库。

git clone https://github.com/apache/apisix-docker.git
cd apisix-docker/example

然后，使用 docker-compose 启用 APISIX。

  • x86
  • ARM/M1
docker-compose -p docker-apisix up -d

安装 etcd#

APISIX 使用 etcd 作为配置中心进行保存和同步配置。在安装 APISIX 之前，需要在你的主机上安装 etcd。

如果你在安装 APISIX 时选择了 Docker 或 Helm 安装，那么 etcd 将会自动安装；如果你选择其他方法或者需要手动安装 APISIX，请参考以下步骤安装 etcd：

  • Linux
  • macOS
ETCD_VERSION='3.5.4'
wget https://github.com/etcd-io/etcd/releases/download/v${ETCD_VERSION}/etcd-v${ETCD_VERSION}-linux-amd64.tar.gz
tar -xvf etcd-v${ETCD_VERSION}-linux-amd64.tar.gz && \
  cd etcd-v${ETCD_VERSION}-linux-amd64 && \
  sudo cp -a etcd etcdctl /usr/bin/
nohup etcd >/tmp/etcd.log 2>&1 &

后续操作#

配置 APISIX#

通过修改本地 ./conf/config.yaml 文件，或者在启动 APISIX 时使用 -c 或 --config 添加文件路径参数 apisix start -c <path string>，完成对 APISIX 服务本身的基本配置。默认配置不应修改，可以在 apisix/cli/config.lua 中找到。

比如将 APISIX 默认监听端口修改为 8000，其他配置保持默认，在 ./conf/config.yaml 中只需这样配置：

./conf/config.yaml

apisix:
  node_listen: 8000 # APISIX listening port

比如指定 APISIX 默认监听端口为 8000，并且设置 etcd 地址为 http://foo:2379，其他配置保持默认。在 ./conf/config.yaml 中只需这样配置：

./conf/config.yaml

apisix:
  node_listen: 8000 # APISIX listening port

deployment:
  role: traditional
  role_traditional:
    config_provider: etcd
  etcd:
    host:
      - "http://foo:2379"
warning

请不要手动修改 APISIX 安装目录下的 ./conf/nginx.conf 文件。当 APISIX 启动时，会根据 config.yaml 的配置自动生成新的 nginx.conf 并自动启动服务。

更新 Admin API key#

建议修改 Admin API 的 key，保护 APISIX 的安全。

请参考如下信息更新配置文件：

./conf/config.yaml

deployment:
  admin:
    admin_key:
      - name: "admin"
        key: newsupersecurekey  # 请修改 key 的值
        role: admin

更新完成后，你可以使用新的 key 访问 Admin API：

curl http://127.0.0.1:9180/apisix/admin/routes?api_key=newsupersecurekey -i

为 APISIX 添加 systemd 配置文件#

如果你是通过 RPM 包安装 APISIX，配置文件已经自动安装，你可以直接使用以下命令：

systemctl start apisix
systemctl stop apisix

如果你是通过其他方法安装的 APISIX，可以参考配置文件模板进行修改，并将其添加在 /usr/lib/systemd/system/apisix.service 路径下。

软件架构

Apache APISIX 是一个动态、实时、高性能的云原生 API 网关。它构建于 NGINX + ngx_lua 的技术基础之上，充分利用了 LuaJIT 所提供的强大性能。 为什么 Apache APISIX 选择 NGINX+Lua 技术栈？。

软件架构

APISIX 主要分为两个部分：

  1. APISIX 核心：包括 Lua 插件、多语言插件运行时（Plugin Runner）、Wasm 插件运行时等；
  2. 功能丰富的各种内置插件：包括可观测性、安全、流量控制等。

APISIX 在其核心中，提供了路由匹配、负载均衡、服务发现、API 管理等重要功能，以及配置管理等基础性模块。除此之外，APISIX 插件运行时也包含其中，提供原生 Lua 插件的运行框架和多语言插件的运行框架，以及实验性的 Wasm 插件运行时等。APISIX 多语言插件运行时提供多种开发语言的支持，比如 Golang、Java、Python、JS 等。

APISIX 目前也内置了各类插件，覆盖了 API 网关的各种领域，如认证鉴权、安全、可观测性、流量管理、多协议接入等。当前 APISIX 内置的插件使用原生 Lua 实现，关于各个插件的介绍与使用方式，可以查看相关插件文档。

插件加载流程#

插件加载流程

插件内部结构#

插件内部结构

保护 API

描述#

本文将为你介绍使用限流限速和安全插件保护你的 API。

概念介绍#

插件#

Plugin 也称之为插件，它是扩展 APISIX 应用层能力的关键机制，也是在使用 APISIX 时最常用的资源对象。插件主要是在 HTTP 请求或响应生命周期期间执行的、针对请求的个性化策略。插件可以与路由、服务或消费者绑定。

注意

如果 路由、服务、插件配置 或消费者都绑定了相同的插件，则只有一份插件配置会生效，插件配置的优先级由高到低顺序是：消费者 > 路由 > 插件配置 > 服务。同时在插件执行过程中也会涉及 6 个阶段，分别是 rewrite、access、before_proxy、header_filter、body_filter 和 log。

前提条件#

在进行该教程前，请确保你已经公开服务。

保护 API#

在很多时候，我们的 API 并不是处于一个非常安全的状态，它随时会收到不正常的访问，一旦访问流量突增，可能就会导致你的 API 发生故障，产生不必要的损失。因此你可以通过速率限制保护你的 API 服务，限制非正常的访问请求，保障 API 服务的稳定运行。对此，我们可以使用如下方式进行：

  1. 限制请求速率；
  2. 限制单位时间内的请求数；
  3. 延迟请求；
  4. 拒绝客户端请求；
  5. 限制响应数据的速率。

为了实现上述功能，APISIX 提供了多个限流限速的插件，包括 limit-conn、limit-count 和 limit-req。

  • limit-conn 插件主要用于限制客户端对服务的并发请求数。
  • limit-req 插件使用漏桶算法限制对用户服务的请求速率。
  • limit-count 插件主要用于在指定的时间范围内，限制每个客户端总请求个数。

接下来，我们将以 limit-count 插件为例，为你介绍如何通过限流限速插件保护你的 API。

  1. 创建路由。
note

您可以这样从 config.yaml 中获取 admin_key 并存入环境变量：

admin_key=$(yq '.deployment.admin.admin_key[0].key' conf/config.yaml | sed 's/"//g')

curl -i http://127.0.0.1:9180/apisix/admin/routes/1 \
-H "X-API-KEY: $admin_key" -X PUT -d '
{
    "uri": "/index.html",
    "plugins": {
        "limit-count": {
            "count": 2,
            "time_window": 60,
            "rejected_code": 503,
            "key_type": "var",
            "key": "remote_addr"
        }
    },
  "upstream_id": "1"
}'

以上配置中，使用了公开服务中创建的上游创建了一个 ID 为 1 的路由， ，并且启用了 limit-count 插件。该插件仅允许客户端在 60 秒内，访问上游服务 2 次，超过两次，则会返回 503 错误码。

  1. 测试插件。

curl http://127.0.0.1:9080/index.html

使用上述命令连续访问三次后，则会出现如下错误。

<html>
<head><title>503 Service Temporarily Unavailable</title></head>
<body>
<center><h1>503 Service Temporarily Unavailable</h1></center>
<hr><center>openresty</center>
</body>
</html>

返回上述结果，则表示 limit-count 插件已经配置成功。

流量控制插件#

APISIX 除了提供限流限速的插件外，还提供了很多其他的关于 traffic 插件来满足实际场景的需求：

  • proxy-cache：该插件提供缓存后端响应数据的能力，它可以和其他插件一起使用。该插件支持基于磁盘和内存的缓存。
  • request-validation：该插件用于提前验证向上游服务转发的请求。
  • proxy-mirror：该插件提供了镜像客户端请求的能力。流量镜像是将线上真实流量拷贝到镜像服务中，以便在不影响线上服务的情况下，对线上流量或请求内容进行具体的分析。
  • api-breaker：该插件实现了 API 熔断功能，从而帮助我们保护上游业务服务。
  • traffic-split：该插件使用户可以逐步引导各个上游之间的流量百分比。，你可以使用该插件实现蓝绿发布，灰度发布。
  • request-id：该插件通过 APISIX 为每一个请求代理添加 unique ID 用于追踪 API 请求。
  • proxy-control：该插件能够动态地控制 NGINX 代理的相关行为。
  • client-control：该插件能够通过设置客户端请求体大小的上限来动态地控制 NGINX 处理客户端的请求。

管理 API 消费者

本教程介绍了如何使用 Apache APISIX 管理单个或多个 API 消费者（API Consumers）。

如今，API 使得多个系统、内部服务以及第三方应用能够轻松且安全地互联。API 消费者（API consumers）对于 API 提供方来说是最重要的利益相关者之一，因为他们与 API 及开发者门户的交互最为频繁。本文将介绍如何使用开源 API 管理解决方案 Apache APISIX 来管理单个或多个 API 消费者。

Manage API Consumers

API 消费者（API Consumers）#

API 消费者是指使用某个 API 的用户，但他们并不会专门为该 API 开发应用。换句话说，API 消费者就是 API 的使用者。 例如，市场部门可能会使用 Facebook API 来分析社交媒体上对特定活动的反馈，他们会在需要时向提供的 API 发送独立且不定期的请求。

一个 API 管理 解决方案需要能够识别谁是 API 的消费者，以便针对不同的消费者配置不同的规则。

Apache APISIX 中的消费者（Consumers）#

在 Apache APISIX 中，Consumer 对象 是 API 消费者访问通过 API 网关（API Gateway） 发布的 API 的主要方式。 当不同的消费者请求同一个 API，而你需要针对不同消费者执行不同的 插件（Plugin） 或 上游（Upstream） 配置时，Consumer 概念会非常有用。

通过 Apache APISIX API 网关发布 API 后，可以轻松使用消费者密钥（consumer key，也称订阅密钥 subscription key）来保护 API 访问。 需要使用已发布 API 的开发者必须在调用这些 API 的 HTTP 请求中包含有效的订阅密钥。若订阅密钥无效，API 网关会立即拒绝请求，而不会将其转发到后端服务。

消费者可以关联不同的作用范围：按插件、所有 API 或单个 API。 在 API 网关中，结合插件使用消费者对象可以实现多种场景：

  1. 为不同消费者启用不同的认证方式。 当消费者尝试通过不同认证机制（如 API key、Basic、或基于 JWT 的认证）访问 API 时，这种机制非常有用。
  2. 限制特定消费者对 API 资源的访问。
  3. 根据消费者将请求路由到相应的后端服务。
  4. 定义数据消费的速率限制。
  5. 分析单个消费者或消费者子集的数据使用情况。

Apache APISIX Consumer 示例#

下面我们来看一个示例，演示如何结合 key-auth 认证插件（API Key）与 limit-count 插件，为单个消费者或一组消费者配置限流策略。

在本示例中，我们将使用一个基于 ASP.NET Core Web API 的 示例项目，该项目包含一个简单的 GET 接口，用于获取商品列表。 项目的运行方式可在其 README 文件 中找到详细说明。

为单个消费者启用限流（Rate Limiting）#

假设此时示例项目已经启动运行。 要将消费者对象与上述两个插件配合使用，我们需要执行以下步骤：

  1. 创建一个新的 Consumer（消费者） 。
  2. 为该消费者配置认证插件 key-auth 和限流插件 limit-count。
  3. 创建新的 Route（路由） ，并设置路由规则（如有需要）。
  4. 为该路由启用 key-auth 插件配置。

以上步骤只需通过两条 curl 命令 调用 APISIX 的 Admin API 即可完成。

第一条命令创建一个启用了 API Key 认证的 新消费者，并配置限流规则： 该消费者在 60 秒内最多只能调用产品 API 两次。

curl http://127.0.0.1:9180/apisix/admin/consumers -H "X-API-KEY: $admin_key" -X PUT -d '
{
   "username":"consumer1",
   "plugins":{
      "key-auth":{
         "key":"auth-one"
      },
      "limit-count":{
         "count":2,
         "time_window":60,
         "rejected_code":403,
         "rejected_msg":"Requests are too many, please try again later or upgrade your subscription plan.",
         "key":"remote_addr"
      }
   }
}'

接下来，我们定义一个新的 Route（路由）  与 Upstream（上游） ， 使得所有到达网关端点 /api/products 的请求在通过认证后，都会被转发到示例项目的产品服务。

curl http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -d '
{
  "name": "Route for consumer request rate limiting",
  "methods": [
    "GET"
  ],
  "uri": "/api/products",
  "plugins": {
      "key-auth": {}
  },
  "upstream": {
    "type": "roundrobin",
    "nodes": {
      "productapi:80": 1
    }
  }
}'

在此配置下，Apache APISIX 将正常处理前两次请求， 但在相同的 60 秒时间窗口内的 第三次请求 将返回一个 403 HTTP 状态码。

curl http://127.0.0.1:9080/api/products -H 'apikey: auth-one' -i

如果在 60 秒内连续调用三次接口，示例输出如下：

HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Server: APISIX/2.13.1

{"error_msg":"Requests are too many, please try again later or upgrade your subscription plan."}

当请求次数达到阈值后，APISIX 将拒绝后续请求。

为消费者组启用限流（Rate Limiting for Consumer Groups）#

在 Apache APISIX 中，Consumer Group（消费者组） 对象用于管理开发者对后端服务的可见性。 后端服务首先对特定组可见，然后组内的开发者即可查看并订阅与该组关联的产品。

借助消费者组，你可以为一组消费者定义多级限流策略，而无需逐个管理每个消费者。

典型场景包括：

  • API 商业化中的不同定价策略，例如“Basic 套餐”的消费者每分钟允许调用 50 次 API；
  • 或根据用户角色（管理员、开发者、访客等）启用不同的 API 权限访问。

你可以通过 Apache APISIX 的管理 REST API 中的 Consumer Group 实体 来创建、更新、删除和管理消费者组。

Consumer groups 示例#

为了演示，我们将分别为 Basic（基础）  和 Premium（高级）  两种套餐创建两个消费者组（Consumer Group）。 我们可以为每个组添加一个或两个消费者，并通过 rate-limiting 插件来控制来自不同消费者组的流量。

要在限流场景中使用消费者组，你需要执行以下步骤：

  • 创建一个或多个启用了 limit-count 插件的消费者组。
  • 创建消费者（Consumers），并将它们分配到对应的组中。

下面的两条 curl 命令用于分别创建名为 basic_plan 和 premium_plan 的消费者组：

创建 Basic Plan（基础套餐）的消费者组

curl http://127.0.0.1:9180/apisix/admin/consumer_groups/basic_plan -H "X-API-KEY: $admin_key" -X PUT -d '
{
    "plugins": {
        "limit-count": {
            "count": 2,
            "time_window": 60,
            "rejected_code": 403,
            "group": "basic_plan"
        }
    }
}'

创建 Premium Plan（高级套餐）的消费者组

curl http://127.0.0.1:9180/apisix/admin/consumer_groups/premium_plan -H "X-API-KEY: $admin_key" -X PUT -d '
{
    "plugins": {
        "limit-count": {
            "count": 200,
            "time_window": 60,
            "rejected_code": 403,
            "group": "premium_plan"
        }
    }
}'

在上述步骤中，我们为 Basic Plan 设置了限流规则：每 60 秒内仅允许 2 次请求； 而 Premium Plan 则允许在相同时间窗口内执行 200 次 API 请求。

创建并将第一个消费者加入 Basic 组

curl http://127.0.0.1:9180/apisix/admin/consumers -H "X-API-KEY: $admin_key" -X PUT -d '
{
    "username": "consumer1",
    "plugins": {
        "key-auth": {
            "key": "auth-one"
        }
    },
    "group_id": "basic_plan"
}'

创建并将第二个消费者加入 Premium 组

curl http://127.0.0.1:9180/apisix/admin/consumers -H "X-API-KEY: $admin_key" -X PUT -d '
{
    "username": "consumer2",
    "plugins": {
        "key-auth": {
            "key": "auth-two"
        }
    },
    "group_id": "premium_plan"
}'

创建并将第三个消费者加入 Premium 组

curl http://127.0.0.1:9180/apisix/admin/consumers -H "X-API-KEY: $admin_key" -X PUT -d '
{
    "username": "consumer3",
    "plugins": {
        "key-auth": {
            "key": "auth-three"
        }
    },
    "group_id": "premium_plan"
}'

之后，我们可以验证限流效果： 属于 Basic Plan 组的第一个消费者 consumer1 在 1 分钟内调用 API 超过 2 次后，将收到 403 HTTP 状态码错误； 而属于 Premium Plan 组的其他两个消费者则可继续请求，直到达到各自的请求上限。

你可以通过在请求头中更换认证密钥来执行以下命令进行测试：

curl -i http://127.0.0.1:9080/api/products -H 'apikey: auth-one'

curl -i http://127.0.0.1:9080/api/products -H 'apikey: auth-two'

curl -i http://127.0.0.1:9080/api/products -H 'apikey: auth-three'

请注意，你还可以在任意时刻将消费者添加到或移出消费者组，并启用其他内置插件。

API 响应缓存

本教程将主要介绍如何在 API 网关 级别进行缓存处理，使用 Apache APISIX API 网关，你将学习如何使用 proxy-cache 插件来提升 Web 或微服务 API 的响应效率。

本次教程涵盖的内容概览：

通过缓存提升性能#

在构建 API 时，你希望保持其简单且高效。当并发请求需要访问相同数据量增加时，你可能会遇到一些问题，从而考虑引入 缓存：

  • 某些 API 请求存在延迟，明显影响用户体验。
  • 从数据库获取数据响应时间过长。
  • API 的高吞吐量可能威胁到其可用性。
  • 网络故障导致频繁访问的 API 信息获取失败。

API 网关中的缓存#

缓存能够存储并获取网络请求及其对应的响应。在 Web 应用中，缓存可以发生在不同层级：

  • 边缘缓存或 CDN
  • 数据库缓存
  • 服务器缓存（API 缓存）
  • 浏览器缓存

反向代理缓存（Reverse Proxy Caching）  是另一种缓存机制，通常在 API 网关 内部实现。它可以减少对后端接口的调用次数，并通过缓存上游响应来提高 API 请求的延迟表现。如果 API 网关缓存中存在请求资源的最新副本，它会直接使用该副本响应请求，而无需访问后端服务。如果未命中缓存，请求将转发到目标上游服务（后端服务）。

Apache APISIX API 网关代理缓存#

借助 Apache APISIX，你可以使用 proxy-cache 插件为 API 启用缓存，从而缓存 API 端点的响应并提升性能。该插件可以与其他插件组合使用，目前支持基于磁盘的缓存。

要缓存的数据可以通过 responseCodes、requestModes 进行过滤，也可以使用 noCache 和 cacheByPass 属性进行更复杂的过滤。你还可以在插件配置中指定缓存的过期时间或内存容量。更多配置项请参考 proxy-cache 插件的 属性说明。

有了这些基础，我们接下来将通过一个例子演示如何使用 Apache APISIX 的 proxy-cache 插件，并将其应用于 ASP.NET Core Web API 的单个端点。

运行演示项目#

到目前为止，我假设你已经启动并运行了演示项目 apisix-dotnet-docker。你可以在 GitHub 上查看完整源码，以及如何通过 Docker CLI 构建多容器 APISIX 的说明。

在 ASP.NET Core 项目 中，有一个简单的 API，用于从服务层获取所有产品列表，位于 ProductsController.cs 文件中。

假设这个产品列表通常每天只更新一次，而该端点每天需要处理数十亿次请求来部分或全部获取产品列表。在这种场景下，使用 proxy-cache 插件进行 API 缓存将非常有用。为了演示的目的，我们仅为 GET 方法启用缓存。

理想情况下，GET 请求应该默认是可缓存的——除非出现特殊条件。

配置 Proxy Cache 插件#

现在，让我们开始在项目的 Apache APISIX 声明式配置文件 config.yaml 中添加 proxy-cache 插件。由于在当前项目中，我们还没有注册本次演示要使用的插件，因此需要将 proxy-cache 插件名称添加到插件列表末尾：

plugins:
 - http-logger
 - ip-restriction
 …
 - proxy-cache

如果你需要指定缓存相关参数（如 disk_size、memory_size），也可以在同一个文件中添加缓存配置，例如：

proxy_cache:
 cache_ttl: 10s # 如果上游未指定缓存时间，则使用默认缓存时间
 zones:
 - name: disk_cache_one # 缓存名称。管理员可以在 Admin API 中按名称指定使用哪个缓存
 memory_size: 50m # 用于存储缓存索引的共享内存大小
 disk_size: 1G # 用于存储缓存数据的磁盘大小
 disk_path: "/tmp/disk_cache_one" # 缓存数据存储路径
 cache_levels: "1:2" # 缓存的层级结构

接下来，我们可以直接运行 apisix reload 命令来重新加载最新的插件代码，而无需重启 Apache APISIX。重新加载新插件的命令如下：

curl http://127.0.0.1:9180/apisix/admin/plugins/reload -H "X-API-KEY: $admin_key" -X PUT

然后，我们运行两个 curl 命令来为 /api/products 端点配置 Upstream 和 Route。首先，创建一个示例 Upstream（也就是我们的 API 服务器）：

curl "http://127.0.0.1:9180/apisix/admin/upstreams/1" -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d '
{
  "type": "roundrobin",
  "nodes": {
    "productapi:80": 1
  }
}'

接下来，我们为 /api/products 添加一个具备缓存能力的路由，通过在 plugins 属性中设置 proxy-cache 插件，并通过 upstream_id 引用上游服务，将请求转发到 API 服务器：

curl "http://127.0.0.1:9180/apisix/admin/routes/1" -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d '{
  "name": "Route for API Caching",
  "methods": [
    "GET"
  ],
  "uri": "/api/products",
  "plugins": {
    "proxy-cache": {
      "cache_key": [
        "$uri",
        "-cache-id"
      ],
      "cache_bypass": [
        "$arg_bypass"
      ],
      "cache_method": [
        "GET"
      ],
      "cache_http_status": [
        200
      ],
      "hide_cache_headers": true,
      "no_cache": [
        "$arg_test"
      ]
    }
  },
  "upstream_id": 1
}'

如上配置所示，我们定义了一些插件属性，表示只缓存 GET 方法的成功响应（HTTP 200） 。

验证 Proxy Cache 功能#

最后，我们可以测试代理缓存是否按预期工作。

我们将向 /api/products 路径发送多次请求，每次都应收到 HTTP 200 OK 响应。然而，响应头中的 Apisix-Cache-Status 会显示 MISS，表示当请求第一次访问路由时，该响应尚未缓存。此时，如果再次发送请求，你会看到响应已被缓存，Apisix-Cache-Status 显示 HIT。

首先，发送初始请求：

curl http://localhost:9080/api/products -i

响应示例：

HTTP/1.1 200 OK
…
Apisix-Cache-Status: MISS

当你再次调用该服务时，由于上一次请求已缓存，路由会返回缓存的响应：

HTTP/1.1 200 OK
…
Apisix-Cache-Status: HIT

如果在缓存的 TTL（生存时间）  结束后再次访问端点，你将得到：

HTTP/1.1 200 OK
…
Apisix-Cache-Status: EXPIRED

太棒了！我们已经为 API 端点启用了缓存。

额外测试案例#

你也可以在 Product Controller 代码中添加一些延迟，并测量有缓存和无缓存情况下的响应时间：

[HttpGet]
public IActionResult GetAll()
{
    Console.Write("The delay starts.\n");
    System.Threading.Thread.Sleep(5000);
    Console.Write("The delay ends.");
    return Ok(_productsService.GetAll());
}

使用 curl 命令测量响应时间：

curl -i 'http://localhost:9080/api/products' -s -o /dev/null -w "Response time: %{time_starttransfer} seconds\n"

配置客户端与 APISIX 之间的双向认证（mTLS）

mTLS 是一种双向身份认证的方式。如果在你的网络环境中，要求只有受信任的客户端才可以访问服务端，那么可以启用 mTLS 来验证客户端的身份，保证服务端 API 的安全。本文主要介绍了如何配置客户端与 Apache APISIX 之间的双向认证（mTLS）。

配置#

本示例包含以下过程：

  1. 生成证书；
  2. 在 APISIX 中配置证书；
  3. 在 APISIX 中创建并配置路由；
  4. 测试验证。

为了使测试结果更加清晰，本文提到的示例会向上游传递一些有关客户端证书的信息，其中包括：serial，fingerprint 和 common name。

生成证书#

我们需要生成三个测试证书，分别是根证书、服务器证书、客户端证书。只需通过以下命令，就可以通过 OpenSSL 生成我们需要的测试证书。

# 根证书
openssl genrsa -out ca.key 2048
openssl req -new -sha256 -key ca.key -out ca.csr -subj "/CN=ROOTCA"
openssl x509 -req -days 36500 -sha256 -extensions v3_ca -signkey ca.key -in ca.csr -out ca.cer

# 服务器证书
openssl genrsa -out server.key 2048
# 注意：CN 值中的 `test.com` 为我们要测试的域名/主机名。
openssl req -new -sha256 -key server.key -out server.csr -subj "/CN=test.com"
openssl x509 -req -days 36500 -sha256 -extensions v3_req  -CA  ca.cer -CAkey ca.key  -CAserial ca.srl  -CAcreateserial -in server.csr -out server.cer

# 客户端证书
openssl genrsa -out client.key 2048
openssl req -new -sha256 -key client.key  -out client.csr -subj "/CN=CLIENT"
openssl x509 -req -days 36500 -sha256 -extensions v3_req  -CA  ca.cer -CAkey ca.key  -CAserial ca.srl  -CAcreateserial -in client.csr -out client.cer

# 将客户端证书转换为 pkcs12 供 Windows 使用（可选）
openssl pkcs12 -export -clcerts -in client.cer -inkey client.key -out client.p12

在 APISIX 中配置证书#

使用 curl 命令请求 APISIX Admin API 创建一个 SSL 资源并指定 SNI。

注意

证书中的换行需要替换为其转义字符 \n

curl -X PUT 'http://127.0.0.1:9180/apisix/admin/ssls/1' \
--header 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' \
--header 'Content-Type: application/json' \
--data-raw '{
    "sni": "test.com",
    "cert": "<服务器证书>",
    "key": "<服务器证书私钥>",
    "client": {
        "ca": "<客户端证书公钥>"
    }
}'
  • sni：指定证书的域名（CN），当客户端尝试通过 TLS 与 APISIX 握手时，APISIX 会将 ClientHello 中的 SNI 数据与该字段进行匹配，找到对应的服务器证书进行握手。
  • cert：服务器证书。
  • key：服务器证书的私钥。
  • client.ca：用来验证客户端证书的 CA 文件。为了演示方便，这里使用了同一个 CA。

配置测试路由#

使用 curl 命令请求 APISIX Admin API 创建一个路由。

curl -X PUT 'http://127.0.0.1:9180/apisix/admin/routes/1' \
--header 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' \
--header 'Content-Type: application/json' \
--data-raw '{
    "uri": "/anything",
    "plugins": {
        "proxy-rewrite": {
            "headers": {
                "X-Ssl-Client-Fingerprint": "$ssl_client_fingerprint",
                "X-Ssl-Client-Serial": "$ssl_client_serial",
                "X-Ssl-Client-S-DN": "$ssl_client_s_dn"
            }
        }
    },
    "upstream": {
        "nodes": {
            "httpbin.org":1
        },
        "type":"roundrobin"
    }
}'

APISIX 会根据 SNI 和上一步创建的 SSL 资源自动处理 TLS 握手，所以我们不需要在路由中指定主机名（但也可以显式地指定主机名）。

另外，上面 curl 命令中，我们启用了 proxy-rewrite 插件，它将动态地更新请求头的信息，示例中变量值的来源是 NGINX 变量，你可以在这里找到它们：nginx.org/en/docs/htt…

测试验证#

由于我们使用域名 test.com 作为测试域名，在开始验证之前，我们必须先将测试域名添加到你的 DNS 或者本地的 hosts 文件中。

  1. 如果我们不使用 hosts，只是想测试一下结果，那么你可以使用下面的命令直接进行测试：
curl --resolve "test.com:9443:127.0.0.1" https://test.com:9443/anything -k --cert ./client.cer --key ./client.key

2. 如果你需要修改 hosts，请阅读下面示例（以 Ubuntu 为例）：

  • 修改 /etc/hosts 文件

    # 127.0.0.1 localhost
127.0.0.1 test.com

  • 验证测试域名是否生效

    ping test.com

PING test.com (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.028 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.037 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=3 ttl=64 time=0.036 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=4 ttl=64 time=0.031 ms
^C
--- test.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3080ms
rtt min/avg/max/mdev = 0.028/0.033/0.037/0.003 ms

  • 测试

    curl https://test.com:9443/anything -k --cert ./client.cer --key ./client.key

    然后你将收到下面的响应体：

    {
  "args": {},
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Accept": "*/*",
    "Host": "test.com",
    "User-Agent": "curl/7.81.0",
    "X-Amzn-Trace-Id": "Root=1-63256343-17e870ca1d8f72dc40b2c5a9",
    "X-Forwarded-Host": "test.com",
    "X-Ssl-Client-Fingerprint": "c1626ce3bca723f187d04e3757f1d000ca62d651",
    "X-Ssl-Client-S-Dn": "CN=CLIENT",
    "X-Ssl-Client-Serial": "5141CC6F5E2B4BA31746D7DBFE9BA81F069CF970"
  },
  "json": null,
  "method": "GET",
  "origin": "127.0.0.1",
  "url": "http://test.com/anything"
}

由于我们在示例中配置了 proxy-rewrite 插件，我们可以看到响应体中包含上游收到的请求体，包含了正确数据。

基于对 URI 正则表达式匹配，绕过 MTLS#

APISIX 允许配置 URI 白名单以便绕过 MTLS。如果请求的 URI 在白名单内，客户端证书将不被检查。注意，如果针对白名单外的 URI 发请求，而该请求缺乏客户端证书或者提供了非法客户端证书，会得到 HTTP 400 响应，而不是在 SSL 握手阶段被拒绝。

时序图#

skip mtls

例子#

  1. 配置路由和证书
note

您可以这样从 config.yaml 中获取 admin_key 并存入环境变量：

admin_key=$(yq '.deployment.admin.admin_key[0].key' conf/config.yaml | sed 's/"//g')

curl http://127.0.0.1:9180/apisix/admin/routes/1 \
-H "X-API-KEY: $admin_key" -X PUT -d '
{
    "uri": "/*",
    "upstream": {
        "nodes": {
            "httpbin.org": 1
        }
    }
}'

curl http://127.0.0.1:9180/apisix/admin/ssls/1 \
-H "X-API-KEY: $admin_key" -X PUT -d '
{
    "cert": "'"$(<t/certs/mtls_server.crt)"'",
    "key": "'"$(<t/certs/mtls_server.key)"'",
    "snis": [
        "*.apisix.dev"
    ],
    "client": {
        "ca": "'"$(<t/certs/mtls_ca.crt)"'",
        "depth": 10,
        "skip_mtls_uri_regex": [
            "/anything.*"
        ]
    }
}'

2. 如果没提供客户端证书，而 URI 又不在白名单内，会得到 HTTP 400 响应。

curl https://admin.apisix.dev:9443/uuid -v \
--resolve 'admin.apisix.dev:9443:127.0.0.1' --cacert t/certs/mtls_ca.crt
* Added admin.apisix.dev:9443:127.0.0.1 to DNS cache
* Hostname admin.apisix.dev was found in DNS cache
*   Trying 127.0.0.1:9443...
* TCP_NODELAY set
* Connected to admin.apisix.dev (127.0.0.1) port 9443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: t/certs/mtls_ca.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Request CERT (13):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=cn; ST=GuangDong; L=ZhuHai; CN=admin.apisix.dev; OU=ops
*  start date: Dec  1 10:17:24 2022 GMT
*  expire date: Aug 18 10:17:24 2042 GMT
*  subjectAltName: host "admin.apisix.dev" matched cert's "admin.apisix.dev"
*  issuer: C=cn; ST=GuangDong; L=ZhuHai; CN=ca.apisix.dev; OU=ops
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x56246de24e30)
> GET /uuid HTTP/2
> Host: admin.apisix.dev:9443
> user-agent: curl/7.68.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 400
< date: Fri, 21 Apr 2023 07:53:23 GMT
< content-type: text/html; charset=utf-8
< content-length: 229
< server: APISIX/3.2.0
<
<html>
<head><title>400 Bad Request</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<hr><center>openresty</center>
<p><em>Powered by <a href="https://apisix.apache.org/">APISIX</a>.</em></p></body>
</html>
* Connection #0 to host admin.apisix.dev left intact

3. 虽然没提供客户端证书，但是 URI 在白名单内，请求会被成功处理和响应。

curl https://admin.apisix.dev:9443/anything/foobar -i \
--resolve 'admin.apisix.dev:9443:127.0.0.1' --cacert t/certs/mtls_ca.crt
HTTP/2 200
content-type: application/json
content-length: 416
date: Fri, 21 Apr 2023 07:58:28 GMT
access-control-allow-origin: *
access-control-allow-credentials: true
server: APISIX/3.2.0
...

WebSocket Authentication

Apache APISIX supports WebSocket traffic, but the WebSocket protocol doesn't handle authentication. This article guides you on how to configure authentication for WebSocket connections using Apache APISIX.

WebSocket Protocol#

To establish a WebSocket connection, the client sends a WebSocket handshake request, for which the server returns a WebSocket handshake response as shown below:

Client request

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

Server response

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

The handshake workflow is shown below:

Websocket Handshake Workflow

WebSocket Authentication#

APISIX supports several authentication methods like basic-auth, key-auth, and jwt-auth.

While establishing connections from the client to server in the handshake phase, APISIX first checks its authentication information before choosing to forward the request or deny it.

Prerequisites#

Before you move on, make sure you have:

  1. A WebSocket server as the Upstream. This article uses Postman's public echo service: wss://ws.postman-echo.com/raw.
  2. APISIX 3.0 installed.

Configuring Authentication#

Create a Route#

First we will create a Route to the Upstream echo service.

Since the Upstream uses wss protocol, the scheme is set to https. We should also set enable_websocket to true.

In this tutorial, we will use the key-auth Plugin. This would work similarly for other authentication methods:

curl --location --request PUT 'http://127.0.0.1:9180/apisix/admin/routes/1' \
--header 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' \
--header 'Content-Type: application/json' \
--data-raw '{
    "uri": "/*",
    "methods": ["GET"],
    "enable_websocket": true,
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "ws.postman-echo.com:443": 1
        },
        "scheme": "https"
    },
    "plugins": {
        "key-auth": {}
    }
}'

Create a Consumer#

We will now create a Consumer and add a key this_is_the_key. A user would now need to use this key configured in the Consumer object to access the API.

curl --location --request PUT 'http://127.0.0.1:9180/apisix/admin/consumers/jack' \
--header 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' \
--header 'Content-Type: application/json' \
--data-raw '{
    "username": "jack",
    "plugins": {
        "key-auth": {
            "key": "this_is_the_key"
        }
    }
}'

Testing the Route#

Now, if you try to connect ws://127.0.0.1:9080/raw without the apikey header or an incorrect key, APISIX will return a 401 Unauthorized.

Connect without Key

To authenticate, you can add the header apikey with the value this_is_the_key:

Connect with key 过去几年，大模型（LLM）和生成式 AI 技术迅猛发展，各行各业纷纷将 AI 功能融入应用。这带来了激增的 AI API 流量和全新的管理挑战。企业开始采用混合云 AI 架构——既调用 OpenAI 等云端大模型服务，也部署开源 LLM 至本地集群。这种模式提供了灵活性，但也产生了数据安全、多模型管理、性能与可靠性等难题。传统 API Gateway 在应对这些AI 场景特有的问题时显得力不从心，需要演进出专门的 AI Gateway。

随着业界对 AI 集成需求的高涨，“AI Gateway”概念应运而生。各大开源社区和厂商敏锐捕捉到这一趋势，纷纷推出面向 AI 场景的网关解决方案。从 2023 年下半年起，我们看到 Envoy、Apache APISIX、Kong、Solo.io、F5 等相继发布 AI Gateway 项目或产品，将网关技术与 AI 场景深度结合，旨在简化 AI 接入、强化安全治理和降低成本。在行业观察者看来，这既是 API 网关在 AI 时代的自然演进，也是云原生社区合作创新的结果。特别值得一提的是，一些公司意识到仅靠封闭的企业付费功能无法满足广泛的 AI 需求，开始倡导开源协作。例如 Tetrate 与 Bloomberg 联合在 CNCF Envoy 项目下开源 Envoy AI Gateway，将关键的 AI 流量管理能力带入社区。总的来说，AI Gateway 的兴起标志着API 基础设施正围绕 AI 场景进行新一轮升级，以满足大模型应用快速普及带来的独特要求。

AI Gateway 与传统 API Gateway 的区别

表面上看，调用大模型的流程和普通 API 请求类似：客户端发送请求，网关转发给后端服务。然而LLM 服务的流量特性与传统 API 有显著不同，导致传统网关功能难以直接胜任：

图 1: 图示：AI Gateway 与传统 API Gateway 的区别

图 1: 图示：AI Gateway 与传统 API Gateway 的区别

  • 计量与限流维度不同：传统网关按请求次数限流，而对计算复杂、计费昂贵的 LLM 服务，需要按词元（token）用量来度量和控制使用。例如，一次简单请求可能消耗上千 token，超出普通限流策略的范畴。AI Gateway 引入基于 token 的用量限制功能，以更精细地管理 LLM 使用成本。
  • 请求/响应不可预测：LLM 输出具有非确定性，可能生成意外内容，需要网关对响应也进行检测过滤。传统网关很少深度检查响应内容，而 AI Gateway 内置了请求/响应双向内容审核和安全过滤机制，防止恶意输入到达模型，并保证输出不含敏感违规信息。例如 F5 的 AI Gateway 可以拦截含有隐私数据的提示，或在响应中移除机密信息。
  • 多后端动态路由：AI 场景下常需接入多个模型服务（不同厂商或不同能力模型）。传统网关处理固定后端尚可，但缺乏根据请求内容或策略在多模型间路由的能力。AI Gateway 则支持智能流量调度，可基于任务类型选择最合适的模型，或在模型故障/延迟高时自动切换。
  • 实时性与成本优化：调用大模型不仅关注服务质量，还需实时考虑成本权衡。例如在高并发场景下，既要保障响应速度又要控制每次调用的花费。AI Gateway 提供了动态负载均衡、弹性伸缩、按延迟/费用调整路由等高级特性，传统网关则缺乏对“每次调用成本”的感知。
  • 性能并发要求更高：许多早期企业用简单的 Python 代理来接入 LLM，但 Python GIL 等因素限制了并发性能。相比之下，AI Gateway 通常构建在高性能代理内核上（如 Envoy），能够高效处理海量并发的流式响应。这使其在大规模 AI 调用场景下更胜任。
  • 上下文与状态管理：一些 AI 应用（例如对话式代理）需要维护对话上下文，多次往返交互。传统无状态网关对此支持有限，而 AI Gateway 可以提供会话级别的上下文缓存或与向量数据库集成来注入聊天记忆，从而更好地支持这类有状态的 AI 调用。

简而言之，AI Gateway 在计费计量、内容合规、多后端路由、性能优化等方面扩展了传统 API Gateway 的能力，以专门应对大模型流量的独特需求。这并非简单的营销包装，而是实际问题驱动的演进。例如 Envoy AI Gateway 专为 LLM 流量增加了 token 级流控、统一接入多家模型和上游鉴权等功能，以解决传统网关在这些方面的不足。再比如 F5 NGINX AI Gateway 强调对 LLM 请求/响应双向检查以及处理非确定性输出的能力，这是过去 API 网关所不涉及的新领域。这些差异充分说明了 AI Gateway 相对于经典网关的价值所在。

市面主要 AI Gateway 产品概览

随着 AI Gateway 概念走热，市面上出现了多种解决方案。下面整理了一些主流产品，并以多维度对比它们的特性：

产品名称开源/授权技术基础主要功能特色
Envoy AI Gateway开源（Apache v2）基于 Envoy Proxy + Envoy Gateway（CNCF 项目，由 Tetrate、Bloomberg 发起）Token 级用量限流、多 LLM 统一 API 入口、上游身份认证集成。首版支持 OpenAI、AWS Bedrock 等模型接入。
Apache APISIX AI Gateway开源（Apache License）基于 Apache APISIX（Lua/OpenResty）插件架构提供ai-proxy插件简化对接多种 LLM 服务，支持多 LLM 负载均衡、自动重试回退、Token 桶限流、内容审核等。以插件形式无缝融入 API 网关，实现统一管理 API 与 AI 流量。
Kong AI Gateway开源（Konnect 平台，可自托管）基于 Kong Gateway（Lua+C）扩展支持 OpenAI、Anthropic、Azure、Cohere、LLaMA 等多模型，通过单一 API 网关接入。内置AI 请求/响应转换器，可动态修改提示和结果（如自动翻译或去除 PII）；提供提示模版、凭据集中管理、语义缓存、负载路由等 AI 特有功能。
Solo.io Gloo AI Gateway商业闭源 (企业版，基于开源 Envoy)基于 Envoy Proxy + Kubernetes Gateway API（Solo.io 企业产品）针对企业级 AI 应用的云原生网关，强调安全与生产可用性。特点包括：集中管理各模型的凭证和认证、提示过滤和增强（防御 Prompt 注入，统一追加系统提示）、使用监控与治理（实时统计各应用 LLM Token 消耗，防滥用)、模型性能优化（内置 RAG 检索增强，减少幻觉；语义向量缓存减少重复调用延迟）。
F5 NGINX AI Gateway商业闭源基于 NGINX (F5 私有扩展)专注于安全防护和流量管控的 AI 网关。能够在 LLM 调用链中执行细粒度的策略：如流量分级和路由（将请求导向适当的后端模型）、请求/响应内容审查（敏感信息遮蔽、违规内容拦截）、双向挂载插件处理（Processors 对请求或响应进行修改/拒绝/标记）。提供每次请求的完整日志审计和 OpenTelemetry 指标上报，满足企业合规需求。
Traefik Hub AI Gateway商业 SaaS 服务基于 Traefik Hub 平台（Go）将 AI Gateway 功能集成到 Traefik Hub，允许在 Kubernetes 环境中通过 CRD 定义AIService资源，实现对 Anthropic、OpenAI、Azure OpenAI、AWS Bedrock、Cohere、Mistral 等众多模型服务的统一配置和流量管理。支持将 AIService 像普通后端一样挂载到 Ingress 路由，方便集成现有流量管理机制。
MLflow AI Gateway开源（Apache License）基于 MLflow 平台（Python）Databricks 开源的 GenAI 工具套件部分，提供统一的 LLM 网关服务。通过 YAML 配置文件定义多个模型端点（如 completions、chat、embeddings），每个端点指定背后的模型提供商和模型名称，网关进程自动处理请求转发。特色在于集中管理 API Key（安全存储各模型密钥，避免在代码中散布）和简单的限流配置（可按每分钟调用次数限制特定端点）。适合需要在内部快速搭建 LLM 统一入口的团队。
Portkey AI Gateway开源（MIT Licensee）定制架构（JS/TS 实现，自称前端 NPM 可用）强调一体化的企业级 AI 流量平台：支持超过 1600+ 种模型/提供商的对接，提供统一的 API 访问层；具有智能路由功能，按延迟、成本动态选择模型并故障切换；内置结果缓存（包括语义缓存）来降低重复调用成本；提供密钥托管与虚拟密钥功能，将各模型密钥保存在其云端保管库中，并可创建子密钥分发给开发者使用，以实现调用隔离和配额控制。此外还有批量请求合并、统一 fine-tuning 接口等高级能力，主要面向需要快速集成多模型且追求极简开发体验的场景。

（注：以上产品信息基于截至 2025 年中旬方案整理，不同方案功能侧重有所区别。）

上表比较了当前较有代表性的 AI Gateway 实现。可以看出，无论开源还是商业方案，都围绕多模型接入、用量治理、安全合规、性能优化等方面提供了增强功能。接下来，我们将进一步拆解 AI Gateway 应具备的核心能力。

AI Gateway 应具备的核心能力

AI 网关的核心能力

AI Gateway 扩展了传统 API 网关，在安全、可观测、提示工程和可靠性四大方面为 AI 场景提供支持。具备上述能力的网关，才能帮助组织充分享受 AI 带来的红利，同时将风险与成本可控在合理范围内。

综合上述产品特性，一个完善的 AI Gateway 通常应提供如下关键能力：

图 2: 图示：AI Gateway 的核心能力

图 2: 图示：AI Gateway 的核心能力

  • 统一多模型接入：屏蔽不同大模型 API 差异，为应用提供统一的调用接口。开发者只需调用网关提供的标准 API，由网关路由到后端相应的模型服务，实现“一处集成，多处调用”。这包括支持多云/多厂商 LLM（如 OpenAI、Anthropic、Azure、本地开源模型等）的接入，以及灵活配置选择使用哪种模型。例如 Kong AI Gateway 支持在不改应用代码的情况下无缝切换不同提供商，以避免厂商锁定。

  • 流量治理与可靠性：提供完善的流量管理策略，确保 AI 服务稳定可靠。具体包括：

    • 智能路由与负载均衡：根据请求内容或策略，将流量分配给最佳的模型后端，支持多模型负载均衡，防止某个模型过载。可基于延迟、成功率、成本等动态调整权重，实现最佳路径选择。
    • 自动重试和降级：当上游模型服务出现错误或延迟过高时，网关应具备重试与故障切换机制，将请求自动切换到备用模型提供商，保证服务的连续性。必要时触发降级策略（如返回缓存结果或友好错误）。
    • 弹性限流与配额：支持细粒度的请求限速和配额控制。尤其重要的是基于 Token 用量的限流，按调用消耗的 tokens 数量进行计量，防止过度使用导致高额账单。另外也可按每用户/每应用设定调用次数上限等，避免单个应用滥用 AI 资源。

  • 安全与合规：AI Gateway 需要在请求进入模型以及响应返回客户端两个方向上提供安全保障：

    • 认证与授权：集成现有身份提供商，对调用方进行认证（如 API Key、JWT 验证），并基于调用者角色/权限授权访问不同 AI 能力。这样可防止未授权用户直接调用敏感的 AI 接口，并支持多租户隔离。
    • 敏感信息保护：在请求送入上游前执行提示词检查，比如自动检测并遮蔽用户输入中的敏感信息（PII）或机密内容，避免泄露给第三方模型。类似地，对模型返回的内容执行内容安全审核，过滤违禁输出或敏感数据，再返回给客户端。这充当了大模型应用的“安全闸”，防止不当输入输出造成合规风险。
    • 提示防护与规范：提供Prompt Template和Prompt Decorator机制，在用户提示前后自动添加企业规定的内容。例如统一加上系统指令以约束模型行为，或在检测到不当请求时主动改写/拒绝。这些功能保证大模型始终在受控范围内运作。

  • 提示工程与响应优化：网关层面加入Prompt Engineering相关能力，帮助提升 AI 应用效果：

    • RAG（检索增强生成） : 原生支持与知识库/向量数据库的集成，在请求流经网关时，自动根据用户问题检索相关资料并扩充到 prompt 上下文。这样模型可以利用企业内部知识作答，减少幻觉和错误。
    • Prompt 模板与装饰器: 允许运维人员在网关上定义标准的提示模板，或为所有请求附加额外上下文。例如每个请求统一附加使用指南，或者根据用户属性插入定制说明。这确保模型对不同调用保持一致的风格和格式输出。
    • 语义缓存: 针对重复或相似的请求，引入语义级缓存机制。网关可对 prompt 进行向量化表示，识别出与历史请求相似的问题并直接返回缓存答案。这样既降低延迟又节省调用成本。与传统键值缓存不同，语义缓存能容忍措辞差异，提高命中率。

  • 可观测性与治理：AI Gateway 作为流量中枢，还需提供丰富的监控和可观测能力，帮助运营团队掌握 AI 使用情况：

    • 用量跟踪: 实时统计每个应用/用户的 Token 消耗、请求次数和费用累积。通过仪表盘呈现AI 使用指标（如每小时 token 用量、平均响应时长等），便于运营决策和成本优化。
    • 日志与审计: 记录每次 AI 请求和响应的详细日志，包括提示内容（可选脱敏）、模型返回结果、耗时、token 数等。这些日志可用于事后审计和追责，以及模型输出质量分析。提到某些网关支持将完整请求 - 响应记录存档至安全存储（如 S3），满足企业合规要求。
    • 实时监控与报警: 集成开放遥测（OpenTelemetry），对模型延迟、错误率等关键指标进行监控。当出现异常（如响应时间剧增或失败率骤升）时触发报警，运维可以及时介入。还可通过追踪分析识别瓶颈，保障 AI 服务 SLA。

  • 开发者体验：降低应用集成 AI 的门槛，让开发和运维更高效：

    • 声明式配置与自服务: 提供 Kubernetes CRD、Dashboard 或配置文件等声明式方式来定义 AI 路由、策略，让平台团队可以方便地上线新模型服务、更新提示模版等，而无需改动应用代码。例如 Traefik Hub 提供 AIService CRD 定义，多云模型接入只需写几行 YAML。这实现了模型即服务的自服务交付。
    • 无代码集成: 通过插件化方式将 AI 能力注入现有 API。比如 Kong 支持在传统 API 网关流程中插入 AI 请求或 AI 响应转换插件，对现有 API 响应进行总结、翻译等处理，而不需要应用改造任何代码。这意味着为老系统批量加上 AI 能力成为可能，只要在网关层配置即可完成。
    • 多语言 SDK 支持: 一些 AI 网关还提供前端 SDK 或客户端库，封装了对统一网关 API 的调用，开发者使用熟悉的语言即可便捷调用内部多模型服务，无需关心鉴权或负载路由细节。

综上，AI Gateway 的核心能力可以归纳为 “多源统一、智能调度、安全可靠、可观可控” 。这些能力协同作用，为大规模 AI 应用保驾护航。例如 Apache APISIX 概括得很好：AI Gateway 扩展了传统 API 网关，在安全、可观测、提示工程和可靠性四大方面为 AI 场景提供支持。具备上述能力的网关，才能帮助组织充分享受 AI 带来的红利，同时将风险与成本可控在合理范围内。

AI Gateway 的架构解析

下图是 AI Gateway 的典型架构示意。网关位于客户端与各种大模型服务之间，内部包含接入层认证、安全过滤、提示处理、路由控制、监控观测等模块，对上游屏蔽差异、对下游提供统一入口，实现对 AI 流量的全面管理。

图 3: AI Gateway 架构图

图 3: AI Gateway 架构图

从架构上看，AI Gateway 通常部署为流量入口的反向代理，衔接客户端应用和后端 AI 服务。上图展示了一个简化的 AI Gateway 架构：客户端的请求首先到达网关，经过身份认证和基本校验后，进入一系列 AI 专属处理流程，最终由网关代替客户端与后端 LLM 服务交互，并将结果返回客户端。以下分步骤说明其内部工作原理：

图 4: 图示：AI 网关工作流程

图 4: 图示：AI 网关工作流程

  1. 接入层（Ingress） ：网关接收来自应用的请求（通常是 HTTP REST 或 gRPC 调用）。首先执行常规的认证与权限校验，比如验证 API Key/JWT、检查调用方是否有权限使用特定模型等。在 AI Gateway 中，这一步还包括请求解析和基础验证，如解析 prompt 内容、校验必需参数是否存在等。

  2. 安全过滤与增强：通过Processor（处理器）链或插件对请求进行检查和改写。典型操作包括：

    • 敏感信息清理：利用正则或 ML 模型扫描 prompt，自动遮蔽或移除如姓名、电话、信用卡号等敏感字段，防止泄漏。
    • 不良内容拦截：检查用户输入是否包含违禁词、仇恨言论等，如有则拒绝请求并返回错误，避免将不良输入发送给模型。
    • 提示预处理：根据策略对 prompt 进行修改或增强。例如添加统一的系统提示（“你是一个有礼貌的助手”），或在用户问题后附加从知识库查询的上下文（即 RAG）。这一阶段，网关可以调用内部集成的向量数据库或搜索服务，找到相关背景信息插入到 prompt 中，以提高回答准确性。
    • 策略标注：一些网关支持对请求打标签，以供后续路由决策使用。例如根据请求的预估 token 数量标记为“大请求”，路由层可以据此将大请求导向成本更低的自有模型运行。

  3. 路由与转发：网关根据配置的路由规则将请求指派给适当的上游 LLM 服务。路由决策可能参考多种因素：请求 URL 或路径（表示期望的模型类型，如/openai/chat/completions）、请求中的自定义头（指定提供商），以及前述过滤阶段添加的标签（如内容类别）等。AI Gateway 维护着后端模型服务的注册信息，包括每个提供商的调用端点、所需认证参数等。它会：

    • 选择模型提供方：如按策略选择 OpenAI 或本地模型，或实现多 LLM 分流。例如对于编程问题走 Codex 模型，其它问题走通用模型。
    • 附加上游鉴权：从网关的密钥管理模块检索对应提供商的 API Key 或 OAuth 令牌，添加到请求头或参数中，然后向上游 LLM 发起调用。调用过程中，网关还可对请求进行协议转换：不同模型可能期望不同的 JSON 字段或 URL 路径，网关会根据选择的提供商自动调整请求格式，使之符合目标 API（这通常由插件封装实现）。

  4. 响应处理：上游 LLM 返回结果后（通常是 JSON 或流式数据），网关接收并进入响应处理管道。这里的处理类似请求侧，也包括一系列安全与优化步骤：

    • 内容审核：扫描模型生成的文本，检查是否有违反政策的内容，如涉敏感政治、歧视言论或版权信息。如果命中违规，网关可以对响应做截断、替换处理，或直接返回错误响应给客户端。这一功能相当于在生成内容出口处加装“内容审查员”。
    • 结果增强或转换：根据需要对模型输出进行修改。例如通过响应 Transformer将结果翻译成另一种语言，或调用额外模型对输出做摘要然后再返回。又或是应用定义的模版，对原始回答包装成一定格式（比如包含引用来源等）。Kong 等网关甚至支持在响应阶段执行 PII 清理，再做一次敏感信息遮盖。
    • 缓存存储：如果启用了语义缓存或普通缓存策略，网关会将此次请求的问答对存储到缓存（内存或独立存储）中。下次遇到相同或相似的问题时，可以直接复用缓存结果而不真实调用模型，从而减少延迟和成本。

  5. 结果返回客户端：经过上述处理后，网关将最终的响应数据返回给调用客户端。对于支持流式响应的场景（如 ChatGPT 的逐字流式输出），AI Gateway 通常会以流（Stream） 形式将上游的分片结果实时转发给客户端，确保用户体验流畅。

  6. 日志与监控输出：在请求完成的同时，网关将本次调用的各类信息发送到监控系统。这包括：

    • 调用日志：记录请求路径、调用方、使用的模型、响应状态、耗时、token 数量等，保存到日志系统或时序数据库，以供离线分析和计费统计。
    • 指标上报：通过 OpenTelemetry 将延迟、错误率、吞吐等指标发送到监控后台，支持仪表盘观测和告警。
    • 审计存档（可选）：如果开启了审计模式，网关会将完整的 Prompt 和响应存档（通常敏感数据已脱敏）。这些记录可存放于安全的存储（如加密的对象存储），以满足合规要求或未来调试复现。

整个架构串联起 “入口控制 – 内容处理 – 智能路由 – 响应治理 – 监控闭环” 的流程。从实现上看，Envoy、NGINX 等高性能代理扮演了流量转发的核心，各种 AI 特有功能通过插件、过滤器或自定义模块注入。例如 Apache APISIX 通过“ai-proxy”等插件扩展 Envoy，Solo Gloo AI Gateway 则基于 Envoy WASM Filter 和 Kubernetes Gateway API 来实现类似功能。下面是一段在 Apache APISIX 中配置 OpenAI 路由的示例，展示 AI Gateway 的配置风格：

# Apache APISIX 路由配置示例：将 /model 路径代理到 OpenAI Chat Completion 接口
routes:
  - uri: /model
    upstream:
      type: roundrobin
      scheme: https
      pass_host: node
      nodes:
        "ignored:80": 1            # OpenAI 实际地址由插件处理，此处占位
    plugins:
      ai-proxy:
        provider: openai          # 指定上游提供商类型为 OpenAI
        auth:
          header:
            Authorization: "Bearer ${OPENAI_API_KEY}"  # 从环境变量注入 API 密钥
        options:
          model: gpt-4            # 选择调用的模型，比如 GPT-4
      key-auth:                   # 启用应用调用的身份认证（这里用简易的 key 认证）

上述配置通过 APISIX 的 ai-proxy 插件，实现了对 OpenAI Chat Completion API 的统一代理。开发者只需调用自己服务域名下的 /model 路径，即可由网关转发至 OpenAI，并且网关自动附加鉴权信息和模型参数，无需应用关心。这种配置驱动的模式体现了 AI Gateway 架构的便利性：模型接入细节下移到网关层处理，应用层得以与复杂的 AI 基础设施解耦。

使用案例：AI Gateway 在实际中的应用

为了更直观地理解 AI Gateway 的价值，我们来看一个实际应用场景。

假设一家大型金融企业希望上线一个面向内部员工的智能问答助手，用于查询公司政策、财务数据分析等。这个助手需要满足以下要求：

  • 多模型支持：简单提问由本地部署的小型开源模型（成本低、延迟小）来回答；复杂问题或需分析大量文本时则调用某云厂商的大型模型（如 OpenAI GPT-4）获取更高质量答案。
  • 数据安全：问题可能涉及内部机密数据，需确保敏感信息不泄露给外部模型。同时对模型返回的内容也要过滤，防止生成不当言论。
  • 使用管控：公司给不同部门分配了月度 AI 调用额度，需要统计每部门用了多少 token，并防止个别用户滥用。
  • 高可用：本地模型服务需有故障切换机制，当本地模型挂掉时自动切到云端模型作为备用，不影响用户提问。

针对以上需求，企业决定部署一套 AI Gateway 来统一管理内部的 AI 调用。Envoy AI Gateway 是一个理想选择，因为它专为多 LLM 场景设计且开源可自主管理。部署后，这套网关实现了如下效果：

图 5: 企业 AI Gateway 实际应用流程

图 5: 企业 AI Gateway 实际应用流程

  • 统一接入：提供一个统一的 REST 接口给前端聊天应用，例如 POST /api/ask。员工提问时，前端将问题发送到网关的这个接口。
  • 智能路由：Envoy AI Gateway 内部配置了路由策略：默认所有请求先尝试发送到本地 LLM 服务（部署了一个精调的开源模型，用于一般问题），但如果检测到问题复杂度高（例如问题长度超过阈值）或者本地服务响应缓慢，则网关自动将请求切换到 OpenAI 云服务。这一智能路由确保了响应质量与成本之间的平衡。
  • 数据安全：在将请求转发给外部云模型前，AI Gateway 会执行数据脱敏：通过内置的 PII 识别模块，将提问中的人名、财务数字等敏感信息用占位符替换，避免直接出现在外发请求中。同时附加一段指令提示模型不要索要公司机密数据。
  • 内容审查：模型生成回答后，网关同样执行内容审查。它使用预设的关键词和规则过滤模型回答，对于涉密内容或不符合公司政策的话语进行屏蔽或替换，然后再把净化后的回答发送给前端用户。员工看到的是经过安全审核的答案。
  • 监控治理：所有这些调用过程都会被详细地记录下来：网关日志记下了某部门某员工调用了哪个模型、用了多少 token、是否命中本地还是云端等信息。运维团队通过可视化看板发现本月市场部调用外部 GPT-4 次数激增，于是及时调整策略，对市场部增加调用审批流程以控成本。这种可观测性帮助企业实现了 AI 资源的精细化管理。

通过这个场景可以看到，AI Gateway 为复杂需求提供了一站式解决方案：它在前端应用和后端模型之间担当“中枢大脑”角色，自动做出了许多策略性决策，同时确保了安全和成本可控。对于企业而言，这意味着可以放心地在各种应用中嵌入 AI 功能，而不必担心数据泄露或费用失控。这也解释了为何像 Bloomberg 这样的公司会参与构建 Envoy AI Gateway 来满足自身在多模型、多环境下的 AI 流量管理需求：唯有一个强大的中间层，才能把异构的 AI 能力变成企业可用、可控的服务。

发展趋势：AI Gateway 的未来

正如早期的 API Gateway 之于微服务浪潮，AI Gateway 作为新兴产物也在快速演进，并呈现出一些值得关注的趋势：

图 6: 图示：AI Gateway 的未来

图 6: 图示：AI Gateway 的未来

  • 开源与标准化：目前多个 AI Gateway 项目走向开源和标准化道路。Envoy AI Gateway 在 CNCF 社区内协作，汇集多家公司需求共同演进；Solo.io 将自家 Kubernetes 网关（kgateway）和 Agent 框架（kagent）捐献给 CNCF，期望形成厂商无关的开源生态。未来可能出现统一的 AI Gateway 接入规范，例如业内或将定义类似 OpenAPI 的标准接口用于 LLM 服务，使网关能够更容易支持新模型类型。Google 等提出的 Model Context Protocol (MCP) 、AI Agent API (A2A)  等标准也有望融入网关，用于规范代理与多代理、多工具交互的流程。这些开放标准会让 AI Gateway 更具互操作性，降低用户的迁移成本。
  • Agent 化与复杂工作流支持：随着自主 Agent(自治代理) 概念兴起，AI 应用不再只是简单的一问一答，而可能是多个 AI Agent 协同完成复杂任务。为应对这一趋势，AI Gateway 正向“Agent Gateway”方向拓展。例如 Solo.io 新推出的 Agent Gateway，就是专门连接 AI Agents 与工具/LLM 的数据平面，支持 Agent 之间、Agent 与工具之间的通信协议（如 A2A 和 MCP）。可以预见，未来的 AI Gateway 将不仅管理“客户端到单一模型”的流量，还要管理“AI 到 AI”的复杂交互，形成人工智能时代的Agent Mesh 网络。这意味着网关需要支持长连接、回调、链式调用等更复杂的模式，并内置对 Agent 执行过程的监控和安全控制。例如，当一个 Agent 召唤另一个 Agent 或外部工具时，网关能够应用统一的身份鉴别和权限控制，以及在整体任务层面进行审计和监管。
  • 更深的云原生融合：AI Gateway 将进一步融入云原生基础设施，例如与服务网格（Service Mesh）、Kubernetes 平台深度结合。设想未来的服务网格控制平面可以统一编排 API 服务和 AI 服务的策略，下层数据面通过 Envoy 同时承担传统流量和 AI 流量，两者应用一致的安全/观测策略。这种融合让运维对应用流量做到统一治理。实际上，一些云厂商正尝试将 AI Gateway 功能集成到自家 API 管理产品中：如 Google Apigee 提供了针对 LLM API 的流量控制方案，把模型 API 看作普通 API 来管控，但辅以 token 计费等自定义逻辑；Azure API Management 也在探索增加对 AI 服务的特殊支持。这表明AI 流量管理将逐步成为 API 管理套件的标配功能，而非完全独立的系统。
  • 性能优化与边缘部署：随着企业对实时 AI 响应要求提高，AI Gateway 的部署形态也在演变。一方面是更高的性能优化——例如引入 eBPF 加速某些内容扫描操作，或者利用 GPU 加速流量中的 AI 相关计算（如实时关键词识别）。另一方面，出现边缘 AI 网关的需求：将部分 AI Gateway 能力下沉到边缘节点，在靠近用户的地方就近缓存常见问答、执行基础的内容过滤，以降低中心节点压力和时延。Cloudflare 等边缘网络公司可能也加入这个领域，将 AI Gateway 功能融入 CDN/边缘代理中，实现中心 - 边缘协同的 AI 流量分发。
  • 安全与合规升级：未来 AI 应用监管可能趋严，AI Gateway 将承担更多合规责任。例如强制审查某些领域的 AI 输出，记录 AI 决策依据（模型产生回答时引用了哪些资料）等。网关可能需要与 “模型监察” 系统对接，在返回结果前让另一套 AI 检测其是否存在不实信息或偏见，再决定是否放行。这类二次审核将可能被集成到 AI Gateway 流程中，形成多层安全网。同时，在隐私保护方面，Gateway 或将内置联邦学习、机密计算等模块，在使用外部 AI 时对数据加密处理，确保连提供商也无法明文获取用户输入。

总体而言，AI Gateway 正朝着更开放、更智能、更无处不在的方向发展。从 API 到 Agent、从中心到边缘，我们会看到网关技术不断延伸其触角，覆盖 AI 应用的各个角落。这也印证了这样一个观点：在 AI 驱动的软件架构中，Gateway 的重要性有增无减，它是连接模型智能与业务逻辑的关键枢纽。正如 APISIX 博客所说，随着 AI 版图扩张，AI Gateway 将成为安全高效部署 AI 的支柱。

瓶颈与局限：AI Gateway 面临的问题

尽管 AI Gateway 为 AI 落地提供了诸多助力，但目前仍存在一些发展中的瓶颈和局限需要正视：

图 7: 图示：AI Gateway 面临的问题

图 7: 图示：AI Gateway 面临的问题

  • 生态尚未成熟：大多数 AI Gateway 项目诞生时间不长，不论是功能完整度还是稳定性都在快速迭代中。一些开源项目仍处于早期版本（如 Envoy AI Gateway 刚发布 0.2 版本），功能相对有限，只覆盖了基本的三两项能力。许多高级特性（如复杂的内容审核、语义缓存等）在开源版本中缺失，需要商业版支持，导致早期采用者必须在开源灵活性和企业功能之间权衡。业界也提醒，目前不少 AI 流量工具仍未经大规模生产验证，投入关键业务前需谨慎评估。
  • 标准之争与兼容性：各家 AI Gateway 对接模型 API 时采用的接口规范不统一。虽然很多产品声称支持多种模型，但实际上往往是内置适配了有限的几个主流服务（OpenAI、Anthropic 等）。当新模型或新 API 出现时，可能需要等待网关升级甚至自己开发插件。这种局面类似早期 API 网关时代不同 REST 规范混战，需要一个统一标准来降低碎片化。在标准统一前，不同 Gateway 的配置和插件无法通用，用户存在锁定风险。目前 Google、Meta 等提出的新协议（如 A2A、MCP）能否被广泛接受尚不明朗，标准之争在所难免。
  • 性能开销：引入 AI Gateway 不可避免增加了一跳网络开销和处理延迟。对于要求毫秒必争的应用（如实时互动 AI），网关的内容扫描、RAG 查询、日志记录都会造成额外的延迟。虽然高性能代理（Envoy/NGINX）将开销降至极小，但复杂策略处理可能带来显著性能损耗。尤其在响应路径做内容审核或语义匹配时，可能要同步调用其它服务或模型来判断，增加了尾延迟。如何在插入丰富功能的同时保持低延迟，是 AI Gateway 需要持续优化的方向。例如，通过异步管线、并行处理等手段减少顺序等待。另外，网关本身也有吞吐极限，在高并发 LLM 调用下能否横向扩展、如何进行状态同步（如各节点共享 token 计数）也是工程挑战。
  • 内容安全的复杂性：尽管 AI Gateway 提供了内容过滤，但治理 AI 内容远非易事。提示和输出的变体无穷无尽，简单的关键词拦截很容易被规避（比如用户故意拼错敏感词）。高级的内容审核模型也难免有误判漏判。一刀切地拦截又可能牺牲可用性。因此，如何拿捏过滤力度需要反复调优。这意味着运营团队需要持续关注模型行为，更新网关策略，这是项长期投入。此外，一些安全问题（如提示攻击、提示泄漏）非常复杂，网关能做的有限。攻击者可以迂回构造输入诱使模型输出机密，网关不一定拦截得住。因此，AI Gateway 的安全功能虽是必要的一道防线，但不能将所有风险都寄托于此，仍需配合模型侧的安全机制和人类监控。
  • 运维复杂度：AI Gateway 本身也是一套复杂系统，引入后给运维带来新的挑战。网关需要维护大量配置（不同模型的路由、密钥、策略等），可能随业务扩展而变得庞大，管理复杂度上升。尤其是多租户、多环境情况下，如何方便地同步和变更配置，是需要考虑的。此外，网关作为关键枢纽，一旦发生故障可能导致所有 AI 请求无法处理，故需要高可用部署（多实例负载均衡）以及良好的监控报警体系。一些团队缺乏网关运维经验，上线 AI Gateway 后可能遇到运维技能短板。为此，很多厂商提供了托管服务（如 Kong Konnect、Traefik Hub）以降低用户自行运维的负担，但在私有环境中运维压力仍需要消化。
  • 成本收益难量化：部署 AI Gateway 需要投入资源（计算、带宽和人力成本），但其带来的收益有时不直接显现。例如通过网关节省了 token 用量，但是否抵消了维护网关的开销？有些企业规模不大，直接把 AI Key 嵌入后端调用也未尝不可，引入网关可能被视为“杀鸡用牛刀”。因此，对于 AI 使用尚处摸索阶段的团队来说，投入一个 AI Gateway 是否划算，是现实的问题。如果 AI 调用规模和复杂度不高，网关的价值就不明显，甚至可能增加系统复杂性。这也提醒我们：AI Gateway 并非所有场景下都是刚需，其价值在于规模效应和复杂场景，在小规模简单应用中，轻量方案（甚至无网关）可能更实用。

概括而言，AI Gateway 目前处于快速发展期，仍有许多实际问题需要解决。值得欣慰的是，社区和厂商已经认识到这些瓶颈并着手改进。例如针对性能问题，Envoy AI Gateway 选择用高效 C++ 实现并支持流式处理，以替代那些受制于 GIL 的 Python 代理。针对生态不成熟的问题，各家也在加速开源协作以丰富功能。可以预见，随着 AI Gateway 的理念和技术逐步成熟，上述局限会逐步被克服。但在当下，用户在引入 AI Gateway 时需要充分权衡利弊，根据自身需求选择恰当的实现和策略，避免盲目跟风。

传统网关的演进：Kong、NGINX、APISIX 等的应对

面对 AI 浪潮，已有的老牌 API Gateway 项目和厂商也纷纷行动，通过升级产品或推出新功能来支持 AI 流量管理：

  • Apache APISIX（开源网关）：作为开源社区的积极参与者，APISIX 很早就意识到 AI 场景需求，并在 2023 年末至 2024 年陆续引入了AI 网关功能插件。其中核心是 ai-proxy 系列插件，它为常见的 LLM 提供商（如 OpenAI、Azure OpenAI、Anthropic、DeepSeek 等）做了适配。使用者只需在路由上启用该插件并填入提供商类型和模型等参数，APISIX 就能将请求自动转换为相应提供商 API 需要的格式并转发调用。例如上文的配置示例展示了 APISIX 配置 OpenAI 的简易方法。除了代理转发，APISIX 还通过丰富的插件体系提供内容审核（如文本审核插件） 、访问控制、缓存等能力，可以配合 ai-proxy 插件构建完整的 AI Gateway 方案。一篇社区博文将 Apache APISIX 称为“在 GenAI 浪潮前就已久经考验的网关，如今通过插件轻松变身 LLM Gateway”。可以说，APISIX 通过插件机制让现有网关原生进化出了 AI 网关特性，这种渐进增强方式降低了用户学习成本，在开源方案中备受关注。
  • Kong Gateway（商业 + 开源）：Kong 公司在 2024 年初高调宣布推出Kong AI Gateway，并开源其主要功能，以融入 Kong Gateway 3.x 版本。Kong 的方案同样基于插件扩展，例如**AI Proxy 插件、AI Request/Response Transformer 插件等。这些插件为 Kong Gateway 增加了 AI 特有能力：请求阶段可根据策略将调用代理至不同的 LLM 提供商，并统一处理各种鉴权；响应阶段则可以执行如 PII 清理、自动翻译等操作。此外 Kong 还提供Prompt 工程插件用于企业统一管理提示词，以及通过 Kong 控制台提供可视化的 AI 使用监控。值得一提的是，Kong 将这些 AI 功能与其云托管平台 Konnect 集成，用户可以在 Konnect 上开启 AI Gateway 服务，实现零代码启用多 LLM 接入和零代码的 API 响应 AI 增强。Kong 的观点是：“AI 的兴起只是 API 用例的又一次增加”，因此他们选择在现有 API 平台上扩展支持 AI，帮助企业以最小改动**拥抱 AI。目前 Kong AI Gateway 支持主流 LLM 平台，并不断加入企业关心的新特性（如针对幻觉的矫正机制、Agent 集成等）。老牌厂商 Kong 的加入，使 AI Gateway 在大型企业中的落地前景更加明朗。
  • NGINX / F5（商业）：作为老牌高性能网关，NGINX 没有缺席这一潮流。F5 公司在 2024 年推出了F5 NGINX AI Gateway解决方案。与前两者偏重功能扩展不同，F5 强调的是安全与性能底座：利用 NGINX 强大的流量处理能力，在此基础上构建针对 LLM 的流量管控模块和安全模块。F5 AI Gateway 包含一个核心代理和多个处理器 (Processor) ：核心负责基础的路由、转发和日志，Processor 则是可以独立扩展的安全/功能单元，用于扫描并修改请求或响应。例如 F5 提供了 PII 清理处理器、内容合规处理器（与外部内容安全服务对接）、甚至可以挂接自定义的 Python 脚本来处理特定领域的审查。因为很多金融和政府客户已经广泛使用 NGINX/F5 的产品，他们可以较低门槛将 AI Gateway 模块部署到原有基础设施中，添加 AI 流量的防护层。F5 的方案也凸显了一种思路：将 AI Gateway 视为安全组件，卖点在于保护 AI 调用的整个生命周期安全可控。这迎合了那些对安全合规要求极高的传统行业用户的需求。
  • Traefik（开源 + 云）：Traefik 作为新兴的云原生网关，在 2023 年底通过其托管平台 Traefik Hub 推出了AI Gateway 集成功能。Traefik 选择将 AI 支持作为其 Hub 云服务的一部分，用户在 Hub 上配置 AIService 资源并绑定到 Traefik IngressRoute 后，就拥有了一个支持多种云 AI 的平台。这种方式下，大部分复杂逻辑由 Traefik Hub 云端托管，用户只需像使用普通云服务一样调用。例如，Traefik Hub 会自动处理各大模型服务的鉴权和 URL 格式，提供统一的接入点。对于不方便使用云服务的用户，Traefik 社区也在探索在自托管 Traefik 中支持 AI 的方案。从方向上看，Traefik 主打Kubernetes 原生，未来可能通过开放其 CRD，让用户用 K8s 声明式方式定义 AI 路由和策略，就像定义 Ingress 一样简单。这会是很符合云原生用户习惯的体验。
  • 其他 API 管理平台：一些传统 API 网关/管理厂商（如 Amazon API Gateway, Google Apigee, Microsoft Azure APIM 等）目前尚未推出专门的 AI Gateway 产品，但都在积极宣传如何用现有产品来管理 AI 接口。例如 Google 发布博客详述如何借助 Apigee 实现对 ChatGPT API 的安全代理，包括使用 API Key 验证、流量配额、响应过滤等。这些方案本质上是用已有网关的常规功能去套 AI 场景，虽然缺乏 Token 级计量等高级能力，但基本的鉴权、安全、缓存都可以实现。这对于一些现有 API 网关用户来说，是一个过渡选择：在等待更成熟的 AI Gateway 之前，先用手头工具做一些防护和管理。当然，随着需求增长，这些厂商预计也会把 AI 特性纳入产品路线图——正如 Kong 所做的。一些第三方扩展也开始出现，比如有社区开发者为 Amazon API Gateway 编写了 Lambda 函数，用于计算 OpenAI 响应中的 tokens 并记录计费。传统厂商正在以各种方式适应 AI Gateway 趋势，要么升级自家产品，要么提供与专业 AI Gateway 整合的接口（如支持接入 Envoy AI Gateway 作为前端代理）。可以预见，不久的将来，“AI 流量管理”会变成几乎所有 API 网关产品的一项标配能力。

总体而言，传统 API Gateway 阵营正通过插件扩展、模块集成或产品升级等多种途径，迅速追赶 AI Gateway 这一新赛道。这既体现了市场对 AI 网关需求的迫切，也说明大家普遍认同：“AI 时代的流量问题，终归还要用网关思维去解决。 ”正因如此，我们看到开源社区和商业公司纷纷投入资源，将已有的成熟网关与 AI 特性结合，把守护 API 的丰富经验移植到 AI 应用上，为用户提供既熟悉又新颖的方案。

AI Gateway：真需求还是跟风噱头？

当一种新技术概念火热起来，人们往往会质疑：它是真有价值，还是炒作？对于 AI Gateway，这个问题也值得探讨。从我们以上的分析可以看出：

AI Gateway 解决的确是现实痛点。随着越来越多应用接入大模型服务，企业亟需一个统一的管控层来应对成本失控、权限滥用、数据安全等问题。如果没有 AI Gateway，各个开发团队可能各自为战，在应用内部实现一堆零散的鉴权、限流、日志代码，既重复劳动又不统一。而网关集中地提供这些功能，无疑能提高效率并降低风险。就像微服务催生 API Gateway 一样，大模型的普及也呼唤专门的 AI Gateway。可以说，这是一种需求驱动的产物，并非凭空杜撰的概念。事实上，不少早期用户已经自发地实现过“智能体服务”来汇总管理 LLM 调用，只是当时还没叫这个名字。现在业界将经验沉淀下来做成通用产品，顺理成章。

另一方面，不可否认市场炒作的成分也有。一些厂商可能只是简单包装了现有产品，就赶着贴上“AI Gateway”标签以追热点，功能上并无太多 AI 特性。这让用户难免困惑该如何选择。此外，当前各种 AI Gateway 良莠不齐，有的很不成熟（甚至只是概念 Demo），如果企业贸然采用反而可能踩坑。因此我们需要理性看待 AI Gateway：既看到其长远价值，也警惕过度宣传。判断它对自己的实际意义，关键在于衡量自身 AI 使用的规模和复杂度。如果你的应用只是偶尔调几个 API，完全可以先用简单方案；但如果已经面临多团队、多模型、严管控的局面，引入 AI Gateway 就是未雨绸缪的明智之举。

观点

AI 本质上是 API 的一种新用例。——Marco Palladino, Kong CTO

或许可以引用 Kong CTO Marco Palladino 的一个观点：“AI 本质上是 API 的一种新用例”。从这个角度说，AI Gateway 并不是异军突起的全新物种，而是 API 治理在 AI 时代的顺延与扩展。它并不试图取代传统网关，而更像传统网关的一套“AI 插件”或者“AI 模式”。因此，与其说 AI Gateway 是炒作，不如说AI Gateway 代表了 API 基础设施适应新需求的自然演化。随着越来越多真实场景证明 AI Gateway 的价值（例如前述企业案例节省了成本、保障了安全），这种怀疑将逐渐消散。

综上，AI Gateway 既不是空穴来风的概念炒作，也非万能灵药。它解决特定的问题，也有自身局限。对于身处 AI 转型中的企业来说，更明智的态度是：密切关注 AI Gateway 技术的演进，在适合的时机将其纳入整体架构，以获得最大收益。在实践中落地时，务必结合自身情况小步试水、逐渐深化，用数据来说话——若它真能带来安全提升和成本节省，那就不怕只是“跟风”，它就是扎扎实实的好工具。

Solo.io 的开源探索：Kagent 和 KGateway

在讨论 AI Gateway 的发展时，值得特别关注 Solo.io 公司在这一领域的开源探索。他们推出的 Kagent 和 Kgateway 项目，为 AI 时代的网关和代理机制注入了新思路。

  • Kagent（Kubernetes Agent Framework）：这是 Solo.io 于 2025 年开源的项目，被称为 “首个面向 Kubernetes 的开源 Agentic AI 框架” 。简单来说，Kagent 旨在帮助 DevOps 和平台工程师在 K8s 环境中构建和运行 AI Agent（自主代理） ，以自动化复杂的运维任务。与传统的静态脚本或告警处理不同，Agentic AI 更加智能自主，能基于环境状况自行决策多步操作。Kagent 提供了三层架构：一是各种可供 Agent 调用的 工具（Tools） ，二是具备规划和执行能力的 Agent 本体，三是让用户以声明式配置 Agent 的 框架层。举例来说，一个基于 Kagent 的“Kubernetes 运维 Agent”可以自动监测集群状态，如果发现某服务崩溃就调用工具重启它，或者在性能下降时自动扩容。此外，Kagent 还实现了对MCP（Model Context Protocol） 等标准的支持，使 Agent 可以方便地调用各种 LLM 工具。Solo.io 将 Kagent 捐赠给 CNCF，希望在开放治理下推动 agentic AI 在云原生领域的发展。Kagent 的意义在于：它让 AI 不仅能回答问题，还能直接在基础设施上“行动”起来。这与 AI Gateway 关注的范畴略有不同，但二者可形成互补：AI Gateway 管理 AI 调用流量，Kagent 则负责实际执行 AI 驱动的运维任务，未来可能通过统一的协议衔接（比如 Agent Gateway）。
  • KGateway（K8s Gateway）：简单地说，KGateway 是 Solo.io 构建的一个开源 Kubernetes 原生网关实现。它遵循 Kubernetes Gateway API 标准，底层基于 Envoy 等高性能代理，为 Kubernetes 社区提供了一个功能完善又易于扩展的网关。该项目已进入 CNCF Sandbox，以作为社区共享的网关核心组件。在 Solo.io 近期发布的 Agent Mesh 架构中，特地提到 KGateway 作为底层基础之一。实际上，Solo 之前的 Gloo Edge 网关就是在 Envoy 基础上构建的企业网关，这次他们把经验抽象为 KGateway 开源出来。一方面，KGateway 可被视为 Envoy Gateway 开源项目的一个有益补充，为 Kubernetes 用户提供更多高级功能选项；另一方面，它也是 Solo 自身产品（如 Gloo AI Gateway 和 Agent Gateway）的核心引擎：Solo 将很多新特性先在 KGateway 中实现验证，再融入商业产品。提到 Agent Gateway 正是建立在 KGateway 等开源底座之上。对于用户而言，这意味着 Solo 的商业 AI 网关/代理与你使用的开源 KGateway 在协议和架构上一脉相承，从而避免了被私有技术锁定。

Kagent 扩展了“Gateway”概念，让智能体的通信也纳入可管理范围；KGateway 则夯实了网关的基础，实现与 Kubernetes 环境的深度融合。二者相辅相成，分别代表了 AI 基础设施的两个重要方向： “管控 AI 流量” 和 “驱动 AI 行动” 。随着这两个项目在社区的发展，我们有理由相信未来会出现一个更全面的云原生 AI 平台，其中既有 AI Gateway 这样的流量中枢，也有 Kagent 这样的智能执行者，共同组成面向 AI 时代的“云原生神经系统”。

avatar
文章
阅读
粉丝