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_addr 和 consumer_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-auth 和 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": {
"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_addr 和 consumer_name 进行速率限制的。
在路由间共享配额
以下示例演示了如何通过配置 graphql-limit-count 插件的 group 字段,在多个路由之间共享 GraphQL 速率限制配额。
请注意,同一 group 的 graphql-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 响应,验证了配置在不同网关节点上的路由共享相同的配额。