关于graphql:GraphQL-碰撞-Apache-APISIX提升-API-领域的安全与性能

本文介绍了 Apache APISIX 和 GraphQL 的个性，以及如何应用 API 网关 Apache APISIX 代理 GraphQL 申请，并提出解决理论场景痛点的计划。

GraphQL 是一个开源的、面向 API 而发明进去的数据查问操作语言以及相应的运行环境。最后由 Facebook 于 2012 年外部开发，2015 年公开公布。2018 年 11 月 7 日，Facebook 将 GraphQL 我的项目转移到新成立的 GraphQL 基金会。

您能够把 GraphQL 类比为 SQL 查问语句来了解，与 SQL 查问语句相比，GraphQL 对 API 中的数据提供了一套易于了解的残缺形容，让客户端可能通过自定义的形容来精确取得其所须要的数据。这也让 API 可能从容面对日益简单的接口倒退，并防止最终成为一个令人望而却步的简单接口。

Apache APISIX 作为云原生网关，在设计之初就曾经具备辨认 GraphQL 语法的匹配能力。通过对申请中携带的 GraphQL 语句进行高效匹配，筛除异样流量，进一步保障安全性和进步零碎性能。

咱们正处于大数据大流量的时代，Apache APISIX 和 GraphQL 能够通过联合的形式，造成共赢的场面。接下来举一个场景具体阐明。

本文将会探讨微服务架构场景下的 Apache APISIX 和 GraphQL 的理论利用。

在我的项目进行到前期时，往往会呈现业务复杂化、团队人员流动性低等问题，而微服务架构曾经成为解决这类问题的常见解决方案。在微服务架构中，GraphQL 暴露出的接口分为分散式和集中式两种，然而只有集中式接口设计才可能最大化体现 GraphQL 的劣势，然而在集中式接口设计中，所有的微服务对外裸露的是同一个接口，因而解决流量的路由就不能简略地依据 URL 进行转发，而是应该依据申请中蕴含的不同字段进行转发。

因为 NGINX 解决申请时仅会解决 URL 以及一些参数，然而只有解析申请参数中的查问信息才能够晓得客户端拜访的资源，从而进行路由转发，因而这种路由转发形式通过传统的 NGINX 是无奈实现的。在理论利用场景中，将 GraphQL 接口间接对外裸露十分危险，因而须要一个业余的高性能 API 网关爱护 GraphQL 的接口。

基于 Apache APISIX 平安、稳固、高性能的个性，减少 GraphQL 灵便的路由匹配规定是解决 GraphQL 集中式接口设计问题的最佳计划。

不反对在 Docs 外粘贴 block

在此计划中，Apache APISIX 作为 API 网关部署在 GraphQL Server 之前，为整个后端系统提供了平安保障，并且 Apache APISIX 依据本身所具备的 GraphQL 匹配性能，筛选一部分申请之后再由 GraphQL Server 进行解决，使整个申请资源过程变得更高效。

得益于 Apache APISIX 的动静个性，您能够启用限流限速、身份认证、可观测性等插件，无需重启服务，进一步提高此计划的运行效率，不便运维工作。

此外，Apache APISIX 还能够针对不同的 graphql_operation 进行不同的权限校验、针对不同的 graphql_name 转发到不同的 Upstream，具体细节将会在下文中进行形容。

综上所述 ，Apache APISIX + GraphQL 的 解决计划，在充分利用 GraphQL 搜寻劣势的同时 也能领有 Apache APISIX 作为 API 网关所具备的平安 性和 稳定性。

不反对在 Docs 外粘贴 block

目前 GraphQL 在 Apache APISIX 中的执行逻辑如下：

Clients 向 Apache APISIX 发动带有 GraphQL 语句的申请；
Apache APISIX 匹配路由并提取预设的 GraphQL 数据；
Apache APISIX 通过预设 GraphQL 数据对申请数据进行匹配；
1. 匹配胜利，Apache APISIX 将持续转发申请；
2. 匹配失败，Apache APISIX 将立即终止申请。
是否存在插件；
1. 如果存在插件，申请将持续被插件解决，解决实现后，持续转发到 GraphQL Server；
2. 如果不存在插件，申请将间接转发到 GraphQL Server。

在 APISIX core 里外部匹配中，Apache APISIX 通过 graphql-lua 库实现对 GraphQL 的反对。Apache APISIX GraphQL 解析库会先对携带 GraphQL 语法的申请进行解析，之后将解析后的申请与预设在 Apache APISIX 数据库里的配置数据进行匹配。如果匹配胜利 Apache APISIX 会放行并转发申请，反之则终止申请。

Apache APISIX 目前反对通过 GraphQL 的一些属性过滤路由：

graphql_operation
graphql_name
graphql_root_fields

GraphQL 的属性与上面的所展现 GraphQL query 语句一一对应：

query getRepo {
    owner {name}
    repo {created}
}

graphql_operation 对应 query
graphql_name 对应 getRepo
graphql_root_fields 对应 ["owner", "repo"]

您能够通过如下示例为 Apache APISIX 设置一条路由来验证对 GraphQL 的匹配能力：

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '{"methods": ["POST"],"uri":"/_graphql","vars": [["graphql_operation", "==", "query"],
        ["graphql_name", "==", "getRepo"],
        ["graphql_root_fields", "has", "owner"]
    ],
    "upstream": {
        "type": "roundrobin",
        "nodes": {"192.168.1.200:4000": 1}
    }
}'

接下来应用带有 GraphQL 语句的申请去拜访：

curl -H 'content-type: application/graphql' -X POST http://127.0.0.1:9080/graphql -d '
query getRepo {
    owner {name}
    repo {created}
}'

如果匹配胜利，则 Apache APISIX 持续进行申请转发。

HTTP/1.1 200 OK

反之，则终止申请。

HTTP/1.1 404 Not Found

Apache APISIX 能够依据不同的 graphql_name 转发到不同的 Upstream，以及依据不同 graphql_operation 进行不同的权限校验。下文将为您展现此个性的代码配置。

应用 `graphql_name` 匹配 Upstream

创立第一个上游服务：

curl http://192.168.1.200:9080/apisix/admin/upstreams/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"type":"chash","key":"remote_addr","nodes": {"192.168.1.200:1980": 1}
}'

创立与第一个上游服务绑定的 GraphQL 路由，graphql_name 设置为 getRepo111：

curl http://192.168.1.200:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '{"methods": ["POST"],"uri":"/graphql","vars": [["graphql_operation", "==", "query"],
        ["graphql_name", "==", "getRepo111"],
        ["graphql_root_fields", "has", "owner"]
    ],    
    "upstream_id": "1"
}'

创立第二个上游服务：

curl http://192.168.1.200:9080/apisix/admin/upstreams/2 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"type":"chash","key":"remote_addr","nodes": {"192.168.1.200:1981": 1}
}'

创立与第二个上游服务绑定的 GraphQL 路由，graphql_name 设置为 getRepo222：

curl http://192.168.1.200:9080/apisix/admin/routes/2 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '{"methods": ["POST"],"uri":"/graphql","vars": [["graphql_operation", "==", "query"],
        ["graphql_name", "==", "getRepo222"],
        ["graphql_root_fields", "has", "owner"]
    ],
    "upstream_id": 2
}'

测试示例

应用之前所创立的两个 graphql_name 服务进行测试，您能够发现 Apache APISIX 能够依据申请中不同的 graphql_name 主动抉择转发的 Upstream。

如果申请是此示例：

curl -i -H 'content-type: application/graphql' -X POST http://192.168.1.200:9080/graphql -d '
query getRepo111 {
    owner {name}
    repo {created}
}'

则会返回来自上游 192.168.1.200:1980 的响应：

HTTP/1.1 200 OK
---URI
/graphql
---Service Node
Centos-port: 1980

如果申请是这个示例：

curl -i -H 'content-type: application/graphql' -X POST http://192.168.1.200:9080/graphql -d '
query getRepo222 {
    owner {name}
    repo {created}
}'

则会返回来自上游 192.168.1.200:1981 的响应：

HTTP/1.1 200 OK
---URI
/graphql
---Service Node
Centos-port: 1981

应用 `graphql_operation` 进行不同的权限校验

上述示例提供了 graphql_operation 为 query 的匹配规定，当初应用 mutation 模式的 GraphQL 申请。

配置 Apache APISIX：

curl http://192.168.1.200:9080/apisix/admin/routes/11 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"methods": ["POST"],"uri":"/hello","vars": [["graphql_operation", "==", "mutation"],
        ["graphql_name", "==", "repo"]
    ],
    "upstream": {
        "nodes": {"192.168.1.200:1982": 1},
        "type": "roundrobin"
    }
}'

发动 mutation 申请用来验证 Apache APISIX 的配置：

curl -i -H 'content-type: application/graphql' -X POST http://192.168.1.200:9080/hello -d '
mutation repo($ep: Episode!, $review: ReviewInput!) {createReview(episode: $ep, review: $review) {
    stars
    commentary
  }
}'

返回后果如下所示：

HTTP/1.1 200 OK
---URI
/hello
---Service Node
Centos-port: 1982

Apache APISIX 领有丰盛的插件生态以利用不同的应用场景，如果在应用 Apache APISIX + GraphQL 时增加适宜的插件，就能够使计划利用的场景变得更多。

本文仅选取了以下两种类型的插件进行举例。

`limit-count` 速度插件

搭配应用 limit-count 插件，流量通过 GraphQL 匹配规定失去转发之后进一步被限度。得益于 Apache APISIX 的个性，能够达到动静、精细化、分布式的限流限速。详情请参考 Apache APISIX 官网文档。

Apache APISIX 提供了包含但不仅限于 prometheus、skywalking 等可观测性插件，可能为零碎提供更多监控指标数据，不便零碎后续的经营保护等实现。

本文为大家初步介绍了 GraphQL 在 Apache APISIX 中的利用，并且应用理论代码，为您展现了 Apache APISIX 与 GraphQL 两项技术的联合，用户能够依据本身的业务需要和理论场景在 Apache APISIX 中应用 GraphQL。

对于 GraphQL 的更多阐明和残缺配置信息，可参考官网文档。

Apache APISIX 我的项目目前正在开发其余插件以反对集成更多服务，如果您对此有趣味，您能够通过 GitHub Discussions 发动探讨，或通过邮件列表进行交换。

关于graphql:GraphQL-碰撞-Apache-APISIX提升-API-领域的安全与性能

背景信息

场景解析

理论场景中遇到的问题

解决方案

GraphQL 在 Apache APISIX 中的利用

根本逻辑

具体配置

进阶操作

应用 `graphql_name` 匹配 Upstream

应用 `graphql_operation` 进行不同的权限校验

搭配插件

`limit-count` 速度插件

可观测性插件

总结

背景信息

场景解析

理论场景中遇到的问题

解决方案

GraphQL 在 Apache APISIX 中的利用

根本逻辑

具体配置

进阶操作

应用 graphql_name 匹配 Upstream

应用 graphql_operation 进行不同的权限校验

搭配插件

limit-count 速度插件

可观测性插件

总结

应用 `graphql_name` 匹配 Upstream

应用 `graphql_operation` 进行不同的权限校验

`limit-count` 速度插件