跳到主要内容

graphql-limit-count

graphql-limit-count 插件使用固定窗口算法,根据 GraphQL 查询(Queries)变更(Mutations)的深度来限制请求速率。

在 GraphQL 中,深度是指查询或变更中的嵌套层级数。以下是一个深度为 3 的查询示例:

{
a {
b {
c
}
}
}

graphql-limit-count 插件通过在给定时间间隔内限制深度的配额来进行速率限制。例如,如果将 30 秒间隔内的配额设置为 4,则允许深度为 3 的请求通过。在该 30 秒内剩余的配额为 1。如果在同一个 30 秒间隔内发送一个深度为 2 的请求,它将被拒绝。

示例

以下示例使用 GitHub GraphQL API 端点作为上游,并演示了如何在不同场景下配置 graphql-limit-count

要进行后续操作,请创建一个 GitHub 个人访问令牌(Personal Access Token),并为你想要交互的资源配置适当的权限范围。

基于远程地址进行速率限制

以下示例演示了如何通过单个变量 remote_addr 对 GraphQL 请求进行速率限制。

创建一个启用了 graphql-limit-count 插件的路由,配置为每个远程地址在 30 秒窗口内允许的深度配额为 2:

curl "http://127.0.0.1:9180/apisix/admin/routes" -X PUT \
-H "X-API-KEY: ${ADMIN_API_KEY}" \
-d '{
"id": "graphql-limit-count-route",
"uri": "/graphql",
"plugins": {
"graphql-limit-count": {
"count": 2,
"time_window": 30,
"rejected_code": 429,
"key_type": "var",
"key": "remote_addr"
}
},
"upstream": {
"type": "roundrobin",
"pass_host": "node",
"scheme": "https",
"nodes": {
"api.github.com:443": 1
}
}
}'

使用 GraphQL 查询进行验证

发送一个深度为 2 的 GraphQL 查询请求进行验证:

curl -i "http://127.0.0.1:9080/graphql" -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer ${GH_ACCESS_TOKEN}" \
-d '{"query": "query {viewer{login}}"}'

你应该会看到一个 HTTP/1.1 200 OK 响应以及相应的响应体。

该请求已消耗了时间窗口内允许的所有配额。如果你在同一个 30 秒时间间隔内再次发送请求,应该会收到一个 HTTP/1.1 429 Too Many Requests 响应,表明请求超过了配额阈值。

使用 GraphQL 变更进行验证

你也可以发送一个深度为 3 的 GraphQL 变更请求进行验证:

curl -i "http://127.0.0.1:9080/graphql" -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer ${GH_ACCESS_TOKEN}" \
-d '{"query": "mutation AddReactionToIssue {addReaction(input:{subjectId:\"MDU6SXNzdWUyMzEzOTE1NTE=\",content:HOORAY}) {reaction {content} subject {id}}}"}'

你会随时看到 HTTP/1.1 429 Too Many Requests 响应,因为深度 3 总是超过深度 2 的配额。

基于远程地址和消费者名称进行速率限制

以下示例演示了如何通过变量组合 remote_addrconsumer_name 对 GraphQL 请求进行速率限制。它允许每个远程地址和每个消费者在 30 秒窗口内的深度配额为 2。

创建一个消费者 john

curl "http://127.0.0.1:9180/apisix/admin/consumers" -X PUT \
-H "X-API-KEY: ${ADMIN_API_KEY}" \
-d '{
"username": "john"
}'

为该消费者创建 key-auth 凭证:

curl "http://127.0.0.1:9180/apisix/admin/consumers/john/credentials" -X PUT \
-H "X-API-KEY: ${ADMIN_API_KEY}" \
-d '{
"id": "cred-john-key-auth",
"plugins": {
"key-auth": {
"key": "john-key"
}
}
}'

创建第二个消费者 jane

curl "http://127.0.0.1:9180/apisix/admin/consumers" -X PUT \
-H "X-API-KEY: ${ADMIN_API_KEY}" \
-d '{
"username": "jane"
}'

为该消费者创建 key-auth 凭证:

curl "http://127.0.0.1:9180/apisix/admin/consumers/jane/credentials" -X PUT \
-H "X-API-KEY: ${ADMIN_API_KEY}" \
-d '{
"id": "cred-jane-key-auth",
"plugins": {
"key-auth": {
"key": "jane-key"
}
}
}'

创建一个启用了 key-authgraphql-limit-count 插件的路由:

curl "http://127.0.0.1:9180/apisix/admin/routes" -X PUT \
-H "X-API-KEY: ${ADMIN_API_KEY}" \
-d '{
"id": "graphql-limit-count-route",
"uri": "/graphql",
"plugins": {
"key-auth": {},
"graphql-limit-count": {
"count": 2,
"time_window": 30,
"rejected_code": 429,
"key_type": "var_combination",
"key": "$remote_addr $consumer_name"
}
},
"upstream": {
"type": "roundrobin",
"pass_host": "node",
"scheme": "https",
"nodes": {
"api.github.com:443": 1
}
}
}'

key-auth:在路由上启用密钥认证。

key_type:设置为 var_combination,以将 key 解释为变量组合。

key:设置为 $remote_addr $consumer_name,以根据远程地址和消费者应用速率限制配额。

作为消费者 jane 发送一个深度为 2 的 GraphQL 查询请求:

curl -i "http://127.0.0.1:9080/graphql" -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer ${GH_ACCESS_TOKEN}" \
-H 'apikey: jane-key' \
-d '{"query": "query {viewer{login}}"}'

你应该会看到一个 HTTP/1.1 200 OK 响应以及相应的响应体。

该请求已消耗了为该时间窗口设置的所有配额。如果你在同一个 30 秒时间间隔内作为消费者 jane 发送相同的请求,应该会收到一个 HTTP/1.1 429 Too Many Requests 响应,表明请求超过了配额阈值。

在同一个 30 秒时间间隔内作为消费者 john 发送相同的请求:

curl -i "http://127.0.0.1:9080/graphql" -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer ${GH_ACCESS_TOKEN}" \
-H 'apikey: john-key' \
-d '{"query": "query {viewer{login}}"}'

你应该会看到一个 HTTP/1.1 200 OK 响应以及相应的响应体,表明该请求没有被速率限制。

在同一个 30 秒时间间隔内再次作为消费者 john 发送相同的请求,你应该会收到一个 HTTP/1.1 429 Too Many Requests 响应。

这验证了插件是根据变量组合 remote_addrconsumer_name 进行速率限制的。

在路由间共享配额

以下示例演示了如何通过配置 graphql-limit-count 插件的 group 字段,在多个路由之间共享 GraphQL 速率限制配额。

请注意,同一 groupgraphql-limit-count 插件配置应完全相同。为了避免更新异常和重复配置,你可以创建一个启用了 graphql-limit-count 插件的服务(Service)供路由连接。

创建一个服务:

curl "http://127.0.0.1:9180/apisix/admin/services" -X PUT \
-H "X-API-KEY: ${ADMIN_API_KEY}" \
-d '{
"id": "graphql-limit-count-service",
"plugins": {
"graphql-limit-count": {
"count": 2,
"time_window": 30,
"rejected_code": 429,
"group": "srv1"
}
},
"upstream": {
"type": "roundrobin",
"pass_host": "node",
"scheme": "https",
"nodes": {
"api.github.com:443": 1
}
}
}'

创建两个路由并将它们的 service_id 配置为 graphql-limit-count-service,以便它们共享相同的插件和上游配置:

curl "http://127.0.0.1:9180/apisix/admin/routes" -X PUT \
-H "X-API-KEY: ${ADMIN_API_KEY}" \
-d '{
"id": "graphql-limit-count-route-1",
"service_id": "graphql-limit-count-service",
"uri": "/graphql1",
"plugins": {
"proxy-rewrite": {
"uri": "/graphql"
}
}
}'
curl "http://127.0.0.1:9180/apisix/admin/routes" -X PUT \
-H "X-API-KEY: ${ADMIN_API_KEY}" \
-d '{
"id": "graphql-limit-count-route-2",
"service_id": "graphql-limit-count-service",
"uri": "/graphql2",
"plugins": {
"proxy-rewrite": {
"uri": "/graphql"
}
}
}'
备注

proxy-rewrite 插件用于将 URI 重写为 /graphql,以便请求转发到正确的端点。

发送一个深度为 2 的 GraphQL 查询请求到路由 /graphql1

curl -i "http://127.0.0.1:9080/graphql1" -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer ${GH_ACCESS_TOKEN}" \
-d '{"query": "query {viewer{login}}"}'

你应该会看到一个 HTTP/1.1 200 OK 响应以及相应的响应体。

在同一个 30 秒时间间隔内发送相同的深度为 2 的查询到路由 /graphql2

curl -i "http://127.0.0.1:9080/graphql2" -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer ${GH_ACCESS_TOKEN}" \
-d '{"query": "query {viewer{login}}"}'

你应该会收到一个 HTTP/1.1 429 Too Many Requests 响应,这验证了两个路由共享相同的速率限制配额。

使用 Redis 服务器在网关节点间共享配额

以下示例演示了如何通过 Redis 服务器在多个网关节点之间对 GraphQL 请求进行速率限制,从而使不同的网关节点共享相同的速率限制配额。

在网关组中创建一个具有以下配置的路由:

curl "http://127.0.0.1:9180/apisix/admin/routes" -X PUT \
-H "X-API-KEY: ${ADMIN_API_KEY}" \
-d '{
"id": "graphql-limit-count-route",
"uri": "/graphql",
"plugins": {
"graphql-limit-count": {
"count": 2,
"time_window": 30,
"rejected_code": 429,
"key": "remote_addr",
"policy": "redis",
"redis_host": "192.168.xxx.xxx",
"redis_port": 6379,
"redis_password": "p@ssw0rd",
"redis_database": 1
}
},
"upstream": {
"type": "roundrobin",
"pass_host": "node",
"scheme": "https",
"nodes": {
"api.github.com:443": 1
}
}
}'

policy:设置为 redis 以使用 Redis 实例进行速率限制。

redis_host:设置为 Redis 实例的 IP 地址。

redis_port:设置为 Redis 实例的监听端口。

redis_password:如果有,设置为 Redis 实例的密码。

redis_database:设置为 Redis 实例中的数据库编号。

发送一个深度为 2 的 GraphQL 查询请求到一个网关实例:

curl -i "http://127.0.0.1:9080/graphql" -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer ${GH_ACCESS_TOKEN}" \
-d '{"query": "query {viewer{login}}"}'

你应该会看到一个 HTTP/1.1 200 OK 响应以及相应的响应体。

在同一个 30 秒时间间隔内发送相同的请求到另一个网关实例,你应该会收到一个 HTTP/1.1 429 Too Many Requests 响应,验证了配置在不同网关节点上的路由共享相同的配额。

使用 Redis 集群在网关节点间共享配额

你也可以使用 Redis 集群在多个网关节点之间应用相同的配额,从而使不同的网关节点共享相同的速率限制配额。

确保你的 Redis 实例运行在集群模式(Cluster Mode)graphql-limit-count 插件配置至少需要两个节点。

在网关组中创建一个具有以下配置的路由:

curl "http://127.0.0.1:9180/apisix/admin/routes" -X PUT \
-H "X-API-KEY: ${ADMIN_API_KEY}" \
-d '{
"id": "graphql-limit-count-route",
"uri": "/graphql",
"plugins": {
"graphql-limit-count": {
"count": 2,
"time_window": 30,
"rejected_code": 429,
"key": "remote_addr",
"policy": "redis-cluster",
"redis_cluster_nodes": [
"192.168.xxx.xxx:6379",
"192.168.xxx.xxx:16379"
],
"redis_password": "p@ssw0rd",
"redis_cluster_name": "redis-cluster-1",
"redis_cluster_ssl": true
}
},
"upstream": {
"type": "roundrobin",
"pass_host": "node",
"scheme": "https",
"nodes": {
"api.github.com:443": 1
}
}
}'

policy:设置为 redis-cluster 以使用 Redis 集群进行速率限制。

redis_cluster_nodes:设置为 Redis 集群中的 Redis 节点地址。

redis_password:如果有,设置为 Redis 集群的密码。

redis_cluster_name:设置为 Redis 集群名称。

redis_cluster_ssl:启用与 Redis 集群的 SSL/TLS 通信。

发送一个深度为 2 的 GraphQL 查询请求到一个网关实例:

curl -i "http://127.0.0.1:9080/graphql" -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer ${GH_ACCESS_TOKEN}" \
-d '{"query": "query {viewer{login}}"}'

你应该会看到一个 HTTP/1.1 200 OK 响应以及相应的响应体。

在同一个 30 秒时间间隔内发送相同的请求到另一个网关实例,你应该会收到一个 HTTP/1.1 429 Too Many Requests 响应,验证了配置在不同网关节点上的路由共享相同的配额。